Design Secure Workloads and Applications for SAA-C03

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.

VPC: Virtual Private Cloud, the AWS network boundary for subnets, routes, and attached security controls.

NACL: Network access control list, a stateless subnet-level packet filter.

DDoS: Distributed denial of service, where attackers overwhelm a service with traffic to exhaust capacity.

WAF: Web Application Firewall for Layer 7 request inspection and filtering.

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:

1. What must be reachable from the internet?
2. What should stay private inside the VPC?
3. 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

Traffic-control layers are not interchangeable

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.

Workforce access, customer identity, and secrets are different questions

SAA-C03 often places several identity-flavored services in the same answer set. Do not collapse them into one bucket.

If the users are employees accessing AWS accounts, think workforce identity. If the users are customers signing in to the application itself, think application identity.

Secure external connections to and from AWS

The task statement is not limited to in-VPC design. AWS also tests whether you can pick the right secure connection model at the network boundary.

Do not confuse secure connectivity into AWS with secure identity inside the application. VPN and Direct Connect solve transport questions. Cognito, IAM Identity Center, and Secrets Manager solve different identity or secret-management questions.

Example: private app tier with workload-scoped security and private secret access

This is the kind of secure-workload pattern SAA-C03 expects you to read quickly.

 1Parameters:
 2  VpcId:
 3    Type: AWS::EC2::VPC::Id
 4  PrivateSubnetA:
 5    Type: AWS::EC2::Subnet::Id
 6  PrivateSubnetB:
 7    Type: AWS::EC2::Subnet::Id
 8
 9Resources:
10  AlbSecurityGroup:
11    Type: AWS::EC2::SecurityGroup
12    Properties:
13      GroupDescription: Allow HTTPS from the internet to the ALB
14      VpcId: !Ref VpcId
15      SecurityGroupIngress:
16        - IpProtocol: tcp
17          FromPort: 443
18          ToPort: 443
19          CidrIp: 0.0.0.0/0
20
21  AppSecurityGroup:
22    Type: AWS::EC2::SecurityGroup
23    Properties:
24      GroupDescription: Allow HTTPS only from the ALB
25      VpcId: !Ref VpcId
26      SecurityGroupIngress:
27        - IpProtocol: tcp
28          FromPort: 443
29          ToPort: 443
30          SourceSecurityGroupId: !Ref AlbSecurityGroup
31
32  SecretsManagerEndpoint:
33    Type: AWS::EC2::VPCEndpoint
34    Properties:
35      VpcId: !Ref VpcId
36      ServiceName: !Sub "com.amazonaws.${AWS::Region}.secretsmanager"
37      VpcEndpointType: Interface
38      PrivateDnsEnabled: true
39      SubnetIds:
40        - !Ref PrivateSubnetA
41        - !Ref PrivateSubnetB
42      SecurityGroupIds:
43        - !Ref AppSecurityGroup

What to notice:

• the workload tier does not need direct internet exposure just because users access the application
• security-group intent is workload-specific: the app tier only accepts traffic from the ALB
• the interface endpoint keeps secret retrieval on private paths instead of forcing NAT or public egress

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

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

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
• treating IAM Identity Center and Cognito as if they solve the same identity problem
• treating VPN and Direct Connect as if they answer application-layer security questions
• 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.