Cloud-Native Security: What the Shared Responsibility Model Actually Demands
Godfrey Maiwun · November 2025 · Cloud Security · 12 min read
The shared responsibility model is the first concept every AWS architect encounters and the one most often misunderstood in practice. AWS is responsible for security of the cloud. You are responsible for security in the cloud. The boundary sounds clear. In production, it is anything but.
What AWS actually owns
AWS's security responsibility covers the physical infrastructure — data centres, networking hardware, power systems — and the managed services that sit on top of it. The hypervisor that runs your EC2 instances. The underlying storage systems that power S3 and EBS. The global backbone that connects AWS regions. The hardware security of the host machines that your virtualised workloads share.
For managed services — RDS, DynamoDB, Lambda, ECS — AWS owns the security of the runtime environment: patching the underlying operating system, maintaining the service software, isolating your workload from other customers'. You do not need to patch the database engine in an RDS managed instance. You do not need to secure the Lambda execution environment. AWS handles these.
This is the part of the model that is genuinely useful: AWS takes on significant operational security burden so you do not have to. The mistakes happen in the other direction — assuming AWS owns more than it does.
What you actually own
Everything above the managed service layer is yours. Your IAM policies. Your S3 bucket permissions. Your security group rules. Your EC2 instance operating systems and the applications running on them. Your encryption key management. Your network ACLs. Your application code. Your data. Your identity configuration.
Everything above the managed service layer belongs to you.
This list sounds obvious written down. The problems arise not from ignorance of the principle but from the operational complexity of implementing it correctly across dozens of services, multiple accounts, and environments that change continuously.
AWS cannot protect you from yourself. IAM policies that are too permissive, S3 buckets that are publicly readable, security groups that allow 0.0.0.0/0 on port 22 — these are your responsibility, and AWS will allow them if you configure them.
The most commonly misconfigured services
S3 bucket permissions are the source of more cloud data exposures than any other misconfiguration. The default settings have improved significantly — S3 Block Public Access is enabled by default on new accounts — but the residue of years of permissive legacy configurations remains across the industry. The specific failure modes: bucket ACLs that grant public read access, bucket policies that allow s3:GetObject to * (everyone), and cross-account access policies that are broader than intended.
The mitigation is not one-time — it is continuous. AWS Config rules that alert on public buckets, SCPs that prevent disabling Block Public Access at the organisation level, and automated remediation that reverts public access configurations are the components of a robust S3 security posture. Periodic manual review is not sufficient in environments where buckets are created by CI/CD pipelines.
IAM over-permissioning is the second most common failure mode. The path of least resistance in IAM is attaching AdministratorAccess to a service role because it makes development faster. The consequence is blast radius: if that role's credentials are compromised, an attacker has full administrative access to your AWS environment. The principle of least privilege is not optional in AWS — it is the primary defence against credential compromise.
The IAM Access Analyzer is underutilised. It identifies policies that grant access to external entities, highlights unused permissions in existing policies, and can generate least-privilege policies based on CloudTrail activity. Running Access Analyzer continuously and acting on its findings is the highest-leverage IAM hygiene practice available for free.
EC2 security groups suffer from the same accumulation problem as firewall rules — they are easy to add, difficult to remove, and the path of least resistance is always broader rules rather than narrower ones. The specific failure modes: inbound rules that allow all traffic from all sources (0.0.0.0/0) on administrative ports (22, 3389), rules that are correct for a past architecture but have not been updated when the architecture changed, and security groups attached to multiple resources where tightening the rules for one resource would break another.
Remediating this requires mapping security groups to the resources that use them, identifying rules with broader source ranges than necessary, and — critically — testing before you remove rules rather than after. AWS VPC Flow Logs are indispensable here: they show you which rules are actually matching traffic, which means you can identify rules that look permissive but are unreachable in practice.
Lambda execution roles are a newer category of over-permissioning. Lambda functions are often granted roles with broad permissions because the function needs access to one S3 bucket, one DynamoDB table, and one SNS topic, and it is faster to attach a managed policy than to write a custom one. Each function should have its own execution role, scoped to exactly the resources it needs to access, with no additional permissions.
The grey zone: where responsibility is genuinely ambiguous
The shared responsibility boundary is clearest at the extremes — AWS owns the physical hardware, you own your application code — and murkiest in the middle. Several areas are consistently misunderstood.
Where the shared responsibility boundary is genuinely ambiguous.
DDoS protection: AWS Shield Standard is included for all customers and protects against common network and transport layer attacks. Application-layer DDoS protection — the kind that targets your APIs specifically — requires AWS WAF and potentially Shield Advanced. This is your responsibility to configure and fund, not AWS's.
Data encryption: AWS provides the tools for encryption at rest and in transit. Whether you use them is your choice. An unencrypted RDS instance is AWS-compliant from the shared responsibility perspective — it is a misconfiguration on your side of the boundary. Enabling encryption at rest for RDS, EBS, and S3 should be a default requirement enforced by policy, not an optional configuration.
Logging and monitoring: AWS provides CloudTrail, VPC Flow Logs, S3 access logging, and CloudWatch. None of these are enabled by default in all cases, and none of them store logs indefinitely. Configuring logging, setting appropriate retention periods, and actually reviewing what is logged is your responsibility. An incident response that begins "we need the logs" and discovers they were not enabled is a preventable failure that the shared responsibility model does not protect you from.
Building a responsibility-aware security posture
The organisations that navigate the shared responsibility model well share one practice: they have translated the abstract boundary into a concrete checklist that applies to every new AWS service they adopt. When a team asks to deploy a new RDS cluster, the checklist answers: encryption enabled? Multi-AZ for production? Access restricted to application security groups only? Credentials in Secrets Manager, not environment variables? Automated snapshots configured? Performance Insights enabled for anomaly detection?
This is not bureaucracy — it is the operationalisation of a security model. The alternative is discovering, during an incident or an audit, that a service was deployed without these controls because no one explicitly asked for them.
Use AWS Security Hub to score your posture continuously against standards including CIS AWS Benchmarks and AWS Foundational Security Best Practices. It is not a substitute for security architecture — but it surfaces the misconfiguration patterns that the shared responsibility model requires you to catch, automatically and continuously.
Filed under: Cloud Security