[{"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-caching-and-database-scaling-dynamodb-scaling-and-dax-en":4,"next-aws-certified-cloudops-engineer-associate-reliability-business-continuity-caching-and-database-scaling-dynamodb-scaling-and-dax-en":19,"lesson-aws-certified-cloudops-engineer-associate-reliability-business-continuity-caching-and-database-scaling-dynamodb-scaling-and-dax-en":661},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"Scaling RDS and Aurora","Read replicas, storage autoscaling, and RDS Proxy on Amazon RDS, and the shared cluster volume that changes the rules for Aurora: reader endpoints, Aurora Auto Scaling, and Serverless capacity.",false,28,"intermediate",[14,15,16,17,18],"Distinguish a Multi-AZ standby, an RDS read replica, and an Aurora Replica by replication method and by what each one is for","Diagnose replica lag and predict what stale reads do to an application that routes queries to a replica","State the exact conditions RDS storage autoscaling requires, and the one thing it can never do","Explain what RDS Proxy solves and where it cannot be attached","Configure Aurora Auto Scaling and Aurora Serverless capacity, and predict how each responds to a load change",{"locked":10,"reason":3,"meta":20,"item":30},{"title":21,"description":22,"isFree":5,"estimatedMinutes":23,"difficulty":12,"learningObjectives":24},"Multi-AZ and Fault-Tolerant Architectures","What an Availability Zone actually is, which AWS resources live inside one and which span the Region, and how to build a compute and data tier that keeps serving traffic when an entire AZ goes away.",24,[25,26,27,28,29],"Explain what an Availability Zone is physically and why AZs are placed at the distance they are","Classify AWS resources as zonal, regional, or global, and predict which ones an AZ failure takes with it","Calculate the spare capacity a compute tier needs to survive the loss of one Availability Zone","Compare Multi-AZ DB instance, Multi-AZ DB cluster, and Aurora deployments by replication method, readability, and failover behavior","Identify the failure classes that Multi-AZ does not protect against",{"id":31,"title":21,"body":32,"description":22,"difficulty":12,"estimatedMinutes":23,"extension":571,"infographics":572,"isFree":5,"learningObjectives":587,"meta":588,"navigation":5,"path":589,"quiz":590,"seo":658,"stem":659,"__hash__":660},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/04-backup-restore-and-disaster-recovery/01-multi-az-and-fault-tolerant-architectures.md",{"type":33,"value":34,"toc":560},"minimark",[35,39,44,47,50,67,70,89,93,100,103,108,170,173,176,200,204,207,210,213,223,226,233,283,286,293,296,310,314,317,423,429,437,442,446,449,481,485,492,526,533,537,557],[36,37,38],"p",{},"Everything in the previous topic assumed the infrastructure stays where you put it. Scaling a fleet, adding readers, warming a cache: none of it helps if the building the instances live in loses power. Skill 2.2 of the exam guide is about the assumption itself, and it starts with the smallest unit of failure AWS gives you a name for.",[40,41,43],"h2",{"id":42},"an-availability-zone-is-a-real-place","An Availability Zone is a real place",[36,45,46],{},"An Availability Zone is one or more discrete data centers inside a Region, with its own power infrastructure, cooling, networking, and physical connectivity. Not a logical partition, not a rack label. AWS operates over 100 of them worldwide.",[36,48,49],{},"Two numbers define how AZs behave, and both are design decisions rather than accidents:",[51,52,53,61],"ul",{},[54,55,56,60],"li",{},[57,58,59],"strong",{},"Up to about 100 km apart."," Far enough that a flood, fire, tornado, utility power failure, or fiber cut is unlikely to hit two of them at once. AZs do not share generators, cooling equipment, or power substations, and AWS staggers its own service deployments across AZs in a Region so that a bad rollout cannot land everywhere simultaneously.",[54,62,63,66],{},[57,64,65],{},"Single-digit millisecond latency between them."," Close enough that you can replicate a database write synchronously to another zone and still commit fast enough for an OLTP workload.",[36,68,69],{},"That pairing is the whole reason Multi-AZ works. If AZs were 5 km apart, a regional storm would take out several at once. If they were 1,000 km apart, synchronous replication would add tens of milliseconds to every commit and nobody would enable it. The distance is chosen to make cross-zone redundancy both meaningful and affordable.",[36,71,72,73,77,78,80,81,84,85,88],{},"An AZ name is also per-account. ",[74,75,76],"code",{},"us-east-1a"," in your account and ",[74,79,76],{}," in a colleague's account are usually different physical zones, because AWS randomizes the mapping to spread load. The stable identifier is the ",[57,82,83],{},"AZ ID"," (",[74,86,87],{},"use1-az1","), which is what you compare when you share subnets across accounts with AWS RAM.",[40,90,92],{"id":91},"zonal-regional-global-the-classification-that-decides-everything","Zonal, regional, global: the classification that decides everything",[36,94,95,96,99],{},"Here is the misconception that causes most surprise outages: ",[57,97,98],{},"\"AWS is highly available, so my workload is highly available.\""," AWS runs its services across AZs. That does not mean the specific resources you created live in more than one.",[36,101,102],{},"Every AWS resource sits in exactly one of three scopes, and the scope tells you what an AZ failure does to it.",[104,105],"infographic",{"alt":106,"slug":107},"A Region containing three Availability Zone columns of zonal resources with a regional band of services spanning them, one column struck out to show that everything inside a failed zone is lost while the regional layer routes around it.","az-failure-blast-radius",[109,110,111,127],"table",{},[112,113,114],"thead",{},[115,116,117,121,124],"tr",{},[118,119,120],"th",{},"Scope",[118,122,123],{},"What it means",[118,125,126],{},"Examples",[128,129,130,144,157],"tbody",{},[115,131,132,138,141],{},[133,134,135],"td",{},[57,136,137],{},"Zonal",[133,139,140],{},"Created in one AZ. Gone when that AZ is gone.",[133,142,143],{},"EC2 instance, EBS volume, subnet, NAT gateway, RDS DB instance, ElastiCache node, EFS One Zone, Redshift cluster",[115,145,146,151,154],{},[133,147,148],{},[57,149,150],{},"Regional",[133,152,153],{},"AWS replicates it across AZs for you.",[133,155,156],{},"S3, DynamoDB, ELB (the load balancer itself), Auto Scaling group, SQS, EFS Standard, EBS snapshots",[115,158,159,164,167],{},[133,160,161],{},[57,162,163],{},"Global",[133,165,166],{},"Outside any single Region.",[133,168,169],{},"IAM, Route 53, CloudFront, WAF web ACLs for CloudFront",[36,171,172],{},"Read that table as an operations checklist rather than trivia. Every zonal resource in your architecture is a question: what happens when its AZ disappears? A regional service has already answered that question for you. A zonal one has not.",[36,174,175],{},"Two entries deserve a closer look because they trap people:",[51,177,178,194],{},[54,179,180,183,184,186,187,190,191,193],{},[57,181,182],{},"An EBS volume is zonal, but its snapshot is regional."," You cannot attach a ",[74,185,76],{}," volume to an instance in ",[74,188,189],{},"us-east-1b",". You can create a new volume in ",[74,192,189],{}," from that volume's snapshot, because snapshot data is replicated across all AZs in the Region. That asymmetry is how you move block storage between zones, and it is a favorite exam detail.",[54,195,196,199],{},[57,197,198],{},"A load balancer is regional, but its nodes are zonal."," You enable an ALB or NLB in specific subnets, and AWS puts a load balancer node in each of those AZs. Enable it in one AZ and you have built a single-zone dependency with a regional-looking name. An ALB requires subnets in at least 2 AZs for exactly this reason.",[40,201,203],{"id":202},"making-the-compute-tier-survive-routing-is-not-capacity","Making the compute tier survive: routing is not capacity",[36,205,206],{},"Put an Auto Scaling group across three AZs behind an ALB and you have solved the routing problem. When a zone fails, the ALB stops sending requests to its unhealthy targets and the ASG marks those instances unhealthy and replaces them. That part is automatic.",[36,208,209],{},"What is not automatic is having somewhere for the traffic to go. Work the numbers.",[36,211,212],{},"You run 6 instances across 3 AZs, 2 per zone, and each instance can absorb 20 percent of peak traffic. At peak you are using 6 x 20 = 120 percent of what you need, which feels like comfortable headroom. Now AZ-B fails:",[214,215,220],"pre",{"className":216,"code":218,"language":219},[217],"language-text","Surviving instances: 4\nCapacity:            4 x 20% = 80% of peak\nShortfall:           20% of peak, until replacements launch and pass health checks\n","text",[74,221,218],{"__ignoreMap":222},"",[36,224,225],{},"For several minutes you are dropping or delaying one request in five. The load balancer did its job perfectly and the site is still degraded.",[36,227,228,229,232],{},"The general rule is ",[57,230,231],{},"size for the loss of one full AZ",", which people write as AZ+1:",[109,234,235,248],{},[112,236,237],{},[115,238,239,242,245],{},[118,240,241],{},"AZs in use",[118,243,244],{},"Fraction lost with one AZ",[118,246,247],{},"Spare capacity required",[128,249,250,261,272],{},[115,251,252,255,258],{},[133,253,254],{},"2",[133,256,257],{},"50 percent",[133,259,260],{},"100 percent overhead",[115,262,263,266,269],{},[133,264,265],{},"3",[133,267,268],{},"33 percent",[133,270,271],{},"50 percent overhead",[115,273,274,277,280],{},[133,275,276],{},"4",[133,278,279],{},"25 percent",[133,281,282],{},"33 percent overhead",[36,284,285],{},"This is the concrete reason AWS recommends three AZs rather than two. Two zones make AZ-redundancy cost you double; three make it cost you half again.",[36,287,288,289,292],{},"The deeper principle behind the table is ",[57,290,291],{},"static stability",": the system should keep working correctly without needing to make any changes when a failure happens. Launching replacement instances during an AZ event is a control plane operation, and control planes have lower availability design goals than data planes, precisely because they do more complex work. Worse, an AZ failure is exactly when every other customer in that Region is also asking for capacity. A design that must scale out to survive has made its recovery depend on the busiest moment of the control plane's life. A statically stable design has the capacity already running.",[36,294,295],{},"Two settings that decide how evenly the load lands:",[51,297,298,304],{},[54,299,300,303],{},[57,301,302],{},"Cross-zone load balancing"," lets a load balancer node in one AZ send traffic to targets in every AZ, rather than only its own. It is on by default for ALB (and can be turned off per target group) and off by default for NLB. With it off and uneven target counts per zone, an AZ with 2 targets gets the same share of traffic as an AZ with 8, and each of those 2 targets works four times harder.",[54,305,306,309],{},[57,307,308],{},"ELB health checks versus ASG health checks."," By default an Auto Scaling group only watches EC2 status checks, which say the instance is running, not that your application answers. Turn on ELB health checks on the ASG so that a target failing the load balancer's HTTP check gets replaced instead of sitting there returning errors.",[40,311,313],{"id":312},"the-data-tier-three-ways-to-survive-a-zone","The data tier: three ways to survive a zone",[36,315,316],{},"Compute is replaceable. Data is not, so the database layer gets its own answer, and RDS gives you three shapes with very different properties.",[109,318,319,334],{},[112,320,321],{},[115,322,323,325,328,331],{},[118,324],{},[118,326,327],{},"Multi-AZ DB instance",[118,329,330],{},"Multi-AZ DB cluster",[118,332,333],{},"Aurora",[128,335,336,350,362,376,395,409],{},[115,337,338,341,344,347],{},[133,339,340],{},"Instances",[133,342,343],{},"1 primary + 1 standby",[133,345,346],{},"1 writer + 2 readers",[133,348,349],{},"1 writer + up to 15 readers",[115,351,352,355,357,359],{},[133,353,354],{},"AZs",[133,356,254],{},[133,358,265],{},[133,360,361],{},"3 (storage always spans 3)",[115,363,364,367,370,373],{},[133,365,366],{},"Replication",[133,368,369],{},"Synchronous",[133,371,372],{},"Semisynchronous, needs acknowledgement from at least 1 reader",[133,374,375],{},"None between instances, one shared cluster volume",[115,377,378,381,386,392],{},[133,379,380],{},"Standby serves reads",[133,382,383],{},[57,384,385],{},"No",[133,387,388,391],{},[57,389,390],{},"Yes",", both readers do",[133,393,394],{},"Yes, all readers do",[115,396,397,400,403,406],{},[133,398,399],{},"Typical failover",[133,401,402],{},"60 to 120 seconds",[133,404,405],{},"Under 35 seconds",[133,407,408],{},"Usually under 30 seconds",[115,410,411,414,417,420],{},[133,412,413],{},"Backups taken from",[133,415,416],{},"The standby, so no I/O pause on the primary",[133,418,419],{},"The cluster",[133,421,422],{},"The cluster volume, continuously",[36,424,425,426,428],{},"The ",[57,427,327],{}," deployment is the classic one and the most commonly tested. RDS keeps a standby in a second AZ, replicates every commit to it synchronously, and on failure flips the DNS CNAME behind your endpoint to point at the promoted standby. Your application keeps the same connection string and just needs to reconnect. Two consequences follow from \"synchronous\":",[51,430,431,434],{},[54,432,433],{},"Write and commit latency go up compared to Single-AZ, because every commit waits for the second zone. This is the cost you are paying for the durability.",[54,435,436],{},"The standby is not a spare server you can use. It accepts no connections. If a scenario asks for read offloading, the answer is a read replica or a Multi-AZ DB cluster, never the standby.",[36,438,439,441],{},[57,440,333],{}," takes a different route: the cluster volume itself spans three AZs and holds six copies of your data, so instance-level replication does not exist. Losing an AZ removes some instances but not the storage, which is why an Aurora reader can be promoted so quickly.",[40,443,445],{"id":444},"the-single-az-dependencies-people-leave-in-place","The single-AZ dependencies people leave in place",[36,447,448],{},"Even a carefully built multi-AZ architecture usually has a few zonal chokepoints. These are the ones worth auditing:",[51,450,451,457,463,469,475],{},[54,452,453,456],{},[57,454,455],{},"NAT gateway."," Created in one subnet, so one AZ. Route every private subnet through a single NAT gateway and one zone's failure cuts outbound internet for the entire VPC. Deploy one per AZ and give each private subnet a route table pointing at the gateway in its own zone. This also removes cross-AZ data transfer charges, so the resilient design is often the cheaper one.",[54,458,459,462],{},[57,460,461],{},"EFS One Zone."," Cheaper storage class, and the name is the warning. EFS Standard replicates across AZs; One Zone does not.",[54,464,465,468],{},[57,466,467],{},"Instance store volumes."," Physically attached to the host. Not just zonal, but instance-lifetime. Stopping the instance loses the data.",[54,470,471,474],{},[57,472,473],{},"A Single-AZ RDS instance with a read replica in another AZ."," This looks like Multi-AZ on a diagram, but the replica is asynchronous and promotion is a manual, minutes-long operation. It is a recovery plan, not a failover mechanism.",[54,476,477,480],{},[57,478,479],{},"A load balancer enabled in one subnet."," Covered above, and easy to create by accident in a test environment that later becomes production.",[40,482,484],{"id":483},"what-multi-az-does-not-do","What Multi-AZ does not do",[36,486,487,488,491],{},"Multi-AZ protects against ",[57,489,490],{},"infrastructure failure inside one zone",". That is a specific and limited promise. It does nothing about:",[51,493,494,508,514,520],{},[54,495,496,499,500,503,504,507],{},[57,497,498],{},"Logical corruption."," A ",[74,501,502],{},"DELETE"," without a ",[74,505,506],{},"WHERE"," clause replicates synchronously to the standby in milliseconds. Both copies are now equally wrong. Recovery means point-in-time recovery or a snapshot.",[54,509,510,513],{},[57,511,512],{},"Accidental deletion."," Deleting the DB instance deletes its standby too.",[54,515,516,519],{},[57,517,518],{},"Region-wide events."," Every AZ in the table above lives in one Region. Surviving the loss of a Region is a different architecture, and the last lesson in this topic covers the four ways to build it.",[54,521,522,525],{},[57,523,524],{},"A bad deployment."," New code that returns HTTP 500 returns it identically in all three zones.",[36,527,528,529,532],{},"This is the cleanest way to hold the boundary in your head: ",[57,530,531],{},"Multi-AZ is high availability, and it protects against things breaking. Backups and cross-Region replication are disaster recovery, and they protect against things being wrong."," The exam separates them consistently, and so should your design.",[40,534,536],{"id":535},"exam-tips","Exam tips",[51,538,539,542,545,548,551,554],{},[54,540,541],{},"The phrases \"survive an Availability Zone failure\", \"high availability\", and \"automatic failover\" point at Multi-AZ. The phrases \"accidental deletion\", \"data corruption\", \"restore to a point in time\", and \"Region outage\" point at backups or a DR strategy, and Multi-AZ is the wrong answer even though it sounds protective.",[54,543,544],{},"Any answer that reads from a Multi-AZ DB instance standby is wrong. The option exists to be rejected. Read offloading is a read replica or a Multi-AZ DB cluster.",[54,546,547],{},"Numbers to hold: Multi-AZ DB instance failover 60 to 120 seconds, Multi-AZ DB cluster failover typically under 35 seconds, Aurora storage 6 copies across 3 AZs, ALB requires at least 2 AZs.",[54,549,550],{},"When a stem describes an outage that affected everything despite multiple AZs, look for a shared zonal dependency. A single NAT gateway is the classic one; a single-subnet load balancer is the other.",[54,552,553],{},"Cross-zone load balancing: on by default for ALB, off by default for NLB. Uneven target counts per AZ plus cross-zone off equals uneven load.",[54,555,556],{},"If a question asks how much capacity to run in each AZ, the intended answer is enough that the remaining zones can carry the full load without scaling out. That is static stability, and its justification is that Auto Scaling is a control plane operation.",[36,558,559],{},"The decision rule to carry forward: for every resource in your architecture, name its scope. Zonal resources need a sibling in another zone and something that routes around the failure; regional resources have already solved it. Everything in this lesson keeps a workload running through infrastructure failure, and none of it helps when the data itself is wrong. That is what the next lesson is for, and it starts with the mechanism underneath every AWS backup: the snapshot.",{"title":222,"searchDepth":561,"depth":561,"links":562},3,[563,565,566,567,568,569,570],{"id":42,"depth":564,"text":43},2,{"id":91,"depth":564,"text":92},{"id":202,"depth":564,"text":203},{"id":312,"depth":564,"text":313},{"id":444,"depth":564,"text":445},{"id":483,"depth":564,"text":484},{"id":535,"depth":564,"text":536},"md",[573],{"slug":107,"concept":574,"style":575,"aspectRatio":576,"labels":577},"One large Region rectangle containing three vertical Availability Zone columns. Each column holds the zonal resources that live inside it: a subnet, EC2 instances, an EBS volume, a NAT gateway, and an RDS instance. Above the columns, spanning the full Region width, sit the regional constructs: the Auto Scaling group, the load balancer, S3, and DynamoDB. The middle AZ column is drawn greyed out with a diagonal strike to show it has failed. Arrows from the spanning regional band redirect around the failed column to the two surviving ones. Emphasis is on the contrast between resources trapped inside the failed column and the band that routes around it. A footer strip states the takeaway.","diagram","16:9",[578,579,580,581,582,583,584,585,586],"AWS Region","Availability Zone A","Availability Zone B: failed","Availability Zone C","Zonal: subnet, EC2 instance, EBS volume, NAT gateway, RDS DB instance","Regional: Auto Scaling group, load balancer, S3, DynamoDB","Lost with the zone: every zonal resource inside it","Survives: the regional layer, which stops sending work to the failed zone","An AZ failure is not a partial outage of your resources. It is a total outage of the ones that live there.",[25,26,27,28,29],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/04-backup-restore-and-disaster-recovery/01-multi-az-and-fault-tolerant-architectures",{"passingScore":591,"questions":592},70,[593,602,612,620,626,634,642,650],{"question":594,"type":595,"options":596,"correctAnswer":597,"explanation":601},"An application runs 6 EC2 instances spread evenly across 3 Availability Zones behind an Application Load Balancer. Each instance can serve 20 percent of peak traffic. One Availability Zone becomes unavailable. What happens?","single",[597,598,599,600],"The ALB redistributes all traffic to the 4 remaining instances, which can serve only 80 percent of peak","The ALB stops accepting traffic until the failed Availability Zone recovers","The 4 remaining instances each automatically double their capacity","Traffic continues normally because 4 instances can serve 100 percent of peak","The load balancer routes around the failed zone correctly, but routing is not capacity. Four instances at 20 percent each cover 80 percent of peak, so the tier is overloaded until Auto Scaling launches replacements, which is exactly the delay a statically stable design pre-provisions away.",{"question":603,"type":604,"options":605,"correctAnswers":610,"explanation":611},"Which of the following are zonal resources, meaning they exist inside a single Availability Zone and are lost if that zone fails? (Choose 2.)","multiple",[606,607,608,609],"An Amazon S3 bucket","A NAT gateway","An EBS volume","An Amazon DynamoDB table",[607,608],"A NAT gateway is created in one specific subnet and therefore one AZ, which is why production designs put one in each AZ with a matching route table. An EBS volume can only attach to instances in its own AZ. S3 and DynamoDB are regional services that replicate across AZs for you.",{"question":613,"type":595,"options":614,"correctAnswer":617,"explanation":619},"A reporting team wants to reduce load on a production RDS for PostgreSQL database and proposes reading from the Multi-AZ standby. What is the problem?",[615,616,617,618],"The standby returns data delayed by replication lag","The standby only accepts connections during the backup window","A Multi-AZ DB instance standby cannot serve read traffic at all","The standby is in a different Region, so query latency is too high","In a Multi-AZ DB instance deployment the standby is invisible to your application until a failover promotes it, and AWS documents that you cannot use it to serve reads. The option about replication lag is tempting because it is true of a read replica, which is the actual answer when the goal is offloading reads.",{"question":621,"type":595,"options":622,"correctAnswer":623,"explanation":625},"True or False: Availability Zones in a Region are placed far enough apart to avoid correlated failures but close enough that synchronous replication between them stays within single-digit millisecond latency.",[623,624],"True","False","AWS separates AZs by up to roughly 100 km with independent power, cooling, and network paths, while keeping round-trip latency in single-digit milliseconds. That combination is what makes RDS Multi-AZ synchronous replication practical without an unacceptable commit penalty.",{"question":627,"type":595,"options":628,"correctAnswer":630,"explanation":633},"Which deployment gives you two standby DB instances that also serve read traffic and typically fails over in under 35 seconds?",[629,630,631,632],"A Multi-AZ DB instance deployment","A Multi-AZ DB cluster deployment","A Single-AZ instance with a cross-Region read replica","A Single-AZ instance with automated backups enabled","A Multi-AZ DB cluster runs a writer and two readers across three AZs using semisynchronous replication, where a commit needs acknowledgement from at least one reader. The Multi-AZ DB instance deployment has one unreadable standby and typically fails over in 60 to 120 seconds.",{"question":635,"type":595,"options":636,"correctAnswer":640,"explanation":641},"An Auto Scaling group is configured across 2 Availability Zones and sized so that its instances are exactly at target utilization at peak. What is the minimum spare capacity the group needs to remain statically stable through the loss of one AZ?",[637,638,639,640],"50 percent, so the surviving AZ runs at one and a half times its normal size","25 percent, spread evenly across both zones","No spare capacity, because Auto Scaling replaces the lost instances","100 percent, so the surviving AZ alone can carry the full peak load","With 2 AZs, losing one removes half the fleet, so each zone must be able to carry the entire peak on its own, which means running at double the strictly required capacity. Spreading over 3 AZs drops that overhead to 50 percent, which is the practical reason AWS recommends three zones over two.",{"question":643,"type":595,"options":644,"correctAnswer":647,"explanation":649},"Which failure does a Multi-AZ deployment NOT protect you against?",[645,646,647,648],"Loss of power to one Availability Zone","Failure of the primary DB instance hardware","An engineer running a DELETE without a WHERE clause","A network partition isolating one Availability Zone","Synchronous replication faithfully copies every committed statement, including destructive ones, so the standby holds the same damaged data microseconds later. Recovering from logical corruption needs point-in-time recovery or a snapshot, which is why availability and backup are separate controls rather than substitutes.",{"question":651,"type":595,"options":652,"correctAnswer":654,"explanation":657},"A VPC has private subnets in three Availability Zones and a single NAT gateway in the AZ-A public subnet, with all three private route tables pointing at it. The AZ-A NAT gateway becomes unavailable. What is the impact?",[653,654,655,656],"Only instances in AZ-A lose outbound internet access","Instances in all three AZs lose outbound internet access","Traffic automatically fails over to a NAT gateway AWS provisions in another AZ","Nothing, because NAT gateways are regional and replicate across AZs","A NAT gateway is zonal, and routing every private subnet through one instance of it makes a single AZ a dependency for the whole VPC. The fix is a NAT gateway per AZ with each private route table pointing at the gateway in its own zone, which also removes cross-AZ data transfer charges.",{"title":21,"description":22},"courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/04-backup-restore-and-disaster-recovery/01-multi-az-and-fault-tolerant-architectures","WlnSoSjoMOuId-vGoADB6Im5IcHJ-Ki8pNxezXoLLTk",{"locked":5,"reason":6,"meta":662,"item":3},{"title":663,"description":664,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":665},"DynamoDB Scaling and DAX","Capacity units and the arithmetic behind them, on-demand versus provisioned with auto scaling, why a table throttles while it still has headroom, and what DAX caches and what it quietly refuses to.",[666,667,668,669,670],"Calculate the read and write capacity a workload consumes, including consistency and item-size rounding","Choose between on-demand and provisioned capacity, and predict how each responds to a traffic spike","Configure DynamoDB auto scaling and explain why it does not stop short spikes from throttling","Diagnose a throttled table that still has unused provisioned capacity","Predict what DAX serves from cache, what it passes through, and when it returns data that is out of date"]