All you need to know about Networking in AWS VPC - Part 1

In the last blogs, we have gone through basics of AWS VPC. Today lets cover in detail about some more topics related to VPC.

Each region in your account has a default VPC. The default CIDR range is 172.32.0.0/16. When we create a VPC-based resource (EC2, RDS, Load Balancer, etc.) without specifying a custom VPC, it will be placed in the default VPC for that region. This includes a default subnet, internet gateway, main route table connecting the default subnet to the internet gateway, default security group, and default NACL. It is configurable like other VPCs, and we can add more subnets.

Default subnets in default VPCs:

Default subnets are created within each availability zone for each default VPC. These are public subnets with a CIDR block of /20 (4096 IPs). If you need to convert a public subnet into a private one, you should remove its route to the internet gateway. When a new Availability Zone is added to a region, your default VPC in that region will get a subnet in the new Availability Zone (unless you have made changes to the VPC).

Use Default VPCs and their subnets only for experimenting in your AWS account. Default VPCs are a quick start solution. They provide an easy way to test launching instances of your VPC-based resources without having to set up a new VPC.

For real-world applications, create your own VPCs and subnets. This gives you better control and understanding of their configurations. If a default VPC is accidentally deleted, it can be restored.

Route tables:

Route tables determine where network traffic is routed. There are both default and custom route tables. All route tables include a local route entry, which cannot be deleted. Each subnet has only one route table. It is best practice to use custom route tables for each subnet.

Security Groups:

Security Groups act as virtual firewalls, controlling inbound and outbound traffic for one or more instances. They deny all incoming traffic by default and use allow rules that filter based on network protocols (TCP, UDP, and ICMP). Security groups are stateful. That means, If an inbound request is allowed, the outbound request is automatically allowed. We can use security groups to control traffic into, out of, and between resources.

By default, all newly created security groups allow all outbound traffic to all destinations. Modifying the default outbound rule on security groups increases complexity and is not recommended unless required for compliance. Most organizations create security groups with inbound rules for each functional tier (web/app/database) within an application.

Network ACL:

A network ACL (NACL) is a virtual firewall that controls traffic in and out of a subnet. We need to use inbound and outbound rule definitions to allow or deny traffic. They are stateless, meaning an allow rule must be explicitly created. Stateless rules inspect all inbound and outbound traffic and do not keep track of connections.

Internet Gateways:

Internet gateways enable communication between the internet and your VPC. They are horizontally scaled, redundant, and highly available by default. They serve as a target in your subnet route tables for internet-routable traffic.

To enable internet access for instances in a VPC subnet, follow these steps:

1. Attach an internet gateway to your VPC.

2. Ensure your subnet's route table points to the internet gateway.

3. Make sure instances in your subnet have public IP addresses or elastic IP addresses.

4. Confirm that your NACLs and security groups allow the necessary traffic to and from your instances.

Network Address Translation Services:

Network Address Translation (NAT) services allow instances in the private subnet to start outbound traffic to the internet or other AWS services. They prevent private instances from receiving inbound traffic from the internet.

There are 2 primary options to setup the NAT:

1. Amazon EC2 instance setup as a NAT in a public subnet.

2. NAT gateway

Lets compare NAT instance and NAT gateway.

VPC Flow logs:

VPC Flow logs capture flow details in your VPC. They show accepted and rejected traffic. You can enable them for VPCs, subnets, and ENIs. The logs are published to CloudWatch Logs.

Some use cases for VPC flow logs are:

1. Troubleshooting connectivity issues.

2. Testing network access rules.

3. Monitoring traffic.

4. Detecting and investigating security incidents.