Calculating the Cost of An AWS Architecture plus a Region Security Warning

ACM.467 Looking at the cost of an AWS private network that sends data from a Site to Site VPN to a Transit Gateway to a NAT

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

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories IAM | AWS Security | pfSense | Network Security

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

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

In the last post, I wrote about how I took a look at the pfSense AWS VPC Wizard and decided not to use it.

Not before I commence on creating the rest of my resources in AWS, I want to take a look at the cost of the architecture I’m about to create.

Here’s the architecture I’m deploying:

I’ve only had this set up for a few days and already my costs are up to almost $20. I think I got this all working like three days ago. Presuming a consistent amount of traffic I’m looking at about $200 per month but this does not include any other resources besides the networking itself. It’s only sending traffic from my home network to AWS to the Internet. I’m guessing my traffic will be higher after having gotten this working so it will be higher than $200 per month at this rate.

Unfortunately, when you look at the first screen in AWS Cost Explorer, it just gives you this lump sum VPC cost. There’s also this nebulous (pun intended) EC2-Other cost. Let’s take a closer look at what all is involved in coming up with that number.

Analyze potential costs before you build (and after)

Initially I thought I might be able to do something like forward traffic from an AWS LoadBalancer from my VPN to my NAT. Well, the Transit Gateway solution is easier, and the LoadBalancer option doesn’t work as I’ll explain later. But the Transit Gateway charges and all the related infrastructure and log charges to do this is kind of a lot for a single home office as far as I can tell. But I’m going to test this out and revisit this later.

However, before you set up anything in AWS it’s a good idea to look at the pricing and make sure you are minimizing the costs as much as possible — up front.

That was a key point in Werner Vogels’ keynote last year. I also mentioned last year that I started setting this up and I had some flexibility but was not too keen on the cost. Although I had some credits to use up in that case, I mentioned that I was building for the day and time that I didn’t have those credits and wanted to reduce the costs.

Choose a Region — and monitor your traffic

One thing I figured out along the way was that you most definitely want to keep all your traffic in the same Region.

You select a region when you go to the AWS console and click the drop down on the top right next to your name.

As you create VPCs, Subnets, and other resources, make sure they are all in the same region for the lowest cost. If you have resources in multiple regions, set up firewall rules to make sure traffic isn’t getting routed across regions. Check all global resources to make sure the traffic is staying within the same region.

And for security reasons you will want to monitor and understand any traffic that is going to regions you don’t normally use. I recently noticed traffic destined for South Africa and Asia Pacific. I have been further locking down traffic rules accordingly.

I also noticed a strange routing issue when setting all this up. My traffic couldn’t get to AWS CloudFront when I had my routing misconfigured. But somehow it was getting to Microsoft on the 20.0.0.0/8 range?!

The next day I could not reproduce the problem. All that traffic should have been disallowed. It feels like some traffic was leaking through a misconfigured route because I could not see the problem on my end. The next day I walked the logs and by the time I got to the end I realized it wasn’t happening anymore. Hmm. I’ve had similar problems with that range on Azure when I locked my traffic down tightly. I wrote about that in another post. Locking down your network to specific ranges helps you find unexpected problems.

I had a client call me on a consulting call who evaluated a vendor that was leaking sensitive client data to Asia and the Middle East. They said another large healthcare company was using that vendor —but I was under NDA so I wasn’t sure what I could say. I asked the company I worked for and got no response. I put some vague messages out on social media. And then I got a data breach notification from that vendor — which I happen to use. It may have been due to this third party vendor leaking data to other regions.

Check your cross-region traffic. For cost savings and security reasons.

It is very important to understand what traffic is headed for what regions and lock down firewall rules appropriately — not just allow “all of AWS.” I wrote about how AWS could make it easier to lock down traffic to specific regions here:

Try to contain your resources in a single region and only use cross-region traffic when absolutely necessary. Lock down your firewalls, IAM policies, and SCPs to only allow the regions you require.

If you require high availability and reliability and you have the budget, you might select a cross-region architecture. But there are different architectures you can leverage. Instead of running everything live you can have scripts to quickly spin up resources in another region. Make sure you test them frequently. You could also have a minimal set of resources in your second region ready for failover if needed. Running your full infrastructure across multiple regions (hot-hot) is about as expensive as it gets. Evaluate your business requirements and design your disaster recovery and business continuity plans accordingly.

Choose an Availability Zone

You also will have problems with various services if they are not in the same Availability Zone. In some cases it will increase your costs. Choose and use the same Availability Zone if you are trying to save costs. That is essentially like running your systems in a single data center. Choose multiple availability zones if you are trying to improve reliability and availability. That way if one data center has an outage your systems will still be up and running in the other.

Cost of all the things on AWS

Costs on AWS consist of a formula. You need to know the inputs to the formula to get the outputs. The formulas can be a bit tricky and even after reading them all the variables may not be exactly clear. That’s why I always recommend testing to confirm what is really going to happen when you run your system. But we can look at the pricing pages to try to sort out what we think the costs may be.

Generally you can find the cost of any resource by searching for: pricing [AWS resource] in Google. So for example, if I want to find the pricing for Transit Gateway I search for pricing aws transit gateway.

Scroll past the ads and the first page is often the pricing page.

I wrote about this in my SANS paper way back in 2018 and this still holds true.

Check out each pricing page to try to sort out the formula and calculate your costs.

AWS Pricing Calculator

AWS Also has a pricing calculator. Some people find it helpful. For whatever reason I don’t use it. Sometimes the resources I want to use are not listed there and sometimes I am not sure what to enter in certain places. But other people seem to like it and it’s very helpful for a lot of use cases.

As for myself and one of my former bosses, we like spreadsheets. We put the formulas into a spreadsheet and calculated the costs that way. However, about four people at a company I worked at misinterpreted a particular pricing formula and missed a charge on a prior project. We found it during the design and testing phase and adjusted the architecture accordingly. The pricing calculator may have helped but it was complicated to use for that particular architecture with new-ish services.

Make sure you include security services!

Make sure you include security services when calculating costs. Will your architecture increase evaluation requests by services like AWS GuardDuty, AWS Inspector, or AWS Config? Will you have additional logs to store and process? Do you need KMS encryption keys? I’m not looking at all of those in this post but would go into the overall equation and cost. I’ve written about considerations for your KMS key architecture in past posts that balance out the need for segregated, zero-trust security if an application is breached versus the cost of creating a key for every single application.

Adding up all the costs

Now that I’ve explained some of the cost considerations, I’m going to take a look at some of the costs I might incur trying to set up a network from my home network through a VPN attachment to a Transit Gateway to the Internet.

Transit Gateway Charges

Monthly Costs

The Transit Gateway owner is billed hourly for the following:

• AWS VPN attachments (This is what I’m going to use)
• Transit Gateway Connect attachments (SD-WAN appliances)
• Peering attachments

The Direct Connect Owner is billed hourly for Direct Connect attachments. (I’m not using Direct Connect. I explained what that is in my first post on this architecture.)

Monthly = .05 * 24 * 30 = $36 per month.

I have two attachments — one for the VPC and one for the VPN.

2 * 36 = $74 per month

Data Transfer Costs

These costs depend on the amount of data transferred over the VPN attachment. I’m going to use various ranges to see costs for different amounts of data,

1 GB = $.02

10 GB = $.2

100 GB = $2

1,000 GB = $20

5,000 GB = $100

10,000 GB = $200

Site-to-Site VPN charges

Monthly charges

$0.05 per Site-to-Site VPN connection per hour

Monthly = .05 * 24 * 30 = $36 per month per tunnel

I’m going to start my test with one tunnel.

NAT Gateway charges

There is no charge for the data transfer between the NAT gateway and an EC2 instance in the same Availability Zone using private IP addresses.

Initially I thought I might be using a Network Load Balancer to transfer data to the NAT but realized that wouldn’t work. I don’t know if the charge applies to a load balancer because it says EC2 instance. But if what they really meant was from an EC2 Network Interface, which an NLB has, then cross AZ charges would incur the following:

Otherwise:

Monthly = .045 * 24 * 30 = $32.40

1 GB = $.045

10 GB = $.45

100 GB = $4.5

1,000 GB = $45

5,000 GB = $225

10,000 GB = $450

I’m hoping to avoid those charges the way I ended up setting up the transit gateway with no EC2 resources between the Transit Gateway and the NAT. But I’ll have to revisit this when I’m through and look at the NAT transfer charges.

Elastic IP Address

To create a public NAT, I need an elastic IP address. I’m going to use an IPv4 address which incurs a charge.

$0.005 / hour

Monthly: .005 * 24 * 30 = $3.6

You can use IPv6 to avoid this charge but make sure you configure it correctly.

Otherwise your costs for IPv6 may exceed your monthly cost for the IPv4 address.

EC2 Data Transfer Within AWS

Data transferred between Amazon EC2 and Elastic Network Interfaces in the same Availability Zone is free.

If we can keep everything in the same AZ we won’t be billed additional charges. Unfortunately, I have faced instances where an AZ was not available and had to use a different one. But for now, I don’t have any EC2 resources in this architecture other than the NAT and I *think* the transfer from the Transit Gateway to the Nat Gateway is covered in the cost of those two services.

If I add any EC2 instances I need to be aware of this Availability Zone cost.

Transfer to and from an IPv4 Elastic IP address

EIP — same region: — IPv4: Data transferred “in” to and “out” from public or Elastic IPv4 address is charged at $0.01/GB in each direction.

So I would expect to be charged for Internet-destined traffic leaving the NAT:

1 GB = $.01

10 GB = $.1

100 GB = $1

1,000 GB = $10

5,000 GB = $50

10,000 GB = $100

EC2 Data transfer to Internet

AWS customers receive 100 GB of free data transfer out to the internet free each month, aggregated across all AWS Services and Regions (except China and GovCloud).

1 GB = FREE

10 GB = FREE

100 GB = FREE

400 GB = FREE

1,000 GB — 400 = 600 * .09 = $54

5,000 GB — 400 = 4600 * .09 = $414

10,000 GB — 400 = 9600 * .09 = $864

OK, but do I incur any of those charges or just the NAT charges? If and when I add EC2 instances, they will be sending data to the NAT in the same AZ. So no charge, right? Only the charge for the NAT and EIP?

CloudWatch Logs Charges:

This includes VPN logs, Transit Gateway Logs, and VPC Flow Logs.

Presuming you keep all logs on AWS so no transfer out fees:

As you can see archiving your log will save you money. So will limiting how long you store them.

1 GB = .5 + .03 = $.53

10 GB = 5 + .3 = $5.3

100 GB = 50 + 3 = $53

1000 GB = 500 + 30 = $530

You can reduce the costs by archiving data to AWS Glacier if you need it for archival purposes or in case of a security incident which hopefully never occurs.

Question — does the fact that you cannot configure which AZ a transit gateway uses incur additional costs?

I noticed that the Transit Gateway was using different AZs than my subnet. I also investigated further and could not control the AZ’s used by the Transit Gateway completely when using a single subnet.

I returned to the Transit Gateway configuration.

There’s no ability to select an AZ here:

I revisit the attachment configuration. No way to choose an AZ here.

The pricing page for Transit Gateway doesn’t mention anything about AZs at the time of this writing.

Well I found this information on Availability Zones in the documentation. The Transit Gateway automatically allows traffic to any AZ. However, the traffic will only route to that AZ if you have a corresponding subnet. Somehow the Transit Gateway, in my case, was routing from a different AZ than the one for the subnet I attached to it. Apparently there is no charge for that cross AZ-transfer according to this documentation. That should probably be added to the pricing page.

What might my total costs be for this architecture?

I’m just guessing at the data transfer and log storage below. I’ll have to take another look at it after I use it for a bit. One thing to note here is that I can reduce my transfer costs potentially by setting up automated batch jobs — which is really what this whole series is all about, where I don’t have to log in or manually do things to run them. If they can be scheduled and run automatically within AWS I will incur less transfer charges hopefully. But here’s a really rough and possibly wrong guesstimate.

I might not have a precise answer, but at least I know some things I need to avoid. When I initially started setting this up, somehow traffic was routing in ways I didn’t expect to regions I wasn’t using I think. Or maybe cross-AZ. I didn’t even expect that traffic to be possible so I’m not exactly sure how it happened. I tore it all down until I had time to investigate further. That’s what I’m doing now. After I set this up I’ll monitor the costs to see what I missed, if anything.

Monthly

Transit Gateway: $74

VPN Tunnel 1: $36

NAT Gateway: $32.40

EIP: $3.6

________________

Total Monthly: $144

Data transfer for all of the above services @ 1000 GB per month:

I have no idea what my data transfer would be. I just looked at my phone and it’s around 750MB at the moment so I picked 1000 GB.

Transit Gateway: $20

NAT Gateway: $45

EIP: $3.6

EC2 transfer to Internet: $54 (??)

— — — — — — — — —

Total Transfer: $122.60

Logs @ 10 GB:

_____________

Total Log Storage: $5.3

— — — — — — — —

Total Cost per month: $272.90

And that’s just me and not my entire home network. Is that even right? Do we incur the EC2 charges if using a NAT? Private networking is pretty expensive for a small business or home user trying to set this up. But I’ll give it a go and report back what the actual charges are after I take a look.

Perhaps there is a way to fire some of the more expensive parts of this up on demand like the VPN tunnels. Unfortunately that has to be created through the Transit Gateway VPN attachment as I’ll show you later.

As I explained in my original post in this series, some of the lower cost VPN-less solutions don’t actually do the same thing as a VPN. Although some other options are pushed as cheaper alternatives, they aren’t really equivalent. Read that post for the technical details.

Also note I have other costs not mentioned here: AWS GuardDuty, any sort of traffic monitoring over and above looking at CloudWatch, a KMS key to encrypt logs in CloudWatch and any sort of long term log archive if required. I’m just focusing on the components required to set up the private connection and route traffic from a home or business network through a NAT.

Revisiting the Billing Console

Now that we have an idea what we’re looking for I can revisit the billing console to try to figure out what is making up that $19 per month charge.

In Cost Explorer, I change the dates to this month.

I choose VPN-Usage-Hours in the right Menu.

I can see that so far my monthly VPN fees are up to $5.50.

I choose Region to Region out under Usage type group to validate I’m not getting any region to region charges.

No. We’re good there.

Rather than go through these one by one, let’s change the chart.

I clear that last setting and at the top I can group by Usage type:

This is much more helpful and not sure why it is not the default.

Skipping all the things that are zero:

The Transit Gateway, VPN, and NAT are incurring the most charges with the Transit Gateway at the top of the list. Here’s where I realize I missed something. I have two attachments — one for the VPC and one for the VPN so that’s $74 per month. Originally I thought meant one transit gateway attached to my account. Nope. You’re going to pay that fee for every VPC and every VPN you attach to your Transit Gateway. Ouch. Pricey for small businesses, unfortunately.

Reducing the cost of our private network

One option would be to nix the transit gateway and the NAT. Connect over the VPC to your EC2 instances and let those connect directly to the Internet. It’s not as secure but if your budget is tight that may be a more viable. Option. You can still restrict inbound access to the EC2 instances to the VPN IP range.

You might also consider this approach from my fellow AWS Hero, Ben Whaley, if you want to save some money. But NAT Instances (as opposed to NAT Gateways) can be painful to set up (I’ve done it) and they can break your whole network when they are down.

When I set them up there was no NAT gateway so I had to implement failover between two NATs. This approach from Ben is interesting because it fails over to the NAT Gateway. The fact that keeping NATs up and running is so critical is why people pay the extra cost to maintain them via a NAT Gateway in many cases. The cost difference in the above post is significant, however, if you have the wherewithal and resources to do this — and support it — it can save you money.

Here’s a good summary of the two NAT options:

One other issue with the above solution is that AWS is not going to provide a NAT instance for Amazon Linux 2023, which I highly recommend moving to as soon as possible for all instances. You’ll have to create your own. They provide guidance here:

Well, now that we have an idea what the costs might be, let’s move on.

Update: March 12th — here are my costs so far this month.

If you liked this post, check on the next one to see how my estimate fared when compared to the actual costs.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2024

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