7.4 NAT Instances & NAT Gateways

The instances in the public subnet can send outbound traffic directly to the Internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) gateway that resides in the public subnet, but prevent the Internet from initiating a connection with the instances.

Steps:

NAT instances can be found from Community AMIs when you create a new EC2 instance. Search "nat", and use the first result is OK.
Network: the VPC you created in lab part 1.
Subnet: public subnet (us-east-1a).
Give it a Tag: Key is Name, Value is NAT-INSTANCE.
Security Group: select a existing security group, select Web-DMZ which has HTTP and SSH enabled. If you didn't add HTTPS, add this rule to it as well, we need it to download MySQL etc later.
Launch this NAT instance.
Go to Instances, select NAT-INSTANCE. Go to Action -> Networking -> Change Source/Dest Check -> Disable. This is because each EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. However, a NAT instance must be able to send and receive traffic when the source or destination is not itself. Therefore, you must disable source/destination checks on the NAT instance. You only need to do this on the NAT instances, and not on the NAT Gateway.
Go to route tables. We want to have a route out from my default route table via my NAT instance. Select the Main route table of your own VPC, and select Routes tab of it and add it another route, the destination is just 0.0.0.0/0. Target should be the NAT instance (instead of IGW). Save. So now we added a route out via the NAT instance to the outside world.
SSH into the public instance (10.0.1.242) firstly, and then SSH into private instance (10.0.2.143).
When you SSH into the private instance, run: yum update -y. Now your private instance can access outside Internet, because we now have NAT instance.
Single NAT instance is a single point, so it need higher availability and higher performance. You can use a powerful instance class to scale it up, you can put it under scaling groups, you can have them across multiple-AZ, but these ways are so complicated. Now the NAT Gateway comes to our rescue.
Terminate your NAT-INSTANCE. Go to VPC dashboard and Create NAT Gateway. (NAT Gateway work in IPv4, Egress Only Internet Gateways work in IPv6).
Create NAT Gateway. Subnet: select the public subnet of your own VPC. Create New EIP (Elastic IP). Create a NAT Gateway. When you finish it, click Close, don't go to Edit route table at this time.
Go to route table tab of VPC dashboard. Select the Main route table of you own VPC, and click Routes tab of it. Delete the rule which has a black hole status. Add a new rule which has a destination 0.0.0.0/0 and target is the ID of your NAT Gateway. Save. Now we have a route out.
SSH into the private EC2 instance. Run: yum install httpd -y. You can see now it has Internet access.
You can search the "Comparison of NAT Gateway vs. NAT instance" on Internet. In terms of availability, NAT Gateway is highly available. You are going to need gateways in each AZ. NAT Gateway in each AZ are implemented with redundancy. Create a NAT Gateway in each AZ to ensure zone-independent architecture. It is not good enough to just have one gateway in one availability zone because if that AZ goes down, you will lose access to it. You do want to have multiple NAT Gateways across multiple AZ, you just need to route out in your Main route table to each one and then failover will happen automatically. NAT instance can be used as a Bastion server, but NAT Gateway cannot. Bastion server is a server that you use it to RDP or SSH into instances that are in your private subnets, and you can do that either via the terminal window or by using Putty, and so you don't need to store your private keys on your public instances, you can store them on your client devices.
What we have done for now:
We have our NAT Gateway sit inside our public subnet, we could have multiple NAT Gateways across multiple public subnets for redundancy. If we did do that we need to make sure our route tables were updated so that we had routes out to multiple gateways. The cool thing about NAT Gateway is that it is not a single instance which may go down and fail, but some sort of clustered instances which managed by Amazon and we don't need to worry about patching the operating system or anti-virus etc. Another important thing is NAT Gateway doesn't sit behind a security group, but when we create a NAT instance we have to place it in a security group (e.g. Web-DMZ). You should always use NAT Gateway instead of NAT instance.

Exam Tips

For NAT instances:

When creating a NAT instance, disable source/destination check on the instance.
NAT instances must be in a public subnet.
There must be a route out of the private subnet to the NAT instance, in order for this to work.
The amount of traffic that NAT instances can support depends on the instance size. If you are bottle-necking, increasing the instance size (upgrading).
You can create high availability using Autoscaling Groups, multiple subnets in different AZs, and a script to automate failover.
Behind a security group.

For NAT Gateways:

Preferred by the enterprise.
Scale automatically up to 10 Gbps.
No need to patch.
Not associated with security groups. Independent with security groups.
Automatically assigned a public IP address.
Remember to update your route tables to point them to the NAT Gateways. Having one NAT Gateway in one AZ is not good enough. You want them in multiple AZs so that you have some form of redundancy in terms of availability failure.
No need to disable source/destination checks.
More secure than a NAT instance. You don't have SSH access to your NAT Gateway.

Previous7.3 VPC Lab - Part 2 Next7.5 Network Access Control Lists vs. Security Groups

Last updated 5 years ago

Was this helpful?

Steps:

NAT instances can be found from Community AMIs when you create a new EC2 instance. Search "nat", and use the first result is OK.

Network: the VPC you created in lab part 1.

Subnet: public subnet (us-east-1a).

Give it a Tag: Key is Name, Value is NAT-INSTANCE.

Security Group: select a existing security group, select Web-DMZ which has HTTP and SSH enabled. If you didn't add HTTPS, add this rule to it as well, we need it to download MySQL etc later.

Launch this NAT instance.

Go to Instances, select NAT-INSTANCE. Go to Action -> Networking -> Change Source/Dest Check -> Disable. This is because each EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. However, a NAT instance must be able to send and receive traffic when the source or destination is not itself. Therefore, you must disable source/destination checks on the NAT instance. You only need to do this on the NAT instances, and not on the NAT Gateway.

Go to route tables. We want to have a route out from my default route table via my NAT instance. Select the Main route table of your own VPC, and select Routes tab of it and add it another route, the destination is just 0.0.0.0/0. Target should be the NAT instance (instead of IGW). Save. So now we added a route out via the NAT instance to the outside world.

SSH into the public instance (10.0.1.242) firstly, and then SSH into private instance (10.0.2.143).

When you SSH into the private instance, run: yum update -y. Now your private instance can access outside Internet, because we now have NAT instance.

Single NAT instance is a single point, so it need higher availability and higher performance. You can use a powerful instance class to scale it up, you can put it under scaling groups, you can have them across multiple-AZ, but these ways are so complicated. Now the NAT Gateway comes to our rescue.

Terminate your NAT-INSTANCE. Go to VPC dashboard and Create NAT Gateway. (NAT Gateway work in IPv4, Egress Only Internet Gateways work in IPv6).

Create NAT Gateway. Subnet: select the public subnet of your own VPC. Create New EIP (Elastic IP). Create a NAT Gateway. When you finish it, click Close, don't go to Edit route table at this time.

Go to route table tab of VPC dashboard. Select the Main route table of you own VPC, and click Routes tab of it. Delete the rule which has a black hole status. Add a new rule which has a destination 0.0.0.0/0 and target is the ID of your NAT Gateway. Save. Now we have a route out.

SSH into the private EC2 instance. Run: yum install httpd -y. You can see now it has Internet access.

You can search the "Comparison of NAT Gateway vs. NAT instance" on Internet. In terms of availability, NAT Gateway is highly available. You are going to need gateways in each AZ. NAT Gateway in each AZ are implemented with redundancy. Create a NAT Gateway in each AZ to ensure zone-independent architecture. It is not good enough to just have one gateway in one availability zone because if that AZ goes down, you will lose access to it. You do want to have multiple NAT Gateways across multiple AZ, you just need to route out in your Main route table to each one and then failover will happen automatically. NAT instance can be used as a Bastion server, but NAT Gateway cannot. Bastion server is a server that you use it to RDP or SSH into instances that are in your private subnets, and you can do that either via the terminal window or by using Putty, and so you don't need to store your private keys on your public instances, you can store them on your client devices.

What we have done for now:

We have our NAT Gateway sit inside our public subnet, we could have multiple NAT Gateways across multiple public subnets for redundancy. If we did do that we need to make sure our route tables were updated so that we had routes out to multiple gateways. The cool thing about NAT Gateway is that it is not a single instance which may go down and fail, but some sort of clustered instances which managed by Amazon and we don't need to worry about patching the operating system or anti-virus etc. Another important thing is NAT Gateway doesn't sit behind a security group, but when we create a NAT instance we have to place it in a security group (e.g. Web-DMZ). You should always use NAT Gateway instead of NAT instance.

Exam Tips

For NAT instances:

When creating a NAT instance, disable source/destination check on the instance.

NAT instances must be in a public subnet.

There must be a route out of the private subnet to the NAT instance, in order for this to work.

The amount of traffic that NAT instances can support depends on the instance size. If you are bottle-necking, increasing the instance size (upgrading).

You can create high availability using Autoscaling Groups, multiple subnets in different AZs, and a script to automate failover.

Behind a security group.

For NAT Gateways:

Preferred by the enterprise.

Scale automatically up to 10 Gbps.

No need to patch.

Not associated with security groups. Independent with security groups.

Automatically assigned a public IP address.

Remember to update your route tables to point them to the NAT Gateways. Having one NAT Gateway in one AZ is not good enough. You want them in multiple AZs so that you have some form of redundancy in terms of availability failure.

No need to disable source/destination checks.

More secure than a NAT instance. You don't have SSH access to your NAT Gateway.