Multilevel network security architecture in AWS with VPC, NAT Gateway and perimeter protection

Organizations operating critical infrastructure on AWS face the constant challenge of balancing security with operability. Throughout multiple projects for different clients in highly regulated sectors, I have designed and implemented enterprise network security architectures that transform vulnerable AWS infrastructures with servers directly exposed to the internet into robust, multilevel, and resilient environments.

These clients shared similar vulnerabilities: internal servers with public IP addresses directly accessible from the internet, critical services running in a single availability zone without redundancy, and absence of perimeter security controls that could stop DDoS attacks or web application exploits. The existing infrastructure not only represented a significant security risk but also lacked the necessary resilience to ensure operational continuity in the face of infrastructure failures or malicious attacks.

As an AWS cloud architect specialized in security, I completely transformed these infrastructures by implementing multilevel VPC architectures with strict separation between public and private subnets, multi-availability zone deployment for high availability, NAT Gateways for granular outbound traffic control, AWS Shield and WAF for perimeter protection against attacks, and AWS Backup for disaster recovery. This architectural transformation eliminated single points of failure, drastically reduced the attack surface, and established a defense-in-depth security model that protects critical assets across multiple layers.

Table of Contents

The Challenge: Exposed and Vulnerable Monolithic Infrastructure

The initial state of these infrastructures presented critical security vulnerabilities that exposed businesses to significant risks of compromise, data loss, and operational disruptions.

Problems Identified in Original Architecture

Security Solution Requirements

The transformation required a complete architectural redesign that established:

• Multilevel VPC architecture with strict separation between public subnets (DMZ) and private subnets (internal services).
• Multi-AZ deployment distributing critical resources across 3 availability zones to eliminate single points of failure.
• Redundant NAT Gateway to allow outbound traffic from private subnets without exposing public IPs.
• Layered Security Groups implementing least privilege principle with specific rules per service role.
• Additional Network ACLs as second firewall layer at subnet level.
• Advanced AWS Shield for protection against volumetric, state, and application-layer DDoS attacks.
• AWS WAF with custom rules for detection and blocking of common attack patterns (SQL injection, XSS, etc.).
• Automated AWS Backup with retention and disaster recovery policies.
• Secured bastion host as single administrative entry point.
• Route 53 private DNS for internal name resolution without external exposure.

Implemented Multilevel Security Architecture

The implemented solution establishes a defense-in-depth model with multiple overlapping security layers (solutions) protecting the infrastructure from the perimeter to the most critical internal services.

Main Security Components

Component	Technology	Security layer	Purpose
AWS Shield	DDoS Protection	External perimeter	Automatic protection against volumetric network and transport attacks
AWS WAF	Web Application Firewall	Application perimeter	HTTP/HTTPS traffic filtering with custom anti-exploit rules
Multilevel VPC	Public/private subnets	Network segmentation	Isolation of front-end and back-end services in differentiated subnets
NAT Gateway	Network Address Translation	Outbound traffic control	Controlled outbound access from private subnets without public IPs
Internet Gateway	VPC Gateway	Controlled entry	Bidirectional communication only for resources in public subnets
Security Groups	Stateful EC2 firewall	Instance control	Specific inbound/outbound traffic rules per service role
Network ACLs	Stateless subnet firewall	Subnet control	Additional deny/allow rules at complete subnet level
Route Tables	Routing tables	Flow control	Specific routes determining accessibility of each subnet
Bastion Host	Hardened EC2 + 2FA	Administrative access	Single SSH entry point with multifactor authentication
AWS Backup	Backup service	Disaster recovery	Automated EC2, RDS, EFS snapshots with configurable retention

Multilevel VPC Architecture Diagram

Solution 1: VPC Restructuring with Multilevel Architecture

Public and Private Subnet Design

The fundamental redesign consisted of creating a completely new VPC with strict segmentation between public subnets (accessible from the internet) and private subnets (completely isolated), distributed across 3 availability zones to ensure high availability.

Implemented IP addressing scheme:

Subnet name	CIDR	Availability Zone	Type	Purpose
public-1a	10.0.11.0/24	us-east-1a / eu-west-1a	Public	Load balancers, bastion host, NAT Gateway
public-1b	10.0.12.0/24	us-east-1b / eu-west-1b	Public	Redundant load balancers, NAT Gateway
public-1c	10.0.13.0/24	us-east-1c / eu-west-1c	Public	Redundant load balancers, NAT Gateway
private-1a	10.0.16.0/24	us-east-1a / eu-west-1a	Private	Application servers, internal services
private-1b	10.0.17.0/24	us-east-1b / eu-west-1b	Private	Redundant application servers
private-1c	10.0.18.0/24	us-east-1c / eu-west-1c	Private	Redundant application servers

Note: The gap between 10.0.13.0/24 and 10.0.16.0/24 reserves IP ranges for future additional availability zones that AWS may enable.

Public Subnets: Controlled Exposure Zone

Public subnets are network segments specifically designed to host resources that must be accessible from the internet under strict control. These resources act as a protected entry layer before reaching critical internal services.

Resources deployed in public subnets:

Internet Gateway: Bidirectional Entry Point

The Internet Gateway (IGW) is the fundamental component that enables bidirectional communication between the VPC and the public internet. It is an AWS-managed service, highly available and horizontally scalable without manual intervention.

Technical characteristics of Internet Gateway:

• Automatic 1:1 NAT translation: Automatically converts private IP addresses of instances in public subnets to their associated public Elastic IPs.
• Unlimited scalability: AWS manages all necessary capacity and redundancy without configurable bandwidth limits.
• Stateful: Automatically allows responses to connections established from public subnets without explicit rules.
• No additional cost: Included in VPC pricing without traffic processing charges.

Inbound traffic flow through Internet Gateway:

Internet traffic passes through AWS Shield and WAF before reaching the Internet Gateway, which routes it to the appropriate Route Table for the public subnet. From there, the Application Load Balancer distributes traffic to Target Groups, which forward requests to EC2 instances in private subnets.

Routing table for public subnets:

Public subnets have a default route (0.0.0.0/0) pointing to the Internet Gateway, enabling direct internet communication. All intra-VPC traffic uses the local route, while internet-bound traffic is directed through the Internet Gateway.

Private Subnets: Complete Isolation from Public Internet

Private subnets represent the protected core of the infrastructure where critical services reside completely isolated from direct internet access. No instance in private subnets has a public IP assigned.

Resources deployed in private subnets:

• Application servers: EC2 instances running web applications, REST APIs, backend services.
• RDS databases: PostgreSQL, MySQL, Aurora with Multi-AZ mode for high availability.
• EFS volumes: Shared NFS storage for static files, user uploads, shared assets.
• Internal services: Redis, Memcached, RabbitMQ, queue systems, asynchronous processing workers.

Routing table for private subnets:

Private subnets have NO direct route to Internet Gateway, guaranteeing complete isolation. Their default route points to a NAT Gateway (see Solution 2) that allows only outbound traffic initiated internally. All intra-VPC traffic uses the local route.

Fundamental security implications:

Solution 2: NAT Gateway for Outbound Traffic Control

Multi-AZ Redundant NAT Gateway Architecture

NAT Gateways allow servers and services located in private subnets without public IP to initiate outbound connections to the internet (security updates, external APIs, third-party services) while remaining completely inaccessible from the outside.

NAT Gateway security features:

Traffic Flow Through NAT Gateway

When a server in private subnet needs to access an external service:

Security benefits:

1. Minimized attack surface: Internal servers are completely invisible from internet (no public IP).
2. Impossibility of direct inbound attacks: An attacker cannot scan or connect to internal services.
3. Centralized auditing: All outbound traffic passes through NAT Gateways monitored with VPC Flow Logs.
4. Resilience: NAT Gateway is a managed high-availability service without operational maintenance.

Solution 3: Perimeter Security with AWS Shield and WAF

AWS Shield: Protection Against DDoS Attacks

AWS Shield Standard is automatically enabled on all AWS resources at no additional cost, providing protection against the most common DDoS attacks at network and transport layers (OSI model layers 3 and 4).

Components protected by AWS Shield in the architecture:

Automatic protection mechanisms:

• Inline detection: Real-time traffic analysis to identify anomalous patterns characteristic of DDoS.
• Automatic mitigation: Immediate activation of countermeasures without manual intervention or waiting time.
• Malicious traffic absorption: Distributed AWS infrastructure absorbs volumetric attacks before they reach resources.

AWS WAF: Web Application Firewall

AWS WAF (Web Application Firewall) provides an additional security layer by inspecting HTTP/HTTPS traffic and blocking malicious requests according to defined custom rules.

Implemented WAF rules:

Rule type	Target	Description
SQL Injection	SQL injection attacks	Detects and blocks SQL code injection attempts in URL parameters, headers, body
Cross-Site Scripting	XSS attacks	Prevents injection of malicious JavaScript scripts in form fields
Rate limiting	Brute force attacks	Limits requests per IP (e.g., 2000 req/5min) to prevent scans and brute force
Geo-blocking	Geographic restriction	Blocks traffic from specific countries with high malicious activity
IP reputation lists	Known IP blocking	Integration with AWS and third-party reputation lists to block malicious IPs
Bot control	Bot detection	Identifies and controls legitimate and illegitimate automated traffic
Custom rules	Specific protection	Custom rules based on observed attack patterns

AWS WAF integrates directly with Application Load Balancers, inspecting all HTTP/HTTPS traffic before it reaches backend EC2 instances. Custom WAF rules include dynamic whitelist updates via Lambda functions to maintain authorized corporate IPs without manual intervention.

Solution 4: Layered Security Groups and Network ACLs

Security Groups: Stateful Firewall at Instance Level

Security Groups function as stateful virtual firewalls controlling inbound and outbound traffic for individual EC2 instances. Being stateful, they automatically allow response traffic to established connections.

Security Groups strategy by layers:

Layer	Security Group	Inbound rules	Outbound rules
Load Balancer	sg-alb-public	0.0.0.0/0:443 (HTTPS) 0.0.0.0/0:80 (HTTP)	sg-web-servers:8000 (App)
Web Servers	sg-web-servers	sg-alb-public:8000 sg-bastion:22 (SSH)	0.0.0.0/0:443 (HTTPS outbound) sg-database:3306 (MySQL)
Database	sg-database	sg-web-servers:3306 sg-bastion:3306 (tunnel)	None
Bastion Host	sg-bastion	Corporate IPs:12119 (SSH)	sg-web-servers:22 sg-database:22
NAT Gateway	sg-nat	sg-web-servers:any	0.0.0.0/0:any

Applied design principles:

1. Least privilege: Only strictly necessary ports are opened for the specific service function.
2. Security Group reference: Instead of specifying IPs, other Security Groups are referenced (e.g., sg-web-servers can connect to sg-database).
3. Separation of responsibilities: Each application layer has its own Security Group with specific rules.
4. No “allow all” rules: 0.0.0.0/0 is never used for traffic between internal layers.

Network ACLs: Stateless Firewall at Subnet Level

Network ACLs (Access Control Lists) operate at the complete subnet level as an additional stateless security layer. Unlike Security Groups, ACLs are stateless (don’t track connection state) and evaluate numbered rules in sequential order.

Network ACL for private subnets:

Rule #	Type	Protocol	Port	Source/Destination	Action	Purpose
100	Inbound	TCP	8000	10.0.11.0/24 (public)	ALLOW	Traffic from ALB
110	Inbound	TCP	22	10.0.11.0/24 (public)	ALLOW	SSH from bastion
120	Inbound	TCP	1024-65535	0.0.0.0/0	ALLOW	Ephemeral port responses
*	Inbound	ALL	ALL	0.0.0.0/0	DENY	Deny rest
100	Outbound	TCP	3306	10.0.0.0/16	ALLOW	MySQL to RDS
110	Outbound	TCP	443	0.0.0.0/0	ALLOW	HTTPS outbound
120	Outbound	TCP	1024-65535	0.0.0.0/0	ALLOW	Ephemeral port responses
*	Outbound	ALL	ALL	0.0.0.0/0	DENY	Deny rest

The combination of Security Groups (stateful, instance level) and Network ACLs (stateless, subnet level) provides defense in depth with two independent layers of traffic filtering.

Layered defense advantages:

• If an attacker discovers a vulnerability in Security Group rules, Network ACL provides second line of defense.
• Network ACLs allow explicit blocks (DENY rules) that Security Groups don’t support.
• The combination provides detailed logs in VPC Flow Logs for forensic analysis.

Solution 5: Multi-AZ Deployment for Resilience

Critical Resource Distribution Across Availability Zones

Multi-AZ (multi-availability zone) deployment distributes critical resources across 3 physically separate data centers within the same AWS region, eliminating single points of failure at infrastructure level.

Multi-AZ distributed components:

Failure scenarios and automatic recovery:

Failure scenario	Impact without multi-AZ	Impact with multi-AZ	Recovery time
EC2 server failure	Complete service outage	Auto Scaling launches new server in healthy AZ	2-5 minutes
Availability zone failure	Total system outage	ALB redirects traffic to healthy AZs	~30 seconds
NAT Gateway failure	Loss of outbound connectivity	Traffic redirected to NAT in another AZ automatically	Instantaneous
RDS database failure	Total data loss until restoration	Automatic failover to standby replica in another AZ	60-120 seconds

Auto Scaling Groups for Self-Healing

Auto Scaling Groups continuously monitor EC2 instance health through Application Load Balancer health checks. When an instance fails or becomes unhealthy, the group automatically terminates it and launches a replacement in a healthy availability zone.

Multi-AZ Auto Scaling Group configuration:

Replacement strategies:

• Balanced distribution: Auto Scaling maintains similar number of instances in each AZ.
• Different AZ replacement: If a complete AZ fails, instances are replaced in healthy AZs.
• Golden Image AMI: New instances launch from pre-configured AMI ensuring consistency.

Solution 6: Bastion Host and Controlled Administrative Access

Single Entry Point with Multifactor Authentication

The bastion host (also known as jump box) is a specially hardened EC2 instance located in a public subnet that functions as the single SSH entry point to the internal infrastructure. This design eliminates the need to assign public IPs to internal servers.

Bastion host security features:

• Two-factor authentication (2FA): Combination of RSA key + mandatory Google Authenticator TOTP.
• Role-based access control: User groups with specific permissions (admin, developer, external-ro, external-rw, sftp-only).
• Complete session auditing: Recording and playback of all administrative activity through sudo logging and sudoreplay.
• Encrypted SSH tunnels: Secure access to internal services (RDS, SFTP, Windows RDP) without exposing ports.
• Restrictive Security Group: Only SSH port (non-standard) accessible from whitelisted corporate IPs.

Administrative access flow:

Solution 7: AWS Backup for Disaster Recovery

Multi-Service Automated Backup Strategy

AWS Backup provides a centralized and automated service for managing backups of multiple AWS services with retention, encryption, and cross-region recovery policies.

Backed-up resources in the architecture:

Resource type	Backup frequency	Retention	Secondary destination
EC2 Instances	Daily at 02:00 UTC	7 daily 4 weekly 6 monthly	Cross-region to secondary region
RDS Aurora	Continuous (Point-in-Time) + Daily snapshot	7 automatic days 35 days Point-in-Time	Automatic cross-region replica
EFS Volumes	Daily at 03:00 UTC	7 daily 4 weekly	Replication to secondary region
DynamoDB Tables	Continuous (Point-in-Time)	35 days PITR	Optional cross-region replica

Automated backup policy:

The implemented backup strategy includes daily, weekly, and monthly backups with automated lifecycle management. Daily backups are retained for 7 days with transition to cold storage after 30 days, and automatic cross-region replication to Frankfurt. Weekly backups maintain 28-day retention, while monthly backups are kept for 180 days with cold storage transition after 90 days.

Disaster recovery process:

1. EC2 recovery: AMIs generated by AWS Backup launch as new instances with identical configuration.
2. RDS recovery: Restore from snapshot or Point-in-Time Recovery with second granularity.
3. EFS recovery: Direct mounting of backup point or creation of new filesystem from snapshot.
4. Cross-region recovery: In case of complete regional disaster, restoration from secondary region (Frankfurt).

Advantages of AWS Backup vs manual snapshots:

Solution 8: VPC Peering for Cross-Region Disaster Recovery

Secure Connectivity Between AWS Regions

VPC Peering enables establishing private network connections between VPCs located in different AWS regions, creating a direct communication path that doesn’t traverse the public internet. This architecture was fundamental for implementing cross-region Disaster Recovery (DR) strategies for several clients with high availability and business continuity requirements.

Typical implementation scenario:

Primary region	Secondary region (DR)	Peering purpose
eu-west-1 (Ireland)	eu-central-1 (Frankfurt)	Data replication, automatic failover, shared resource access
us-east-1 (Virginia)	us-west-2 (Oregon)	Cross-region backup, standby services, data synchronization

VPC Peering Security Features

Implemented VPC Peering Use Cases

Solution 9: Secure Hybrid Connectivity with On-Premise Infrastructure

Corporate Environment Integration with AWS

Several clients operated existing on-premise infrastructure that required secure and reliable connectivity with resources deployed on AWS. We implemented hybrid connectivity solutions using different technologies according to each client’s specific requirements: latency, bandwidth, regulatory compliance, and budget.

Implemented connectivity solutions:

Technology	Use cases	Latency	Bandwidth	Cost
AWS Site-to-Site VPN	Corporate offices, administrative access, non-critical traffic	~50-100ms (over internet)	Up to 1.25 Gbps	Low
AWS Direct Connect	Massive data replication, latency-sensitive apps, compliance	~10-20ms (dedicated)	1-100 Gbps	High
VPN over Direct Connect	Maximum security for regulated data, end-to-end encryption	~15-25ms	1-10 Gbps	Medium-High

For clients with existing on-premise infrastructure, I implemented secure connectivity between corporate data centers and AWS using two approaches based on their specific requirements:

AWS Site-to-Site VPN was deployed for clients requiring encrypted connectivity over the internet. This solution established IPsec tunnels between the Customer Gateway (client’s on-premise router) and the Virtual Private Gateway in AWS, providing redundant tunnels and BGP routing for automatic failover.

AWS Direct Connect was implemented for clients with high bandwidth requirements (1-10 Gbps) or regulatory compliance mandating that data not transit public internet. This dedicated fiber connection provided consistent low latency and predictable performance for database replication and latency-sensitive applications.

For clients requiring both bandwidth and end-to-end encryption, I configured hybrid architectures combining Direct Connect as the high-speed primary connection with Site-to-Site VPN layered on top for encryption, ensuring compliance with GDPR and HIPAA requirements.

Results and Business Impact

The implemented architecture transformed the security posture and operational resilience of these infrastructures:

Security improvements: Complete elimination of public IPs on internal servers and databases drastically reduced the attack surface. AWS Shield and WAF provided automatic protection against DDoS attacks and common web exploits (SQL injection, XSS). The multilevel network segmentation established physical and logical separation between front-end and back-end services.

High availability: Multi-AZ deployment eliminated single points of failure with automatic failover capabilities. Auto Scaling Groups provided self-healing for EC2 instances, while RDS Aurora maintained automatic database failover to standby replicas. Cross-region backup replication ensured recovery capabilities even in complete regional disasters.

Compliance: The architecture aligned with GDPR, SOC 2, ISO 27001, and PCI DSS requirements through documented technical controls. VPC Flow Logs enabled complete network traffic capture for forensic analysis, while the bastion host with 2FA provided traceable administrative access.

Key Technical Achievements

Lessons Learned

What worked exceptionally well:

1. Physical public/private subnet separation: Strict network segmentation completely eliminated direct attack vectors to critical internal services.
2. NAT Gateway per AZ: Deploying independent NAT Gateway in each availability zone avoided costly cross-AZ traffic and single points of failure.
3. Centralized AWS Backup: Unified backup management for EC2, RDS, and EFS simplified operations and ensured consistency in retention policies.
4. Security Groups by reference: Using Security Group references instead of specific IPs facilitated scaling and maintenance without constantly modifying rules.
5. VPC Flow Logs from day one: Enabling network flow logging from the start provided complete visibility for troubleshooting and security analysis.

Technical challenges overcome:

1. Zero-downtime migration: Required cutover strategy with reduced DNS TTL and data synchronization to migrate services from old architecture to new VPC without interruptions.
2. Routing table complexity: Requires exhaustive documentation and traffic flow diagrams to avoid configuration errors causing connectivity loss.
3. NAT Gateway costs: NAT Gateway has hourly cost and per-GB processed. Implemented traffic analysis to optimize usage and avoid billing surprises.
4. Initial WAF false positives: WAF rules generated some legitimate blocks initially, requiring fine-tuning based on real traffic patterns.
5. Corporate static IP management: Clients with dynamic IPs for bastion access required implementation of dynamic Security Group update solution via Lambda.

Conclusion

This AWS network security transformation project represents a complete case study on how to redesign vulnerable and monolithic architectures into resilient, secure, and scalable enterprise infrastructures. By implementing a multilevel VPC with strict separation between public and private subnets, redundant NAT Gateway for outbound traffic control, multi-AZ deployment for high availability, AWS Shield and WAF for perimeter protection, and AWS Backup for disaster recovery, these organizations completely transformed their security posture.

The resulting architecture not only eliminates single points of failure and drastically reduces the attack surface but also establishes a defense-in-depth model with multiple overlapping security layers protecting critical assets from the perimeter to the most sensitive internal services. This architectural approach is applicable to any organization operating infrastructure on AWS and requiring security, availability, and regulatory compliance guarantees.

Key Conclusions for Similar Projects

1. Network segmentation is fundamental: Separation between public and private subnets should be the first step in any production AWS architecture.
2. NAT Gateway vs NAT Instance: Using managed NAT Gateway instead of self-managed NAT Instances eliminates maintenance operations and ensures availability.
3. Multi-AZ is not optional: Deploying critical resources in multiple availability zones should be a baseline requirement, not a later optimization.
4. Layered Security Groups: Implementing service role-specific security groups facilitates maintenance and complies with least privilege principle.
5. WAF requires fine-tuning: Generic WAF rules can generate false positives; they require calibration based on legitimate traffic patterns specific to each application.
6. Automated AWS Backup from start: Configuring automated backups from day one prevents data loss from unexpected incidents.
7. Network flow documentation: Maintaining updated diagrams of traffic flows and routing tables is critical for rapid troubleshooting.

---