AWS VPC with a NAT

ACM.269 Setting up a NAT to allow outbound Internet Access From a Private VPC

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Git Security | Application Security | Secure Code | AWS Security | Network Security | Lambda Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I pondered Lambda functions for batch jobs and explained when they might be useful.

Now I want to set up a VPC and networking for a Lambda function to clone my GitHub repo and push it to AWS Code Commit. I can use the resources I set up before but I need one additional component — a NAT.

What is a NAT?

NAT stands for Network Address Translation. It’s a device that sits usually at the edge of a network and translates internal private addresses to an external, public address that routes over the Internet. NATs are typically used for outbound traffic, with the purpose of allowing resources on Internal networks to make outbound network requests to the Internet.

The resources are not directly exposed to the Internet so nothing on the Internet can connect to them. The NAT only allows outbound, not inbound connects. Although there may be some tricky attacks that can get around a NAT in particular circumstances, a NAT makes an attacker’s job more difficult.

AWS NAT Pricing

NATs can be expensive. Let’s take a look at the cost of a NAT. It is .045 per GB per hour.

In my case, I need outbound traffic very sporadically. If I add a NAT to my VPC for a month with 31 days to send a few KB of data the cost will be:

$.045 = 24 hours per day X 31 days = minium $33.48

This is where your consolidating resources into a single network where it makes sense will save money. If you have to stand up a NAT for a whole bunch of separate VPCs that is going to add up. Perhaps instead of adding a NAT to a bunch of VPCs you handle all outbound traffic to get system updates through your DevOps VPC and then pull updates from that VPC instead of adding a NAT to all the different VPCs you stand up. Also, it will be easier to monitor if you consolidate traffic destined for the Internet.

What if I don’t use the NAT? I’ll still be charged.

a charge of $0.045 per hour will always apply once the NAT gateway is provisioned and available

What if resources are in different regions or different availability zones? If resources are in different availability zones there will be a charge:

There will be data transfer charges between your NAT gateway and EC2 instance if they are in a different Availability Zone.

You can avoid charges for AWS Services by using a VPC Endpoint. As I demonstrated in prior posts, you need to make sure the traffic to the AWS Service is sent to the endpoint, not the NAT, to avoid those charges.

Also remember that resources in different regions tend to have different prices and the AWS NAT is no exception.

NAT as a Single Point of Failure

I remember at one point that AWS had some sort of outage and many systems were down. My friend works at ZipWhip (prior to the purchase by Motorola) and I remember him saying that many companies had an outage when AWS did because they failed to stand up completely redundant infrastructure in multiple regions — and in that case, a NAT was the single point of failure for some companies.

If you have a business model with resources in a private network that must access the Internet to function, then you will want to set up a NAT in at least two regions. As always this depends on the nature and criticality of your business.

If ZipWhip is handling text messages for MFA access to other systems or some other type of urgent SMS notification, then it’s pretty critical that their systems can withstand as much failure as possible. For other companies, perhaps you take a break and come back later when you can’t log into AWS. Each company needs to make this decision based on their own business model.

A NAT with a Transit Gateway

An interesting approach to avoid the cost of too many NAT instances would be to stand up a NAT along with a Transit Gateway.

A Transit Gateway is kind of like a funnel that all your network traffic flows through to get to and from the Internet. It’s actually more like a router that routes traffic to the correct connecting network. I explained the general topic of routers and routing in this post.

The thing that interests me about a Transit Gateway is the idea that you could have a way to add traffic inspection at one point in your network. You can monitor all network traffic traversing major trust boundaries at that point — presuming nothing can find an alternate route to the Internet.

I actually spoke about and posed this potential solution before transit gateways existed way back in this presentation in 2017:

At the same time I published a paper on how to implement packet capture in the cloud. That was before cloud providers offered packet capture solutions or AWS had a network firewall as well. Now I’m interested in diving into this topic again.

I’ll explore Transit Gateways further in the next post.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab