Share a NAT-GW through TGW
Complexity in the cloud grows every day and every time you need to manage infrastructure. Maybe you are already building some great serverless applications but for now, you still have the need to take care of infrastructure on AWS. Not a problem! Transit Gateway is what you’re searching for! This great AWS service is now available in a lot of AWS regions and more are coming. So let’s go straight to business! NAT Gateway is a great solution to provide internet connectivity for AWS resources sitting in private subnets and that don’t need or wanted to be exposed to the internet accessible traffic, this means that a normal setup involves having a NAT Gateway per account, even if you have several AWS accounts in the same region to logically separate AWS resources and environments (as recommended by AWS to follow the best practices), translating in a lot of costs only for NAT Gateways spread out across different accounts and adding a relatively good amount of money spent on these beauties every year. (i) Normally a NAT Gateway price per hour (excluding the traffic) varies between regions, from $0.045 / hour — $0.093 / hour. Summing up means that by the end of a full year running 1x NAT Gateway the bill we be nothing less than USD$394.2 also if you are running a PROD + TEST + DEV environments each in its own AWS account all of this equals to $1182.6 / year. So the solution would definitely go for creating or leverage an existing AWS Transit Gateway, this means that with the TGW you can connect different VPCs in different accounts, manage a single routing table common to all these VPCs or having isolated Routing tables for each VPC (Routing Domains) if you want or need to have fine-grained control of the traffic going in and out of your VPCs. That’s it! Simple as that, let us describe the solution for you and list the resources needed, so we can finally deep dive into the details. Save money by sharing resources
In our example, we use a Transit Gateway to share a NAT Gateway with other VPCs to enable communication with the internet for instances which are located in the private subnets.
The NAT Gateway is a component part of the Virtual Private Cloud (VPC) solution offered by AWS. As an important component that is, the NAT gateway has the ability and is mainly focused on providing egress-only internet connectivity for the resources associated or routed to the NAT Gateway.
Some situations where a NAT gateway can be helpful:
- Installation/Download of software tools needed in the server during the deployment (ex. Putty, Windows RSAT, installation files, etc);
- Reduce complexity on how the resources (EC2 instances) communicate with other AWS services (Systems Manager, Secrets Manager, Security Token Service, etc);
- Use of AWS SystemsManager documents that require internet access; (For example the “DomainJoin” document provided by AWS to join an existing server to a Microsft Windows Domain * could be used, currently the AWS directory service does not support AWS PrivateLink and then is not possible to use SSM automation through VPC endpoints);
A transit gateway enables attachments from/to VPCs and VPN connections in the same Region and route traffic between them. Each VPC or VPN attachment is associated with a single route table. The Route table decides the next hop for the traffic coming from that resource attachment. A route table inside the transit gateway allows for both IPv4 or IPv6 CIDR and targets. The targets are VPCs and VPN connections. When a VPC is attached or VPN connection created on a transit gateway, the attachment is associated with the default route table of the transit gateway.
The AWS Resource Access Manager enables you to share your resources with any AWS account or through AWS Organizations. If you have multiple AWS accounts, you can create resources centrally and use AWS RAM to share those resources with other accounts.
Cut down on your Lambda cost
What to keep in mind when focussing on optimizing cost for Lambda
Share your ACM Private CA cross-account
How to automate AWS RAM to share your ACM Private CA cross-account
SCP Best Practices
How to use service control policies to secure resources and avoid unnecessary costs across accounts in your AWS Organization