The following are some key best practices and recommendations to keep in mind when using VPCs:
Plan and design your VPC before actually implementing one. Determine the right choice of subnet that your application will need and build your VPC around it.
Choose your VPC's network block allocation wisely. A /16 subnet can provide you with a potential 65,534 IP addresses that rarely will get utilized. So ideally, go for a /18 (16,382 IP addresses) or a /20 (4094 IP addresses) as your VPC network choice.
Always plan and have a set of spare IP address capacity for your VPC. For example, consider the network block for my VPC as 192.168.0.0/18.
In this case, we design the subnet IP addressing as follows:
192.168.32.0/19 Public Subnet
192.168.64.0/19 Public Subnet spares
192.168.128.0/20 Private Subnet
192.168.192.0/20 Private Subnet spares
Remember that you cannot edit a network block's size once it is created for a VPC. The only way to change the network block is by deleting this VPC and creating a new one in its place.
Use different security groups to secure and manage traffic flows from your instances. For example, a separate Security Group for web servers and a different one for your database servers. Avoid using the default security groups at all times.
Leverage multiple AZs to distribute your subnets across geographies. For example, the US-WEST region has three AZs, namely us-west-2a, us-west-2b, and us-west-2c. So an ideal situation would have you divide your VPC's network block and create subnets in each of these AZs evenly. The more AZs, the better the fault tolerance for your VPC.
Leverage IAM to secure your VPC at the user level as well. Create dedicated users with restricted access to your VPC and its resources.
Create and stick with a standard naming convention so that your VPC's resources can be easily identified and tagged. For example, in our scenarios, we named the VPC as US-WEST-PROD-1, which clearly identifies this particular VPC to be hosted in the US-WEST region and to be a PRODUCTION environment.