SG’s are VPC-specific, not subnet-specific. The diagram needs to be updated to reflect this. Having the SG’s inside the subnet might lead some to think SG’s are tied to a subnet.
8 Answers
Hi there,
Thanks for pointing this out. I have passed this on to ACG content team for review.
No the diagram is correct, the SG’s are at the instance level.
You have a point when it comes to "unattached" SGs, however when SG is attached to an instance it sits at the instance level. Assuming the SG is attached, the diagram would be correct from the perspective of traffic flow.
Check how AWS shows SGs https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/
SGs are attached to ENIs, not instances or subnets directly. Be aware if dual-homing.
Attached to the interface, but not necessarily and ENI. But you are spot on about being aware of the impact of the rules if you have one NIC/port being used for multiple networks.
The diagram is correct. The SG presentation should be tied to network interface which indirectly should surround the Ec2 instance diagramatically. NACL surrounds the subnet.
All of you are correct that when assigning an SG to an EC2 instance that the SG is connected to the ENI. My point here is not at the physical level since the diagram is not physical. My original point was from a logical viewpoint the diagram shows the route tables and NACLs in the VPC (not in the subnet — which is of course the correct way to show it). The SG should also be outside of the subnet to show that SGs are not tied to a specific subnet. In the diagram, the same SG could be assigned to both EC2 instances. In that case the SG would need to be shown outside the subnet, or noted in the diagram that both pictures denote they are the same SG.
I agree with you Lecube.
I think that the key to understanding SGs is how you visualize and draw it. If you consider the network hierarchically, the SG is not a subdivision of an AZ or subnet. It is an independent object in a VPC that can be referenced by a resource. I tend to visualize the VPC / AZ / subnets as a vertical hierarchical stack, and the SG as being service that cuts across them.
For those struggling with SGs, I think it also helps if you are clear in your mind what an SG is. It is a list of rules that is applied to the port or NIC of an instance or service to tell the service what traffic you want to allow in and out. It is not like a VLAN or magical network control. It is just a list of rules. The subnet that the NIC opr port is on is pretty much irrelevant. Visualize a mini firewall at the NIC and the SG is the set of rules that it applies. (That is not how it is done physically, but it will help you understand it better)
This visualization also allows you to understand that the SG can be used for resource grouping instead of creating lists of subnets. This comes in handy when you have large load balanced groups that are across multiple AZs and Subnets.
I am going to escalate his and see if we can create a better visualization.
Thanks Lecube
Rusty
Moderator & Coach
Adrien, you must have not understood my point. While SGs are attached to instances, or services (e.g., EC2, RDS, ELBs), my point was that SG’s are assigned to a VPC and are then available to attach to instances or services within that VPC. The diagram makes it look like the SGs are tied to a subnet and not available to instances or services in the other subnet. That is not correct. SGs are available to assign to instances and services in all subnets of a VPC.