1.4 Amazon S3
Key Takeaways
- S3 storage classes range from Standard (frequent access) through Standard-IA/One Zone-IA to Glacier tiers (archival); Intelligent-Tiering moves objects automatically based on access.
- Versioning preserves every object version (delete adds a delete marker); lifecycle rules transition or expire objects and should abort incomplete multipart uploads.
- Server-side encryption options are SSE-S3 (S3-managed AES-256, the default), SSE-KMS (KMS keys with key policies and CloudTrail audit), and SSE-C (customer-provided keys).
- Presigned URLs grant temporary, time-limited access to a specific object using the signer's permissions, enabling direct browser upload/download with no AWS credentials on the client.
- Multipart upload is recommended above 100 MB and required for single-object PUT above 5 GB; S3 provides strong read-after-write consistency for all operations.
S3 in Developer Scenarios
Amazon Simple Storage Service (S3) stores objects in buckets with 99.999999999% (eleven nines) durability. Each object is identified by a key within a bucket; the max single object size is 5 TB. Developer-domain questions focus on secure access (presigned URLs, encryption), large uploads (multipart), event-driven triggers, and cost optimization through storage classes and lifecycle rules. Bucket access is governed by IAM policies, bucket policies, and (legacy) ACLs, with Block Public Access on by default.
Storage Classes
| Class | Use case | Notes |
|---|---|---|
| S3 Standard | Frequently accessed data | Multi-AZ, highest availability |
| Standard-IA | Infrequent access | Lower storage, per-GB retrieval fee, 30-day min |
| One Zone-IA | Infrequent, re-creatable | Single AZ, ~20% cheaper, lower durability |
| Glacier Instant Retrieval | Archive, instant access | Millisecond retrieval, 90-day min |
| Glacier Flexible / Deep Archive | Long-term archive | Minutes-to-hours retrieval, lowest cost, 90/180-day min |
| Intelligent-Tiering | Unknown/changing patterns | Auto-moves between tiers, small monitoring fee, no retrieval fees |
Versioning and Lifecycle
Versioning keeps every version of an object so you can recover from accidental overwrites and deletes; a DELETE inserts a delete marker rather than removing data. Lifecycle rules transition objects to cheaper classes or expire them (current and noncurrent versions) on a schedule. Always include a rule to abort incomplete multipart uploads after a few days, because abandoned parts keep accruing storage cost invisibly.
Encryption Models
| Option | Who manages the key | Audit / control | When tested |
|---|---|---|---|
| SSE-S3 | S3 (AES-256), default | None per-request | Simple at-rest encryption |
| SSE-KMS | AWS KMS key | Key policies + CloudTrail logs every use | Compliance, audit, fine-grained control |
| SSE-C | Customer supplies key per request | You hold the key; S3 never stores it | Customer must control keys outside AWS |
A compliance requirement for auditable, controlled key usage points to SSE-KMS, because KMS key policies and CloudTrail give you the access trail SSE-S3 cannot. Watch for KMS request-rate throttling on very high-volume buckets; S3 Bucket Keys reduce KMS calls and cost.
Presigned URLs
A presigned URL grants temporary, time-limited access to a single object using the creator's credentials and permissions, so a client can GET or PUT one object directly without its own AWS credentials and without making the bucket public. This is the standard pattern for secure browser uploads and time-boxed downloads. The URL's validity is bounded by the signer's session — short-lived for role credentials, longer for IAM-user keys (up to 7 days).
Multipart Upload
Multipart upload splits a large object into parts (5 MB minimum each, except the last) uploaded in parallel and reassembled server-side, improving throughput, allowing pause/resume, and retrying only failed parts. AWS recommends multipart for objects over 100 MB and requires it for any object over the 5 GB single-PUT limit. Combine it with S3 Transfer Acceleration for long-distance uploads.
Events and Consistency
Event notifications fire on object actions such as s3:ObjectCreated:* or s3:ObjectRemoved:* and target Lambda, SQS, SNS, or EventBridge for event-driven pipelines (thumbnailing, indexing, virus scanning). S3 provides strong read-after-write consistency for all GET, PUT, and LIST operations across all buckets, with no configuration required — a read issued immediately after a successful write returns the latest data.
Access Control and Static Hosting
Object access is decided by combining identity-based IAM policies, resource-based bucket policies, and Block Public Access (on by default at the account and bucket level, and the reason many "why is my object private" questions resolve). For static websites, S3 can serve content directly via website hosting, but the production pattern fronts a private bucket with Amazon CloudFront using an Origin Access Control (OAC) so the bucket stays private while CloudFront caches at the edge. S3 Object Lambda can transform objects on the fly during GET (redact PII, resize images) without storing a second copy.
Replication, Performance, and Traps
Cross-Region Replication (CRR) and Same-Region Replication (SRR) asynchronously copy new objects to another bucket (CRR requires versioning on both ends) for compliance, latency, or DR. S3 scales to very high request rates per prefix automatically, so old advice to randomize key prefixes is obsolete.
Frequent exam traps: choosing One Zone-IA for non-reproducible data (it lives in a single AZ and can be lost if that AZ fails); forgetting the lifecycle rule to abort incomplete multipart uploads, which silently bills for orphaned parts; assuming you must enable versioning to get strong consistency (you do not); and using a public bucket when a presigned URL would grant scoped, time-limited access far more safely.
A further point worth memorizing: presigned-URL validity is bounded by the lifetime of the credentials that signed it, so a URL signed with short-lived role credentials may expire sooner than the requested expiration, while one signed with IAM-user keys can last up to seven days. When uploads must be enforced to a specific size or content type, generate a presigned POST policy rather than a presigned PUT, because the POST policy can impose conditions the browser must satisfy before S3 accepts the object.
A web app must let users upload files up to 8 GB directly from the browser to a private S3 bucket, without giving each user AWS credentials. Which two features are required?
A compliance team requires that every object's encryption be auditable and that key usage be controlled by key policies and logged. Which server-side encryption option fits best?
Immediately after a successful PUT that overwrites an existing object, a client reads the object and worries it may receive the old version. What is true for current S3?