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 is AWS's own framing of who owns which controls, and it splits into two halves AWS names precisely: security of the cloud (theirs) and security in the cloud (yours). Those two prepositions carry the entire model — and in every breach post-mortem I have read, the failure sat on the "in" side while everyone assumed it was on the "of" side.
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.
The line has moved, and a default is not a guarantee
AWS has quietly moved several controls from your side of the line to safe-by-default. It is worth knowing exactly which ones, and exactly where each one stops, because the half-remembered version of this is where people get hurt.
S3 encrypts new objects for you. Since 5 January 2023, every new object uploaded to S3 is encrypted with SSE-S3 using AES-256, "at no additional cost and with no impact on performance". You can no longer switch it off for new uploads even if you want to.
The catch sits a few lines further down the same page: objects already in an unencrypted bucket are not encrypted retroactively. So if your compliance evidence says "all data at rest is encrypted", that statement covers everything written after January 2023 and nothing written before it. Closing the gap is an S3 Batch Operations job, and it is yours to run.
New buckets are private. AWS states plainly that "by default, new buckets, access points, and objects don't allow public access", and Block Public Access gives you four independent settings on top of that.
The catch: they can still be turned off, and a bucket policy can still be written that grants public access. AWS's own recommendation is to enable all four at the account level rather than per bucket, precisely because anyone who can edit a bucket policy could otherwise undo the bucket-level version. That account-level decision is your configuration, not AWS's default.
CloudTrail shows you 90 days, and only 90 days. Event history is "a viewable, searchable, downloadable, and immutable record of the past 90 days of CloudTrail management events in an AWS Region". It is genuinely useful and it costs nothing.
The catch is the three limits hiding in that one sentence. Ninety days. Management events only. One Region. If your incident is older than a quarter, involves data events such as S3 object reads, or spans Regions, event history simply will not have it. A configured trail delivering to S3 would have. Nobody sets one up mid-incident.
The pattern across all three is the same, and it is the thing worth taking away: AWS moving a control to a safe default changes the starting position, never the ownership. Every one of those defaults can be overridden by a customer action, and none of them reaches backwards in time.
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 is not an abstract diagram. It is an ownership map, and its entire value is making the gaps visible before an auditor or an incident does it for you.
Three things worth doing this week, all of which sit on your side of the line:
- Turn on all four Block Public Access settings at the account level rather than bucket by bucket, so a future bucket policy cannot quietly undo them.
- Check whether anything written to S3 before January 2023 is still sitting there unencrypted. Automatic encryption was not retroactive, and "all data at rest is encrypted" is a claim someone will eventually ask you to evidence.
- Configure a CloudTrail trail. Ninety days of Region-scoped management events is a recent-activity view, not an audit trail, and the difference only becomes obvious when you need the thing you did not keep.
The same boundary applies to the pipelines built on top of all this: on the dynamic ETL pipeline I run, AWS operates Glue and S3, and every IAM role, bucket policy and retention rule around them is mine to get right.
If you are standing up data infrastructure on AWS and want that ownership boundary written down before it goes live rather than after, that is part of how I scope a build.
Mirza Hammad Tariq
Data & Automation Engineer with 5+ years on AWS: ETL pipelines, backend APIs and automation workflows in Python, SQL and FastAPI, built to cost less to run.