Before deploying PaaS or IaaS services, you must have a configured Virtual Private Cloud (VPC) in AWS.
AWS provides a default VPC with an internet gateway for convenience. While this setup is easy to use, it may lead to higher costs and increased security risks.
For enhanced architecture, security, and cost efficiency, you can create a custom VPC to your requirements.
This blog post outlines my minimal and preferred VPC setup for any new projects I undertake, featuring a highly resilient emphasizing security and cost efficiency.
📂 Poject Source Code 🔗
High Resiliency
The rule of thumb for high availability is to have at least two subnets in different AZs for resource distribution. Additionally, including one AZ for backup ensures compliance and supports AWS resources that may not be available in every AZ.
Subnets
I chose to create subnets in three different AZs, with one designated for backup.
The subnets are also grouped into three types of internet connectivity: Public, Private-NAT, and Private subnets.
- Public Subnet: Configured with an internet gateway, enabling direct internet access. Resources launched here receive public IP addresses, making it ideal for those needing a public endpoint.
- Private Nat Subnet: Configured with a NAT gateway, this setup allows resources to access the internet while remaining hidden from public view. It’s ideal for resources that need internet access without being exposed publicly.
- Private Subnet: Also known as an isolated subnet, it has no internet access. This setup is ideal for internal resources that do not require internet connectivity.
This architecture allows me to run small to medium-scale businesses.
You can create subnets in all available AZs to increase resiliency. However, I found that this approach adds management complexity and potential costs issues.
NAT Gateway and Internet Gateway
For the Internet Gateway, you don’t need to worry about resiliency. It provides high scalability, redundancy, and availability, all managed by AWS. One Internet Gateway can be shared by all public subnets within a VPC.
However, in private NAT subnets, it’s best to create a NAT gateway for each subnet in each AZ to ensure high resiliency in production. If one AZ fails, the NAT subnet in that AZ also fails, which can impact availability. While this approach can be costly, it provides redundancy.
For non-critical applications, you can create a single NAT gateway in one AZ and use it for subnets in other AZs, accepting the risk of a single point of failure.
CIDR Block
It’s also important to consider CIDR range planning for future expansion without affecting existing configurations.
I’ve created a CIDR range of 10.0.0.0/16. In AWS, you can only create private networks using the ranges 10.x.x.x, 172.16.x.x, and 192.168.x.x, with sizes ranging from /16 to /28.
Security
Security is crucial in networking; if your network is compromised, your entire infrastructure is at risk. In AWS VPC, you can simply manage security at the subnet level using Network ACLs.
Network ACLs are stateless and consist of allow and deny rules. This means you must explicitly permit both inbound and outbound traffic for connections to be established.
AWS lets you set rules numbered from 1 to 32766, with lower numbers taking priority. It’s best to start numbering your rules from 100 so you can easily add more rules below 100 later.
I’ve used rule number 3276 to allow 0.0.0.0/0, ensuring that other rules are positioned above it.
Cost Management
Knowing how data transfer influences your costs is vital when working with AWS.
Inbound and Outbound Traffic
Inbound traffic to AWS is free, but outbound traffic from aws to the internet incurs costs, so minimizing outbound data can reduce expenses.
Public Ip and Elastic IP
Public subnets require public or Elastic IPs, which can be expensive, so it’s best to limit their use and consider private subnets when possible.
AZ Data Transfer
Data transfer between different availability zones (AZs) costs money, while transfers within the same AZ are free; therefore, keeping applications that frequently exchange data in the same AZ can save costs.
Utilizing VPC Endpoints
Additionally, using AWS VPC endpoints allows you to transfer data between AWS services without going through the internet, which is more cost-effective, such as connecting EC2 instances to S3 or Systems Manager (SSM) or Cloudwatch etc.
You can access the project code here 🔗 .
I hope you enjoyed the post, and I would love to hear your feedback in the comments below!
Thanks for reading,
-Alon