AWS VPC Security — Hardening Every Layer for Production

A startup in Bengaluru left port 3306 open to 0.0.0.0/0 on their RDS Security Group. Not their EC2. Their RDS. The database was directly reachable from the internet. It took automated scanners 11 minutes to find it and begin brute-forcing. By the time the team noticed anomalous CloudTrail activity, 2.3 million user records had been exfiltrated.

VPC security is not a one-time setup. It is a layered architecture where each layer catches what the previous one misses. This guide walks through every layer — from subnet design to IAM conditions — the way production security teams at Razorpay and Zerodha implement it.

Why VPC Misconfiguration is the Root Cause of Most AWS Breaches

The AWS Shared Responsibility Model puts network configuration entirely in your hands. AWS secures the physical infrastructure. You secure what runs on it.

The most common VPC mistakes that lead to breaches:

• RDS, ElastiCache, or EC2 instances in public subnets with public IPs
• Security Groups open to 0.0.0.0/0 on sensitive ports (22, 3306, 5432, 6379)
• No VPC Flow Logs — no visibility when something goes wrong
• Single NAT Gateway — availability risk and cross-AZ data transfer costs
• No VPC Endpoints for S3 and DynamoDB — traffic going through the internet unnecessarily

None of these are difficult to fix. All of them are frequently found in production.

Subnet Architecture — Public and Private, Always Separate

The foundational rule: application servers and databases must never be in public subnets. The only resources in public subnets are load balancers, NAT Gateways, and Bastion Hosts.

Three tiers of private subnets give you defence in depth. Even if an attacker reaches the application layer, they cannot directly access the data layer — different Security Groups, different subnets, different route tables.

Disable auto-assign public IP on every private subnet. An EC2 instance accidentally launched in a private subnet with a public IP is a security incident waiting to happen.

Security Groups — The First Line of Defence

Security Groups are stateful allow-only firewalls attached to individual resources. They are the most frequently misconfigured element in AWS environments.

The Security Group chain pattern — enforce it everywhere:

Source is always a Security Group ID — never an IP address or a CIDR range. IPs change when instances restart. Security Group IDs never change. Using SG IDs as sources means your rules stay correct even as your fleet scales up and down.

The rules that must never exist in production:

NACLs — Subnet-Level Defence for Explicit Blocking

Network ACLs are stateless subnet-level firewalls. Unlike Security Groups, they support both allow and deny rules. They evaluate by rule number — lowest number wins.

The primary use case for NACLs: block known malicious IPs. If GuardDuty flags an IP as a threat, or your WAF identifies a DDoS source, add a NACL deny rule immediately.

The stateless trap — ephemeral ports:

NACLs must explicitly allow return traffic. When a client connects to your server on port 443, the response goes back on an ephemeral port (1024-65535) that the client chose. If your NACL blocks outbound traffic on the ephemeral range, the response never reaches the client.

VPC Flow Logs — See Everything That Happens

Without VPC Flow Logs you are debugging network issues blind. Every accepted and rejected connection is recorded — source IP, destination IP, port, protocol, and whether it was accepted or rejected.

Debugging a mysterious connection failure:

At Razorpay, VPC Flow Logs feed into a CloudWatch Metrics Filter that alerts when there are more than 1,000 REJECT events per minute from a single source IP. This is the first indicator of a port scanning or brute-force attempt.

NAT Gateway — One Per AZ, Never One Total

A single NAT Gateway in one AZ creates two problems: it is a single point of failure for internet access, and instances in other AZs pay cross-AZ data transfer fees on every outbound request.

Then associate each private subnet route table with the NAT Gateway in its own AZ. AZ-1a instances route through NAT GW A. AZ-1b instances route through NAT GW B. Neither depends on the other.

VPC Endpoints — Keep AWS Traffic Off the Internet

Private EC2 instances accessing S3 through NAT Gateway pay NAT processing fees ($0.045/GB) for traffic that never needed to touch the internet. A VPC Gateway Endpoint routes S3 and DynamoDB traffic directly through AWS's private network — free of charge.

For a team reading 10 TB/month from S3 through NAT Gateway, this single change saves $450/month. Do it in every VPC from day one.

IAM as a Network Control — The Zero Trust Layer

Modern AWS security treats IAM as a network control. Even if traffic reaches an S3 bucket from inside your VPC, IAM decides whether the specific caller is allowed to access that specific object.

Restrict S3 access to VPC only:

This bucket policy denies all S3 access that does not originate from your specific VPC. Even if someone has valid IAM credentials, they cannot access this bucket from outside the VPC — not from their laptop, not from another AWS account, not from any external system.

Require MFA for sensitive operations:

Network changes require MFA. Even if an attacker steals valid IAM credentials, they cannot open Security Group ports without the physical MFA device.

GuardDuty — Threat Detection Inside the VPC

GuardDuty monitors VPC Flow Logs, CloudTrail, and DNS logs automatically and uses ML to detect threats that rule-based systems miss.

Critical GuardDuty findings to wire up immediately:

Wire findings to EventBridge → Lambda → automated response:

Production Implementation Guidelines

Implement these in order — each builds on the previous:

• Deploy a three-tier VPC on day one: public (LB only), private-app, private-data. Never add this layer later — retrofitting subnets is painful.
• Enforce Security Group chaining using SG IDs as sources — audit weekly using AWS Config rule restricted-ssh and vpc-sg-open-only-to-authorized-ports.
• Enable VPC Flow Logs from the start. Storage cost is minimal. The debugging and incident response value is enormous.
• Create S3 and DynamoDB Gateway Endpoints in every VPC immediately — free, faster, and eliminates unnecessary NAT traffic.
• Enable GuardDuty in every region and every account. Wire findings to EventBridge for automated response.
• Use AWS Config rules to continuously verify your security posture — not just at setup time.

REMEMBER THIS

**References and Further Reading** * [AWS VPC Security Best Practices](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) — official AWS guidance * [AWS GuardDuty findings types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) — full catalogue of threats detected * [AWS Config managed rules](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) — compliance rule library