Designing VPC with Security First Mindset

Everyone is moving to Cloud for deployment of their workload and hence it is pretty important to ensure that the logical network in which workload is deployed is hardened enough to ensure that security is not compromised.

In this article, I will be covering how to design a AWS Virtual Private Cloud (VPC) with Security First mindset. This set-up can be used for Production level deployment as well.

Here is the high level requirement of the application to be deployed:

1. 3-tier Web Application. Has a Web tier for serving web pages and content, Application tier for the business logic execution and Data tier for persisting the data in the system for long term storage.
2. Application tier integrates with AWS Simple Storage Service (S3) for persisting files and with AWS Simple Email Service (SES) for sending emails.
3. Application tier also interacts with another 3rd party service which exposes a public endpoint over HTTPs.
4. High Availability required for Web and Application Server.

And below is the security requirement:

1. The Web tier should be open to all and is allowed to serve requests on HTTPs only.
2. Application tier can accept requests HTTPs requests only from the Web tier
3. The Data tier can be accessed only from Application tier.
4. Developers should be allowed to connect to servers in Web tier or Application tier for debugging purpose over SSH from corporate network only.
5. Traffic from Application tier to to S3 and SES should not be exposed to Internet.
6. End to End encryption of data in transit.

Well, the requirements are pretty standard. Let’s see how we can design our AWS VPC to ensure above requirements are met.

General Flow

For Web Access over HTTPs —

End User -> Access Web via Browser -> DNS Resolution performed (Not covered in the diagram) -> Traffic reaches Internet Gateway -> Enters Internet facing Web Server Load Balancer -> Load Balancer sends traffic to one of the Health Web Server Instance -> Web Server calls Application Server API over HTTPs via Application Server Load Balancer (Internal) -> Load Balancer forwards traffic to one of the Healthy Application Server Instance -> Application Server interacts with Database and performs the required job. And data flows back.

SSH —

Corporate User -> Access Bastion over SSH via SSH client -> DNS resolution performed (Not covered in the diagram) -> Traffic reaches Bastion and authentication happens via Public/Private Keys -> Once in Bastion, user can connect to other Web and Application instances over SSH.

Key points for the VPC and Application Deployment:

1. Multi Availability Zone (AZ) deployment to handle failure of AZ. For simplicity, I have represented 2 AZs. This can go further to 3 or more depending on the requirement and availability of AZs in the region you are deploying.
2. Each AZ has multiple subnets created (details captured later)
3. Auto Scaling Group configured for Web and Application Server for scalability.
4. Traffic for Web Servers is funneled via Internet Facing Application Load Balancer (ALB) and Traffic for Application Sever is funneled via Internal Application Load Balancer.
5. Bastion (Jump Box) deployed in Ingress subnet for SSH access from corporate Network.
6. VPC Gateway Endpoint is configured for S3 access — which sends traffic to S3 via AWS backbone network and does not take Internet route.
7. VPC Interface Endpoint configured for SES access — which sends traffic to SES via AWS backbone network and does not take Internet route.

Subnets

Four Subnets are created in each Availability Zone. They are:

1. Ingress — This is a public subnet with route configured to Internet Gateway. Bastion (Jump Box) and Internet facing Application Load Balancer for Web Servers will be hosted here. Traffic getting into the system gets comes via this subnet.
2. Egress — This is also a public subnet with route configured to Internet Gateway. This has NAT Gateway deployed. Traffic for accessing other systems over Internet is routed via this Subnet.
3. Application — This is a private subnet with route configured to NAT Gateway. Web Servers, Application Servers and Internal Application Load Balancer for Application Server will be hosted here.
4. Data — This is also a private subnet but no route configured to NAT Gateway. AWS RDS Database instance will be hosted here.

Route Table

Every subnet has its own Custom Route Table (and not the default main route table created at the time of VPC creation). This allows to control routes for each subnet should there be a need.

1. Route table for Ingress will have routes to send traffic to — a) local endpoints in the VPC CIDR range and b) 0.0.0.0/0 via Internet Gateway.
2. Route table for Egress will have routes to send traffic to — a) local endpoints in the VPC CIDR range and b) 0.0.0.0/0 via Internet Gateway.
3. Route table for Application subnet will have routes to send traffic to — a) local endpoints in the VPC CIDR range, b) access S3 via Gateway VPC Endpoint and c) To 0.0.0.0/0 via Internet Gateway.
4. Route table for Data subnet will have route to send traffic to local endpoints configured in the VPC CIDR range.

Network Access Control List (NACL)

If you look very closely to the diagram, both Ingress and Egress are public subnets. And I am sure there must be a question on why do we need to public subnets. Well, time to answer !!!

We will have 2 NACLs created in the VPC. One NACL shall be attached to Ingress, Private and Data subnets and the other NACL is reserved only for Egress subnet. It gives me much better control for the outgoing traffic initiated from the instances in other subnets — which all servers to allow traffic to and which all to block — based on let’s say the Enterprise firewall rules.

Security Group

If you look at the VPC Deployment diagram, there are multiple Security Groups configured for each tier to allow only the designated traffic into the system. Anything other than the allowed traffic automatically gets denied.

1. Security Group for Bastion (SG-Bastion) allows traffic on port 22 from the Corporate Network IP range only.
2. Security Group for Web Server ALB (SG-Web-ALB) allows traffic from anywhere on HTTPs protocol.
3. Security Group for Web Server instances (SG-Web) allows traffic from SG-Bastion over SSH and SG-Web-ALB over HTTPs.
4. Security Group for Application Server ALB (SG-App-ALB) allows traffic only from SG-Web over HTTPs.
5. Security Group for Application Server instances (SG-App) allows traffic from SG-Bastion over SSH and SG-App-ALB over HTTPs.
6. Security Group for RDS Database instance (SG-Data) allows traffic only from SG-App over Database port (lets say 3306 for MySQL)

In my next article, I plan to cover how to remotely access instances (both Linux and Windows) running in private subnets via Bastion. Stay tuned !!!