Internet Gateway serves as a bridge between the internet and our VPC, enabling instances within our VPC to directly send and receive traffic from the internet.

However, instead of direct access to the internet, API Gateway can be used as an intermediary, together with a VPC link, to securely connect it to your VPC.

A common architectural design is to expose the public facing EC2 instance to the internet directly via Internet Gateway.

Let’s walk through the traffic flow step by step. Imagine you have a website, www.example.com that is hosted on an EC2 instance and interacts with backend services. This all lives within a VPC.

Internet Gateway

1. User requests a web page: 

   • A user types www.example.com into their browser and hits enter. The browser initiates a DNS lookup to resolve the domain name www.example.com to an IP address.

   • This IP address is typically associated with your EC2 instance, either directly as a Public IP or an Elastic IP (EIP).

2. Internet Gateway:

   • Using the resolved IP address, the request for www.example.com is made over the internet.

   • The traffic reaches the Internet Gateway associated with your VPC. The Internet Gateway serves as the entry point for this inbound traffic.

3. Routing to EC2 Instance:

   • Once the Internet Gateway receives the incoming request, it routes the traffic to the EC2 instance. This routing is based on the route table associated with the subnet in which the EC2 instance reside

   • The route table will have a default route (0.0.0.0/0), pointing to the Internet Gateway for all outbound internet traffic and will direct inbound traffic from the internet to the appropriate instances within the subnet.

   • The instance should be in the public subnet which directly connects to the Internet Gateway, allowing both inbound traffic from the internet and outbound traffic back to the internet.

4. EC2 Instance Processes the Request:

   • The EC2 instance receives the request, processes it, and generates a response.

5. Response Sent Back to User:

   • The response from the EC2 instance travels back through the Internet Gateway to the user's browser. This completes the round-trip communication between the user and your server.

API Gateway

1. User requests a web page: 

   • A user types www.example.com into their browser and hits enter.

   • The browser or application initiates a DNS lookup to resolve the domain name to the IP address of the API Gateway.

2. API Gateway:

   • Using the resolved IP address, the request is made over the internet.

   • The request reaches the API Gateway, which serves as the entry point for this inbound API traffic.

3. Request Validation and Authorisation:

   • API Gateway processes the incoming request. It performs necessary validations, such as checking API keys, authorisation tokens, or other access controls, depending on the API's security configuration

   • If the request passes all validations and authorisations, it is ready to be routed to the backend services.

4. Routing to EC2 Instance via VPC Link:

   • If the backend service (such as an EC2 instance) is within a private subnet of a VPC, API Gateway uses a VPC Link to securely connect to the service.

   • The VPC Link is connected to a Network Load Balancer (NLB) that is set up within the VPC, which then routes the traffic to the appropriate EC2 instance based on its internal load balancing and health check policies.

5. EC2 Instance Processes the Request:

   • The EC2 instance receives the request from the NLB, processes it (this might involve executing backend logic, accessing databases, etc.), and generates a response.

6. Response Sent Back to API Gateway:

   • The response from the EC2 instance is sent back to the NLB, which forwards it to the VPC Link.

   • The VPC Link then relays the response back to API Gateway.

7. API Gateway Returns the Response to the User:

   • API Gateway receives the response from the VPC Link and sends it back to the user's application or browser. This completes the round-trip communication between the user and your server.

Considerations

1. Cost and Complexity: Using API Gateway for all traffic might increase costs and add complexity. API Gateway charges per million API calls, so high traffic levels could lead to higher costs compared to serving content directly via an Internet Gateway.

2. Latency: Adding an intermediary layer can introduce additional latency, although AWS optimisations like VPC Link and regional endpoints can mitigate this.

3. Overhead: For purely static content, the overhead of managing API Gateway might not justify the benefits if simpler solutions can suffice.

4. Security: Using Internet Gateway, it is important to configure security groups and NACL (Network Access Control List) to only allow desired traffic to and from the EC2 instance.

5. Monitoring and Logging: Using Internet Gateway, there is no built in monitoring features. You should utilise AWS CloudWatch and VPC Flow Logs to monitor and log the traffic coming in and out of your EC2 instances for security and performance analysis.