A security group is a virtual firewall to control ingress and egress traffic at the instance level for all instances in your VPC. Each VPC has its own default security group. When you launch an instance without assigning a security group, AWS will assign a default security group of VPC with this instance. Each instance can be assigned up to five security groups.

For a security group, in order to control ingress and egress traffic, we need to define rules for a security group. These rules need to be defined separately for controlling ingress and egress traffic. These rules are only permissive; that is, there can only be allow rules and there can't be deny rules.

When you create a new security group, by default, it does not allow any inbound traffic. You have to create a rule that allows inbound traffic. By default, a security group has a rule that allows all outbound traffic. Security groups are stateless, so if you create a rule for inbound traffic that allows traffic to flow in, this rule will allow outbound traffic as well; there is no need to create a separate rule to allow outbound traffic. These rules are editable and are applied immediately. You can add, modify, or delete a security group, and these changes are effective immediately as well. You can perform these actions from the AWS console or through the command line or an API.

An ENI can be associated with up to five security groups, while a security group can be associated with multiple instances. However, these instances cannot communicate with each other unless you configure rules in your security group to allow this. There is one exception to this behavior: the default security group already has these rules configured.

The following figure shows the security groups set up in my AWS account. This security group is created for the web server, so it has rules configured in order to allow HTTP and HTTPS traffic. It also allows SSH access on port 22 for logging into this instance:

Figure 9: AWS VPC security groups

The network access control list (NACL), as it is popularly known, is another virtual firewall provided by AWS VPC to configure inbound and outbound traffic for your subnets inside a VPC. So, all instances within this subnet are going to use the same configuration for inbound and outbound traffic. NACLs are used for creating guardrails in an organization for your network on the cloud as it does not offer granular control. Moreover, NACLs are usually configured by system administrators in an organization.

Every VPC has a default NACL that allows all inbound and outbound traffic by default. When you create a custom NACL, it denies all inbound and outbound traffic by default. Any subnet that is not explicitly associated with an NACL is associated with a default NACL and allows all traffic, so make sure all subnets in your VPCs are explicitly associated with an NACL.

NACL uses rules similar to security groups to configure inbound and outbound traffic for a subnet. Unlike security groups, NACL gives you the option to create allow and deny rules. NACL is stateless and you will need to create separate rules for inbound and outbound traffic.

Each subnet in your VPC can be attached to only one NACL. However, one NACL can be attached to more than one subnet. Rules in NACL are evaluated from the lower to the higher number, and the highest number you can have is 32776. AWS recommends that you create rules in multiples of 100, such as 100, 200, 300, and so on, so you have room to add more rules when required.

The following figure shows network ACL for a public subnet. It allows inbound and outbound HTTP and HTTPS traffic. This NACL can be used for all public subnets that will contain all instances that need to access the internet and those that are publicly accessible:

Figure 10: AWS VPC NACL

VPC facilitates the flow of inbound and outbound traffic for all resources in your VPC. It is important to monitor the flow of this IP traffic on a continuous basis in order to ensure that all traffic is going to the desired recipient and is received from expected resources. This feature is also useful for troubleshooting issues related to traffic not reaching its destination or vice versa. The VPC flow log is a very important security tool that helps monitor the security of your network in the AWS cloud.

You can create a flow log for your VPC as well as a subnet and a network interface based on your requirement. For a VPC flow log, all resources in VPC are monitored. For a subnet flow log, all resources in a subnet are monitored. This can take up to 15 minutes to collect data after you have created a flow log.

Each network interface has a unique log stream that is published to a log group in AWS CloudWatch logs. You can create multiple flow logs publishing data to one log. These logs streams consist of flow log records that are essentially log events with fields describing all the traffic for that resource. Log streams contain flow log records, which are log events consisting of fields that describe the traffic, such as the accepted traffic or rejected traffic for that network interface.

You can configure the type of traffic you want to monitor, including accepted, rejected, or all traffic for the flow log you create. You give this log a name in CloudWatch logs, where it will be published, and choose a resource you want to monitor. You will also need the Amazon Resource Name (ARN) of an IAM role that will be used to publish this flow log to CloudWatch logs group. These flow logs are not real-time log streams.

You can also create flow logs for network interfaces created by other AWS services, such as AWS RDS, AWS workspaces, and so on. However, these services cannot create flow logs; instead, you should use AWS EC2 to create flow logs, either from the AWS console or through the EC2 API. VPC flow logs are offered free of charge; you are charged only for logs. You can delete a flow log if you no longer need it. It might take several minutes before this deleted flow log stops collecting data for your network interface.

VPC flow logs have certain limitations. You cannot create VPC flow logs for peered VPCs that are not in your AWS account. VPC flow logs can't be tagged. A flow log cannot be modified after it is created; you need to delete this flow log and create another one with the required configuration. Flow logs do not capture all types of traffic, such as traffic generated by instances when they contact Amazon DNS servers, traffic to and from 169.254.169.254 for getting instance metadata, and so on.

As discussed in IAM, all AWS services require permission to access their resources. It is imperative to define access control for VPC as well. You need to grant appropriate permissions to all users, applications, and AWS services to access all VPC resources. You can define granular, resource-level permissions for VPC, which allows you to control what resources could be accessed or modified in your VPC.

You can give permissions such as managing a VPC, a read-only permission for VPC, or managing a specific resource for VPC, such as a security group or a network ACL.