1.7 The Shared Responsibility Model for Solutions Architects

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

1.7 The Shared Responsibility Model for Solutions Architects

Key Takeaways Explain This Topic AI

AWS is responsible for security OF the cloud — hardware, networking, hypervisor, facilities, and managed-service platforms.

The customer is responsible for security IN the cloud — data, IAM, guest-OS patching on EC2, encryption, and network configuration.

Responsibility shifts toward AWS as services become more managed: EC2 (IaaS) > RDS (managed) > Lambda/S3 (serverless).

Encryption choices and data classification are ALWAYS the customer's responsibility, regardless of service type.

Architects must explicitly design controls for the customer side rather than assuming AWS covers everything.

Last updated: June 2026

Quick Answer: AWS secures OF the cloud (facilities, hardware, hypervisor, managed-service platforms). You secure IN the cloud (data, IAM, encryption choices, guest-OS patches on EC2, application code). The more managed the service, the less you manage — but data classification and encryption are always yours .

The Core Split

Think of one dividing line. AWS owns everything below the line; you own everything above it. Where that line falls depends entirely on the service type .

• Layer AWS Owns Customer Owns
• Facilities / physical Data centers, guards, power, cooling —
• Hardware Servers, storage, network gear —
• Hypervisor / virtualization Host OS, hypervisor isolation —
• Network infrastructure Global backbone, edge VPC, subnets, SGs/NACLs
• Guest OS For managed services (RDS, Lambda) For EC2 instances
• Application / runtime Managed-service internals Your code and config
• Data — Classification, encryption, backup
• Identity The IAM service itself IAM policies, roles, MFA , key rotation
• Responsibility Shifts by Service Type
• IaaS — Amazon EC2 (maximum customer responsibility)

• Customer Manages AWS Manages
• Guest-OS patches and updates Physical hardware
• Application install/patching Hypervisor
• Security group / NACL config Network infrastructure
• Data encryption (EBS/KMS) Host OS and firmware
• IAM and key management Facility security
• Managed — Amazon RDS, ElastiCache (shared)

• Customer Manages AWS Manages
• DB user accounts and IAM OS and DB-engine patching
• Security group config Automated backups (if enabled)
• Encryption settings (KMS) Multi-AZ failover
• Network placement (VPC/subnet) Hardware and infrastructure
• Serverless — AWS Lambda, S3, DynamoDB (minimal customer responsibility)

• Customer Manages AWS Manages
• Function code and dependencies Runtime patching
• IAM execution roles / policies Scaling and availability
• Encryption settings and data All underlying infrastructure
• Resource policies (e.g., bucket policy) Host and OS

On the Exam: "Who patches the OS on an EC2 instance?" → Customer . "Who patches the OS on an RDS instance?" → AWS . The single deciding factor is the service type (IaaS vs. managed vs. serverless).

Why This Matters to an Architect

The model is not trivia — it shapes design reviews. If you choose EC2, your design must include a patch strategy (Systems Manager Patch Manager), guest-level hardening, and OS-level logging, because AWS will not do any of that for you. Choose a managed or serverless equivalent and those duties disappear, which is often why the exam's "most operationally efficient" answer favors managed services. Regardless of service, the customer always owns data classification, encryption decisions, and account/identity configuration — a public S3 bucket or a leaked access key is never AWS's fault under this model.

Quick Duty-to-Owner Reference

• Duty EC2 RDS Lambda/S3
• Patch OS Customer AWS AWS
• Patch DB/runtime Customer AWS AWS
• Configure SG/NACL Customer Customer Customer (where applicable)
• Choose encryption Customer Customer Customer
• Physical security AWS AWS AWS
• Patch Management as a Design Decision

Because the customer owns OS patching on EC2, the exam expects you to name the AWS tool that operationalizes it: AWS Systems Manager Patch Manager scans and patches managed instances on a schedule using patch baselines and maintenance windows. This is the standard answer to "keep hundreds of EC2 instances patched with minimal operational effort." It does not apply to RDS or Lambda, where AWS already patches the platform — recognizing that boundary keeps you from proposing Patch Manager for a managed service.

Mapping the Model to Compliance

Auditors care which party owns each control. Under frameworks like PCI DSS or HIPAA, AWS provides attestations for the OF the cloud layers (delivered through AWS Artifact), while the customer must demonstrate controls for the IN the cloud layers — encryption configuration, IAM least privilege, logging, and network isolation. This is why "inherited controls" appear in audit conversations: the customer inherits AWS's data-center and hypervisor controls but must still prove their own configuration.

A HIPAA workload, for instance, requires the customer to sign a Business Associate Addendum , enable encryption, and restrict access, even though AWS secures the physical infrastructure.

Worked Scenario

A company runs a three-tier app: an ALB, EC2 web servers, an RDS MySQL database, and an S3 bucket for uploads. Who does what? AWS patches the RDS engine and OS, runs the ALB and S3 platforms, and secures all hardware. The customer patches the EC2 guest OS , writes the application code, configures every security group and bucket policy , enables encryption on EBS, RDS, and S3, sets up IAM roles for the instances, and classifies the uploaded data. Notice that across every tier the customer owns identity, network configuration, and encryption — the three duties that never shift to AWS regardless of service.

Exam framing: When a question says "most operationally efficient," the model nudges you toward more-managed services precisely because they move patching and availability duties to AWS — but never assume AWS owns your data, identities, or encryption choices.