Today while I was struggling with getting an EC2 instance to be able to communicate with an RDS Aurora cluster, my coworker Craig Andera taught me a something very useful about AWS Security Groups.

They can be thought of as two things:

1. An identity
2. A container for rules.

This first aspect was completely missing from my mental model.

In my mind, and through AWS, I was attempting to create the following.

EC2 Instance <--- The Security Group --->  DB Cluster

Where The Security Group was simply a set of rules, a mapping of ports. The in/outbound 5432 ports open, and yet it wasn't working. And this is of course where the missing element of identity came into play. I wasn't specifying who was allowed to connect on those ports only how they were allowed to connect.

The answer was to create an additional SG for just the EC2 machine and then use this to specify both who, and how the machine would connect to the DB Cluster.

With this I have created a new mental model.

EC2 Instance (as SG-1234)
   ^
   |
   \
    -> DB Cluster (allowing: SG-1234 on port 5432)

I now understand that I need to specify who is connecting and not just how.