Amazon S3 與應用程式快取

S3 and caching in applications is the single largest developer-focused topic in DVA-C02 — it stretches across Domain 1 (Development with AWS Services), Domain 2 (Security) and Domain 3 (Deployment), and practically every exam sitting leans on it for at least 8 to 12 questions. Unlike the CLF-C02 flavor of S3 (which is about "what is S3"), the DVA-C02 flavor of S3 and caching in applications is about how a developer wires S3, Amazon ElastiCache, and Amazon CloudFront into a working application: how to upload a 20 GB video reliably, how to hand a browser a temporary upload URL without exposing your IAM key, how to keep a login session alive across an Auto Scaling group, and how to shave 200 ms off a read path.

This study note walks the full developer surface area of S3 and caching in applications — from multipart upload thresholds to cache-aside vs write-through, from CloudFront signed URLs to externalizing session state in Redis. Every section points at the SDK behavior, the failure mode, and the exam trap. Work through it end to end and the "developer toolbox" questions become free points.

What Is S3 and Caching in Applications?

S3 and caching in applications is the umbrella concept that binds three AWS services into a single application-design pattern:

• Amazon S3 — object storage that applications use for user uploads, static assets, exports, backups, logs, and data-lake inputs.
• Amazon ElastiCache — managed Redis or Memcached used as a low-latency in-memory cache for database results, session state, leaderboards, and pub/sub.
• Amazon CloudFront — global CDN that caches S3 objects and API responses at the edge.

When DVA-C02 asks about S3 and caching in applications it is really asking "given this read/write pattern, which storage + cache combination do you reach for?" The right answer almost always involves S3 as the durable origin, ElastiCache or DynamoDB as the hot-tier, and CloudFront for edge distribution. Understanding S3 and caching in applications as a layered stack — durable origin, in-memory cache, edge cache — is the mental model the exam rewards.

白話文解釋

Plain-language walkthrough of S3 and caching in applications using three different analogies so the pieces click.

Analogy One: The Library, the Librarian's Desk, and the Neighborhood Kiosks

Think of a city-wide library system. The warehouse in the suburbs is Amazon S3: every book (object) ever published is there, perfectly preserved, but a trip to the warehouse takes time. The librarian's desk at the main branch is Amazon ElastiCache: the 200 most-requested books of the week sit within arm's reach, and if you ask for one the librarian hands it to you in a blink. The neighborhood kiosks scattered around town are Amazon CloudFront edge locations: they pre-position the hottest titles near where people live, so a kid three blocks away can grab the bestseller without ever visiting the main branch.

In this analogy, "S3 and caching in applications" means designing your app so that the first read goes to a kiosk, if the kiosk misses, it walks back to the librarian's desk, and only if the desk misses does someone drive all the way to the warehouse. A cache miss is a warehouse trip — expensive, slow, but guaranteed to find the book.

Analogy Two: The Restaurant Kitchen

A restaurant is your application. The walk-in freezer is S3 — it holds every ingredient the restaurant has ever bought, safely frozen, but the chef has to walk in and out each time. The mise en place station next to the stove is ElastiCache — the chef keeps pre-chopped onions, grated cheese, and warm stock right there, because during dinner service you cannot afford a freezer trip per plate. The tableside bread basket is CloudFront — the bread is already at the table, the customer does not even have to ask.

Cache-aside pattern is "chef only refills the mise en place station when they reach for something and it is empty." Write-through is "every time the chef buys a new ingredient, they immediately copy a portion into the station." Write-behind is "the chef scribbles the new ingredient on a sticky note and updates the freezer inventory later."

Analogy Three: The Toolbox and the Bench Drawer

A carpenter's workshop shed is S3 — every tool the carpenter owns lives there. The bench drawer beside the workbench is ElastiCache — the five tools used every minute live in the drawer for instant access. The apron pocket the carpenter wears is an in-process cache or CloudFront — the single tool being used right now is already in hand. S3 and caching in applications is about deciding which tool lives in which tier and how stale a tool can be before it gets swapped out.

The takeaway: caching is always about copying data closer to the consumer, and every tier has its own staleness window and invalidation contract. DVA-C02 loves scenarios where you must name the right tier and the right consistency model.

S3 for Developers — Beyond the Basics

S3 for developers in DVA-C02 is not "object storage overview." The exam wants to know whether you can stitch S3 into an application — using the SDK correctly, presigning URLs, handling large uploads, versioning safely, invalidating edge caches, and wiring event notifications into downstream compute.

S3 API Building Blocks a Developer Must Know

Every DVA-C02 S3 question assumes you can translate between console clicks and SDK calls. The core API verbs:

• PutObject / GetObject / DeleteObject / HeadObject
• CreateMultipartUpload / UploadPart / CompleteMultipartUpload / AbortMultipartUpload
• GeneratePresignedUrl (SDK-side) → produces a signed HTTPS URL with a time-bound signature
• CopyObject (server-side, up to 5 GB for a single call; larger needs multipart copy)
• SelectObjectContent (S3 Select)
• PutObjectAcl / PutBucketPolicy / PutBucketCors / PutBucketVersioning / PutBucketLifecycleConfiguration
• PutBucketNotificationConfiguration (for events)

All of these use Signature Version 4 (SigV4) under the hood, which is why a cloned request five minutes later still fails — the signature is time-bound.

S3 Request Rates and Prefix Sharding

S3 supports at least 3,500 PUT/COPY/POST/DELETE requests per second per prefix and 5,500 GET/HEAD requests per second per prefix. If your application exceeds those per-prefix rates, shard your keys across prefixes (for example logs/2026/04/20/shard=0/…, shard=1/…). This is a favorite DVA-C02 trap because candidates forget that S3 scales by prefix, not by bucket.

S3 Multipart Upload — Thresholds and SDK Auto-Behavior

S3 multipart upload is how a developer pushes a large object reliably. Instead of sending a single 5 GB blob, you break it into parts, upload them in parallel, and ask S3 to reassemble.

S3 Multipart Upload Hard Rules

• Minimum object to use multipart: any object, but AWS recommends multipart for objects larger than 100 MB.
• Required when object exceeds 5 GB — PutObject is hard-capped at 5 GB.
• Maximum object size: 5 TB.
• Part size: 5 MB minimum (except the last part), 5 GB maximum per part, up to 10,000 parts.
• Parts can be uploaded in parallel and retried independently.
• Incomplete multipart uploads keep consuming storage until aborted — so you always need a lifecycle rule to clean them up.

SDK Auto-Behavior Developers Must Know

The high-level AWS SDK transfer managers (for example TransferManager in Java, Upload in boto3 s3.transfer, the @aws-sdk/lib-storage Upload class in JavaScript v3) automatically switch to multipart when the object is larger than an SDK-defined threshold (often 8 MB or 16 MB, configurable). They also parallelize parts and retry failures transparently.

If the exam says "the application uses the default SDK transfer manager to upload a 2 GB video," the right assumption is: multipart is automatic, the developer does not write part-by-part code.

S3 Presigned URLs and Policies

S3 presigned URLs let an application delegate short-lived access to a specific object to an anonymous client (typically a browser or mobile app) without exposing IAM credentials.

How S3 Presigned URLs Work

1. The backend holds an IAM role or credentials that allow s3:PutObject or s3:GetObject.
2. The backend calls GeneratePresignedUrl in the SDK with a verb (GET, PUT), a bucket/key, and an expiration (up to 7 days for SigV4; 1 hour for Lambda execution role credentials due to temporary session lifetime).
3. The SDK returns an HTTPS URL that includes the signature as query parameters.
4. The client performs the HTTP verb directly against S3 with that URL. The S3 endpoint validates the signature and the expiration.

Presigned URL vs Bucket Policy vs IAM

• Presigned URL — temporary, narrow to a single object + verb. Uses the signing principal's permissions.
• Bucket policy — resource-based, applies to everyone hitting the bucket. Use for cross-account or public read.
• IAM policy — identity-based, applies to the user/role making the request.

A presigned URL cannot grant permissions the signer does not have. If the backend role lacks s3:PutObject, a presigned PUT URL is still useless.

S3 Presigned POST for Browser Uploads

GeneratePresignedPost produces form fields a browser <form method="POST" enctype="multipart/form-data"> can submit directly to S3. You can constrain size, content-type, and key prefix with a policy document. For pure "browser uploads file to S3" scenarios, presigned POST is frequently the cleanest choice.

S3 Versioning

S3 versioning turns your bucket into a write-only history. Every PutObject on the same key creates a new version (with a unique versionId) rather than overwriting. DeleteObject without a versionId inserts a delete marker but keeps prior versions intact.

Versioning States

• Unversioned (default) — no version IDs.
• Versioning-enabled — every write creates a new version.
• Versioning-suspended — existing versions remain, new writes get versionId=null.

You cannot go back to unversioned once enabled — only suspended. Combine with MFA Delete for write-protection on deletes.

Developer Implications of S3 Versioning

• Reading the latest version is transparent (GetObject with no versionId).
• Reading a specific historical version needs the versionId parameter.
• Lifecycle rules can expire noncurrent versions (for example "delete noncurrent versions older than 90 days").
• CRR/SRR requires versioning enabled on both source and destination buckets.

S3 Lifecycle Rules

S3 lifecycle rules automate transitions between storage classes and expirations. In DVA-C02, you are expected to encode business rules as lifecycle policy JSON.

Lifecycle Actions

• Transition — move objects to a cheaper class (for example Standard → Standard-IA → Glacier Flexible Retrieval).
• Expiration — permanently delete objects after N days.
• Noncurrent version transition / expiration — separate knobs for older versions in a versioned bucket.
• Abort incomplete multipart uploads — the must-have rule.

Filter Dimensions

Rules can filter by:

• Prefix (logs/2026/)
• Tag (tag:Classification=Archive)
• Object size (>128 KB to dodge the Standard-IA minimum size premium)

S3 Event Notifications to Lambda, SQS, SNS, and EventBridge

S3 event notifications are how a developer turns an S3 bucket into an event source. A new object upload can invoke a Lambda function to generate a thumbnail, push a message to SQS for batch processing, or publish to SNS for fan-out.

S3 Event Types Developers Use

• s3:ObjectCreated:* (and per-verb variants Put, Post, Copy, CompleteMultipartUpload)
• s3:ObjectRemoved:* (Delete, DeleteMarkerCreated)
• s3:ObjectRestore:* (Glacier restore completed)
• s3:Replication:*
• s3:LifecycleTransition, s3:LifecycleExpiration
• s3:ObjectTagging:*

Delivery Targets

Native Notifications vs EventBridge

Native S3 notifications deliver to Lambda/SQS/SNS directly and are simpler, but have a single-target-per-event-type constraint in older configs (now supports multiple destinations for the same event type). Amazon EventBridge gives you content-based filtering, archive/replay, cross-account routing, and a single event bus model — at the cost of slightly higher latency.

Event Delivery Semantics

• Delivery is at-least-once, not exactly-once. Your Lambda must be idempotent.
• Notifications are best-effort eventually consistent — typically seconds.
• For Lambda, the event payload carries an array of records. Process all of them, not just Records[0].

S3 Select — In-Place Query

S3 Select lets you run a SQL SELECT over a single object (CSV, JSON, or Parquet) and return only the matching rows/columns without downloading the full object. This is the developer's "lightweight analytics" tool.

When S3 Select Wins

• Object is large (hundreds of MB to GB) and you only need a small subset.
• Format is structured (CSV/JSON/Parquet).
• Query is simple (filter + projection) — no joins, no aggregates that need multiple objects.

Compared to Athena (which scans many objects with a full SQL engine) and Redshift Spectrum (data-warehouse scale), S3 Select is per-object and much cheaper for narrow projections.

S3 Select API Call

SELECT s.user_id, s.event
FROM S3Object s
WHERE s.event = 'purchase'

The SDK returns a streaming EventStream of records. You pay for data scanned and data returned.

S3 Transfer Acceleration

S3 Transfer Acceleration speeds up uploads from globally distributed clients by routing traffic through the nearest Amazon CloudFront edge location over the AWS backbone, rather than over the public internet all the way to the bucket's Region.

Key Facts

• Enabled per bucket (PutBucketAccelerateConfiguration).
• Accessed via the bucketname.s3-accelerate.amazonaws.com endpoint.
• Costs a per-GB premium on top of normal S3 data transfer.
• Useful when clients are far from the bucket Region (for example users in Asia uploading to us-east-1) and the object is at least tens of MB.
• AWS provides a Transfer Acceleration Speed Comparison tool to prove the win for your specific geography.

If the exam scenario is "global users upload large files to one central bucket and upload time is unacceptable," Transfer Acceleration is almost always the intended answer.

S3 CORS — Cross-Origin Resource Sharing

S3 CORS is the configuration that lets a browser served from https://app.example.com make PUT or GET requests to https://my-bucket.s3.amazonaws.com. Without CORS the browser blocks the request with a No 'Access-Control-Allow-Origin' header error.

CORS Config Shape

[
  {
    "AllowedOrigins": ["https://app.example.com"],
    "AllowedMethods": ["GET", "PUT", "POST"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

You set it with PutBucketCors. The developer traps:

• Mixing up CORS with bucket policy — CORS is about browsers, bucket policy is about authorization. You usually need both.
• Forgetting ExposeHeaders: ETag — multipart uploads need the browser to read the ETag of each part.
• Wildcarding origins in production — AllowedOrigins: ["*"] works but exposes the bucket to every site on the internet.

S3 Object Lock

S3 Object Lock is WORM (write-once-read-many) retention for compliance workloads. Once you set a retention period on an object version, S3 refuses to delete or overwrite that version until the period expires — even the account root cannot remove it.

Retention Modes

• Governance mode — users with s3:BypassGovernanceRetention can still delete. Useful for internal guardrails.
• Compliance mode — no one can delete, including root. Truly immutable.
• Legal hold — boolean flag, no expiration, toggled independently.

Object Lock requires versioning enabled and must be turned on at bucket creation (or via a support ticket later). Classic exam answer for "SEC 17a-4 / HIPAA / FINRA WORM storage without running your own tape robot."

ElastiCache Redis vs Memcached for Application Caching

Amazon ElastiCache offers two engines: Redis and Memcached. The DVA-C02 exam loves to ask which one fits a given scenario. The rule of thumb:

• Pick Redis when you need any of: persistence, replication, high availability (Multi-AZ), pub/sub, streams, geospatial queries, sorted sets, transactions, or complex data types.
• Pick Memcached when you need simple multi-threaded key-value caching with the ability to scale out horizontally by sharding across many nodes.

Feature Comparison Table

Redis Persistence and High Availability

Redis offers two persistence mechanisms:

• RDB snapshots — periodic point-in-time binary dumps. ElastiCache can schedule automatic snapshots to S3.
• AOF (Append-Only File) — every write is appended to a log; replayed on restart. Not enabled by default in ElastiCache and largely superseded by Multi-AZ replicas.

In ElastiCache for Redis, the high-availability story is primary + replicas with automatic failover across AZs. When the primary fails, a replica is promoted within seconds and the cluster DNS endpoint is updated.

Redis Streams and Pub/Sub

• Pub/Sub — fire-and-forget channels, no persistence, no consumer groups.
• Streams — append-only log with consumer groups, similar to Kafka in miniature. Useful for lightweight event streaming inside an application.

Memcached Strengths

• Multi-threaded — one node can use all CPU cores, whereas single-node Redis pegs one core at a time.
• Simpler operationally — no persistence, no replication, no failover to tune.
• Scales by adding nodes — the client library hashes keys across the pool (consistent hashing).

Cache Patterns for S3 and Caching in Applications

Cache patterns define how your application reads and writes with a cache in the path. DVA-C02 tests four classic patterns.

Cache-Aside (Lazy Loading)

The application owns the cache logic. On read:

1. Check the cache for the key.
2. If hit, return the cached value.
3. If miss, read from the database, populate the cache, return the value.

On write, the application updates the database and invalidates or updates the cache key.

Pros:

• Only requested data is cached — efficient memory use.
• Cache failure does not break the write path.

Cons:

• First read after a miss is slow (three hops: cache miss, DB read, cache write).
• Stale data if the write path forgets to invalidate.

Cache-aside is the default pattern for S3 and caching in applications. When in doubt, pick it.

Write-Through

The application writes to the cache and the database together, treating the cache as the source of truth for subsequent reads.

1. Write to cache.
2. Cache writes through to the database (or app does both sequentially).
3. Reads are always fresh from the cache.

Pros:

• No stale data; cache is always consistent with DB.
• Read latency is predictable.

Cons:

• Write latency increases (two writes).
• Cache fills with data that might never be read again.

Write-Behind (Write-Back)

Application writes to the cache; the cache asynchronously flushes to the database later.

Pros:

• Fastest write latency for the application.
• Smooths out bursty write load.

Cons:

• Data loss risk if the cache node fails before flush.
• Complex consistency; rarely the DVA-C02 answer unless the scenario explicitly prioritizes write speed and tolerates loss.

TTL-Based Expiration

Every cached item carries a time-to-live (TTL). When the TTL elapses, the cache evicts the entry; the next read triggers a fresh load (via cache-aside).

Pros:

• Bounded staleness — you know the worst case.
• Self-healing — wrong data eventually ages out.

Cons:

• Short TTLs reduce hit rate; long TTLs increase staleness.

Use TTL in combination with any other pattern. In ElastiCache Redis, SET key value EX 300 sets a 300-second TTL in one command.

Cache Invalidation Strategies

Cache invalidation is famously one of the two hardest problems in computer science. For S3 and caching in applications the practical strategies are:

1. TTL-Based Invalidation

Let the cache expire the entry on its own. Simple, bounded staleness, no extra code — but bad data lives for the TTL window.

2. Explicit Delete on Write

On every write to the system of record (DynamoDB, RDS, S3), delete the corresponding cache key. Immediate consistency, but you must touch every write path.

3. Write-Through Update

On write, update the cache in the same operation. Guarantees consistency at the cost of slower writes.

4. Versioned Keys

Embed a version suffix in the cache key (user:42:v17). To invalidate, bump the version; old entries naturally fall out via LRU eviction. Useful when you cannot enumerate every dependent key.

5. Event-Driven Invalidation

Hook a database stream (DynamoDB Streams, RDS change events) or an S3 event notification to a Lambda function that deletes the matching cache key. Decouples invalidation from the write path.

CloudFront Invalidation

CloudFront caches objects at the edge, so invalidation is its own tool:

• Create an invalidation (CreateInvalidation API) with a path pattern like /images/product-42.jpg or /*. Invalidations cost money beyond a small free tier and take minutes to propagate.
• Versioned filenames — ship product-42.v17.jpg instead of invalidating. The industry-preferred pattern because it is free and instant.
• Cache-Control headers — set reasonable max-age on origin responses so you are not over-reliant on invalidation.

CloudFront as the App-Layer CDN

Amazon CloudFront is the edge cache layer in S3 and caching in applications. A developer uses CloudFront in front of S3 (for static assets), in front of API Gateway or an ALB (for dynamic APIs), or in front of a Lambda function URL.

CloudFront Core Concepts for Developers

• Distribution — the top-level CloudFront object; has a domain name like d123.cloudfront.net.
• Origin — the backend (S3 bucket, custom HTTP origin, Lambda function URL).
• Behavior — path-pattern rule that maps requests to an origin and a cache policy (/images/* → S3 origin, /api/* → API Gateway origin).
• Cache policy — controls what is part of the cache key (headers, cookies, query strings) and the TTL.
• Origin request policy — controls what is forwarded to the origin.
• Response headers policy — lets you inject CORS, security headers without touching the origin.

CloudFront + S3 Patterns

• Origin Access Control (OAC) — the modern way to lock down an S3 bucket so only CloudFront can read it. Replaces the older Origin Access Identity (OAI).
• Signed URLs / Signed Cookies — restrict CloudFront distribution access to authenticated users. Signed cookies cover many files at once; signed URLs cover one file.
• Field-Level Encryption — encrypt specific fields in POST payloads at the edge.
• Lambda@Edge / CloudFront Functions — run code at the edge for auth, header manipulation, A/B testing, URL rewrites.

Cache Key and Hit Ratio

Every request is hashed into a cache key made up of the URL plus whichever headers/cookies/query strings you declared in the cache policy. The fewer inputs in the cache key, the higher the hit ratio. A common mistake is forwarding all headers (including User-Agent) to the origin, which effectively makes every request unique and kills the cache.

Session State Externalization

Session state externalization is the part of S3 and caching in applications that touches application scaling. A stateful web app keeps a user's login, cart, and flow state in the server's memory — which breaks the moment you put it behind an Auto Scaling group or a load balancer.

Three Options DVA-C02 Tests

1. Sticky sessions on the load balancer — Application Load Balancer can pin a client to the same target using a cookie. The server-side code stays simple, but scaling events and unhealthy targets drop sessions.
2. Amazon DynamoDB — store session data in a table with TTL enabled; every request reads and writes the session. Durable, cross-Region capable with Global Tables, but single-digit-millisecond — not microsecond.
3. Amazon ElastiCache for Redis — store session data in Redis with an expiration. Microsecond latency, supports Multi-AZ failover, and is the reference pattern for high-traffic web apps.

Decision Matrix

The DVA-C02 exam usually frames session state externalization as a scaling problem: "users report being logged out when Auto Scaling terminates an instance." The correct move is stop relying on local memory and externalize the session — typically to Redis or DynamoDB.

Session in Redis Example Pattern

• Key: session:<sessionId>
• Value: JSON-encoded user context
• TTL: 30 minutes, refreshed on every request
• Multi-AZ replicas for failover

Session in DynamoDB Example Pattern

• Table: Sessions, partition key sessionId
• Item attributes: userId, createdAt, expiresAt
• TTL attribute: expiresAt — DynamoDB auto-deletes expired items
• Optional GSI on userId to log users out across devices

Putting S3 and Caching in Applications Together — A Reference Architecture

A canonical DVA-C02 application stack using S3 and caching in applications end to end:

1. Client — browser or mobile app.
2. CloudFront distribution — path-based behaviors.
   • /static/* → S3 bucket via OAC with long max-age.
   • /api/* → API Gateway or ALB with short TTL on cache-friendly responses.
3. API Gateway → Lambda — handles the dynamic calls.
4. ElastiCache Redis (Multi-AZ) — session store keyed by session cookie; cache-aside for hot database reads.
5. DynamoDB — primary store for user data with DynamoDB Streams feeding a Lambda that invalidates Redis keys on write.
6. S3 bucket (versioned, Object Lock where needed, lifecycle to Glacier) — user uploads via presigned POST, application-generated reports, logs, data-lake inputs.
7. S3 event notifications — s3:ObjectCreated:* → Lambda (generate thumbnail) → writes derived object back to S3 → notifies SNS for downstream fan-out.
8. S3 Transfer Acceleration — enabled on the upload bucket for global users.

Every exam scenario for S3 and caching in applications is a subset of this stack. Learning to identify which layer the question is poking at — edge vs cache vs origin vs durable archive — is the skill DVA-C02 rewards.

Common DVA-C02 S3 and Caching in Applications Traps

A condensed list of traps that recur in DVA-C02 questions on S3 and caching in applications:

• Presigned URL vs bucket policy confusion — presigned URLs do not override missing permissions on the signer.
• Lifecycle rules without the "abort incomplete multipart upload" action — orphaned parts bill forever.
• Using S3 Select when Athena is correct — S3 Select is single-object; Athena is dataset-wide.
• Picking Memcached when the scenario requires persistence, pub/sub, Multi-AZ, or sorted sets.
• Using CloudFront invalidation as the primary cache-busting strategy — versioned filenames are preferred.
• Forwarding too many headers/cookies to CloudFront origin — destroys hit ratio.
• Assuming Standard-IA is cheapest for small frequent objects — retrieval fees and 128 KB minimums reverse the math.
• Relying on sticky sessions to solve session scaling — externalize to Redis or DynamoDB instead.
• Sharing a single S3 prefix for 10k+ requests per second — shard by prefix.
• Forgetting CORS ExposeHeaders: ETag for multipart uploads from the browser.
• Mixing up S3 Object Lock modes — Governance allows bypass with IAM permission; Compliance does not.
• Using PutObject for files larger than 5 GB — you must use multipart.

FAQ

Q1. For a browser upload of a 2 GB video directly to S3 without routing through my backend, what is the best pattern?

Use an S3 presigned POST (or presigned PUT) generated by your backend with an expiration of, say, 15 minutes and a policy that constrains the key prefix, content-type, and max size. The browser posts the multipart form directly to S3. The SDK in the browser (v3 @aws-sdk/lib-storage Upload) will automatically break the file into multipart parts. Remember to configure S3 CORS with AllowedOrigins set to your app domain and ExposeHeaders including ETag.

Q2. When should I choose ElastiCache for Redis over ElastiCache for Memcached?

Choose Redis whenever you need persistence across node reboots, Multi-AZ with automatic failover, read replicas, pub/sub, streams, sorted sets (leaderboards), geospatial queries, or transactions. Choose Memcached only for simple multi-threaded key-value caching where losing all cached data on a node failure is acceptable, and you need to scale by adding nodes with client-side hashing. In practice, roughly 80% of new AWS cache deployments pick Redis, which is also what the DVA-C02 exam biases toward.

Q3. My CloudFront distribution in front of S3 shows a poor cache hit ratio. What do I check first?

Inspect the cache key configured in the cache policy. If you are forwarding many headers (especially User-Agent), cookies, or query strings to the cache key, each small variation produces a unique cache entry. Narrow the cache policy to just the URL path for static assets. Then confirm your origin emits a sensible Cache-Control: max-age header — CloudFront honors origin TTLs by default. Finally, check that assets use versioned filenames so redeployments do not force you to issue invalidations.

Q4. How do I safely invalidate a cached database row in ElastiCache Redis when the row changes in DynamoDB?

The cleanest pattern is event-driven invalidation: enable DynamoDB Streams on the table and attach a Lambda function that, for each change record, deletes (DEL) or updates the matching Redis key. Combine this with a TTL on the cache entry as a safety net so even if an invalidation event is lost, the wrong data expires within a bounded window. Avoid invalidating from the application write path alone because it couples your writer to the cache's availability.

Q5. A user complains they get logged out when Auto Scaling terminates an EC2 instance. What change do I make?

The root cause is session state living in the instance's local memory. Externalize the session to a shared store. For most web apps, Amazon ElastiCache for Redis (Multi-AZ) is the right answer because it gives sub-millisecond reads and supports session TTL with EXPIRE. For serverless or mobile apps, Amazon DynamoDB with a TTL attribute is equally valid and eliminates operational overhead. Sticky sessions on the ALB can mask the problem for a while but still drop sessions on target failure, so they are not the DVA-C02 answer when the scenario mentions scaling events or high availability.

Q6. Which S3 feature stops anyone — including the root account — from deleting a regulatory archive for seven years?

S3 Object Lock in Compliance mode with a seven-year retention period. Compliance mode is the only setting that truly blocks the root account. Governance mode allows users with s3:BypassGovernanceRetention to delete, so it is not sufficient for SEC 17a-4 or FINRA-style mandates. Object Lock requires versioning enabled and is typically set at bucket creation.

Q7. When is S3 Transfer Acceleration actually worth the extra cost?

When clients are globally distributed and far from the bucket Region, upload sizes are tens of MB or larger, and upload time is the bottleneck (not egress cost). The feature routes traffic through the nearest CloudFront edge over the AWS backbone, which skips the slowest internet hops. For small objects or clients already in the bucket's Region, the extra per-GB fee does not pay back. AWS publishes a Transfer Acceleration Speed Comparison tool — run it for your actual client geography before enabling.

Q8. What is the difference between S3 Select and Amazon Athena for a developer?

S3 Select runs a SQL projection/filter on a single object (CSV, JSON, or Parquet) and streams matching records back. It is cheap, narrow, and designed to replace "download the whole object and grep." Amazon Athena runs full ANSI SQL (joins, aggregates, window functions) over an entire dataset of objects in one or more buckets, using the AWS Glue Data Catalog for schema. If the DVA-C02 scenario says "query one file," answer S3 Select; if it says "query a dataset" or "query many files," answer Athena.

Summary — S3 and Caching in Applications for DVA-C02

S3 and caching in applications is the developer's bread and butter on DVA-C02. The exam rewards candidates who can:

• Reach for multipart upload above 100 MB and always clean up incomplete uploads with a lifecycle rule.
• Hand out presigned URLs / POSTs for browser-direct uploads without leaking IAM credentials.
• Use versioning + lifecycle to keep history safely and cheaply, and Object Lock for regulatory immutability.
• Wire S3 event notifications into Lambda, SQS, SNS, or EventBridge — with idempotent consumers.
• Pick S3 Select for single-object projections, Transfer Acceleration for global uploads, and CORS for browser access.
• Choose ElastiCache Redis for anything requiring persistence, pub/sub, streams, or Multi-AZ, and Memcached only for simple multi-threaded key-value scale-out.
• Apply the right cache pattern — cache-aside by default, write-through for read-after-write consistency, TTL as a safety net, event-driven invalidation for correctness.
• Put CloudFront in front with narrow cache keys, Origin Access Control, and versioned filenames instead of invalidations.
• Externalize session state to Redis or DynamoDB so Auto Scaling stops logging users out.

Treat the layers as a stack — CloudFront at the edge, ElastiCache in the middle, S3 and DynamoDB as durable origins — and every S3 and caching in applications question becomes "which layer is the question poking at?" That framing alone earns most of the points.