AWS VPC configuration: getting it right.
The great thing about an AWS VPC is the incredible flexibility and security it offers. Amazon’s VPCs allow you to provision compute resources, like EC2 instances and RDS deployments, inside Amazon’s isolated virtual networks, giving you complete control over all inbound and outbound network traffic. You can select IP address ranges, subnet association, and route table and network gateway configuration. You’re really in control.
Here’s what’s great about the VPCs:
- Since instances launched into an AWS VPC aren’t directly accessible from the internet, they are by default more secure.
- VPCs simplify security, allowing seamless integration with ACLs, Routing rules, and security groups.
- You can attach multiple network interfaces.
- You can directly connect your on-premise network to an AWS VPC.
- VPCs simplify secure, multi-tier web deployments (like connecting a public app to a private database server living in a private subnet).
- Disaster recovery backup images built on VPC connectivity through private connections can make recovering mission-critical data simpler and more reliable.
- Launch-dedicated instances running on hardware dedicated to a single customer gain additional isolation.
On the other hand…
As well-designed as VPCs are, they’re not bulletproof. Especially when human beings get involved. Since you should be aiming for absolute perfection for all your deployments, make sure that you avoid these configuration blunders:
Five AWS VPC config mistakes
- Poor subnet/CIDR Block planning: Administrators often fail to keep network compatibility and future needs in mind while designing their VPC subnets and CIDR blocks. Bearing in mind that AWS VPC subnet blocks, once assigned, can’t be modified, you should carefully calculate how many nodes each subnet might need. Remember: creating a /24 or /27 CIDR might not leave you enough addresses. Also, choosing, say, a 10.0.0.0/16 block for your VPC subnet when the local data center you want to connect to uses 10.0.26.0/24 won’t end happily.
- Public IP addresses: When you launch an instance into the public subnet of a nondefault VPC (using it’s default settings), it will not get a public IP or hostname the way it would use the old EC2-Classic. Once it’s created, the only way to make your instance publicly addressable is by assigning an elastic IP to the node. Elastic IPs are not free and, by default, you are limited to five per account (although you can always request more).
- Sharing Production and Development Environments: Putting all your staging, dev, and production environments into a single VPC will pretty much guarantee loads of confusion and endless security group and routing table conflicts.
- Not considering distributed redundancy for NAT instances: Smart admins always build High-Availability into their applications. But then some of them place their applications or database servers inside private subnets that will access remote services (S3, SQS, patches, and updates) through stand-alone NAT instances. When the NAT instance goes down, your whole application will break. Here’s a quick tutorial to build and configure a NAT Instance.
- Assuming an AWS VPC requires complex networking skills: VPCs are not switches. VPCs are not routers. VPCs are not firewalls. Even if they perform the work of all three of those hardware tools, VPCs are really software-defined networks (SDN). AWS designed them from the bottom up to be straightforward and uncomplicated. You do need to understand a few very basic networking concepts like routing, NAT, VPN, and ACL, but AWS itself does most of the heavy lifting.
If you’re still hosting your applications within EC2-Classic, you should seriously consider migrating to AWS VPC to leverage the huge benefits of VPC. But always stick with Best Practices…and think ahead!
And by the way, Cloud Academy has a full video course on AWS VPCs.