Design Secure Workloads and Applications for SAA-C03
Learn the subnet, endpoint, security-group, WAF, Shield, and secure-application-access patterns that show up in SAA-C03 workload-security scenarios.
This objective is where AWS combines networking and security into one design problem. SAA-C03 wants to know whether you can place resources in the right subnets, control traffic with the right layers, and expose only the parts of the application that actually need to be reachable.
What AWS is explicitly testing
The current exam guide points to application configuration and credentials security, AWS service endpoints, ports and protocols, VPC security components, segmentation strategies, secure application access, threat vectors such as DDoS and SQL injection, and security services such as Cognito, GuardDuty, Macie, Shield, WAF, and Secrets Manager. In practice, that means you need to reason about public versus private placement, security groups versus NACLs, private service access versus internet egress, and which security service actually fits the threat.
The architecture habit to use
Start with exposure:
- What must be reachable from the internet?
- What should stay private inside the VPC?
- Which service needs private access to AWS dependencies such as S3 or other APIs?
That sequence usually gets you to the right subnet, endpoint, and filtering choices faster than memorizing service names.
Security placement chooser
| Requirement | Strongest first fit | Why |
|---|---|---|
| Internet-facing HTTP application | ALB in public subnets, app tier in private subnets | Exposes the frontend without exposing the whole stack |
| Private subnet access to S3 or DynamoDB | Gateway endpoint | Avoids unnecessary NAT egress |
| Private access to most other AWS services | Interface endpoint | Keeps traffic private without public internet routing |
| Web-layer filtering | AWS WAF | Handles Layer 7 filtering and common web threats |
| DDoS baseline protection | AWS Shield Standard | Included by default for common AWS edge services |
Traffic-control layers are not interchangeable
| Layer | Best use | Common mistake |
|---|---|---|
| Security group | Instance, ENI, or workload-level stateful filtering | Reaching for NACLs first when the requirement is workload-specific |
| Network ACL | Coarse subnet-level stateless filtering | Treating it like a workload-aware firewall |
| WAF | HTTP and HTTPS request inspection | Using it as if it replaces subnet design or security groups |
| Shield | DDoS protection for supported edge-facing services | Expecting it to solve SQL injection or app-layer authorization |
Security groups versus NACLs
Security groups are usually the primary answer because they are stateful, easier to reason about, and attach closer to the workload. NACLs are subnet-level and stateless. They matter, but SAA-C03 often uses them as distractors when a security-group-first design is cleaner.
Secure three-tier pattern
This is the shape AWS wants you to recognize quickly:
flowchart LR
U["Users"] --> A["ALB in public subnets"]
A --> W["Web or app tier in private subnets"]
W --> D["Database tier in private subnets"]
W --> S["S3 or DynamoDB through VPC endpoint"]
What matters here is not the art. It is the exposure model:
- only the load balancer is public
- application and database tiers stay private
- AWS service access does not require public internet egress if an endpoint fits
Private service access and credentials handling
If the application needs private access to AWS services, decide whether a gateway or interface endpoint matches the dependency. If it needs secrets, the exam usually wants you to remove hardcoded credentials rather than rotate bad patterns forever.
| Requirement | Strongest first fit | Why |
|---|---|---|
| S3 or DynamoDB access from private subnets | Gateway endpoint | Low-cost private access without NAT |
| Private access to services such as Secrets Manager or API endpoints | Interface endpoint | Private connectivity for most other AWS services |
| Application secret rotation and retrieval | Secrets Manager | Strong fit when rotation and managed secret handling matter |
Secure application access
If the scenario is about customer-facing sign-in, user identities, or mobile and web app authentication, Amazon Cognito often fits. If the scenario is about infrastructure threat detection or data-classification findings, GuardDuty or Macie fit different jobs. Do not collapse all “security services” into one bucket.
Match the AWS service to the actual threat
| Threat or requirement | Strongest first fit | Why |
|---|---|---|
| SQL injection or HTTP request filtering | AWS WAF | App-layer filtering for web traffic |
| DDoS baseline protection on supported AWS edge services | AWS Shield Standard | Default protection for common edge-facing resources |
| Threat detection from logs and telemetry | GuardDuty | Detects suspicious behavior and potential compromise |
| Sensitive-data discovery or classification findings in S3 | Macie | Data-discovery answer, not network filtering |
| End-user sign-in for web or mobile application | Cognito | Application identity and token management |
SAA-C03 often gives two security services that both sound credible. The better answer is the one that matches the exact layer of the problem.
Failure patterns worth recognizing
| Symptom | Strongest first check | Why |
|---|---|---|
| Private workloads reach AWS services only through a costly NAT path | VPC endpoint fit | The workload may not need internet egress at all |
| The app tier is private, but secrets are still stored in user data or config files | Secret-management design | Network placement does not fix credential sprawl |
| The architecture uses WAF, but backend tiers are still publicly reachable | Subnet and security-group design | App-layer filtering does not replace exposure control |
| A security service is selected because it sounds “protective” | Service-to-threat fit | GuardDuty, Macie, WAF, Shield, and Cognito solve different problems |
Common traps
- putting application instances in public subnets when only the ALB needs to be public
- using NAT when the requirement is really private access to S3 or DynamoDB
- overusing NACL complexity when security groups already solve the problem
- treating GuardDuty, WAF, Shield, and Cognito as interchangeable security answers
- leaving secrets in instance configuration when the real problem is credentials handling
Quiz
Continue with 1.3 Data Security Controls to move from workload placement into encryption, access policy, lifecycle, backup, and replication choices.