Provider Responsibility Model

On a rented virtual machine you patch the guest operating system and everything above it. On a managed database service the provider patches the host and the engine, while the data, the accounts and the configuration inside it stay yours.

Default encryption at rest protects bytes on the provider's media against drive loss, disposal or raw block access. It restricts nobody who calls the service: an authorized caller, and the provider holding the key, still get plaintext.

A provider can only promise an outcome it fully controls. Each duty a rung takes over becomes a guarantee made across many tenants at once, and any change you could still make by hand is state the fleet operator cannot assume.

A managed tier exposes only what it can operate, persist and support for every tenant at once, so settings that need host access, load foreign code into the engine, or weaken the tier's own promises are withheld, and the work they would have done moves into your application.

Three duties stay with the tenant at every tier: the data put into the service, the identities granted access to it, and the configuration the tenant is given control of. Climbing tiers shrinks that surface; it never empties it.

Everything still stored as ciphertext under that key goes dark: live objects and service-taken backups holding the same ciphertext. Anything already decrypted and copied out stays readable, and so does metadata - names, sizes, timestamps.

Three sources survive: the metrics the tier exports, the engine's own statistics visible over its normal interface, and your own client-side telemetry. Process lists, kernel counters, profilers, packet capture and core dumps do not exist for you, so diagnosis becomes elimination from the client inward.

Everything the tier was quietly doing returns: patching the guest operating system and the engine, standby replicas and failover promotion, backups with a proven restore, capacity and sizing, engine health monitoring, and an on-call rota. The engine behaves the same; the operating burden does not.

Chiefly one capability and one signal: a revocation switch that renders ciphertext needing that key unopenable, and a record of key use under your own policy. It does not stop an authorized caller reading now.

Capacity changes from an object you build, to a target you declare, to a quantity you only meet on the bill. The rung decides who performs the scaling, never whether the service must tolerate copies coming and going.

A ceiling that is the product's design cannot be raised by asking or by paying more, so it turns a capacity problem into a migration decision: reduce the workload, split it across several instances, or run the same engine yourself on plain machines.

A system is a set of components and each one sits on its own rung, so fully managed is almost never true of all of them. The routine operational work of the system is set by its lowest-rung component, not by an average.

You are now running two clocks and you control only one. Open the case early and in parallel, make it actionable on first read, and drive a mitigation that does not depend on the provider's answer — because the one thing a queue never returns on your schedule is a fix.

The tier trails upstream because the provider must qualify each release against its own backup, failover and patching machinery. You cannot pull a release forward, so the practical moves are a workaround in your own code, confirming whether the fix was backported into the tier's build, and planning as if the release date is not yours.

Because the schedule is set by how long the bytes take to copy and how much of the data changes while they are copying. Engineering effort can be parallelised across people; the copy cannot, it grows with the dataset, and its tail decides the cutover window.

An independent audit report evidences the provider's side of a control only. Every row still needs the tenant's half answered and evidenced separately, because managed means the provider operates the layer, not that the control is satisfied for your workload.

You accept that the key store becomes the availability of the archive, that losing the key is indistinguishable from destroying it, and that key residency is now a separate fact to defend. In return you get a destruction switch you can evidence.

Bound the part you own. Mandate client-side telemetry before adoption, require every critical store to have a rehearsed mitigation that needs no answer from the provider, keep a register of what evidence and what mitigation exist per dependency, and set a written trigger for re-opening the tier choice.

Every deferred quarter makes the copy longer, the tail larger and the dependent surfaces more numerous, so waiting spends the very option it claims to preserve. Deferral is defensible only when it names a measured trigger, an owner and a date.

Everything you shipped: your own code, the third-party libraries bundled with it, and anything baked into the image or artifact you deployed. The provider patches what it installed, never what you put on top of it.

Normally nothing in the archive is re-encrypted. Rotation adds a new key version that future wraps use; existing objects keep the version they were written under, which is why rotation is cheap and why it is not revocation.