A Backend Developer's Guide to AWS VPC Works

As a backend developer, I've always been intrigued by the seamless integration of code and infrastructure. Today, I want to share a step-by-step working process of AWS Virtual Private Cloud (VPC), a powerful tool that has transformed how we manage and scale applications in the cloud.

When a user makes a request to access a service or application hosted in AWS, a series of events take place behind the scenes to process that request and send the appropriate respons.

1. User Request

A user initiates a request by accessing a domain, such as example.com. This request is then routed to your AWS environment, triggering the subsequent steps in the process.

2. Request Hits the Internet Gateway

The request travels across the internet and reaches the Internet Gateway (IGW) attached to your Virtual Private Cloud (VPC). The IGW acts as the entry point for internet traffic into your VPC.

• The request (e.g., example.com) reaches the public IP of your VPC.
• The IGW forwards the request to the Load Balancer.

3. Load Balancer (Application Load Balancer)

Once the request reaches the Load Balancer (such as an Application Load Balancer or ALB), it performs traffic management based on predefined listener rules.

• Request Group: Defines rules for handling various types of requests. For instance, a request for example.com/api might be routed differently than one for example.com/login.
• Target Group: After processing the request, the Load Balancer directs it to a Target Group. This group contains EC2 instances or other services that handle the incoming traffic.

The Load Balancer can distribute traffic to resources located in both:

• Public Subnets (internet-facing)
• Private Subnets (internal resources like databases or application servers)

4. Routing Traffic via Route Table

After reaching the Load Balancer, the request continues to its final destination based on the rules in the Route Table.

• The Route Table defines how traffic flows between subnets and resources within the VPC.
• If traffic needs to move between subnets (e.g., from a public subnet to a private subnet), the Route Table ensures smooth routing.
• For cross-VPC traffic, options like VPC Peering or a Transit Gateway are used to route traffic.

5. Security Groups and Network ACLs (Access Control)

To ensure secure communication, Security Groups and Network ACLs are used.

• Security Groups: Act as firewalls for your EC2 instances and other resources in the VPC, ensuring that only authorized traffic can access specific resources. For instance, an EC2 instance may only accept traffic on ports 80 (HTTP) and 443 (HTTPS), while blocking other ports.
• Network ACLs: Provide an additional layer of security by controlling inbound and outbound traffic at the subnet level.

6. Application in Private Subnet (If Applicable)

If the application resides in a private subnet, the traffic is forwarded via Route Tables. However, private subnets typically do not have direct internet access.

• Direct access is only possible through a NAT Gateway or a VPC Endpoint.

7. NAT Gateway for Internet Access from Private Subnet

For instances in a private subnet that need internet access (e.g., to download updates), traffic is routed through a NAT Gateway or NAT Instance located in a public subnet.

• The NAT Gateway ensures that private resources can initiate outbound internet connections while keeping their private IP addresses hidden.
• It also replaces the private IP address of the EC2 instance with a public IP for external communication.

8. Request Completion

Once the application processes the request, the response is sent back through the same path:

• The Load Balancer forwards the response back to the user.
• The flow continues until the response reaches the user’s browser, completing the request.