Storage, databases, and recovery

Start with the data's behavior

“Store the data” hides several different requirements. A database engine needs appropriate durable storage and consistency. Uploaded documents may be independent objects. Several machines may need shared files. A cache may contain data that can be rebuilt. Choosing a service starts with those behaviors, not a list of product names.

An S3 key can contain slashes that look like directories, but that does not make an object a regular file with POSIX update semantics. EBS snapshots are recovery artifacts; the running database's consistency and the restore process still need consideration.

Managed does not mean responsibility-free

A managed database takes on infrastructure and engine operations according to its service model. You still choose schema, queries, credentials, network access, capacity, backup retention, maintenance policy, and a tested recovery procedure. A slow unindexed query does not become efficient merely because PostgreSQL is managed.

RDS and Aurora have different deployment options. A traditional RDS Multi-AZ DB instance uses a standby for availability; that standby is not a general read-scaling endpoint. A Multi-AZ DB cluster has different readable-instance behavior. Read replicas serve a different purpose and can lag. Name the exact deployment type instead of treating every “Multi-AZ” design as identical.

High availability and backup answer different questions. A standby may help when an instance fails, while a backup may help recover data deleted by mistake. Replicating an accidental deletion quickly does not create a historical copy you can restore.

Work through a MicroBank decision

The inspected application uses PostgreSQL for Accounts and Ledger. For a proposed cloud design, retaining PostgreSQL semantics may keep the migration understandable. That does not establish that the code is ready for managed database TLS, credentials, failover, or network paths; those need implementation and tests.

The practice S3 bucket belongs to the cloud-dependency exercise. Its presence does not mean account balances should be stored as unrelated JSON objects. The ledger needs the transaction and query behavior its actual code expects. Similarly, introducing a cache before measuring a read problem adds another consistency question rather than automatically improving the service.

Practice a recovery decision without provisioning

Write three rows for your proposed deployment: a deleted upload, a failed database instance, and an accidental database update. For each, choose the mechanism you would inspect and the proof needed after recovery.

Example reasoning: object versioning may retain an earlier upload version if configured; database failover may restore service after an instance failure; point-in-time recovery may help recover data to an earlier moment. These are conditional capabilities, not proof of successful recovery. A restore can create a new endpoint requiring application changes, and the recovered contents must be checked.

Add who may read the data, who may manage its encryption keys, how secrets reach the application, and what happens when credentials rotate. Encryption at rest does not authorize every caller or prevent accidental logical deletion. KMS key access and service resource access are related but distinct permissions.

Checkpoint: can a live replica substitute for every backup need? No. Can a bucket lifecycle rule replace a reviewed retention requirement? No; it implements chosen transitions or expiry and can remove data. Next, estimate the cost and retirement work for these choices before creating resources.

References: S3 model↗, EBS volumes↗, RDS Multi-AZ↗, and RDS backup and restore↗.