One part of my job is to work with our Client Services team to deploy hosted software solutions for customers. We accomplish this using Amazon Web Services (AWS) and a number of their cloud networking solutions. The base solution we have defined looks something like this:
- An AWS Virtual Private Cloud (VPC) is created for the customer in the specified AWS Region – for this example, we’ll say ‘us-east-1’ (N. Virginia). The subnet allocated to this VPC is from RFC1918 – we typically allocate a /21 (or larger).
- Within this VPC, 4 subnets are created which are spread across two Availability Zones (AZs). For this article, we’ll use ‘east-1a’ and ‘east-1b’. There are two private subnets which access the outside network via a NAT instance (or NAT gateway), and two public subnets which use an Internet Gateway (IGW) for outside reachability. Each subnet is a /24, and each AZ is allocated one private and one public subnet.
- AWS Relational Database Service (RDS) is often used for the application database. RDS is configured to use the private subnets, with one being primary and one being secondary/failover. We’ll say that east-1a is the primary subnet, and east-1b is the secondary.
- Customer Gateways (CGW), Virtual Gateways (VGW), and VPNs are created in the AWS console to support secure connectivity to the VPC from our company as well as from the customer. Customers may connect to RDS over an IPsec tunnel to create reports directly from the DB using the reporting tool of their choice.
We have successfully deployed a number of customers using this framework, and it has worked well. However, all customers have different requirements – and a new customer had a limitation that we had not dealt with before:
VPN connectivity is required, but no RFC1918 addresses may be used within the VPC. All addresses must come from the Public IP space.
This is the first in a series of posts describing how I arrived at a solution; hopefully these will help if you find yourself in a similar situation.