The question this answers
When I adopt a managed service, exactly which obligations transfer to the provider and which stay mine?
A team is adopting a managed database, an object store and a managed container platform, and has to be able to state — to an auditor, and to itself at 03:00 — who is responsible for each failure and each control.
An explicit boundary per service: what the provider guarantees and evidences, what you must configure, and what remains entirely yours no matter how managed the service is.
The line moves; the bottom half is never yours and the top half never leaves
The model is simple to state and routinely misapplied. The provider is responsible for the security of the cloud: facilities, power, hardware, the hypervisor, the physical network, and the availability of the service they sell you. You are responsible for security in the cloud: your data, your access control, your network configuration, your patching above the line, and every setting you were given the ability to set.
What moves is the line. On a virtual machine you own the guest OS, its patches, its firewall and everything above. On a managed container platform you own the image and the workload but not the node OS. On a function platform you own the code, its dependencies and its permissions, and essentially nothing below. Every step up the abstraction removes obligations — and, importantly, never removes the top three: your data, your identity and access configuration, and your application logic are yours in every model that exists.
The reason this lesson exists is that "managed" is heard as "handled". A managed database is an enormous reduction in work: the provider runs the process, patches the engine, handles hardware failure and takes automated backups. It does not choose your schema, write your indexes, size your instance, restrict who can connect, decide your retention, or notice that a query is doing a sequential scan over forty million rows. The bill and the outage are still yours.
| Obligation | On-prem | Virtual machine | Managed container platform | Managed database | Functions |
|---|---|---|---|---|---|
| Facility, power, hardware | you | provider | provider | provider | provider |
| Hypervisor / physical network | you | provider | provider | provider | provider |
| Host OS + patching | you | you | provider | provider | provider |
| Runtime / engine version + patching | you | you | you (image) | provider (you approve the window) | provider |
| Capacity and instance sizing | you | you | you | you | you (memory + concurrency) |
| Network exposure and firewall rules | you | you | you | you | you |
| Identity, policy, who may connect | you | you | you | you | you |
| Backups configured, retained, restored | you | you | you | you configure + verify; provider executes | you (for whatever it writes) |
| Your data and its classification | you | you | you | you | you |
| Application logic and its bugs | you | you | you | you | you |
The customer side is where the incidents are
Provider-side failures happen and they make the news, but the overwhelming majority of cloud security incidents are configuration failures on the customer side of the line. An object store made public by a permissions change nobody reviewed. A database reachable from the internet because a security group was opened during a debugging session and never closed. A static access key committed to a repository and valid for two years because nothing forced it to expire.
None of those are provider failures, and none of them would have been prevented by a better provider. They are the direct consequence of the customer owning the configuration surface — which is exactly what the model says, and exactly what teams forget when they hear "managed".
The topology below is a managed-database deployment with the responsibility annotated per node. It is worth reading with the security overlay in mind: the load balancer being public is the design, and the database being reachable from the internet would be the finding. Exposure is not a verdict on its own; the question is always what is on the other side of the port. See Public Exposure, Read With Context.
The identity half never transfers
Of everything on the customer side, access configuration is both the most consequential and the least affected by how managed a service is. A serverless function on a fully managed platform with a policy granting full administrative access to the account is a more dangerous object than a self-hosted database on a VM with a tight security group. The abstraction level did nothing for the blast radius.
The policy panel below is the pattern that shows up in real accounts constantly: a workload that reads one bucket prefix and writes to one table, holding a policy that grants everything on everything, because the tight policy was hard to write and the broad one made the error go away. The provider is running that service flawlessly. The provider has no opinion about the policy.
The practical discipline is to write the *needed* list before the *allowed* list. It takes twenty minutes, it is derived directly from the workload the way Workload-First Thinking prescribes, and it is the difference between a compromised function leaking one bucket prefix and a compromised function owning the account.
- storage:* on *
- database:* on *
- compute:* on *
- iam:* on *
- storage:GetObject on exports-bucket/pending/*
- storage:PutObject on exports-bucket/done/*
- database:Query on orders (read only)
Blast radius: A single vulnerability in the export worker — a dependency with a deserialization flaw, a prompt injection in an untrusted document it processes — becomes full control of the account: read every bucket, alter every table, create new identities, and delete the backups. The identity policy, not the service model, is what decides this. See Least Privilege in Infrastructure.
Key points
- The provider secures the cloud; you secure what you put in it. Which obligations transfer depends entirely on the service model.
- Three things never transfer in any model: your data, your identity and access configuration, and your application logic.
- "Managed" reduces work substantially and reduces responsibility only partially — the schema, the sizing, the access rules, the retention and the bill stay yours.
- Nearly all publicly reported cloud security incidents are customer-side configuration failures, not provider failures.
- A provider-executed backup is not proven recovery until you have restored from it against your stated RTO.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • The provider operates every layer below the abstraction you rented and publishes attestations rather than giving you access to audit it yourself.
- • You are given a configuration surface — network rules, identity policies, encryption settings, retention, sizing — and every setting on it is your responsibility by definition.
- • The provider's availability commitment covers the service being reachable and functioning, not your workload being correct or your configuration being sane.
- • Support and incident boundaries follow the same line: the provider will tell you the service is healthy, which is frequently true while your workload is down.
- • Schema, indexes, query plans and connection management on a managed database — none of which the provider touches.
- • Instance class, storage size, IOPS provisioning and read-replica count; defaults are chosen for a generic workload and are rarely right for yours.
- • The maintenance window: the provider patches, you decide when, and "never" accumulates into a forced upgrade at the worst time.
- • Backup retention, cross-region copies, and the restore drill that proves the whole chain works.
- • Every network rule and every policy, forever, including the ones added during incidents.
- • A managed database at 100% CPU because of a missing index — the provider's dashboards are green, the service is functioning exactly as sold.
- • An object store opened to the public by a policy change, discovered by a security researcher rather than by monitoring.
- • A connection limit reached because the application opened a pool per process and the instance class caps connections — a sizing decision the customer made.
- • A forced engine upgrade during a deferred maintenance window, applied at a time the provider chose because the customer kept deferring.
- • A backup that exists, is retained, and cannot be restored inside the recovery objective — discovered during the incident.
- • Managed services scale the parts the provider owns and expose the parts you own as your problem: connection limits, storage ceilings and per-account quotas.
- • Quotas are the boundary teams meet first at scale, and raising one is a support request with a lead time — during exactly the event that made you need it.
- • The provider scaling well does not make your workload scale: a hot partition key, an N+1 query or an unbounded fan-out is yours at every size.
- • The provider owns physical, hypervisor and fabric security and evidences it with attestations you inherit rather than produce.
- • You own identity, network exposure, encryption configuration, secret handling and data classification in every model.
- • Encryption at rest is usually provider-managed by default; who holds the key and who can decrypt is a customer decision with real consequences — see Key Management and Encryption at Rest.
- • Audit logging of who changed the infrastructure is available and often not enabled by default, and it is the only evidence you will have — see Audit Trails.
- • Managed services trade operational hours for a premium on the hourly rate; that trade is excellent for a small team and worsens with steady scale.
- • Sizing is a customer decision, so over-provisioning is a customer cost — the provider has no incentive to point it out. See Right-Sizing Without Causing an Outage.
- • Backup retention, snapshot storage and cross-region copies are separately metered and grow silently for years.
- • Both sides: provider service-health dashboards and your own workload metrics, because they answer different questions and both are needed.
- • Configuration change events — who altered a security group, a policy or a retention setting, and from where.
- • Your own utilization and saturation against the limits of the class you chose, since those limits are your decision.
- • The signal that lies: a provider status page showing all green. It reports their obligations, not yours, and it is green through most of your outages.
- • Self-hosting, which moves the line down and gives you full control plus full obligation. Correct when you need engine features or tuning the managed offering does not expose, and expensive in people otherwise — see Managed vs Self-Hosted.
- • A higher-level platform that moves the line further up, if the parts you own are the parts you keep getting wrong. Fewer settings is a legitimate security strategy.
- • For a small workload, a single managed offering with defaults and a documented restore drill beats a self-run system that is theoretically better tuned and practically unpatched.
- • Managed services buy back operational hours and charge a rate premium plus reduced visibility into the layers you handed over.
- • The narrower your responsibility, the fewer things you can get wrong and the fewer things you can fix during an incident.
- • Provider attestations satisfy auditors more cheaply than your own evidence would, and they replace evidence you can no longer produce yourself.
What people believe, and what is true
The cloud provider handles security.
They handle their half, which is the physical and hypervisor layers. Your data, your access control, your network rules and your application are yours, and that is where essentially every reported breach occurred.
A managed database means we do not have to think about the database.
It means you do not run the process. Schema, indexes, query plans, sizing, connections, retention and access are unchanged, and they are what actually causes database incidents.
Provider backups mean we have disaster recovery.
You have backups. Recovery is a restore executed within a stated RTO, and until you have performed one, both numbers are guesses — see Restore Testing.