Cloud Database Security and Compliance
The shared-responsibility baseline, and the controls that actually close audit findings.
Executive summary Serverful and serverless databases on the major clouds both offer enterprise-grade security: encryption, identity-based access, network isolation, and audit logging. The meaningful differences are not in the primitives but in control and evidence, how much of the infrastructure you govern directly, and how easily you can prove what happened. This paper compares the two models across access, encryption, residency, and auditability, and identifies where each helps or complicates a compliance review.
Start from the shared baseline
It is worth stating plainly, because the serverless-is-less-mature reflex is common and mostly wrong: on AWS, Azure, and Google Cloud, both provisioned and serverless managed databases provide encryption at rest and in transit, integration with the cloud's identity system, private networking, and audit logging. The baseline is strong on both sides. The security question is therefore not "is it secure" but "who controls which layer, and can you evidence it."
The distinction that matters Security posture is what your system is capable of. Compliance is your ability to prove it. Two databases can have identical controls and very different compliance stories, because one team can produce the evidence on demand and the other cannot.
Where the models diverge
Control over the infrastructure
Serverful gives you more direct control of the layers beneath the database: instance configuration, network placement, patching timing, and sometimes the underlying operating system in instance-based options. For workloads with unusual regulatory or infrastructure requirements, that control can be the deciding factor, which is why highly regulated systems often stay on provisioned or instance-level services.
Serverless abstracts those layers away. That is a security benefit in the common case, less surface for you to misconfigure, and a constraint in the uncommon case, fewer levers when a control mandate is specific about infrastructure you no longer touch.
Access control
This is the area least affected by the hosting model and most affected by discipline. Both models integrate with the cloud identity provider and support fine-grained, role-based access. The risk is not the model; it is standing, over-privileged credentials and direct human access to production data. A serverless database with a broad, permanent admin credential is less safe than a provisioned one with least-privilege, time-bound access. The control that matters, least privilege and no standing production access, is yours to enforce on either.
Encryption and key management
Both models encrypt at rest and in transit by default on the major clouds, and both support customer-managed keys for teams that require control of the key material. The difference is minor: serverful sometimes exposes more granular options for key rotation and placement, while serverless keeps the defaults strong and the options fewer. For most compliance regimes the default managed encryption is sufficient; where customer-managed keys are mandated, confirm the specific service supports them before committing.
Data residency and sovereignty
Residency is where the model interacts with regulation most directly. Provisioned services generally give you explicit control over the region and, in some cases, the availability zone where data lives, which maps cleanly onto residency requirements. Serverless services are also regional, but the abstraction can make it less obvious exactly where data and its replicas sit, so confirm the residency guarantees of the specific serverless tier rather than assuming. Globally distributed serverless engines, which replicate across regions by design, require particular care where regulation forbids data leaving a jurisdiction.
Auditability and evidence
Compliance lives or dies on evidence. Both models produce audit logs of access and administrative actions through the cloud's logging services. The gap is rarely the presence of logs; it is whether change to the database, who altered what schema or data, when, and with whose approval, is captured in a form a reviewer can read. Infrastructure audit logs tell you an instance was modified. They do not, on their own, tell you that a column was dropped after a reviewed approval. That layer of evidence is something you assemble, not something the hosting model hands you.
A comparison for the review
| Dimension | Serverful (provisioned) | Serverless |
|---|---|---|
| Encryption at rest and in transit | Default, granular key options | Default, fewer key options |
| Identity-based access | Full | Full |
| Network isolation | Explicit, you configure | Managed, sometimes fewer controls |
| Data residency control | Explicit region and often zone | Regional; confirm the tier's guarantees |
| Infrastructure control | High | Low by design |
| Change and access evidence | Yours to build | Yours to build |
| Best fit | Strict, infrastructure-specific mandates | Standard compliance with lower ops burden |
How to shorten the review
The fastest security review is the one you have already answered. A few practices do most of the work, on either model.
- Enforce least privilege and eliminate standing production access. This single control addresses a large share of database incidents and a large share of audit findings.
- Confirm residency at the service tier, not the provider level. "It runs in AWS" is not a residency answer. "It runs in this region, with replicas only in these regions" is.
- Capture change as evidence, not just access. Reviewers increasingly ask not only who could touch the data but who did change it and with what approval. Record change at the workflow level, above the infrastructure logs.
- Decide the key-management requirement early. If customer-managed keys are mandatory, verify support before selecting a service; it narrows the options.
- Prefer control where regulation is specific, abstraction where it is standard. Let the strictness of the mandate, not a preference for one model, drive the choice.
The takeaway Neither serverful nor serverless is inherently more secure on the major clouds; the primitives are strong on both. The differences are control and evidence. Choose provisioned control when a mandate is specific about infrastructure, choose serverless abstraction when requirements are standard and you want less surface to manage, and in both cases enforce least privilege and capture change as evidence. Those two habits answer most of the review before it begins.
Simcha Solutions helps regulated teams design cloud data platforms where the compliance evidence is a byproduct of how the system runs, not a scramble before the audit.
