Storage: block volumes, snapshots and S3-compatible Object Storage
Storage questions test whether you choose block or object storage for the right reason, and whether you respect the zone boundary when planning durability.
Block Storage
Block volumes are network-attached disks that live in one zone and attach to one instance at a time. They can be detached, reattached to another instance in the same zone, and grown (not shrunk). Volumes are the right home for databases, container image caches and anything needing a POSIX filesystem. Snapshots capture a volume at a point in time; they are per volume, so a multi-volume application needs a consistent order or an application-level freeze.
Object Storage
Object Storage is S3-compatible: buckets, objects, multipart upload, presigned URLs, versioning, lifecycle rules and bucket policies. Buckets are created in a zone, which is exactly what makes it usable for data residency. It is not a filesystem - you cannot mount it and edit a byte in place; you PUT whole objects (or parts) and read them back. Design for that: serve static assets from it behind a CDN, stage datasets there, but never point a relational database at it.
Snapshots are not backups
A snapshot in the same zone as its volume survives an accidental delete but not a zone-level event or an account compromise. Real backups leave the failure domain: copy snapshots or exports to a bucket in another zone, or to your own storage, and test restores on a schedule.
Worked example
A team runs a 2 TB PostgreSQL volume and a 500 GB image library. Reasoning: PostgreSQL needs block semantics and low-latency random I/O, so it lives on a block volume, snapshotted nightly. The image library is write-once, read-many and served over HTTPS, so it belongs in Object Storage with lifecycle expiry and a bucket policy limiting public reads to the CDN path. Copying nightly snapshots into a second zone's bucket satisfies the backup requirement; keeping them only in the source zone does not.
Traps
Treating a bucket as a shared drive; assuming volumes can follow an instance to another zone; snapshotting only one volume of a multi-volume app and calling it consistent; forgetting a bucket must be emptied of objects and versions before deletion; and leaving buckets public because presigned URLs felt complicated.