Choose storage for four workloads: a Postgres data directory, user-uploaded images, a shared build cache, and seven years of audit records.

Postgres data directory — block storage

It needs low-latency random reads and writes and a filesystem, and it attaches to one instance. That is precisely block storage.

The decision within it is volume type and provisioned IOPS, not size. Under-provisioned IOPS is a common cause of unexplained database slowness: the volume is throttled, the database looks slow, and no application metric shows why. Watch also for general-purpose volumes with burst credits, which have the same silent-exhaustion failure as burstable instances.

User-uploaded images — object storage, behind a CDN

Immutable blobs, HTTP-addressable, effectively unlimited, cheap. Two things worth doing beyond the default: pre-signed URLs so clients upload and download directly without the bytes traversing your application tier, and a lifecycle policy moving older images to an infrequent-access tier.

Shared build cache — file storage, or object storage with a cache-aware tool

This is the awkward one. If the build tooling requires a POSIX filesystem shared across machines, file storage is the answer, and it is considerably more expensive per gigabyte. If the tooling supports an object-backed cache — most modern build systems do — use object storage and save substantially.

Seven years of audit records — object storage with lifecycle tiering and object lock

Written once, read almost never, retained by obligation. Transition to archive tiers on a schedule.

Critically, object lock in compliance mode for the retention period: audit records that a compromised credential can delete do not satisfy the requirement they exist for.

What a strong answer adds

Checking the archive costs before writing the lifecycle policy: retrieval from deep archive costs money and takes hours; minimum storage durations make early deletion chargeable; and per-object transition requests mean archiving fifty million small files can cost more than leaving them. And noting that tiering is not deletion — archived data is still held, still discoverable and still a liability under an erasure obligation.