SkarpChapter 3 of 9
Designing Secure Architectures: Identities, Access, and Data Protection
When every question seems to say “secure” in a different way, how do you know which AWS security tool to reach for? This module turns IAM policies, encryption options, and network controls into a clear decision tree you can apply under time pressure.
Step 1: Security Mindset for the SAA Architect
Security = Right Control, Right Risk
In AWS architecture, security is about choosing the right control for the right risk, not turning on every feature. The exam tests whether you can pick the best-fit control under constraints.
Three Core Questions
1) Who are you? (IAM, roles, policies, federation) 2) From where can you reach it? (VPC, SGs, NACLs, WAF) 3) How is data protected? (encryption at rest/in transit, KMS, keys).
Decision Pattern
1) Identify trust boundary. 2) Pick identity mechanism. 3) Restrict network paths. 4) Layer data protection. Map each exam scenario to these three buckets before picking tools.
Step 2: IAM Building Blocks and When to Use Them
IAM Users
IAM users are long-lived identities, mainly for people. Use sparingly; prefer SSO or federation. Users can have policies directly or via groups.
IAM Roles
Roles provide temporary credentials for AWS services, cross-account access, or federation. Default choice for applications (EC2, Lambda, ECS).
Policies & Evaluation
Identity-based policies attach to users/roles; resource-based policies attach to resources. Deny by default, explicit allow, and explicit deny always wins.
Permission Boundaries
Permission boundaries cap the maximum permissions a user or role can ever get. Use when delegating IAM creation but wanting strict limits.
Quick IAM Choices
Humans → SSO/user. Apps on EC2/Lambda/ECS → role. Cross-account → role + resource policy. Delegated admin with limits → permission boundary.
Step 3: IAM Scenario Walkthrough
Scenario Overview
EC2 app in Account A must read from S3 Bucket A and write to S3 Bucket B in Account B. Developers must not get long-lived access keys.
Step 1: Identity for EC2
Create an IAM role `EC2AppRole` in Account A and attach it as an instance profile to EC2. The instances assume this role automatically.
Step 2: Role Permissions
Attach a policy to `EC2AppRole` with s3:GetObject on Bucket A and s3:PutObject on Bucket B. Keep actions and resources as narrow as possible.
Step 3: Cross-Account S3 Policy
In Account B, add a bucket policy on Bucket B that allows s3:PutObject only from the `EC2AppRole` ARN in Account A. This is a resource-based policy.
Step 4: No Static Keys
The app uses IMDSv2 to get temporary credentials from the role. Developers never see S3 keys, aligning with least privilege and exam best practice.
Step 4: IAM Thought Exercise
You are designing access for three situations. For each, decide what primary IAM construct you would use.
- Data analyst needing console and CLI access to multiple AWS accounts using their corporate login.
- Lambda function that must read messages from an SQS queue and write results to DynamoDB.
- A partner company needs to read from a specific S3 bucket in your account. They already have their own AWS account.
Pause and pick a construct for each before reading the suggested answers below.
Suggested answers (peek only after thinking):
- Federation/SSO (e.g., IAM Identity Center) with roles in each account, not individual IAM users.
- Execution role for Lambda with an identity-based policy allowing SQS read and DynamoDB write.
- Cross-account IAM role in your account that the partner assumes, plus optionally an S3 bucket policy referencing that role.
On the exam, the question stem often hints at the right choice with phrases like "temporary credentials", "no long-lived keys", or "use corporate identities".
Step 5: Network-Level Security – SGs, NACLs, Endpoints, WAF
Security Groups
Security groups are stateful, instance-level firewalls. They only have allow rules and automatically permit return traffic. Use to lock down EC2, RDS, and ALBs.
Network ACLs
NACLs are stateless, subnet-level controls with allow and deny rules. Use for coarse subnet filtering or blocking specific IP ranges.
VPC Endpoints
Gateway endpoints (S3, DynamoDB) and interface endpoints (PrivateLink) let you reach AWS services privately, without internet or NAT.
WAF and Shield
AWS WAF filters HTTP(S) traffic at ALB, API Gateway, CloudFront. Shield provides DDoS protection (Standard for all, Advanced as a paid upgrade).
Network Decision Hints
Instance access → SGs. Subnet-level allow/deny → NACLs. Private service access → VPC endpoints. HTTP request filtering → WAF.
Step 6: Quick Network Security Check
Choose the best answer for this exam-style question.
Your company runs a private app in a VPC. EC2 instances in private subnets must access S3 to store backups. Compliance forbids any internet access from these subnets. What is the MOST appropriate solution?
- Attach an internet gateway and use a NAT gateway for S3 access.
- Create a VPC gateway endpoint for S3 and update route tables.
- Use a VPC peering connection to the S3 service VPC.
- Configure a VPN connection from the private subnets to S3.
Show Answer
Answer: B) Create a VPC gateway endpoint for S3 and update route tables.
A VPC gateway endpoint for S3 allows private access without internet or NAT. Attaching an IGW and NAT violates the 'no internet access' requirement. S3 is not reached via VPC peering or a VPN from your subnets.
Step 7: Data Protection – Encryption at Rest and In Transit
S3 Encryption Options
SSE-S3: AWS manages keys. SSE-KMS: uses KMS keys with fine-grained control. SSE-C: you supply keys per request. Client-side: encrypt before upload.
When to Choose SSE-KMS
Pick SSE-KMS when you need key rotation, granular permissions, or audit logs of key usage via CloudTrail. Use customer managed keys for control.
KMS Key Policies
Key policies define who can use or manage a KMS key. They work with IAM policies, but if the key policy does not allow a principal, access is denied.
Encryption in Transit
Use TLS (HTTPS) for data in transit between clients and AWS, and between services. You can terminate TLS at ALB or use end-to-end TLS based on requirements.
Data Protection Decisions
Control and audit over keys → KMS CMK. Simple S3 encryption → SSE-S3. Maximum control, provider cannot see plaintext → client-side encryption.
Step 8: Sample S3 + KMS Policy Snippets
This step shows minimal JSON snippets you might see in exam explanations or real designs.
- IAM policy allowing a role to use a specific KMS key and S3 bucket:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-secure-bucket/*"
},
{
"Effect": "Allow",
"Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey"],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/abcd-1234"
}
]
}
```
- KMS key policy allowing a specific role to use the key:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAppRoleUseOfKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/AppRole"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
]
}
```
Remember: both the IAM policy and the key policy must permit the action for it to succeed.
Step 9: Key Term Review
Flip these cards to reinforce core concepts.
- IAM Role vs IAM User
- IAM user has long-lived credentials, usually for people. IAM role has temporary credentials and is assumed by principals (apps, users, services). Prefer roles for applications and cross-account access.
- Security Group
- Stateful, instance-level virtual firewall. Supports allow rules only. Automatically allows return traffic. Used to control traffic to EC2, RDS, and other ENI-attached resources.
- Network ACL (NACL)
- Stateless, subnet-level control list. Supports allow and deny rules. Must explicitly allow both inbound and outbound traffic. Good for coarse subnet filtering.
- VPC Endpoint
- Enables private connectivity to AWS services without using the internet. Gateway endpoints for S3 and DynamoDB; interface endpoints (PrivateLink) for many other services.
- SSE-S3 vs SSE-KMS
- SSE-S3: AWS manages keys, simple default. SSE-KMS: uses KMS keys, supports fine-grained access control, key rotation, and detailed audit via CloudTrail.
- KMS Key Policy
- Resource-based policy attached to a KMS key that defines who can use or manage the key. If the key policy does not allow a principal, IAM policies alone are not enough.
- Permission Boundary
- An advanced IAM feature that sets the maximum permissions a user or role can have, even if attached policies are broader. Useful for safely delegating IAM creation.
- AWS WAF
- Web Application Firewall that filters HTTP(S) traffic at ALB, API Gateway, and CloudFront. Protects against common web exploits like SQL injection and XSS.
Step 10: Integrating Identity, Network, and Data Protection
Final integrated scenario check.
A healthcare app runs on EC2 behind an Application Load Balancer. Requirements: - Only users from the corporate IdP can access the app. - EC2 instances must not have direct internet access. - Medical records in S3 must be encrypted with customer-managed keys and access must be auditable. Which combination BEST meets these requirements?
- IAM users for staff, public ALB, NAT gateway for EC2, S3 with SSE-S3.
- Cognito user pools, internet-facing ALB, EC2 in public subnets, S3 with SSE-S3.
- ALB integrated with corporate SSO, EC2 in private subnets with S3 VPC endpoint, S3 with SSE-KMS using CMKs and appropriate key policies.
- Private ALB, EC2 with public IPs, S3 with SSE-C.
Show Answer
Answer: C) ALB integrated with corporate SSO, EC2 in private subnets with S3 VPC endpoint, S3 with SSE-KMS using CMKs and appropriate key policies.
Corporate SSO via ALB authentication handles identity. EC2 in private subnets with an S3 VPC endpoint removes direct internet access. SSE-KMS with customer-managed keys and key policies provides encryption at rest and auditable key usage, matching healthcare-style compliance.
Key Terms
- IAM
- AWS Identity and Access Management, the service that controls who can do what on which AWS resources.
- SSE-S3
- Amazon S3 server-side encryption where S3 manages the encryption keys.
- AWS KMS
- AWS Key Management Service, which creates and manages cryptographic keys and controls their use across AWS services.
- AWS WAF
- AWS Web Application Firewall that filters HTTP(S) traffic at services like ALB, API Gateway, and CloudFront.
- SSE-KMS
- Amazon S3 server-side encryption that uses AWS KMS keys for added control and auditing.
- IAM Role
- An identity with permissions that can be assumed to obtain temporary security credentials. Commonly used by AWS services and for cross-account access.
- IAM User
- A long-lived identity in IAM, usually representing a person. Has permanent credentials unless rotated.
- Network ACL
- A stateless network access control list at the subnet level that supports both allow and deny rules.
- VPC Endpoint
- A private endpoint that allows traffic from a VPC to reach supported AWS services without using the public internet.
- KMS Key Policy
- A resource-based policy attached directly to a KMS key that defines who can use or manage that key.
- Security Group
- A stateful virtual firewall at the instance or ENI level that controls inbound and outbound traffic using allow rules.
- Encryption at Rest
- Protecting stored data using cryptographic techniques so that it cannot be read without decryption keys.
- Permission Boundary
- An IAM feature that sets the maximum permissions a user or role can have, regardless of attached policies.
- Encryption in Transit
- Protecting data as it moves over a network, typically using TLS/HTTPS.
- Client-side Encryption
- Encryption performed by the client before sending data to AWS; AWS only stores ciphertext.