[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-aws-certified-cloudops-engineer-associate-reliability-business-continuity-scaling-compute-workloads-scaling-containers-and-serverless-en":4,"next-aws-certified-cloudops-engineer-associate-reliability-business-continuity-scaling-compute-workloads-scaling-containers-and-serverless-en":19,"lesson-aws-certified-cloudops-engineer-associate-reliability-business-continuity-scaling-compute-workloads-scaling-containers-and-serverless-en":1141},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"ASG Lifecycle Hooks and Instance Refresh","The states an instance passes through inside an Auto Scaling group, the lifecycle hooks that pause it at launch and termination, warm pools for slow boots, and how instance refresh rolls a new AMI across the fleet without dropping capacity.",false,27,"advanced",[14,15,16,17,18],"Trace an instance through the Auto Scaling group lifecycle states, including the wait states a lifecycle hook creates","Configure a lifecycle hook with the right timeout and default result for a launch or termination action","Decide when a warm pool is justified and which instance state to keep the pool in","Use standby and detach to work on an instance without the group replacing it","Set minimum and maximum healthy percentages for an instance refresh to get the replacement behavior you need",{"locked":10,"reason":3,"meta":20,"item":31},{"title":21,"description":22,"isFree":5,"estimatedMinutes":23,"difficulty":24,"learningObjectives":25},"Caching with CloudFront and ElastiCache","Where to put a cache so it removes real load: the CloudFront cache key and TTL rules that decide what the edge keeps, and the lazy loading, write-through, and TTL strategies that decide what ElastiCache holds in front of your database.",30,"intermediate",[26,27,28,29,30],"Decide whether a workload needs an edge cache, a database cache, or both","Predict how long CloudFront keeps an object given the cache policy TTLs and the origin's Cache-Control headers","Raise a CloudFront cache hit ratio by shrinking the cache key, and choose between invalidation and versioned file names","Compare lazy loading, write-through, and TTL as ElastiCache population strategies and name the failure each one carries","Read ElastiCache CloudWatch metrics to choose between scaling up, adding replicas, and adding shards",{"id":32,"title":21,"body":33,"description":22,"difficulty":24,"estimatedMinutes":23,"extension":1051,"infographics":1052,"isFree":5,"learningObjectives":1067,"meta":1068,"navigation":5,"path":1069,"quiz":1070,"seo":1138,"stem":1139,"__hash__":1140},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/03-caching-and-database-scaling/01-caching-with-cloudfront-and-elasticache.md",{"type":34,"value":35,"toc":1037},"minimark",[36,40,43,48,136,144,147,151,161,168,171,235,243,246,306,312,316,319,342,347,350,420,423,474,492,496,499,509,527,530,534,537,559,562,593,607,613,617,620,626,632,643,649,655,666,672,678,681,685,688,793,800,804,807,913,931,934,960,964,971,974,992,996,1034],[37,38,39],"p",{},"Your catalog page runs one query that takes 300 ms and returns the same 200 rows for every visitor. At 400 requests per second, the database runs that query 400 times a second and burns its CPU producing an answer it already produced. Nothing is wrong with the query. The problem is that you are recomputing a constant, and the fix is to keep the answer somewhere closer than the thing that computed it.",[37,41,42],{},"AWS gives you two very different places to keep it, and SOA-C03 Skill 2.1.2 names both: Amazon CloudFront at the edge and Amazon ElastiCache next to your application. They are not interchangeable, and picking the wrong one means adding a service that removes no load.",[44,45,47],"h2",{"id":46},"two-caches-two-distances","Two caches, two distances",[49,50,51,66],"table",{},[52,53,54],"thead",{},[55,56,57,60,63],"tr",{},[58,59],"th",{},[58,61,62],{},"CloudFront",[58,64,65],{},"ElastiCache",[67,68,69,81,92,103,114,125],"tbody",{},[55,70,71,75,78],{},[72,73,74],"td",{},"Where it sits",[72,76,77],{},"AWS edge locations, near the viewer",[72,79,80],{},"Inside your VPC, near your application",[55,82,83,86,89],{},[72,84,85],{},"What it stores",[72,87,88],{},"Whole HTTP responses, keyed by a cache key",[72,90,91],{},"Whatever your code puts there, keyed by a string",[55,93,94,97,100],{},[72,95,96],{},"Who writes to it",[72,98,99],{},"CloudFront, automatically, on a cache miss",[72,101,102],{},"Your application code, explicitly",[55,104,105,108,111],{},[72,106,107],{},"What it protects",[72,109,110],{},"The origin and the network path to it",[72,112,113],{},"The database",[55,115,116,119,122],{},[72,117,118],{},"A miss costs",[72,120,121],{},"One request to the origin",[72,123,124],{},"One database query plus one cache write",[55,126,127,130,133],{},[72,128,129],{},"You tune it with",[72,131,132],{},"Cache policies, TTLs, the cache key",[72,134,135],{},"Strategy, TTL, node type, shard count",[37,137,138,139,143],{},"The line that decides which one you reach for: ",[140,141,142],"strong",{},"CloudFront is a cache you configure, ElastiCache is a cache you program."," If the same bytes go out to many viewers over HTTP, CloudFront can absorb that traffic without a code change. If the expensive thing is a query result, a session object, or a computed leaderboard that only your application understands, no edge cache can help, because CloudFront cannot see inside the response to know it is reusable.",[37,145,146],{},"Large systems run both. CloudFront takes the repeated public responses, ElastiCache takes the repeated internal reads, and the database only sees what genuinely varies.",[44,148,150],{"id":149},"the-cloudfront-cache-key-decides-what-a-hit-even-means","The CloudFront cache key decides what a \"hit\" even means",[37,152,153,154,157,158],{},"CloudFront stores each object under a ",[140,155,156],{},"cache key",". A viewer request is a hit only if it produces the same cache key as an earlier request and that object is still valid at the edge location. Everything about tuning CloudFront caching comes back to one rule: ",[140,159,160],{},"fewer values in the cache key means more hits.",[37,162,163,164,167],{},"You control the key with a ",[140,165,166],{},"cache policy"," attached to a cache behavior. The policy says which headers, cookies, and query strings become part of the key, and it carries the TTL settings.",[37,169,170],{},"The managed policies are worth memorizing because they mark the two ends of the range:",[49,172,173,192],{},[52,174,175],{},[55,176,177,180,183,186,189],{},[58,178,179],{},"Managed cache policy",[58,181,182],{},"Min TTL",[58,184,185],{},"Max TTL",[58,187,188],{},"Default TTL",[58,190,191],{},"Cache key contents",[67,193,194,218],{},[55,195,196,202,205,208,211],{},[72,197,198],{},[199,200,201],"code",{},"CachingOptimized",[72,203,204],{},"1 s",[72,206,207],{},"31,536,000 s (365 days)",[72,209,210],{},"86,400 s (24 h)",[72,212,213,214,217],{},"Nothing but the normalized ",[199,215,216],{},"Accept-Encoding"," header",[55,219,220,225,228,230,232],{},[72,221,222],{},[199,223,224],{},"CachingDisabled",[72,226,227],{},"0 s",[72,229,227],{},[72,231,227],{},[72,233,234],{},"Nothing",[37,236,237,239,240,242],{},[199,238,201],{}," is the default answer for static assets. ",[199,241,224],{}," is the correct answer for anything genuinely per-user, and it works because all three TTLs are 0, not because it forwards nothing.",[37,244,245],{},"Three cache-key mistakes cost real hit ratio, and each has a fix:",[247,248,249,271,281],"ul",{},[250,251,252,255,256,259,260,263,264,259,267,270],"li",{},[140,253,254],{},"Case and order in query strings."," ",[199,257,258],{},"?parameter1=A"," and ",[199,261,262],{},"?parameter1=a"," are two different keys, and so are ",[199,265,266],{},"?parameter1=a&parameter2=b",[199,268,269],{},"?parameter2=b&parameter1=a",". Same object, up to four cache entries. Standardize on one case and one order in the application that builds the URLs.",[250,272,273,276,277,280],{},[140,274,275],{},"Forwarding all cookies."," For every cookie you forward, CloudFront caches a separate copy per name and value combination. Two cookies with three possible values each is up to 9 copies of the same ",[199,278,279],{},".css"," file. Split static and dynamic content into separate cache behaviors and forward cookies only on the dynamic one.",[250,282,283,290,291,294,295,294,298,301,302,305],{},[140,284,285,286,289],{},"Caching on ",[199,287,288],{},"User-Agent","."," It has an enormous number of distinct values, so it effectively disables caching while looking like a working configuration. If you need device-aware responses, cache on the CloudFront device headers instead: ",[199,292,293],{},"CloudFront-Is-Desktop-Viewer",", ",[199,296,297],{},"CloudFront-Is-Mobile-Viewer",[199,299,300],{},"CloudFront-Is-SmartTV-Viewer",", and ",[199,303,304],{},"CloudFront-Is-Tablet-Viewer",". Four values, not thousands, and you can forward only the ones that actually change the response.",[37,307,308,309,311],{},"One more lever sits outside the key. If compression is not in play, attach a custom origin header named ",[199,310,216],{}," with a blank value. CloudFront then drops that header from the cache key entirely instead of splitting every object into Gzip, Brotli, and uncompressed variants.",[44,313,315],{"id":314},"how-long-an-object-stays-the-origin-proposes-the-policy-decides","How long an object stays: the origin proposes, the policy decides",[37,317,318],{},"This is the part operators get wrong, and it is worth walking slowly.",[37,320,321,322,294,325,301,328,330,331,294,334,337,338,341],{},"Three settings live in the cache policy: ",[140,323,324],{},"Minimum TTL",[140,326,327],{},"Maximum TTL",[140,329,188],{},". The origin can also send ",[199,332,333],{},"Cache-Control: max-age",[199,335,336],{},"Cache-Control: s-maxage",", or an ",[199,339,340],{},"Expires"," header. Neither side wins outright. The origin proposes a duration and the policy clamps it into range.",[343,344],"infographic",{"alt":345,"slug":346},"A cache duration axis with the Minimum TTL and Maximum TTL drawn as gates, showing an origin max-age below the floor being clamped up, one inside the range honored exactly, one above the ceiling clamped down, and a response with no Cache-Control header resolving to the Default TTL.","cloudfront-ttl-clamp",[37,348,349],{},"Work through it with a policy of Minimum TTL 60, Maximum TTL 86400, Default TTL 3600:",[49,351,352,365],{},[52,353,354],{},[55,355,356,359,362],{},[58,357,358],{},"Origin response",[58,360,361],{},"CloudFront caches for",[58,363,364],{},"Why",[67,366,367,380,393,406],{},[55,368,369,374,377],{},[72,370,371],{},[199,372,373],{},"Cache-Control: max-age=10",[72,375,376],{},"60 s",[72,378,379],{},"Below the minimum, so it is raised to the Minimum TTL",[55,381,382,387,390],{},[72,383,384],{},[199,385,386],{},"Cache-Control: max-age=7200",[72,388,389],{},"7200 s",[72,391,392],{},"Inside the range, so it is honored exactly",[55,394,395,400,403],{},[72,396,397],{},[199,398,399],{},"Cache-Control: max-age=31536000",[72,401,402],{},"86400 s",[72,404,405],{},"Above the maximum, so it is lowered to the Maximum TTL",[55,407,408,414,417],{},[72,409,410,411,217],{},"No ",[199,412,413],{},"Cache-Control",[72,415,416],{},"3600 s",[72,418,419],{},"Nothing was proposed, so the Default TTL applies",[37,421,422],{},"Three details around the edges of that table:",[247,424,425,444,462],{},[250,426,427,437,438,440,441,443],{},[140,428,429,432,433,436],{},[199,430,431],{},"s-maxage"," beats ",[199,434,435],{},"max-age"," at the edge."," When the origin sends both, CloudFront clamps ",[199,439,431],{}," and the browser uses ",[199,442,435],{},". That is how you cache an object for an hour at the edge and a minute in the browser.",[250,445,446,451,452,259,454,456,457,459,460,289],{},[140,447,448,450],{},[199,449,340],{}," is the weaker option."," If the origin sends both ",[199,453,333],{},[199,455,340],{},", CloudFront uses only ",[199,458,435],{},". AWS recommends ",[199,461,435],{},[250,463,464,467,468,259,470,473],{},[140,465,466],{},"A viewer cannot force a refresh."," CloudFront ignores ",[199,469,413],{},[199,471,472],{},"Pragma"," in viewer requests, so a hard reload in the browser does not clear the edge.",[37,475,476,477,480,481,484,485,487,488,491],{},"Now the misconception that ships bugs. It is tempting to assume that ",[199,478,479],{},"Cache-Control: no-store"," from the origin always stops CloudFront from caching. ",[140,482,483],{},"It does not when the cache policy's Minimum TTL is greater than 0."," In that case CloudFront caches the object for the minimum TTL even though the origin said not to, which is how a personalized account page gets served to the next viewer that hits the same edge location. Both ",[199,486,201],{}," (Minimum TTL 1 second) and the ",[199,489,490],{},"Amplify"," policy (Minimum TTL 2 seconds) carry this warning in the AWS docs. If content must never be cached, the answer is a policy whose minimum TTL is 0.",[44,493,495],{"id":494},"serving-stale-on-purpose","Serving stale on purpose",[37,497,498],{},"Two directives let you trade a little freshness for latency and for surviving an origin outage:",[500,501,506],"pre",{"className":502,"code":504,"language":505},[503],"language-text","Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400\n","text",[199,507,504],{"__ignoreMap":508},"",[247,510,511,514,521],{},[250,512,513],{},"For the first hour, CloudFront serves from cache normally.",[250,515,516,517,520],{},"After that, ",[199,518,519],{},"stale-while-revalidate=600"," lets CloudFront hand the viewer the stale copy immediately while it fetches a fresh one in the background, for up to 10 minutes.",[250,522,523,526],{},[199,524,525],{},"stale-if-error=86400"," lets CloudFront keep serving the stale copy for up to 24 hours if the origin is unreachable or returns a 5xx.",[37,528,529],{},"Both are capped by the cache policy's Maximum TTL, whichever is less. Past the maximum TTL the object is gone from the edge regardless of what the directives asked for.",[44,531,533],{"id":532},"invalidation-versus-versioned-file-names","Invalidation versus versioned file names",[37,535,536],{},"When you need content out of the cache before it expires, you have two options, and AWS recommends the one people reach for second.",[37,538,539,542,543,546,547,550,551,554,555,558],{},[140,540,541],{},"Invalidation"," removes files from edge caches now. The first ",[140,544,545],{},"1,000 invalidation paths per month are free per AWS account"," across all distributions, and you pay per path after that. A path with a ",[199,548,549],{},"*"," wildcard ",[140,552,553],{},"counts as one path"," no matter how many files it removes, so ",[199,556,557],{},"/*"," is a single billable unit. The wildcard must be the last character; an asterisk anywhere else is matched literally.",[37,560,561],{},"Two invalidation traps that waste a deployment:",[247,563,564,581],{},[250,565,566,569,570,573,574,577,578,289],{},[140,567,568],{},"Query strings are part of the path."," If the cache key includes query strings, ",[199,571,572],{},"/images/logo.jpg"," does not invalidate ",[199,575,576],{},"/images/logo.jpg?v=2",". Use ",[199,579,580],{},"/images/logo.jpg*",[250,582,583,586,587,259,590,289],{},[140,584,585],{},"Directory paths need both forms."," If your URLs are not consistent about trailing slashes, invalidate ",[199,588,589],{},"/images",[199,591,592],{},"/images/",[37,594,595,598,599,602,603,606],{},[140,596,597],{},"Versioned file names"," mean shipping ",[199,600,601],{},"app.a3f91c.js"," instead of overwriting ",[199,604,605],{},"app.js",". AWS recommends this as the primary approach for content that changes often, and the reason is not just cost. An invalidation clears CloudFront but does nothing about the copy sitting in the viewer's browser or a corporate proxy; a new file name changes the URL, so every cache in the chain misses. It also makes rollback trivial and makes access logs readable, because the log line names the version that was served.",[37,608,609,612],{},[140,610,611],{},"Origin Shield"," is the other structural lever. It puts one more caching layer in front of the origin so that all CloudFront layers, edge locations and regional edge caches, funnel through a single location. The origin can then serve one request per object instead of one per regional cache.",[44,614,616],{"id":615},"elasticache-the-cache-you-have-to-program","ElastiCache: the cache you have to program",[37,618,619],{},"CloudFront populates itself. ElastiCache does not: your code decides what goes in, when, and for how long. AWS documents three strategies, and the exam tests the failure mode of each rather than the definition.",[37,621,622,625],{},[140,623,624],{},"Lazy loading"," writes to the cache only after a miss.",[500,627,630],{"className":628,"code":629,"language":505},[503],"get_customer(customer_id)\n    customer_record = cache.get(customer_id)\n    if (customer_record == null)\n        customer_record = db.query(\"SELECT * FROM Customers WHERE id = {0}\", customer_id)\n        cache.set(customer_id, customer_record)\n    return customer_record\n",[199,631,629],{"__ignoreMap":508},[37,633,634,635,638,639,642],{},"Only requested data ever enters the cache, and a node failure is survivable: a fresh empty node still returns correct answers, just slower, while misses refill it. The costs are a ",[140,636,637],{},"three-trip miss penalty"," (read the cache, query the database, write the cache) and ",[140,640,641],{},"stale data",", because nothing updates the cache when the database changes underneath it.",[37,644,645,648],{},[140,646,647],{},"Write-through"," writes to the cache on every database write.",[500,650,653],{"className":651,"code":652,"language":505},[503],"save_customer(customer_id, values)\n    customer_record = db.query(\"UPDATE Customers WHERE id = {0}\", customer_id, values)\n    cache.set(customer_id, customer_record)\n    return success\n",[199,654,652],{"__ignoreMap":508},[37,656,657,658,661,662,665],{},"Cached data is never stale, and the extra latency lands on writes, where users tolerate it better. The costs are the mirror image of lazy loading: ",[140,659,660],{},"missing data"," on any new node, because a fresh node holds nothing until the corresponding rows are written again, and ",[140,663,664],{},"cache churn",", because you are caching writes that may never be read.",[37,667,668,671],{},[140,669,670],{},"Adding a TTL"," to every write is what makes the pair work together. A TTL caps how stale a lazily loaded entry can get and evicts write-through entries that nobody reads. The production pattern is all three: write-through for correctness, lazy loading for resilience, TTL to bound both.",[500,673,676],{"className":674,"code":675,"language":505},[503],"cache.set(customer_id, customer_record, 300)   # expires in 5 minutes\n",[199,677,675],{"__ignoreMap":508},[37,679,680],{},"TTL never guarantees freshness. It guarantees a ceiling on staleness, which is a different and much more achievable promise. Say so in the design review rather than letting \"we cache for 5 minutes\" be heard as \"the cache is correct\".",[44,682,684],{"id":683},"choosing-the-engine-and-why-it-changes-your-scaling-options","Choosing the engine, and why it changes your scaling options",[37,686,687],{},"ElastiCache supports Memcached, Valkey, and Redis OSS. The engine you pick determines which scaling actions even exist, so this is not a preference question.",[49,689,690,705],{},[52,691,692],{},[55,693,694,696,699,702],{},[58,695],{},[58,697,698],{},"Memcached",[58,700,701],{},"Valkey / Redis OSS (cluster mode disabled)",[58,703,704],{},"Valkey / Redis OSS (cluster mode enabled)",[67,706,707,721,734,745,758,770,781],{},[55,708,709,712,715,718],{},[72,710,711],{},"Data types",[72,713,714],{},"Simple strings and objects",[72,716,717],{},"Complex (lists, hashes, sets, sorted sets)",[72,719,720],{},"Complex",[55,722,723,726,729,732],{},[72,724,725],{},"Multi-threaded",[72,727,728],{},"Yes",[72,730,731],{},"No",[72,733,731],{},[55,735,736,739,741,743],{},[72,737,738],{},"Replication (read replicas)",[72,740,731],{},[72,742,728],{},[72,744,728],{},[55,746,747,750,752,755],{},[72,748,749],{},"Automatic failover",[72,751,731],{},[72,753,754],{},"Optional",[72,756,757],{},"Required",[55,759,760,763,766,768],{},[72,761,762],{},"Data partitioning across shards",[72,764,765],{},"Yes, client-side",[72,767,731],{},[72,769,728],{},[55,771,772,775,777,779],{},[72,773,774],{},"Online resharding",[72,776,731],{},[72,778,731],{},[72,780,728],{},[55,782,783,786,789,791],{},[72,784,785],{},"Backup and restore",[72,787,788],{},"Node-based clusters: no",[72,790,728],{},[72,792,728],{},[37,794,795,796,799],{},"Choose Memcached when you want the simplest possible model, large multi-core nodes, and plain object caching. Choose Valkey or Redis OSS when you need replication, failover, persistence, sorted sets, or pub/sub. The practical consequence: ",[140,797,798],{},"a Memcached cluster cannot be fixed by adding replicas, because it has none."," Its only levers are a larger node type or more nodes.",[44,801,803],{"id":802},"reading-the-metrics-then-choosing-the-scaling-action","Reading the metrics, then choosing the scaling action",[37,805,806],{},"ElastiCache scaling questions are usually diagnostic. A metric tells you which resource is short, and the resource plus the engine tells you the action.",[49,808,809,822],{},[52,810,811],{},[55,812,813,816,819],{},[58,814,815],{},"Metric",[58,817,818],{},"What it means",[58,820,821],{},"What it points you toward",[67,823,824,837,850,863,887,900],{},[55,825,826,831,834],{},[72,827,828],{},[199,829,830],{},"CPUUtilization",[72,832,833],{},"Host-level CPU percentage",[72,835,836],{},"On small nodes, the workload ceiling",[55,838,839,844,847],{},[72,840,841],{},[199,842,843],{},"EngineCPUUtilization",[72,845,846],{},"Usage of the single engine core",[72,848,849],{},"The real signal on nodes with 4 or more vCPUs",[55,851,852,857,860],{},[72,853,854],{},[199,855,856],{},"Evictions",[72,858,859],{},"Keys removed to make room",[72,861,862],{},"Not enough memory for the working set",[55,864,865,873,876],{},[72,866,867,259,870],{},[199,868,869],{},"SwapUsage",[199,871,872],{},"FreeableMemory",[72,874,875],{},"Memory pressure",[72,877,878,880,881,883,884,886],{},[199,879,872],{}," under 100 MB, or ",[199,882,869],{}," above ",[199,885,872],{},", means the node is in trouble",[55,888,889,894,897],{},[72,890,891],{},[199,892,893],{},"ReplicationLag",[72,895,896],{},"How far a replica trails the primary",[72,898,899],{},"Replica reads are returning old data",[55,901,902,907,910],{},[72,903,904],{},[199,905,906],{},"TrafficManagementActive",[72,908,909],{},"Value of 1 means ElastiCache is throttling incoming commands",[72,911,912],{},"The node is underscaled for the workload",[37,914,915,916,919,920,923,924,927,928,930],{},"The CPU threshold catches people out, so work it. Valkey and Redis OSS run the engine on ",[140,917,918],{},"one thread",", so a node can be completely saturated while host CPU reads far below 100 percent. AWS gives the arithmetic: set the threshold at ",[140,921,922],{},"90 divided by the number of cores",". On a 2-core node that is ",[140,925,926],{},"45 percent",". A cluster sitting at 46 percent CPU with climbing latency is not healthy and idle, it is pinned. On node types with 4 or more vCPUs, use ",[199,929,843],{}," instead and the division disappears. Memcached is multi-threaded, so its threshold really is around 90 percent.",[37,932,933],{},"Once you know the resource, the action follows the engine and the workload:",[247,935,936,942,948,954],{},[250,937,938,941],{},[140,939,940],{},"Read-heavy and over threshold, Valkey or Redis OSS:"," add read replicas.",[250,943,944,947],{},[140,945,946],{},"Write-heavy, cluster mode disabled:"," scale up to a larger node type. There is only one primary, so more writes need a bigger primary.",[250,949,950,953],{},[140,951,952],{},"Write-heavy, cluster mode enabled:"," add shards, which spreads writes across more primary nodes.",[250,955,956,959],{},[140,957,958],{},"Any pressure, Memcached:"," larger node type, or more nodes.",[44,961,963],{"id":962},"how-the-scaling-actually-happens","How the scaling actually happens",[37,965,966,967,970],{},"For ",[140,968,969],{},"cluster mode enabled",", online resharding changes the shard count while the cluster keeps serving requests. Adding shards raises read and write capacity, removing them lowers cost, and rebalancing evens out the keyspace across existing shards. Three limits to know: new shards get the same node count as the smallest existing shard, you cannot set per-shard keyspaces online (that requires the offline backup-and-restore path), and keys holding items larger than 256 MB after serialization are not migrated, which can leave shards unbalanced. Before removing shards, ElastiCache checks that the remaining shards can hold the data and cancels the operation rather than losing keys.",[37,972,973],{},"Vertical scaling by node type is also an online operation for Valkey and Redis OSS. Offline resharding, the backup-and-restore path, is the one that goes dark, and you accept that downtime only when you need the things it uniquely allows: changing node type, engine version, per-shard replica counts, and keyspaces in a single move.",[37,975,976,979,980,983,984,987,988,991],{},[140,977,978],{},"ElastiCache Serverless"," removes the shard decision. It tracks CPU, memory, and network continuously and adds shards on its own, and you watch two metrics instead of a node list: ",[199,981,982],{},"BytesUsedForCache"," for storage and ",[199,985,986],{},"ElastiCacheProcessingUnits"," (ECPUs) for compute. You can cap both to bound cost, but understand what a cap does at the edge: hitting the storage maximum makes ElastiCache evict TTL-bearing keys by LRU and then return out-of-memory errors, and hitting the ECPU maximum makes it throttle requests. AWS recommends a CloudWatch alarm at ",[140,989,990],{},"75 percent of whatever maximum you set",", so you find out before your users do.",[44,993,995],{"id":994},"exam-tips","Exam tips",[247,997,998,1001,1010,1013,1016,1019,1022,1028,1031],{},[250,999,1000],{},"\"Same response to many viewers over HTTP\" is CloudFront. \"Expensive query result reused by the application\" is ElastiCache. A stem that describes a database under read pressure is not asking about the edge.",[250,1002,1003,1004,1006,1007,1009],{},"Given TTL numbers, do the clamp: ",[199,1005,435],{}," below Minimum TTL rounds up to the minimum, above Maximum TTL rounds down to the maximum, and Default TTL applies only when the origin sends no ",[199,1008,435],{},". Wrong answers pick whichever number was mentioned last.",[250,1011,1012],{},"\"The origin sends no-store but stale content is still served\" points at a cache policy with a Minimum TTL greater than 0, not at a CloudFront defect.",[250,1014,1015],{},"1,000 free invalidation paths per month per account, and a wildcard path counts as one. If the stem stresses frequent updates, the intended answer is usually versioned file names, not more invalidations.",[250,1017,1018],{},"Any option that raises the cache hit ratio by adding headers, cookies, or query strings to the cache key is wrong. Hits come from a smaller key.",[250,1020,1021],{},"Lazy loading allows stale data and survives empty nodes. Write-through is always fresh and fails on empty nodes. TTL is what makes running both viable. Match the symptom to the strategy, not the definition.",[250,1023,1024,1025,1027],{},"Valkey and Redis OSS are single-threaded: the CPU alarm threshold is 90 divided by the core count, and ",[199,1026,843],{}," is the cleaner signal on larger nodes.",[250,1029,1030],{},"Memcached has no replicas, no failover, and no cluster mode. Any answer offering those for a Memcached cluster is wrong on the engine boundary alone.",[250,1032,1033],{},"Read-heavy means replicas, write-heavy on cluster mode disabled means a bigger node, write-heavy on cluster mode enabled means more shards.",[37,1035,1036],{},"The rule to carry out of this lesson: name the thing that is repeating before you name the service. Repeated HTTP responses belong at the edge, repeated query results belong in memory next to the application, and anything that genuinely varies per request belongs nowhere but the database. That last category is the one caching cannot rescue, and it is where the next lesson starts, on scaling the relational database itself.",{"title":508,"searchDepth":1038,"depth":1038,"links":1039},3,[1040,1042,1043,1044,1045,1046,1047,1048,1049,1050],{"id":46,"depth":1041,"text":47},2,{"id":149,"depth":1041,"text":150},{"id":314,"depth":1041,"text":315},{"id":494,"depth":1041,"text":495},{"id":532,"depth":1041,"text":533},{"id":615,"depth":1041,"text":616},{"id":683,"depth":1041,"text":684},{"id":802,"depth":1041,"text":803},{"id":962,"depth":1041,"text":963},{"id":994,"depth":1041,"text":995},"md",[1053],{"slug":346,"concept":1054,"style":1055,"aspectRatio":1056,"labels":1057},"A single horizontal axis of cache duration in seconds, with the cache policy's Minimum TTL and Maximum TTL drawn as two vertical gates that bracket a shaded allowed band. Four origin responses are plotted as arrows landing on the axis: a max-age below the minimum that is pulled up to the Minimum TTL, a max-age inside the band that lands untouched, a max-age above the maximum that is pulled down to the Maximum TTL, and a response with no Cache-Control header that resolves to a dashed Default TTL marker inside the band. Emphasis is on the two clamping arrows, drawn thicker than the others. A footer strip states the rule in one sentence.","diagram","16:9",[1058,1059,1060,1061,1062,1063,1064,1065,1066],"Cache duration (seconds)","Minimum TTL: the floor CloudFront will not cache below","Maximum TTL: the ceiling CloudFront will not cache above","Default TTL: used only when the origin sends no Cache-Control max-age","max-age=30, below the floor: clamped up to the Minimum TTL","max-age=3600, inside the band: honored exactly","max-age=31536000, above the ceiling: clamped down to the Maximum TTL","No Cache-Control header: CloudFront falls back to the Default TTL","The origin proposes a duration. The cache policy's minimum and maximum decide the one CloudFront actually uses.",[26,27,28,29,30],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/03-caching-and-database-scaling/01-caching-with-cloudfront-and-elasticache",{"passingScore":1071,"questions":1072},70,[1073,1082,1090,1098,1108,1116,1124,1132],{"question":1074,"type":1075,"options":1076,"correctAnswer":1080,"explanation":1081},"A cache behavior uses a cache policy with Minimum TTL 60, Maximum TTL 86400, and Default TTL 3600. The origin returns an object with the header Cache-Control: max-age=10. How long does CloudFront keep the object in the edge cache?","single",[1077,1078,1079,1080],"10 seconds, because the origin header wins","86400 seconds, because CloudFront uses the Maximum TTL when max-age is invalid","3600 seconds, because CloudFront falls back to the Default TTL","60 seconds, because max-age is below the Minimum TTL","The origin proposes a duration and the cache policy clamps it: a max-age below the Minimum TTL is raised to the minimum, and one above the Maximum TTL is lowered to the maximum. The Default TTL is not part of this calculation at all, because it only applies when the origin sends no Cache-Control max-age directive.",{"question":1083,"type":1075,"options":1084,"correctAnswer":1086,"explanation":1089},"An operator sets a cache policy Minimum TTL of 300 seconds on a behavior serving personalized account pages. The origin returns Cache-Control: no-store on those responses. What happens?",[1085,1086,1087,1088],"CloudFront respects no-store and does not cache the responses","CloudFront caches the responses for 300 seconds, ignoring no-store","CloudFront returns an error because the directives conflict","CloudFront caches the responses but revalidates on every request","When the cache policy's Minimum TTL is greater than 0, CloudFront applies it even if the origin sends no-cache, no-store, or private, which is how personalized pages get served to the wrong viewer. Browsers still respect the directives, so the bug only shows up at the edge. If content must never be cached, use a policy whose minimum TTL is 0, such as the managed CachingDisabled policy.",{"question":1091,"type":1075,"options":1092,"correctAnswer":1095,"explanation":1097},"A team deploys a site update and submits an invalidation for /* to refresh everything. Their AWS account has already submitted 940 invalidation paths this month. How many paths are billable from this request?",[1093,1094,1095,1096],"Thousands, one per file that the wildcard matched","Zero, because wildcard invalidations are always free","One, and it falls inside the remaining free allowance","60, the difference between 1,000 and the paths already used","A path containing the * wildcard counts as one invalidation path no matter how many files it removes, and the first 1,000 paths per month are free across all distributions in an account. The billing unit is the path you submit, not the object count, which is why /* is cheap to submit and versioned file names are still the better habit for frequent updates.",{"question":1099,"type":1100,"options":1101,"correctAnswers":1106,"explanation":1107},"Which changes increase a CloudFront cache hit ratio? (Choose 2.)","multiple",[1102,1103,1104,1105],"Forwarding the User-Agent header so the origin can vary responses by device","Setting a custom origin header of Accept-Encoding with a blank value when compression is not in use","Configuring CloudFront to forward only the specific cookies the origin actually varies on","Adding all query string parameters to the cache key so every URL is cached separately",[1103,1104],"Every value in the cache key splits one object into many cache entries, so a higher hit ratio comes from removing values, not adding them. User-Agent has an enormous number of distinct values and is the classic mistake; the CloudFront-Is-Mobile-Viewer style device headers give you the same routing with four values instead of thousands.",{"question":1109,"type":1075,"options":1110,"correctAnswer":1113,"explanation":1115},"An application uses lazy loading only. A cache node fails and is replaced with an empty node. What does the application experience?",[1111,1112,1113,1114],"Errors, because the cache returns nulls the application cannot handle","Nothing, because ElastiCache repopulates the node from the database automatically","Correct results with higher latency, while misses refill the cache from the database","Stale results, because the empty node still serves the old values","Lazy loading treats a miss as normal control flow, so an empty node degrades performance rather than correctness: each miss costs three trips (cache read, database query, cache write) and refills the entry. That resilience is exactly what write-through lacks, because a write-through cache only holds keys that have been written since the node came up.",{"question":1117,"type":1075,"options":1118,"correctAnswer":1119,"explanation":1123},"A Valkey cluster (cluster mode disabled) runs on a node type with 2 vCPUs. CPUUtilization sits steadily at 46 percent and latency is climbing. What does this indicate?",[1119,1120,1121,1122],"The engine core is saturated, because the effective threshold is about 45 percent on a 2-core node","Normal operation, since 46 percent is well below a 90 percent threshold","A network bottleneck, because CPUUtilization cannot exceed 50 percent on any node","Memory pressure, which always presents as elevated CPU","Valkey and Redis OSS run the engine on a single thread, so a host-level CPUUtilization of 100 percent is unreachable and the alarm threshold is 90 divided by the core count: 45 percent on 2 cores. On larger node types with 4 or more vCPUs, EngineCPUUtilization reports the engine core directly and removes the arithmetic.",{"question":1125,"type":1075,"options":1126,"correctAnswer":1129,"explanation":1131},"A Memcached cluster is showing sustained Evictions and rising latency for a read-heavy workload. Which action fits the engine?",[1127,1128,1129,1130],"Add read replicas to the cluster to spread the read load","Enable automatic failover so the cluster stops evicting","Scale up to a larger node type or scale out by adding more nodes","Turn on cluster mode so the keyspace is resharded across shards","Memcached has no replication, no automatic failover, and no cluster mode, so its only two levers are a bigger node type or more nodes in the cluster. Read replicas and automatic failover are Valkey and Redis OSS features, and offering them for a Memcached cluster is a common distractor built on that engine boundary.",{"question":1133,"type":1075,"options":1134,"correctAnswer":1136,"explanation":1137},"True or False: with the write-through strategy alone, data in the cache can become stale because the cache is only updated on a read miss.",[1135,1136],"True","False","That description belongs to lazy loading, which is the strategy that allows stale data because nothing updates the cache when the database changes. Write-through updates the cache on every database write, so it is never stale; its own weaknesses are missing data on a fresh node and cache churn from writing values nobody reads.",{"title":21,"description":22},"courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/03-caching-and-database-scaling/01-caching-with-cloudfront-and-elasticache","qNoVyGltmW9XQOkTz7qup5pM3eGao_Of0RpuYKsWZjI",{"locked":5,"reason":6,"meta":1142,"item":3},{"title":1143,"description":1144,"isFree":10,"estimatedMinutes":1145,"difficulty":12,"learningObjectives":1146},"Scaling Containers and Serverless","What changes when the unit of capacity is a task, a pod, or a request: Application Auto Scaling for ECS services, the second scaling layer under EC2-backed clusters, EKS node scaling, and Lambda concurrency.",26,[1147,1148,1149,1150,1151],"Explain what Application Auto Scaling is and which resources it scales","Distinguish ECS service auto scaling from ECS cluster auto scaling and identify which one a symptom points to","Interpret the CapacityProviderReservation metric and the target capacity setting","Compare the EKS scaling layers: Horizontal Pod Autoscaler, Cluster Autoscaler, and Karpenter","Calculate Lambda concurrency and choose between reserved and provisioned concurrency"]