While preparing for the AWS SAA-C03, many candidates confuse network-layer controls (route tables, NACLs) with application-layer security (security groups). In the real world, this is fundamentally a decision about Defense in Depth vs. Operational Simplicity. Let’s drill into a simulated scenario.
The Scenario #
TechFlow Solutions is deploying a three-tier web application on AWS. Their cloud architect is designing a VPC spanning two Availability Zones, with each AZ containing:
- 1 Public Subnet (for Application Load Balancers)
- 1 Private Subnet (for EC2 application servers)
- 1 Database Subnet (for Amazon RDS instances)
Security Requirement: Only EC2 instances running in the private subnets should be permitted to establish connections to the RDS database instances. Public subnet resources must be explicitly denied access.
Key Requirements #
Implement the most secure and operationally efficient access control mechanism that enforces least-privilege database access.
The Options #
- A) Create a custom route table that excludes routes to the public subnet CIDR blocks, then associate this route table with the database subnets.
- B) Create a security group that denies inbound traffic from security groups assigned to public subnet instances, then attach this security group to the RDS database instances.
- C) Create a security group that allows inbound traffic only from security groups assigned to private subnet instances, then attach this security group to the RDS database instances.
- D) Establish VPC peering connections between the public and private subnets, and another peering connection between the private and database subnets.
Correct Answer #
Option C.
Step-by-Step Winning Logic #
AWS Security Groups support source referencing by security group ID, enabling you to create dynamic, self-maintaining access control lists. This approach:
- Implements Least Privilege: Only explicitly allows traffic from the private subnet security group
- Scales Automatically: New EC2 instances with the private subnet security group gain access automatically
- Maintains Statefulness: Return traffic is automatically permitted (unlike NACLs)
- Zero Infrastructure Cost: No additional AWS charges for security group rules
- Audit-Friendly: CloudTrail captures all security group modifications
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option A? ❌ #
Route tables control routing decisions, not access control.
- Route tables determine where packets are sent (Internet Gateway, NAT Gateway, local VPC)
- They cannot block traffic between subnets in the same VPC
- All subnets in a VPC can communicate by default via the local route (
10.0.0.0/16 → local) - Fundamental Misunderstanding: Confuses Layer 3 routing with Layer 4/7 security
Cost Impact: Unnecessary complexity with zero security benefit.
Why not Option B? ❌ #
Security Groups do not support DENY rules.
- Security Groups are allow-only (implicit deny all)
- You cannot explicitly deny traffic from a specific security group
- This is a Network ACL (NACL) characteristic, not a Security Group feature
- Exam Trap: Tests knowledge of Security Group vs. NACL capabilities
Operational Risk: This configuration is impossible to implement.
Why not Option D? ❌ #
VPC Peering is for connecting separate VPCs, not subnets within the same VPC.
- Subnets in the same VPC communicate natively via the local route
- VPC Peering adds unnecessary complexity and potential routing conflicts
- Incurs data transfer costs ($0.01/GB for cross-AZ peering traffic in some scenarios)
- Architectural Anti-Pattern: Over-engineering a simple security requirement
FinOps Impact: Introduces avoidable data transfer charges (~$73/month per TB transferred).
The Architect Blueprint #
graph TB
subgraph "Availability Zone 1 & 2"
subgraph "Public Subnet"
ALB[Application Load Balancer]
end
subgraph "Private Subnet"
EC2[EC2 Instances
SG: sg-private]
end
subgraph "Database Subnet"
RDS[(RDS Database
SG: sg-database)]
end
end
ALB -->|HTTP/HTTPS| EC2
EC2 -->|MySQL 3306
✅ Allowed by SG Rule| RDS
ALB -.->|❌ No Security Group Rule| RDS
style EC2 fill:#90EE90,stroke:#333,stroke-width:2px
style RDS fill:#FFB6C1,stroke:#333,stroke-width:2px
style ALB fill:#87CEEB,stroke:#333,stroke-width:2px
SecurityRule[SG Rule: Source=sg-private
Port=3306, Protocol=TCP]
SecurityRule -.-> RDS
style SecurityRule fill:#FFFF99,stroke:#FF6347,stroke-width:3px
```
Diagram Note: The RDS security group contains a single inbound rule referencing sg-private (the security group attached to EC2 instances in private subnets), creating a dynamic whitelist that automatically adapts as instances scale.
Real-World Practitioner Insight #
Exam Rule #
“For AWS SAA-C03, when you need to restrict RDS access to specific EC2 instances, always use Security Groups with security-group-based source references rather than CIDR-based rules.”
Real World (FinOps Considerations) #
In production environments, we typically implement defense in depth:
- Security Groups (Primary control): Reference-based rules as shown above
- Network ACLs (Subnet boundary): Optional deny rules for known malicious IP ranges
- IAM Database Authentication: Replace traditional passwords with short-lived tokens
- VPC Endpoints for AWS Services: Prevent data exfiltration via public internet routes
- Database Activity Monitoring: AWS Database Activity Streams for RDS compliance auditing
Advanced Pattern:
Production RDS Security Group:
Rule 1: sg-app-servers (Private Subnet) → Port 3306
Rule 2: sg-bastion-host → Port 3306 (Conditional, time-based via Lambda)
Rule 3: sg-backup-servers → Port 3306 (For AWS Backup or custom solutions)We also leverage AWS Systems Manager Session Manager instead of bastion hosts to eliminate the need for inbound SSH rules entirely.
FinOps Consideration: Security Groups are free, but overly permissive rules can lead to data breach costs averaging $4.45M per incident (IBM 2023 Cost of Data Breach Report). The $0 investment in proper security group configuration provides immeasurable risk reduction.