Cloud security is a partnership. AWS protects the infrastructure, and you protect your data and configuration. Understanding this split the AWS Shared Responsibility Model is the first step toward a secure, auditable cloud environment.
What the model is and why it matters
The Shared Responsibility Model defines who owns which controls. It prevents confusion in audits and helps answer questions like:
- Who encrypts data at rest?
- Who patches the hypervisor?
- Who configures S3 bucket policies?
Getting those answers upfront reduces risk, speeds incident response, and clarifies compliance scope.
AWS responsibilities: "Security of the cloud"
AWS secures the global backbone: Regions, Availability Zones, physical datacenters, and the host infrastructure that runs services.
- Physical security of data centers and networking
- Host operating systems, hypervisors and virtualization layer
- Underlying hardware and foundation services
- For many managed services, AWS also operates server-side encryption and platform hardening
Quick reference: what AWS manages by service category
| Category | Examples | AWS responsibility |
|---|---|---|
| Infrastructure services | EC2, VPC | Physical hosts, network, hypervisor, physical security |
| Container / managed platform | RDS, ECS, EKS | Underlying infra + OS and runtime platform maintenance |
| Abstracted services | S3, DynamoDB, Lambda | Infrastructure, platform, server-side storage protections |
Customer responsibilities: "Security in the cloud"
You remain responsible for the configuration and contents you put into AWS.
- Identity and Access Management (IAM) policies and roles
- Data classification, encryption keys you manage (client-side or KMS usage)
- Network controls (security groups, NACLs, VPC configuration)
- Application-level controls and secure coding
- Backups, retention, and data lifecycle
- Monitoring, logging and alerting (CloudTrail, CloudWatch, Config)
A common misstep is assuming a managed service removes all configuration work. For example, S3 is managed by AWS, but an incorrectly configured S3 bucket (public ACL) is still your mistake to fix.
If you're unsure how changes are actually sent to AWS (console vs script vs code), it's worth getting familiar with the different control plane interfaces: the Console, the CLI and the SDKs each apply configuration in their own way.
Practical mapping: examples that teams ask about
- S3 bucket encryption: AWS provides SSE options, but you must ENABLE and choose keys (SSE-S3 vs SSE-KMS)
- EC2 host patching: AWS patches the hypervisor, but you patch the guest OS you run inside EC2
- RDS backups: AWS provides snapshots and storage durability, but you set retention and backup windows
CLI example enforce S3 encryption with a bucket policy
aws s3api put-bucket-encryption --bucket my-app-bucket \
--server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/my-key"}}]}'Controls that reduce shared-responsibility gaps
- Enable CloudTrail (all regions) and ship logs to a centralized, immutable bucket.
- Enforce least privilege with IAM: prefer roles and permission boundaries over broad policies.
- Require MFA for console access and protect sensitive roles with session policies.
- Use AWS KMS and prefer customer-managed keys for sensitive workloads.
- Automate drift detection with AWS Config rules and run regular compliance scans.
For region-specific compliance considerations that affect your shared responsibilities, review AWS Regions & Availability Zones to pick locations that meet legal and contractual requirements.
Responsibility checklist by common workloads
| Workload | Who secures what (high level) |
|---|---|
| EC2-based web app | AWS: hardware, hypervisor. You: OS patches, app updates, security groups, IAM roles |
| RDS production DB | AWS: DB engine patching options and infra. You: DB credentials, parameter tuning, backup retention, network access |
| S3 data lake | AWS: durability & storage infra. You: bucket policies, encryption settings, object lifecycle |
Frequently asked questions
What is the difference between "security of the cloud" and "security in the cloud"?
"Security of the cloud" is AWS's responsibility physical infrastructure, network and foundational services. "Security in the cloud" is your responsibility, data, access control, configuration and application security.
Does AWS manage data encryption for me?
AWS offers server-side encryption features, but enabling and configuring them (SSE-S3, SSE-KMS, or client-side encryption) is typically your responsibility. KMS keys you create are also under your control for key rotation and policy.
Who is responsible for patching EC2 instances?
AWS patches the underlying hypervisor and host, but you must patch the guest OS and any software running inside the instance unless you use fully managed services that abstract that layer.
How do I prove compliance in audits?
Combine AWS-provided artifacts (SOC / ISO reports, config snapshots from AWS Config) with your evidence: IAM policies, change logs, CloudTrail records, and documented encryption settings. AWS Artifact supplies the vendor compliance documents you may need to collect.
The takeaway
The Shared Responsibility Model isn't an abstract concept, it's a practical tool to assign ownership, avoid gaps and speed incident response. Use the checklist and examples above to codify controls in your runbooks and IaC.
If you'd like, I can:
- add an automated
aws-configstarter recipe for your account, - generate a short remediation playbook for common S3 and IAM misconfigurations,
- or run a quick review of the controls in one of your
projects(e.g. the dynamic ETL pipeline).
Tell me which of those you'd like next and I'll add it to the plan.
Mirza Hammad Tariq
AWS Data Engineer with 5+ years building production-grade ETL pipelines, cloud data warehouses, and scalable data architectures in Python, SQL, Dagster, and AWS.