AWS VPC Design Session
Over the weekend, I had to redesign my VPC in AWS due to some networking oversight early on in the design back in the summer. As I began to rebuild my VPC I figured it would be a good time to document the steps and hopefully save someone the trouble of having to build a VPC from scratch while avoiding some of the pitfalls associated with this step. With that being said, let’s dive in.
- Decide what type of application you are planning on running, whether it be a two tier or three tier app, and design your network appropriately. For example, placing your web servers in the public subnet makes the most sense while placing your DB and app servers in a public subnet as well would not make sense.
- Consider the ramifications of a faulty availability zone or AZ could do to your application. AWS uses regions spread out around the world, currently 11, to load balance and create a fault tolerant network for its customers. AZ’s are placed inside each region, which are nothing more than data centers in say “us-east-1” or the Virginia data center.
- If you using NAT, network address translation, create a NAT instance per AZ.
- Use auto-scaling for NAT availability as well as for monitoring and health reporting of EC2 resources.
- Vertically scale your NAT instance per your performance needs
There are several VPC scenarios available in AWS which include the following:
- VPC w/ single public subnet
- VPC w/ public and private subnets
- VPC w/ public and private subnets and hardware VPN access
- VPC w/ private subnet only and hardware VPN access
For the purposes of my VPC I choose the “VPC w/ public and private subnets” as I’m not routing traffic to/from a corporate data center. First, it’s important to understand how subnets and VPC’s work but to keep it simple remember that subnets can’t span AZ’s so as new AZ’s come online you need to plan for this. Second, secure your VPC with security groups and network ACLs. I will get into this a little later on in this post but for now think of these as firewalls. Third, several best practices around VPC networking include:
- Create a layered security approach utilizing security groups and network access control lists.
- Use IAM, Identify and Access Management, to secure access from individuals and teams to your VPC.
- Use direct connect or IPsec for connections if possible.
Okay, now that the architectural considerations and best practices are complete, let’s build the VPC. Pictured below is a quick whiteboard design of my internal VPC.
As you can see, I am utilizing a three tier application consisting of multiple AZ’s and a single VPC inside the eu-west datacenter. I’ve also noted some key considerations when designing your subnets and AZ’s listed to the right on the network diagram. These are key considerations and necessities to keep in mind as these rules cannot be broken and should be adhered to for a proper design.
Okay, the network is built but what about NAT, security, etc? Glad you asked because I will now use another whiteboard to describe both NAT and security as it pertains to AWS VPC.
Network ACL’s and Security groups might not sound like the most entertaining topic in the world but when it comes to security of your environment you can’t be too careful. Now that the network is secured it’s time to get some traffic to the private subnet so our DB and app servers can fetch updates and communicate with those on the Internet. Let’s see what a whiteboard drawing of this might look like as well as walk through the steps to create a NAT instance in AWS VPC.
And there you have it, all the information you would need, albeit the exact commands, to build a functional, secure and elastic VPC in AWS.