If you’ve worked with AWS for any amount of time, you’ve seen the shared responsibility model. “Security of the cloud” is on AWS. “Security in the cloud” is on you. Simple enough. Most people nod, move on, and never think about it again.
But that model isn’t a fixed line. It’s a slider. And where it sits depends entirely on which services you choose.
The slider
The classic diagram suggests a clean split: AWS handles hardware and infrastructure, you handle everything on top. That’s true for EC2. You rent a virtual machine, and from the operating system upward, it’s your problem - patching, runtime, application security, all of it.
But what happens when you move to RDS? Suddenly AWS manages the operating system and the database engine patching. You’re still responsible for your data, access control, and network configuration, but an entire layer just disappeared from your plate.
Go further to Lambda or S3, and even more shifts. You don’t think about servers, operating systems, or runtime patching. Your responsibility narrows to your code, your data, and who has access to it.
AWS categorizes this into three tiers:
- Infrastructure services (EC2, VPC) - You control the OS, platform, and everything above it.
- Container/Platform services (RDS, ECS) - AWS manages the OS and platform. You manage data and access.
- Abstracted services (Lambda, S3, DynamoDB) - AWS handles nearly everything. You manage your data and client-side encryption.
The newer AI services push this even further. You’re essentially responsible for your prompts, your data, and your access policies. That’s it.
This isn’t just a security consideration. It’s a fundamental shift in what you’re actually buying.
AI is shifting the model in two directions
On one side, AI services like Bedrock represent the most extreme version of the slider moving toward the provider. You don’t manage models, training infrastructure, or GPU clusters. You send a prompt, you get a response. Your responsibility is your data, your access policies, and how you use the output. That’s the abstraction layer taken to its logical conclusion.
But there’s a second, less obvious shift happening. AI is now building the infrastructure itself. People are using AI assistants to generate Terraform modules, CDK stacks, and Kubernetes manifests. Entire architectures are being “vibe coded” into existence by people who may not fully understand what they just deployed.
This creates a strange new question for the responsibility model: who is responsible for infrastructure that nobody on your team truly understands? The model is clear - it’s still you. AWS doesn’t care whether a human or an AI wrote your security group rules. If port 22 is open to the world, that’s your problem.
But organizationally, this is uncharted territory. When someone prompts their way into a production stack without understanding the networking, the IAM policies, or the encryption settings, the responsibility hasn’t shifted - but the capability to meet that responsibility hasn’t kept pace.
The real cost: money and people
Here’s where it gets interesting for anyone making strategic decisions. When people compare cloud costs, they typically look at the service price. “Lambda is expensive per invocation at scale” or “EC2 is cheaper per compute hour.” And in raw unit economics, that might be true.
But unit price is not total cost.
When you run on EC2, you’re also paying for:
- A team (or at least a person) who patches operating systems
- Security tooling to scan and harden those instances
- Network engineering for firewall rules and segmentation
- On-call rotations for infrastructure incidents
- Compliance evidence gathering for every layer you own
None of that shows up on your AWS bill, but it absolutely shows up in your budget. With Lambda, those costs don’t exist - not because they disappeared, but because they shifted to AWS’s side of the model.
And behind every one of those line items is a team of experts you wish you had. Most organizations don’t have dedicated specialists for relational databases and NoSQL, for Windows and Linux, for networking and security. They have a handful of people stretching across all of it, doing their best. And the threat landscape isn’t waiting for them to catch up - especially now that AI is supercharging attackers too.
Every layer you own in the responsibility model is a layer you need to staff, train for, and keep current on. Moving up the stack isn’t just a cost decision - it’s a focus decision. It lets your team spend their energy on what differentiates your business instead of maintaining commodity infrastructure and platforms that a provider can handle better at scale.
A fair TCO comparison requires understanding which layers of the responsibility model each service covers. If you only compare list prices, you’re ignoring half the equation.
What this means for digital sovereignty
This is where the shared responsibility model becomes a useful lens for a completely different debate.
The push for digital sovereignty has produced a wave of “sovereign cloud” providers across Europe and beyond. Their pitch is straightforward: your data stays in your jurisdiction, operated by a local entity, free from foreign government access. That’s a valid concern.
But here’s what often gets lost in the conversation: many sovereign cloud providers operate only at the Infrastructure-as-a-Service level. They offer virtual machines, storage, and networking. Everything above that - the operating system, the platform, the security tooling, the managed services - is on you. In shared responsibility terms, they’re covering the smallest possible slice. The slider moves all the way back to you.
If you’ve followed the argument so far, you already know what that means: more layers to staff, more security surface to manage, more cost that doesn’t show up on the infrastructure bill. This isn’t an argument against sovereignty - it’s an argument for honest accounting. Anyone evaluating a sovereign provider should apply the same responsibility-model lens and understand the full cost of operating at that layer.
And that raises a deeper question: beyond cost, how well are organizations actually handling the responsibility they already have?
How well are we doing?
Not well. Gartner estimated that through 2025, 99% of cloud security failures will be the customer’s fault. Not provider outages. Not zero-days in the hypervisor. Customer misconfiguration.
Trend Micro’s own research puts misconfigurations at up to 70% of all cloud security challenges. The Tenable Cloud Security Risk Report 2025 makes this concrete for AWS: 54% of organizations using AWS ECS task definitions have at least one secret embedded directly in their configurations - a direct attack path sitting in plain sight.
Organizations are already overwhelmed by the responsibilities they have. Taking on more - by choosing lower-level services or moving to providers that cover fewer layers - doesn’t make you more secure. It makes you more exposed.
Use the model as a strategic tool
The shared responsibility model was designed as a security framework. But it’s equally powerful as a lens for cost, operations, and vendor evaluation.
Before you pick a service - or a provider - understand where the responsibility line sits. Know what you’re taking on. Know what it costs to operate at that layer, not just in money, but in people and process.
That said, moving up the abstraction ladder isn’t free either. Higher-level services give you less responsibility but also less control. You accept opinionated defaults, vendor-specific patterns, and reduced flexibility. For some workloads that’s perfectly fine. For others, it’s a real constraint.
The point isn’t “always go higher.” It’s “choose deliberately.” The slider moves. Make sure you understand what you’re gaining and what you’re giving up when it does. That’s the real value of the shared responsibility model today.