Shared Responsibility and the Well-Architected Framework

The shared responsibility model tells you who must protect each layer of an AWS workload. The Well-Architected Framework tells you how to judge whether those choices are good enough. Together they turn a vague statement like "AWS is secure" into an engineering question: which controls are already provided by AWS, which controls must you configure, and which evidence proves the workload is operated well?

In this course section on cloud and account foundations, this lesson connects account setup, identity, Regions, service choice, and operational review. By the end, you should be able to classify responsibilities for common AWS services, use the six Well-Architected pillars to find design gaps, and run a small review that produces concrete remediation work.

Purpose and Outcome

AWS is responsible for security of the cloud: the facilities, hardware, networking, virtualization layer, and managed service infrastructure that make AWS services run. You are responsible for security in the cloud: identities, data, network exposure, application code, workload configuration, and operating procedures. The exact boundary moves by service type. With Amazon EC2 you manage guest operating system patching. With Amazon S3 you do not manage servers, but you still manage bucket policy, object access, encryption choices, retention, and data classification.

The Well-Architected Framework is a review method organized around six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. A review does not certify that an architecture is perfect. It exposes risks, records trade-offs, and helps teams choose improvement work based on impact.

How the Model Works Internally

Think of responsibility as a stack. At the bottom are physical sites, power, cooling, physical network devices, and host fleets. AWS owns those layers. Above that are service control planes: APIs that create buckets, launch instances, attach policies, rotate managed certificates, or modify database settings. AWS operates those control planes, but you decide what API calls are made and by whom. At the top are workload assets: code, data, IAM principals, network routes, logs, backups, and incident response. You own those decisions even when the underlying service is managed.

Service abstraction determines how much of the stack AWS takes on. Infrastructure services such as EC2 give you broad control and therefore more operational responsibility. Container services move some host management to AWS, depending on whether you choose Amazon ECS on EC2, ECS on Fargate, Amazon EKS, or managed node groups. Platform and serverless services such as Lambda, S3, DynamoDB, and managed database services remove more server operations, but they do not remove data governance, least privilege, event design, quota planning, or cost control.

The Well-Architected Framework applies a second lens. It asks whether your choices are deliberate, tested, and measurable. For example, a public S3 bucket might be correct for a website asset bucket, but the security pillar expects you to prove that the public access is intentional, constrained, logged, and separated from private data. The reliability pillar asks what happens if a Region, Availability Zone, dependency, or deployment fails. The cost pillar asks whether the selected service shape matches the workload rather than a habit.

Configuration Anatomy

The model becomes practical when it is translated into policies, account structure, service settings, and review questions. IAM policies describe allowed or denied actions. Resource policies such as S3 bucket policies define who can access a specific resource. Network controls such as VPC route tables, security groups, and network ACLs shape reachability. Data controls include encryption keys, backup plans, lifecycle rules, and retention locks. Operational controls include CloudTrail, CloudWatch alarms, AWS Config rules, runbooks, and deployment rollback procedures.

A useful responsibility statement names the service, the layer, the owner, the control, and the evidence. For example: "For the customer-data S3 bucket, the platform team owns bucket policy, default encryption, public access block, lifecycle rules, and access logging; evidence is the bucket configuration, CloudTrail events, Config compliance, and a quarterly restore test."

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-customer-data",
        "arn:aws:s3:::example-customer-data/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

This policy fragment demonstrates a customer-owned control. AWS provides S3, TLS support, policy evaluation, and durability mechanisms. You decide that insecure transport is not allowed for this bucket and attach a policy that makes HTTP requests fail even if another identity policy would otherwise allow access.

Example 1: Static Assets in S3

A team stores public web images in one S3 bucket and private invoices in another. AWS owns the storage fleet, replication mechanisms inside the service, and S3 API availability targets. The team owns bucket naming, object classification, public access settings, encryption configuration, logging, and lifecycle policy. Expected behavior is different for the two buckets: anonymous reads may succeed for public image objects, while anonymous reads to invoices must return access denied.

The Well-Architected review turns that example into checks. Security asks whether public access is limited to the asset bucket and whether private objects are blocked by both identity and resource configuration. Cost optimization asks whether old image versions should expire. Operational excellence asks whether changes to bucket policy are reviewed and logged. Reliability asks whether accidental deletion is protected by versioning or backup for data that cannot be regenerated.

Example 2: EC2 Web Server

With EC2, AWS operates the physical host, the hypervisor, and the regional infrastructure. You choose the AMI, patch the guest operating system, configure host firewall rules, install the application, rotate instance role permissions, and decide how instances are replaced. If the instance runs an outdated package with a remote code execution vulnerability, that is normally a customer-side failure because the guest operating system and application stack are inside your boundary.

Expected behavior in a sound design is that users reach the service through a load balancer, the instance accepts traffic only from that load balancer security group, and administrators use a controlled management path such as Systems Manager Session Manager rather than opening SSH to the internet. Reliability improves when instances are stateless and launched from an Auto Scaling group across multiple Availability Zones. Cost improves when the instance family and scaling policy match observed traffic.

Example 3: Managed Database Review

Amazon RDS shifts database engine installation, managed backups, host replacement, and optional Multi-AZ failover mechanisms toward AWS. You still choose the engine version policy, schema design, parameter groups, network placement, credentials, encryption keys, backup retention, maintenance windows, and restore testing. If backups exist but nobody has tested a restore into an isolated environment, the reliability risk remains yours.

set -euo pipefail

DB_INSTANCE_ID="orders-prod"

aws rds describe-db-instances \
  --db-instance-identifier "$DB_INSTANCE_ID" \
  --query 'DBInstances[0].{MultiAZ:MultiAZ,Endpoint:Endpoint.Address,Encrypted:StorageEncrypted,BackupDays:BackupRetentionPeriod,Public:PubliclyAccessible}' \
  --output table

This worked check turns the shared boundary into evidence. AWS operates the RDS control plane and underlying managed infrastructure, but the team must verify the instance settings it selected. For a production order database, the expected review result is that MultiAZ is true when the recovery design requires automatic failover, Encrypted is true for regulated or sensitive data, BackupDays meets the recovery policy, Public is false for a private application database, and applications use the returned endpoint rather than an individual host address.

Expected behavior during a Multi-AZ failover is a brief connection interruption followed by reconnection to the database endpoint. Applications should use connection retry logic and avoid hard-coding an individual database host. The Well-Architected security pillar also asks whether the database is private, whether application roles have only the necessary permissions, and whether audit logs are retained long enough for investigations.

Example 4: Turning a Review into Work

Suppose a review finds that a Lambda function processes payment events from a queue, but it has no dead-letter handling and its IAM role can write to every DynamoDB table in the account. The shared responsibility model says AWS runs the Lambda service and DynamoDB service; the team owns function code, event source configuration, retry behavior, and IAM scope. The Well-Architected findings become two work items: add a dead-letter queue with an alarm, and restrict the role to the one table and actions the function actually uses.

The expected deterministic outcome is a smaller permission surface and a visible failure path. A malformed message should move to the dead-letter queue after configured retries, and the function should receive access denied if it tries to write to an unrelated table.

Design Choices and Trade-offs

Choosing a more managed service usually reduces undifferentiated operations, but it can reduce low-level control. EC2 gives maximum control over the operating system, agents, and network stack, but increases patching and recovery responsibility. Lambda removes server management, but changes how you reason about cold starts, timeouts, concurrency, and event retries. RDS reduces database administration toil, but you still need to understand maintenance windows, failover behavior, parameter changes, and restore objectives.

Account design is another trade-off. A single account is simple at first, but it makes blast-radius control and billing separation harder. Multiple accounts add governance overhead, yet they create stronger boundaries for production, security tooling, shared networking, and experimentation. The Well-Architected approach is to make the trade-off explicit: define the isolation requirement, pick the account pattern that meets it, and automate the guardrails.

Failure Modes and Troubleshooting

Symptom: a supposedly private S3 object is reachable by an unexpected principal. Cause: access can be granted by identity policy, bucket policy, access point policy, ACLs in older designs, or public access settings. Diagnose: inspect the bucket public access block, run IAM Access Analyzer, review CloudTrail data events if enabled, and test with the exact principal. Correct: remove unintended grants, block public access where appropriate, prefer bucket-owner-enforced object ownership, and add a Config rule or policy-as-code check.

Symptom: EC2 instances pass health checks after launch but drift over time. Cause: manual changes, missing patch automation, or user data that only works on first boot. Diagnose: compare the instance to the launch template, check Systems Manager inventory and patch compliance, and inspect deployment logs. Correct: rebuild immutable images or bootstrap idempotently, replace instances through Auto Scaling, and record patch compliance as operational evidence.

Symptom: an RDS failover causes a long outage even though Multi-AZ is enabled. Cause: the application caches connections too aggressively, uses low retry counts, or points to an instance-specific address. Diagnose: review application connection strings, database events, client error logs, and retry timing. Correct: use the RDS endpoint, tune connection pools, add retry with backoff, and rehearse failover during a controlled window.

Security, Performance, and Reliability Implications

Security improves when each customer-owned control has an owner and evidence source. IAM should start from required actions, not from administrator convenience. Encryption should include key ownership decisions, not just a checkbox. Logging should capture who changed policies, networks, keys, and data access paths.

Performance and reliability are also shared. AWS provides regional infrastructure and service capabilities, but you select Regions, quotas, scaling policies, cache strategy, and dependency behavior. A service quota that throttles production traffic is not fixed by saying the service is managed. You must measure load, request quota increases before launch when needed, and design clients to handle throttling and retries.

Hands-on Lab: Review One Small Workload

Prerequisites: an AWS account you are allowed to inspect, AWS CLI credentials with read-only access to IAM, S3, EC2, CloudTrail, and Config if available, and a shell with the AWS CLI configured. Do not run this lab in an account you are not authorized to assess.

set -euo pipefail

aws sts get-caller-identity --output json
aws s3api list-buckets --query 'Buckets[].Name' --output table
aws ec2 describe-security-groups --query 'SecurityGroups[].{GroupId:GroupId,GroupName:GroupName,VpcId:VpcId}' --output table
aws cloudtrail describe-trails --output table
aws configservice describe-configuration-recorders --output table

Steps: first, identify one bucket, one compute component, and one data store or queue in the account. Second, write a five-column responsibility table with service, AWS responsibility, customer responsibility, control, and evidence. Third, classify one finding under each Well-Architected pillar. Fourth, choose the highest-risk finding and write the smallest corrective action. Fifth, define how you would verify the correction without relying on a screenshot.

Verification: the CLI identity output must show the intended account, the resource listings must return only resources you are authorized to inspect, and your responsibility table must include evidence for every customer-owned control. A strong result names specific settings such as a bucket policy, security group rule, backup retention value, CloudTrail trail, or alarm.

Cleanup or rollback: this lab is read-only. If you created notes in a ticket or document, mark speculative findings as unverified until an owner confirms them. If you accidentally used broader credentials than intended, discard the session credentials and repeat with a read-only role.

Assessment Exercises

1. An application runs on EC2 instances in a public subnet and stores customer files in S3. Draw the responsibility boundary for patching, network exposure, bucket policy, TLS, and data retention. Which two controls would you verify first and why?
2. A team wants to move a worker from EC2 to Lambda. Explain which responsibilities move to AWS and which remain with the team. Include timeout, retry, IAM, logging, and cost considerations.
3. During a Well-Architected review, a database has backups enabled but no restore test. Which pillar is most directly affected, what is the risk, and what evidence would close the finding?
4. Write a corrective action for an IAM role that uses broad write permissions because developers were unsure which DynamoDB actions were required. Your answer should include a diagnostic step and a verification step.

Summary

Shared responsibility is not a slogan; it is a boundary map for each AWS service and workload layer. The Well-Architected Framework is the review method that tests whether those boundaries are implemented with clear controls and evidence. Use service abstraction to decide who owns what, then use the six pillars to turn hidden assumptions into prioritized engineering work.