Amazon Web Service VPC Best Practices
Amazon's Virtual Private Cloud (VPC for short) allows you to create your own private networks in the cloud. It makes the cloud behave much like a private data center with IP ranges you choose and great security features. However, as a newcomer to VPC there are a few things that will quickly suck the time out of your day and leave you wondering if it right for you. So here are a couple of best practices to get you up and running quickly:
Create Public and Private Subnets
There are cases where you might want just a private subnet, for instance if you are planning to host only applications availabe from your local network. But for most situations, you are going to want both public and private subnets. The public subnets are used to host Internet facing services like mail servers, web servers, etc. The private subnets are used to secure resources that don't need to availble from the Internet such as database servers, internal api servers, and so on. You might think, "can't I just put a private server instance in the public subnet and not give it a public IP address?" While this is possible, based on the fact that VPC Internet Gateways don't provide NAT translation, that server will never be able to connect to the Internet. Because of this, I recommend creating both private and public subnets (in multiple availability zones for redudancy) and put your public facing servers in the public subnet and your private servers in the private subnet.
Providing NAT to your private Subnets
If you have followed my first best practice you will have private subnets, but they won't be able to connect to the Internet. This is because AWS doesn't provide NAT services native to the VPC offerings (it would be really nice if they would). To deal with this you need to create your own NAT instances. Amazon has a pre-built AMI to startup NAT instances. I recommend creating a few NAT instances for redudancy, and then make these instances the default route for your private subnets with a subnet or two pointed at each NAT box. Now you have Internet access for boxes in your private subnets.
Configure a Hardware VPN
VPC has a built-in service for connecting your office network to your Virtual Private Cloud over an IPSec VPN tunnel. While this certainly isn't required it will simplify your life in the long run. Once up and running, people on your local office network will be able to connect the VPC as if the resources were local. This does require that you plan your VPC subnet IP space properly so that the routing works between your office network and the cloud. You also need to make sure that you enable whatever security is necessary for your specific situation since the VPN will be providing connectivity directly to your virtual data center.
Configure a Software VPN
Even if you have created a hardware VPN, I still recommend that you create a software VPN instance in your VPC also. There are two advantages of doing this. First, it can be used to provide access to remote employees, contractors, etc. Second, it is a great redudancy for the hardware VPN should you have a failure that knocks it offline. There are several ways you can do this. I have had good results using OpenVPN to provide an SSL VPN.