My journey to AWS Solution Architect Exam — Part 10 — IGW, Route Tables, Bastion Host, NAT Instance & NAT Gateway

6 min readJan 10, 2024

In AWS, an Internet Gateway (IGW) and Route Tables play crucial roles in managing network traffic within a Virtual Private Cloud (VPC). Let’s discuss each of them.

Internet Gateway (IGW)

An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet. It serves as a gateway for internet-bound traffic, enabling instances within your VPC to connect to the internet or for the internet to reach your instances.

Key points about Internet Gateways

Each VPC can have only one Internet Gateway.
To enable internet access, you attach an Internet Gateway to your VPC.
Internet Gateways are stateful; they track the state of connections, which allows responses to incoming traffic.

Route Tables

A Route Table is a set of rules, called routes, that are used to determine where network traffic is directed. Every subnet in a VPC must be associated with a route table, which controls the traffic routing for that subnet. Each route in a table specifies a destination and a target, such as a specific gateway or instance.

Key points about Route Tables:

A VPC can have multiple route tables, but each subnet can only be associated with one route table at a time.
The main route table is created by default and associated with every subnet in the VPC, but you can create custom route tables.
The routes in a route table define how traffic is directed. For example, a default route (0.0.0.0/0) might point to an Internet Gateway for internet-bound traffic.

Internet Access Setup

Create an Internet Gateway.
Attach the Internet Gateway to your VPC.

Update Route Table: Create a custom route table or modify the main route table for your subnet.
Add a route to the Internet Gateway (0.0.0.0/0) in the route table, directing internet-bound traffic to the Internet Gateway.

Associate the route table with the subnet(s) that need internet access.

This setup allows instances in the associated subnet(s) to communicate with the internet through the Internet Gateway.

An Internet Gateway provides the connection point between your VPC and the internet, while Route Tables define the routing rules for traffic within your VPC, including directing internet-bound traffic to the Internet Gateway.

Bastion Host

Bastion Host is used to enhance the security of accessing private EC2 instances within an AWS VPC.
It serves as a secure entry point for SSH access to private instances. Administrators or authorized users connect first to the BH and then can access private instances from there.

Placement: BH is located in the public subnet, making it directly accessible from the internet. Private subnets, where the instances you want to protect are located, are not directly accessible from the internet.
Security Rule Configurations: the security group associated with the BH should allow inbound traffic on port 22 (SSH) from specific IP addresses or a known range of addresses (CIDR). This ensures that only authorized connections can access the BH.
Security Groups associated with private instances should allow inbound traffic from the Security Group of the BH or the private IP address of the BH. This ensures that only connections from the BH are allowed to access private instances.

The BH is connected to the private subnets, allowing SSH sessions to pass through the Bastion to reach private instances. This creates an additional layer of security, as private instances are not directly exposed to the internet.

This approach is useful for controlling and restricting access to private instances, thereby enhancing the overall security of the AWS infrastructure.

NAT Instance

NAT stands for Network Address Translation. It allows EC2 instances in private subnets to initiate outbound connections to the internet while hiding their private IP addresses.

The NAT Instance must be launched in a public subnet. This ensures that it has a route to the internet and can forward traffic from private instances to the internet.
The EC2 setting “Source/Destination Check” must be disabled for the NAT Instance. This setting, by default, ensures that the EC2 instance only sends and receives traffic that is destined for its IP address. Disabling this check allows the NAT Instance to forward traffic on behalf of other instances.
The NAT Instance must have an Elastic IP (EIP) attached to it. An Elastic IP provides a static, public IP address that remains associated with the NAT Instance even if it is stopped and restarted. This is crucial for ensuring consistent outbound connectivity.
Route Tables associated with private subnets must be configured to route outbound traffic to the NAT Instance. This is achieved by adding a route with the destination of 0.0.0.0/0 (all traffic) and the target as the NAT Instance.

This setup allows instances in the private subnet to send their internet-bound traffic to the NAT Instance, which in turn forwards the traffic to the internet.

It’s worth noting that while this NAT Instance approach was commonly used in the past, AWS now recommends using NAT Gateways instead, which are managed and more scalable.

NAT Gateways offer improved performance, availability, and simpler configuration compared to NAT Instances. However, knowledge of NAT Instances might still be relevant for exam purposes.

NAT Gateway

NAT Gateway is an AWS-managed service that provides Network Address Translation (NAT) functionality for instances in private subnets. It is a fully managed service, meaning AWS takes care of its administration, ensuring higher availability and reliability.

NAT Gateway offers higher bandwidth compared to NAT Instances. It is designed for high availability across multiple Availability Zones (AZs) within a region.
Pay-Per-Hour Model: users are billed per hour for the usage of NAT Gateway, along with additional charges for the data bandwidth consumed.
Availability Zone Specific: NAT Gateway is created in a specific AZ and uses an Elastic IP. Each AZ must have its own NAT Gateway.
Usage Limitation: NAT Gateway can’t be used by EC2 instances in the same subnet. It is meant to facilitate outbound internet connectivity for instances in other subnets.
Architecture Requirement: to enable outbound internet connectivity for instances in private subnets, the typical architecture involves placing the NAT Gateway in a public subnet, which has a route to the Internet Gateway (IGW). The traffic flow is from the private subnet to the NAT Gateway and then to the IGW.
Bandwidth and Scaling: NAT Gateway provides a baseline bandwidth (e.g., 5 Gbps) with automatic scaling capabilities. It can scale up to 100 Gbps to accommodate varying levels of outbound traffic.
No Security Groups Management: unlike NAT Instances, NAT Gateway does not require the management of Security Groups. The NAT Gateway service handles the necessary security aspects.

In summary, NAT Gateway is a fully managed service by AWS, providing higher bandwidth, high availability, and simplified administration for outbound internet connectivity from private subnets. It is designed to be scalable and removes the operational overhead associated with managing NAT Instances.

AWS NAT Gateway High Availability (packetswitch.co.uk)

To enhance fault-tolerance and ensure continued outbound connectivity in the event of an Availability Zone failure, it is recommended to create multiple NAT Gateways in different Availability Zones.

Unlike certain AWS services that support cross-AZ failover mechanisms, NAT Gateways do not require cross-AZ failover. If an AZ goes down, the NAT Gateway in another AZ can still handle the outbound traffic for instances in the affected AZ: deploying multiple NAT Gateways across different AZs ensures redundancy.
Scalability and bandwidth considerations: each NAT Gateway has a baseline bandwidth, and if higher bandwidth is needed, you can create additional NAT Gateways. The distribution of traffic among these gateways happens automatically based on the number of resources in the respective AZs.

By strategically distributing NAT Gateways across multiple AZs, you can achieve a high level of fault-tolerance and availability for outbound traffic from private subnets. This aligns with AWS best practices for designing resilient and scalable architectures in a cloud environment.