Are Security Groups really associated with instances?
What do you think? If yes, then that’s what I thought until I saw something while reading the AWS Certified Solutions Architect Study Guide.
It’s very common to say that Security Groups are associated with instances and Network Access Control Lists (NACLs) are associated with subnets, and that’s the most basic difference between both of them. But to be more precise, what I found is that security groups are associated with ENIs, not directly to the instances.
Those who don’t know what are security groups are, then let me help you to make them familiar with you.
A security group functions as a firewall that controls traffic to and from an instance by permitting traffic to ingress or egress that instance’s ENI.*
*source: AWS Certified Solutions Architect Study Guide
It says instance’s ENI, so what’s basically an ENI? Have you heard of Network Interface Cards? I hope you know the functioning of those cards, if not then it’s not a big deal just continue to read. The NICs that we know, in AWS cloud architecture they are called Elastic Network Interfaces (ENIs). The Elastic Network Interface gives the instances an ability to carry out communication with other network resources. These network resources can be AWS services, other instances, your on-premises servers, and the world wide web.
An instance can have multiple ENIs but there’s always a primary network interface present which is also known as primary ENI.
And do you know why can’t you launch an instance without specifying a subnet with it?
The reason is that the primary ENI of an instance is connected to only one subnet and you can’t just detach or remove the primary ENI from an instance. That’s why it becomes necessary to specify a subnet during the launch.
And there are more amazing facts about ENIs. Like an ENI doesn’t always need to be attached to an instance, it can exist independently! And since ENIs are independent, they can be created separately in a subnet and then later can be attached to an instance as a primary or secondary. You can also preserve the ENIs upon the deletion or termination of the instances.
Consider the ENI like a CUG Number in your organization. Let’s suppose, there’s a new recruit in your department and he has been given a CUG Number which was being used by the person who has now transferred to a different country. Now he has two sim cards in his mobile phone — one for his personal usage to talk to the people outside of the organization and the CUG number for the official use. Consider the CUG number as the primary ENI, if he has to call someone within the organization he’ll use that but it doesn’t restrict him to not to make any calls outside. And he decides to leave in future he’d have to submit that CUG Sim back to the organization.
I hope the concept is now clearer to you. In practice, most of the instances have only one ENI and that’s the reason why people think that security groups are associated with instances and forgets about ENIs. I can guess what you are thinking. What if an instance has more than one ENIs? Yes, it happens, and it’s not necessary for all the ENIs of an instance to be associated with only one security group, instead, they can be linked to different ones.
That’s all for today! I hope you liked the article. If you found any mistake please feel free to reach out to me, I’d be glad! There’s one thing that I’d like to add that don’t let your curiosity die, keep asking questions to yourself, to your mentors, to google and you’ll end with vivid concepts and a great deal of knowledge!
Stay Safe, Stay Secure!
References:
* aws.amazon.com (Image)
* Certified Solutions Architect Exam Guide (Concepts)
Top comments (0)