Cloud storage and managed databases

Storage is the one part of a cloud design that cannot simply be rebuilt. Compute can be recreated from code in minutes; lost data stays lost. Choosing where data lives therefore shapes cost, performance and resilience more than most other decisions, and the options fall into two families: storage services that hold objects, disks and files, and managed databases that hold structured records and answer queries about them. Containers complicate the picture, since their data must outlive the container itself; the CNCF landscape guide describes the standard storage interface that lets clusters request volumes on demand.

Managed databases

A managed database hands patching, backups, replication and failover to the provider while leaving schema, queries and capacity choices with you. Relational engines speak SQL; every major cloud runs PostgreSQL and MySQL as a service, and Microsoft's SQL Server has its managed form on Azure. Non-relational services give up joins and flexible queries in exchange for predictable speed at scale, usually by key. An in-memory cache often sits in front of either to absorb repeated reads, and warehouses such as Snowflake serve analytics rather than transactions.

• Access pattern: read-heavy or write-heavy, by key or by complex query, steady or bursty.
• Engine and type: relational or not, and which engine, for instance MySQL against PostgreSQL.
• Scaling reads: read replicas and a cache before a larger instance.
• Tiers and lifecycle: moving rarely read objects into colder, cheaper classes on a schedule.
• Redundancy: how many copies, in how many zones or regions, measured against recovery point and recovery time objectives.
• Hybrid and transfer: bringing data in from existing sites, and serving it back to them.

A mistake worth avoiding, and where it leads

Newcomers often reach for a relational database for everything or, having read about scale, for a NoSQL service for everything. Both errors come from choosing before describing the data and how it will be read. A second mistake is to trust replication as a backup: a replica copies a deletion as faithfully as it copies a write. The SAA-C03 blueprint touches storage and data in all four of its domains, from encryption and backups in the security domain to storage tiers and database cost in the cost domain, and AZ-900 asks about tiers, redundancy options and storage account types. AZ-104 has a storage domain for Azure administrators, DP-900 covers data fundamentals on Azure, and DEA-C01 tests storage choices for data engineering on AWS. For putting object storage behind a public site safely, read cloud security; for bringing existing databases across, cloud migration.