Amazon AWS VPC Design Considerations

Tracey Flanders Published Jul 12, 2014 at 10:08 PM MST by Tracey Flanders Tags Cloud, Architecture, Amazon AWS, Design  (1) comment

While researching Amazon AWS cloud over the past few months I soon discovered that AWS would be a complex addition for most businesses. Sure you could spin up a Virtual Private Cloud (VPC) and run with it. But what happens when you need to scale? Rip and replace? No way! VPC's are the pinnacle of complexity and define the foundation of any successful deployment into the AWS cloud. Be prepared to have your IP subnets, connectivity/peering options, traffic flows, DNS etc ready to go before deploying your first production VPC. I heard from an AWS customer, that their own engineer made a castrophic network change and locked them out of their VPC. What then? Rebuild.


Yinal Ozkan discusses some of the challenges I mentioned above. I did attend this session at the AWS summit. I found his presentation invaluable for my own understanding of scaling VPC's.



Video presentation @Amazon AWS Summit 2014

From One to Many: Evolving VPC Design


Slideshare of the presentation

From One to Many: Evolving VPC Design from Amazon Web Services


My Notes about VPC Design



There are 3 ways for traffic to leave your VPC, InternetGW, VPN GW and VPC peering. Use EIP for traffic that needs a persistent return path, inbound access from the internet. All AWS services require going to the Internet unless you have AWS Direct connect setup between your datacenter and AWS. You an be hosted in a datacenter or use metro ethernet, MPLS.


Dont proxy connections from AWS VPC --> Your DC --> then to the internet --> then to AWS service. Bad idea, use direct connect.


VPC peering creates a connection between 2 VPC's. It does not however allow transient traffic to hop onto another VPC through a VPC. Won't act like a router. Only one peering per VPC, highly redundant because its a software feature, no banwidth contraints. Direct Connect helps for large VPC scaling, removes most of the VPN complexity.


Security groups are bound to the VPC they have been created in. Provide consistent performance, connect into private network, one per region.



Nothing special about the AWS ami. You can use autoscaling to keep your NAT servers highly available behind ELB. You will need to do some scripting to talk to the load balancer for add/removes, and NAT instance id changes for all required NAT'd subnets. For apps that require high bandwidth, try to use public ot EIP and not the NAT servers. Otherwise scale the NAT instance verticall (use bigger instance). 



Use Tags! Not only for billing but for the design, however dont use them to enforce security based on tag names. Use things like Project codes, cost centers, environments (prod, dev), team name, business unit, etc.


IP Addresses

Do not overlap IP space. AWS reserves both the first four IP addresses and the last IP address in each subnet CIDR block. They're not available for you to use.


Network ACL

You can associate a network ACL with multiple subnets; however, a subnet can be associated with only one network ACL. Any subnet not associated with a particular ACL is associated with the default network ACL by default.


You might want to disassociate a subnet from its network ACL. For example, you might have a subnet that is associated with a custom network ACL, and you instead want it associated with the default network ACL. By disassociating the subnet from the custom network ACL, the subnet becomes associated with the default network ACL.

Considered for blacklisting, use sparingly to avoid complexity, use as a catchall for things you never want to leave your network, they are stateless, use IAM to control who can manage NACL's.


Route Tables

Your VPC can have route tables other than the default table. One way to protect your VPC is to leave the main route table in its original default state (with only the local route), and explicitly associate each new subnet you create with one of the custom route tables you've created. This ensures that you must explicitly control how each subnet's outbound traffic is routed.



Services that use the Hadoop framework, such as Amazon EMR, require instances to resolve their own fully qualified domain names (FQDN). In such cases, DNS resolution can fail if the domain-name-servers option is set to a custom value.To ensure proper DNS resolution, consider adding a conditional forwarder on your DNS server to forward queries for the domain region-name.compute.internal to the Amazon DNS server. For more information about launching an Amazon EMR cluster into a VPC, see Setting Up a VPC to Host Clusters in the Amazon Elastic MapReduce Developer Guide.




Comments: (1)

Leave comment

We welcome your participation on our website. Please keep your comments civil and on point. Your email address may be used to notify you of comment replies.
By submitting a comment, you agree to these Terms of Use.

Login to comment on this article.