S3 Object Storage
What does zop.dev create for S3 Object Storage?
zop.dev provisions S3 buckets with public access blocked, encryption enabled and versioning configured. Those 3 defaults exist to prevent the 2 most common S3 incidents: accidental public exposure of data, and an overwrite or delete that turns out to be unrecoverable.
| Field | Value |
|---|---|
| Cloud | aws |
Amazon S3 provides durable object storage for application assets, backups, and logs. zop.dev provisions encrypted, versioned buckets so data is protected by default.
Buckets with KMS encryption and versioning on
S3 bucket with KMS server-side encryption and versioning enabled.
Bucket name, with secure defaults preset
Bucket name; KMS SSE and versioning are on by default.Object storage has no GCP or Azure equivalent
The object-storage module exists for AWS only. There is no GCP or Azure equivalent module.
The defaults exist because of specific failures
Public access block on. S3 bucket exposure remains one of the most common cloud data incidents, and it almost never happens deliberately; it happens through an ACL or policy edit whose blast radius nobody checked. The account-level and bucket-level blocks make that edit fail rather than succeed silently.
Versioning on. An overwrite or delete without versioning is unrecoverable. With it, both are undoable. This is the setting people turn off to save money and regret exactly once.
Encryption at rest. Free, and required by most compliance frameworks.
Versioning changes what storage costs
This is the tradeoff to understand up front: with versioning enabled, deleting an object does not free its storage. It writes a delete marker and retains every previous version, billing for all of them indefinitely.
A bucket with heavy overwrite traffic and no lifecycle policy grows without limit while appearing to hold a constant number of objects. The fix is a lifecycle rule expiring noncurrent versions after a retention period you actually need, usually 30 to 90 days.
Lifecycle is where the savings are
Standard storage is the most expensive tier and the default for everything. For data with a predictable access pattern, lifecycle transitions to Infrequent Access and then Glacier cut the rate substantially without changing how the bucket is used.
Intelligent-Tiering does it automatically for unpredictable patterns, at a small per-object monitoring charge that is worth it above roughly 128 KB per object and not below.
Naming is permanent
Bucket names are globally unique across all AWS accounts and cannot be changed. Renaming means creating a new bucket and copying, which for large buckets is a project rather than a task.