[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"lesson-cloud-computing-fundamentals-security-and-reliability-reliability-and-operations-backup-and-disaster-recovery-en":4,"prev-cloud-computing-fundamentals-security-and-reliability-reliability-and-operations-backup-and-disaster-recovery-en":341,"next-cloud-computing-fundamentals-security-and-reliability-reliability-and-operations-backup-and-disaster-recovery-en":616},null,{"locked":5,"reason":3,"meta":6,"item":16},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"Backup and Disaster Recovery","What Recovery Time Objective and Recovery Point Objective actually bound, and the 4 disaster recovery strategies cloud teams choose between when redundancy inside a region was not enough.",20,"intermediate",[12,13,14,15],"Define Recovery Time Objective and Recovery Point Objective and explain what each one bounds","Explain how AWS Backup automates data protection through backup plans, schedules, and retention rules","Compare backup and restore, pilot light, warm standby, and multi-site active/active by cost, complexity, and recovery speed","Apply a scenario's RTO and RPO requirements to choose the appropriate disaster recovery strategy",{"id":17,"title":7,"body":18,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":264,"infographics":265,"isFree":5,"learningObjectives":266,"meta":267,"navigation":268,"path":269,"quiz":270,"seo":338,"stem":339,"__hash__":340},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/03-backup-and-disaster-recovery.md",{"type":19,"value":20,"toc":249},"minimark",[21,26,30,34,37,44,50,53,57,60,64,67,149,152,156,159,163,166,170,173,177,180,184,242,246],[22,23,25],"h2",{"id":24},"when-redundancy-inside-a-region-was-not-enough","When redundancy inside a region was not enough",[27,28,29],"p",{},"The last 2 lessons covered redundancy inside a single AWS Region: spreading instances and databases across Availability Zones so that 1 data center's failure doesn't take the whole system down. That protects against a hardware failure or a power outage. It does nothing if a bad deployment corrupts a database table, or if an entire geographic region goes dark, the exact gap the regions-and-Availability-Zones lesson flagged earlier in this course. This lesson is about the plan for exactly that: when the failure is bigger than AZ-level redundancy was ever built to absorb.",[22,31,33],{"id":32},"two-questions-before-any-recovery-plan-how-much-data-how-long-down","Two questions before any recovery plan: how much data, how long down",[27,35,36],{},"Every disaster recovery plan starts by answering 2 separate questions, and mixing them up is the most common mistake teams make.",[27,38,39,43],{},[40,41,42],"strong",{},"Recovery Point Objective (RPO)"," bounds acceptable data loss. It answers \"how much data can we afford to lose,\" measured as the maximum acceptable time between now and the last point you could recover from. An RPO of 15 minutes means your backups or replication have to run at least that often, or you risk losing more than the business can tolerate.",[27,45,46,49],{},[40,47,48],{},"Recovery Time Objective (RTO)"," bounds acceptable downtime. It answers \"how long can we be down,\" measured as the maximum acceptable delay between an outage starting and service being restored. An RTO of 1 hour means the entire recovery process, detecting the failure, standing up infrastructure, restoring data, has to finish inside that hour.",[27,51,52],{},"An e-commerce order database with a 15-minute RPO and a 1-hour RTO is promising 2 very different things: at most 15 minutes of lost orders, and at most 1 hour before the store is taking orders again. Meeting both takes deliberate engineering, and meeting them more tightly always costs more.",[22,54,56],{"id":55},"backups-the-foundation-under-every-strategy","Backups: the foundation under every strategy",[27,58,59],{},"No disaster recovery strategy works without reliable backups underneath it. AWS Backup centralizes that work across services, EC2, RDS, DynamoDB, EFS, and more, through backup plans: policies that define schedules and retention. A typical plan might pair a daily rule, backing up every night and keeping each backup for 1 month, with a monthly rule, backing up once a month and keeping that copy for a full year. Resources get assigned to a plan simply by tagging them, and backups can copy automatically to a different AWS Region on the same schedule, which is what turns a routine backup into the raw material a disaster recovery strategy can actually use.",[22,61,63],{"id":62},"the-4-disaster-recovery-strategies-cheapest-to-most-expensive","The 4 disaster recovery strategies, cheapest to most expensive",[27,65,66],{},"With backups as the foundation, the question becomes how much infrastructure you keep running in a secondary location, and readiness costs money whether or not disaster ever strikes.",[68,69,70,89],"table",{},[71,72,73],"thead",{},[74,75,76,80,83,86],"tr",{},[77,78,79],"th",{},"Strategy",[77,81,82],{},"What runs in the secondary Region before a disaster",[77,84,85],{},"Relative cost",[77,87,88],{},"Relative RTO/RPO",[90,91,92,107,121,135],"tbody",{},[74,93,94,98,101,104],{},[95,96,97],"td",{},"Backup and restore",[95,99,100],{},"Nothing; only backups exist there",[95,102,103],{},"Lowest",[95,105,106],{},"Slowest, highest data loss risk",[74,108,109,112,115,118],{},[95,110,111],{},"Pilot light",[95,113,114],{},"Core data replicating live; compute stays off until failover",[95,116,117],{},"Low",[95,119,120],{},"Faster, but infrastructure still has to be switched on and scaled",[74,122,123,126,129,132],{},[95,124,125],{},"Warm standby",[95,127,128],{},"A scaled-down but fully running copy of the whole stack",[95,130,131],{},"Moderate",[95,133,134],{},"Faster still; only needs to scale up, not deploy from scratch",[74,136,137,140,143,146],{},[95,138,139],{},"Multi-site active/active",[95,141,142],{},"The full stack, already serving live production traffic",[95,144,145],{},"Highest",[95,147,148],{},"Fastest; failover is rerouting traffic, not building anything",[27,150,151],{},"Backup and restore rebuilds everything, data and infrastructure, from scratch after a disaster is declared, usually through Infrastructure as Code, which is why it takes the longest but costs the least day to day. Pilot light keeps the data layer continuously replicated but leaves the rest of the stack dark, needing to be switched on and scaled before it can serve traffic. Warm standby goes further, keeping a smaller version of the entire application already running, so recovery means scaling an existing deployment up rather than deploying one for the first time. Multi-site active/active removes the switching step entirely: more than 1 Region is already handling production traffic, so a Region-level failure just means rerouting requests away from the Region that can't serve them.",[22,153,155],{"id":154},"worked-example-matching-the-strategy-to-the-requirement","Worked example: matching the strategy to the requirement",[27,157,158],{},"An internal reporting dashboard can tolerate several hours of downtime and losing up to a day of data without hurting the business in any measurable way; backup and restore is not just acceptable here, it's the correct engineering choice, since paying for a warmer strategy would be spending money the requirement never asked for. A payment-authorization service is the opposite case: a minute of downtime or any lost transaction is unacceptable, which justifies the cost and complexity of multi-site active/active. Neither team is wrong. Each has matched the strategy to the RTO and RPO the business actually needs, which is the entire point of having 4 strategies instead of reaching for the most expensive one by default.",[22,160,162],{"id":161},"boundary-backup-and-restore-versus-pilot-light","Boundary: backup and restore versus pilot light",[27,164,165],{},"These 2 are the pair most often confused, because both keep your data safe in a second Region and both look, from the outside, like \"we have backups somewhere else.\" The difference is what happens to compute. Backup and restore has no infrastructure standing by at all; everything gets provisioned from Infrastructure as Code only after a disaster is declared. Pilot light keeps a minimal core, often just the data tier, continuously live and replicating, while the rest of the stack (application servers, for instance) stays completely dark until failover triggers it. That single difference, whether anything besides data is already there waiting, is what separates the cheapest strategy from the next one up.",[22,167,169],{"id":168},"active-active-reappears-at-a-larger-radius","Active-active reappears, at a larger radius",[27,171,172],{},"Multi-site active/active is not a new idea introduced for disaster recovery specifically. It's the active-active redundancy pattern from the previous lesson, where every replica serves traffic simultaneously, stretched from the scale of Availability Zones inside 1 Region to the scale of entire Regions. The mechanism is the same; only the geography and the stakes are bigger.",[22,174,176],{"id":175},"misconception-backups-alone-are-not-a-disaster-recovery-plan","Misconception: backups alone are not a disaster recovery plan",[27,178,179],{},"It's tempting to treat \"we have automated nightly backups in a second Region\" as the same thing as \"we have a disaster recovery plan.\" It isn't. A backup that has never been restored from is a hypothesis about how recovery would go, not evidence that it will. A real plan has a documented, rehearsed restore procedure and a known RTO that leadership has actually signed off on as acceptable. Backups are necessary for every one of the 4 strategies above; they are sufficient for none of them on their own.",[22,181,183],{"id":182},"exam-cues-matching-a-scenario-to-a-strategy","Exam cues: matching a scenario to a strategy",[68,185,186,196],{},[71,187,188],{},[74,189,190,193],{},[77,191,192],{},"The scenario says...",[77,194,195],{},"Points to",[90,197,198,205,212,219,226,234],{},[74,199,200,203],{},[95,201,202],{},"\"Cost-sensitive,\" \"can tolerate hours or days of downtime\"",[95,204,97],{},[74,206,207,210],{},[95,208,209],{},"\"Core data must stay current, but full infrastructure cost is a concern\"",[95,211,111],{},[74,213,214,217],{},[95,215,216],{},"\"Needs faster recovery than pilot light, already-running but scaled-down\"",[95,218,125],{},[74,220,221,224],{},[95,222,223],{},"\"Cannot tolerate any noticeable downtime, cost is secondary\"",[95,225,139],{},[74,227,228,231],{},[95,229,230],{},"\"Maximum acceptable data loss\"",[95,232,233],{},"RPO",[74,235,236,239],{},[95,237,238],{},"\"Maximum acceptable downtime\"",[95,240,241],{},"RTO",[22,243,245],{"id":244},"where-this-leaves-you","Where this leaves you",[27,247,248],{},"Choosing a disaster recovery strategy is choosing a point on a dial between steady-state cost and recovery speed, not searching for a single best answer; the right point is wherever the business's actual RTO and RPO land, no more expensive than that. Backups make every strategy possible, but only a tested restore procedure turns them into an actual plan. The next lesson closes out this topic by asking a different question: how do you actually find out a failure happened at all, and what does a cloud provider's SLA really promise when it does?",{"title":250,"searchDepth":251,"depth":251,"links":252},"",3,[253,255,256,257,258,259,260,261,262,263],{"id":24,"depth":254,"text":25},2,{"id":32,"depth":254,"text":33},{"id":55,"depth":254,"text":56},{"id":62,"depth":254,"text":63},{"id":154,"depth":254,"text":155},{"id":161,"depth":254,"text":162},{"id":168,"depth":254,"text":169},{"id":175,"depth":254,"text":176},{"id":182,"depth":254,"text":183},{"id":244,"depth":254,"text":245},"md",[],[12,13,14,15],{},true,"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/03-backup-and-disaster-recovery",{"passingScore":271,"questions":272},70,[273,282,290,298,308,316,322,330],{"question":274,"type":275,"options":276,"correctAnswer":278,"explanation":281},"A company's Recovery Point Objective for its order database is 15 minutes. What does this actually specify?","single",[277,278,279,280],"The system must be back online within 15 minutes of an outage","The company can afford to lose at most 15 minutes of data since the last recoverable backup or replica","Backups must be tested every 15 minutes","The database must respond to queries within 15 minutes","RPO bounds acceptable data loss, measured backward in time from the moment of failure to the last point you could recover from. A 15-minute RPO means backups or replication have to happen at least every 15 minutes; anything less frequent would risk losing more data than the objective allows. It says nothing about how fast the system comes back online, which is what RTO measures instead.",{"question":283,"type":275,"options":284,"correctAnswer":286,"explanation":289},"Which of the following correctly matches a disaster recovery strategy to its defining characteristic?",[285,286,287,288],"Pilot light: multiple regions actively serve production traffic at the same time","Backup and restore: infrastructure is rebuilt from backups and Infrastructure as Code only after a disaster is declared","Warm standby: no infrastructure exists in the secondary region until failover begins","Multi-site active/active: a minimal, idle copy of core infrastructure sits ready in a secondary region","Backup and restore is the cheapest and slowest strategy precisely because nothing runs in the secondary region until a disaster actually happens; everything, data and infrastructure alike, gets rebuilt on demand. Pilot light keeps core data live with idle infrastructure ready to switch on; warm standby keeps a scaled-down version already running; multi-site active/active keeps multiple regions actively serving traffic simultaneously.",{"question":291,"type":275,"options":292,"correctAnswer":294,"explanation":297},"Rank the 4 disaster recovery strategies from lowest cost and slowest recovery to highest cost and fastest recovery.",[293,294,295,296],"Multi-site active/active, warm standby, pilot light, backup and restore","Backup and restore, pilot light, warm standby, multi-site active/active","Pilot light, backup and restore, multi-site active/active, warm standby","Warm standby, backup and restore, multi-site active/active, pilot light","The 4 strategies form a spectrum: backup and restore is cheapest and slowest because nothing runs until disaster strikes, and each strategy after it keeps progressively more infrastructure already running in the secondary region, trading higher steady-state cost for progressively lower RTO and RPO, until multi-site active/active reaches the fastest recovery by already serving live traffic from more than 1 region.",{"question":299,"type":300,"options":301,"correctAnswers":306,"explanation":307},"Which of the following are true about AWS Backup? (Select all that apply.)","multiple",[302,303,304,305],"A backup plan can define multiple rules, such as a daily rule with a 1-month retention and a monthly rule with a 1-year retention","It only supports Amazon EC2 instances, not managed services like RDS or DynamoDB","Resources are commonly assigned to a backup plan by tagging them","It can copy backups to a different AWS Region as part of a scheduled plan",[302,304,305],"AWS Backup centralizes backup policy across many AWS services, including RDS, DynamoDB, EFS, and Storage Gateway alongside EC2, so limiting it to EC2 alone is incorrect. Tag-based assignment, multi-rule plans with independent retention periods, and cross-Region copy are all real features, and cross-Region copy specifically is what makes AWS Backup useful as the data layer underneath a disaster recovery strategy, not just routine data protection.",{"question":309,"type":275,"options":310,"correctAnswer":312,"explanation":315},"A company has automated backups running every night and stores them safely in a second AWS Region. Its leadership considers this a complete disaster recovery plan. What is missing from that conclusion?",[311,312,313,314],"Nothing; backups alone are sufficient for any disaster recovery plan","A tested, documented restore procedure with a known RTO, not just the existence of backups","The backups need to be stored in the same Region to count as a disaster recovery plan","Disaster recovery plans cannot use automated backups at all","Backups are the foundation every disaster recovery strategy sits on, but a backup nobody has ever restored from is a hypothesis, not a plan. A real plan has a tested restore procedure, a documented and rehearsed set of steps, and a known RTO that leadership has actually agreed is acceptable, not just confidence that data exists somewhere safe.",{"question":317,"type":275,"options":318,"correctAnswer":319,"explanation":321},"Multi-site active/active disaster recovery is the same concept as active-active redundancy across Availability Zones from the previous lesson, applied at a larger scale.",[319,320],"True","False","The active-active pattern doesn't change between the 2 lessons, only its radius does. Within a Region, active-active means multiple Availability Zones simultaneously serve traffic. Multi-site active/active stretches the same idea across multiple Regions, so that even losing an entire Region leaves other Regions already serving requests, with failover reduced to rerouting traffic rather than starting anything from scratch.",{"question":323,"type":275,"options":324,"correctAnswer":326,"explanation":329},"An internal reporting dashboard can tolerate several hours of downtime and the loss of up to a day's data without meaningfully hurting the business. A payment-authorization service cannot tolerate more than a minute of downtime or any data loss at all. Which strategy pairing best fits each system?",[325,326,327,328],"Both systems should use multi-site active/active, since it is always the safest choice","The dashboard fits backup and restore; the payment service fits multi-site active/active","The dashboard fits multi-site active/active; the payment service fits backup and restore","Both systems should use pilot light, since it is a balanced middle option","Matching the strategy to the actual RTO and RPO the business needs, not defaulting to the most expensive option everywhere, is the point of having 4 strategies instead of 1. The dashboard's generous tolerances make the cheapest strategy the right engineering choice; the payment service's near-zero tolerance justifies the cost and complexity of running live in more than 1 Region at once.",{"question":331,"type":275,"options":332,"correctAnswer":334,"explanation":337},"Why is a low RTO and RPO more expensive to achieve than a higher one?",[333,334,335,336],"Cloud providers charge a fixed penalty fee for choosing a low RTO","Achieving a low RTO and RPO generally requires running more infrastructure continuously, in more than 1 location, rather than building it only after a disaster occurs","Low RTO and RPO values are only a marketing distinction with no real infrastructure difference","It is not more expensive; all 4 strategies cost the same to operate","Every step from backup and restore toward multi-site active/active trades a lower steady-state cost for a slower recovery, or a higher steady-state cost for a faster one. There is no way to get instant, lossless recovery without something already running and ready to take over, and that something bills you whether or not a disaster ever happens.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/03-backup-and-disaster-recovery","AsZCE0m54MMgw_6Y7GFMwlnG2NgZ1_KgsnK7mzsHq3Y",{"locked":5,"reason":3,"meta":342,"item":351},{"title":343,"description":344,"isFree":5,"estimatedMinutes":345,"difficulty":10,"learningObjectives":346},"Scalability and Elasticity","Why a system that can grow and a system that grows and shrinks itself automatically are 2 different skills, and how an Auto Scaling group's capacity settings and scaling policies deliver the second one.",18,[347,348,349,350],"Distinguish scalability from elasticity and explain why they answer different questions","Explain how an Auto Scaling group's minimum, desired, and maximum capacity settings work together","Compare target tracking, step, and scheduled scaling policies and identify which fits a given demand pattern","Apply elasticity to a worked example that shows the cost impact of matching capacity to real-time demand",{"id":352,"title":343,"body":353,"description":344,"difficulty":10,"estimatedMinutes":345,"extension":264,"infographics":544,"isFree":5,"learningObjectives":555,"meta":556,"navigation":268,"path":557,"quiz":558,"seo":613,"stem":614,"__hash__":615},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/02-scalability-and-elasticity.md",{"type":19,"value":354,"toc":532},[355,359,362,366,369,373,376,380,383,386,390,393,396,401,405,455,458,462,465,469,472,476,527,529],[22,356,358],{"id":357},"the-2-ways-a-plan-for-more-traffic-can-go-wrong","The 2 ways a plan for more traffic can go wrong",[27,360,361],{},"A retailer sizes its checkout servers for an average shopping day and gets crushed the first time a flash sale doubles traffic overnight; requests queue, pages time out, and the sale becomes the outage story instead of the revenue story. A different team overcorrects: it provisions enough servers to survive its single biggest sale day of the year, then pays for that same fleet the other 364 days, most of them running at a fraction of their capacity. Neither team has solved the actual problem, which has 2 separate parts: can the system grow at all, and does it grow (and shrink) itself to match what is actually happening right now.",[22,363,365],{"id":364},"recall-growth-you-already-know-how-to-do","Recall: growth you already know how to do",[27,367,368],{},"The compute lesson earlier in this course covered horizontal scaling, adding more instances of the same size behind a load balancer, as one answer to running out of capacity. What it did not cover is who decides when to add those instances, or when to take them away again once the load passes. That gap, the decision-making layer sitting on top of horizontal scaling, is exactly what this lesson fills in.",[22,370,372],{"id":371},"scalability-the-capacity-to-grow","Scalability: the capacity to grow",[27,374,375],{},"Scalability is a system's ability to handle more load by adding resources, whether that means resizing 1 machine (vertical scaling) or adding more machines of the same size (horizontal scaling). Nothing in that definition says the growth has to be automatic. A team that notices rising traffic and manually launches 3 more instances has scaled the system. So has an on-premises IT department that orders and racks 2 new physical servers over the course of a month. Both improved the system's capacity to handle load; neither one did it by itself, in real time, or gave any capacity back once it stopped being needed.",[22,377,379],{"id":378},"elasticity-matching-capacity-to-demand-automatically","Elasticity: matching capacity to demand, automatically",[27,381,382],{},"Elasticity is what happens when that decision-making gets automated in both directions: capacity increases as demand rises and decreases as demand falls, without a person watching a dashboard and clicking a button each time. It is a genuinely cloud-native idea. A physical server you already own and paid for doesn't shrink your bill when it sits idle overnight; a cloud instance that gets terminated during a quiet period stops costing you anything the moment it's gone. Elasticity is the reason \"pay only for what you use\" is more than a slogan: it requires the system to actually notice when \"what you use\" has changed and to act on that, continuously, without waiting for a human.",[27,384,385],{},"Picture a highway that engineers can widen with a construction crew over several months versus a highway with a reversible lane that opens automatically when sensors detect rush-hour traffic and closes again once it clears. Widening the highway is scalability: real capacity, real effort, and no reason to ever undo it. The reversible lane is elasticity: the same road, resized instantly and automatically to the traffic actually on it right now, and closed back up the moment it isn't needed. Push the comparison further and it breaks, a reversible lane is a fixed piece of infrastructure that gets toggled, not created and destroyed, while a cloud instance is provisioned and torn down entirely each time, which is exactly what makes it cost nothing while it's gone.",[22,387,389],{"id":388},"worked-example-1-day-inside-an-auto-scaling-group","Worked example: 1 day inside an Auto Scaling group",[27,391,392],{},"An Auto Scaling group is the AWS mechanism that automates this. Say a group is configured with a minimum of 4 instances, a desired capacity of 6, and a maximum of 12. Minimum and maximum are hard boundaries the group will never cross in either direction; desired capacity is the starting point a scaling policy adjusts from within that range.",[27,394,395],{},"At 9am, traffic climbs and average CPU utilization across the group rises past its target. A target-tracking policy launches new instances, 1 or 2 at a time, until CPU utilization settles back near target, capacity landing around 10 instances by mid-morning. Traffic holds through the day and eases off by 6pm; the same policy now terminates instances as CPU utilization drops below target, easing capacity back down toward 6, and further toward the 4-instance minimum overnight. The group never touches its 12-instance ceiling that day, and it never runs below 4. The team pays for roughly 10 instances during the 9 busy hours that needed them and far fewer overnight, instead of running 12 (or even a flat 10) for all 24.",[397,398],"infographic",{"alt":399,"slug":400},"A chart showing customer traffic rising and falling over a 24-hour day as a smooth curve, with an Auto Scaling group's stepped capacity line tracking it automatically between a minimum and a maximum boundary.","scalability-and-elasticity-capacity-vs-demand",[22,402,404],{"id":403},"scaling-policies-3-ways-to-tell-the-group-when-to-act","Scaling policies: 3 ways to tell the group when to act",[68,406,407,420],{},[71,408,409],{},[74,410,411,414,417],{},[77,412,413],{},"Policy",[77,415,416],{},"How it decides",[77,418,419],{},"Best fit",[90,421,422,433,444],{},[74,423,424,427,430],{},[95,425,426],{},"Target tracking",[95,428,429],{},"Continuously adjusts capacity to hold a chosen metric, like average CPU utilization, near a target value",[95,431,432],{},"Live, somewhat unpredictable demand",[74,434,435,438,441],{},[95,436,437],{},"Step scaling",[95,439,440],{},"Adds or removes capacity in defined steps sized to how far a metric has moved past its threshold",[95,442,443],{},"Demand that can spike sharply and needs a proportionally larger response",[74,445,446,449,452],{},[95,447,448],{},"Scheduled scaling",[95,450,451],{},"Sets capacity ahead of a known time, independent of any live metric",[95,453,454],{},"Predictable patterns, like a retailer's daily 9am traffic or a monthly batch job",[27,456,457],{},"These are not mutually exclusive. A retail team might run scheduled scaling to pre-warm capacity just before its known 9am spike, then let target tracking handle the rest of the day's smaller fluctuations on top of that head start.",[22,459,461],{"id":460},"elasticity-also-means-self-healing","Elasticity also means self-healing",[27,463,464],{},"Auto Scaling groups do more than resize for demand. They continuously health-check every instance and replace any that fail, automatically, to keep the group at its desired capacity even when nothing about traffic has changed. That connects directly back to the previous lesson: an Auto Scaling group spread across multiple Availability Zones is part of how a highly available architecture gets built in the first place, not a separate concern from it.",[22,466,468],{"id":467},"misconception-auto-scaling-is-not-just-about-scaling-up","Misconception: \"Auto Scaling\" is not just about scaling up",[27,470,471],{},"It's tempting to hear \"Auto Scaling\" and picture only the exciting half: automatically adding capacity to survive a traffic spike. The half that actually saves money is scaling in, removing capacity once demand drops. A group with no minimum worth respecting or no scale-in policy attached just becomes an expensive, self-launching version of plain scalability: it grows on its own, but it never gives anything back, and the cost advantage elasticity is supposed to deliver never shows up on the bill.",[22,473,475],{"id":474},"exam-cues-reading-a-scalability-versus-elasticity-question","Exam cues: reading a scalability-versus-elasticity question",[68,477,478,486],{},[71,479,480],{},[74,481,482,484],{},[77,483,192],{},[77,485,195],{},[90,487,488,496,504,512,519],{},[74,489,490,493],{},[95,491,492],{},"\"Handle a growing amount of load by adding resources\"",[95,494,495],{},"Scalability",[74,497,498,501],{},[95,499,500],{},"\"Automatically adjusts to real-time demand,\" \"pay only for what you use,\" \"scales in when idle\"",[95,502,503],{},"Elasticity",[74,505,506,509],{},[95,507,508],{},"\"Minimum,\" \"desired,\" \"maximum capacity\"",[95,510,511],{},"Auto Scaling group settings",[74,513,514,517],{},[95,515,516],{},"\"Known, predictable spike at a specific time\"",[95,518,448],{},[74,520,521,524],{},[95,522,523],{},"\"Maintain a target CPU utilization\"",[95,525,526],{},"Target tracking scaling",[22,528,245],{"id":244},[27,530,531],{},"Scalability answers whether a system can grow at all; elasticity answers whether it grows, and shrinks, itself, automatically, in step with demand that changes minute to minute. Every cloud workload needs the first. Only workloads with genuinely variable demand get real value from the second, which is most of them, since traffic that never varies is rare outside a handful of steady internal systems. The next lesson assumes all of this, redundancy, health checks, right-sized capacity, and asks what happens anyway: when a failure is bigger than any of it can absorb, and a team has to fall back on backups and a disaster recovery plan.",{"title":250,"searchDepth":251,"depth":251,"links":533},[534,535,536,537,538,539,540,541,542,543],{"id":357,"depth":254,"text":358},{"id":364,"depth":254,"text":365},{"id":371,"depth":254,"text":372},{"id":378,"depth":254,"text":379},{"id":388,"depth":254,"text":389},{"id":403,"depth":254,"text":404},{"id":460,"depth":254,"text":461},{"id":467,"depth":254,"text":468},{"id":474,"depth":254,"text":475},{"id":244,"depth":254,"text":245},[545],{"slug":400,"concept":546,"style":547,"aspectRatio":548,"labels":549},"A single quantitative chart over a 24-hour horizontal axis. A smooth curved line shows customer traffic rising through the morning, peaking at midday, and falling overnight. A stepped line overlays it, showing Auto Scaling group capacity rising and falling in blocks to track the traffic curve, bounded above and below by dashed horizontal lines marking maximum and minimum capacity. A footer strip carries the cost takeaway.","diagram","16:9",[550,551,552,553,554],"Traffic: rises in the morning, peaks midday, falls overnight","Auto Scaling group capacity: steps up and down to track traffic","Maximum capacity: 12 instances","Minimum capacity: 4 instances","Elasticity means paying for the stepped line, not a flat line held at the maximum all day.",[347,348,349,350],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/02-scalability-and-elasticity",{"passingScore":271,"questions":559},[560,568,576,584,593,601,605],{"question":561,"type":275,"options":562,"correctAnswer":564,"explanation":567},"A team manually doubles the size of its database server after a product launch permanently increases traffic. What is this an example of?",[563,564,565,566],"Elasticity, since capacity changed to meet demand","Scalability, since the system's capacity to handle load grew","Fault tolerance, since the change prevents future outages","A single point of failure being removed","Scalability is the ability to grow, whether by resizing 1 machine or adding more of them, and whether that growth is manual, scripted, or automatic. This example is scalability because the capacity grew; it is not elasticity because nothing here happened automatically in response to a live demand signal, and the change was not reversed once it was no longer needed.",{"question":569,"type":275,"options":570,"correctAnswer":572,"explanation":575},"Which of the following best distinguishes elasticity from scalability?",[571,572,573,574],"Elasticity only applies to compute, while scalability applies to storage and databases as well","Scalability is the system's capacity to grow at all; elasticity is that growth (and shrinkage) happening automatically in response to real-time demand","Scalability requires downtime, while elasticity never does","They are the same concept, described with 2 different marketing terms","A system can be scalable without being elastic, for example an on-premises data center that can add more physical servers, slowly and manually, but can never give any of them back once demand drops. Elasticity specifically adds automation in both directions, scaling out and scaling back in, which is why it is a cloud-era concept more than an on-premises one.",{"question":577,"type":275,"options":578,"correctAnswer":581,"explanation":583},"An Auto Scaling group is configured with a minimum of 4, a desired capacity of 6, and a maximum of 12. What does the maximum of 12 guarantee?",[579,580,581,582],"The group will always run exactly 12 instances","The group will never run fewer than 12 instances","The group will never scale beyond 12 instances, no matter how high demand climbs","The group will terminate all instances once traffic exceeds 12 requests per second","Maximum capacity is a ceiling, not a target: the group can run anywhere from its minimum up to its maximum, and scaling policies decide the actual count moment to moment within that range. Desired capacity, 6 in this example, is the starting point a scaling policy adjusts from, not a fixed value the group is locked to.",{"question":585,"type":300,"options":586,"correctAnswers":591,"explanation":592},"Which of the following are true about Amazon EC2 Auto Scaling? (Select all that apply.)",[587,588,589,590],"It automatically replaces instances that fail their health checks to maintain the desired capacity","It balances instances across the Availability Zones configured for the group","It can only scale a group up; scaling back in requires manual intervention","Target tracking scaling adjusts capacity to hold a chosen metric, such as average CPU utilization, near a target value",[587,588,590],"Auto Scaling groups scale in both directions automatically once a policy is attached; a scale-out-only group would keep adding instances forever and never realize the cost savings elasticity is meant to deliver. Health-check-based replacement and AZ balancing are both automatic parts of what makes an Auto Scaling group reliable, not just elastic.",{"question":594,"type":275,"options":595,"correctAnswer":597,"explanation":600},"A scheduled scaling policy is best suited for which situation?",[596,597,598,599],"Traffic spikes that are unpredictable and happen at random times","A demand pattern that is known in advance, such as a retailer's traffic spiking every day at 9am","Keeping a single metric, like CPU utilization, at a constant target at all times","Replacing an unhealthy instance immediately after it fails a health check","Scheduled scaling sets capacity ahead of a known pattern, so instances are already warmed up before the predictable spike hits, instead of reacting after the fact. Target tracking is the better fit for unpredictable, live demand, since it continuously adjusts to hold a metric near its target regardless of when the change happens.",{"question":602,"type":275,"options":603,"correctAnswer":320,"explanation":604},"A well-configured Auto Scaling group only ever adds capacity in response to rising demand; it never removes it once traffic drops.",[319,320],"Scaling in, removing instances as demand falls, is where elasticity actually pays for itself. A group with no minimum-respecting scale-in behavior is not elastic, it is just an expensive, manually-triggered version of scalability that happens to launch itself but never shrinks back down.",{"question":606,"type":275,"options":607,"correctAnswer":609,"explanation":612},"A team sizes its Auto Scaling group's maximum capacity for its historical worst-case traffic day, but sets a low minimum and a target-tracking policy for everyday demand. What is the main cost benefit of this setup compared to running the maximum capacity permanently?",[608,609,610,611],"None; AWS charges the same regardless of how many instances are actually running","The team pays only for the capacity it actually needs at each moment, instead of paying for peak capacity around the clock","It removes the need for a load balancer entirely","It guarantees the system becomes fault-tolerant","This is the entire economic case for elasticity: instances cost money by the hour they run, so a group that tracks real demand and scales back in during quiet periods avoids paying for idle peak-day capacity 24 hours a day. A fixed fleet sized for the worst case would handle the same traffic but at a much higher steady-state bill.",{"title":343,"description":344},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/02-scalability-and-elasticity","0PTUatXygnuSsmAEr9ZZClZQBUy9H7qc9Z4RJq5xNXs",{"locked":5,"reason":3,"meta":617,"item":626},{"title":618,"description":619,"isFree":5,"estimatedMinutes":620,"difficulty":10,"learningObjectives":621},"Monitoring and SLAs","How metrics, logs, and alarms tell you a system is failing, what an uptime percentage costs in real downtime, and what a cloud provider's SLA actually promises when it doesn't hold.",19,[622,623,624,625],"Explain how monitoring uses metrics, logs, and alarms to detect a problem as or before it happens","Convert an uptime percentage into its equivalent downtime and explain why each additional nine matters","Distinguish SLI, SLO, and SLA and explain what happens when each one is missed","Interpret a real cloud SLA's compensation structure and explain what it does and does not guarantee",{"id":627,"title":618,"body":628,"description":619,"difficulty":10,"estimatedMinutes":620,"extension":264,"infographics":827,"isFree":5,"learningObjectives":828,"meta":829,"navigation":268,"path":830,"quiz":831,"seo":882,"stem":883,"__hash__":884},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas.md",{"type":19,"value":629,"toc":816},[630,634,637,641,644,647,651,654,669,672,675,679,682,728,731,735,738,741,745,748,752,755,759,811,813],[22,631,633],{"id":632},"every-pattern-in-this-topic-assumes-you-find-out","Every pattern in this topic assumes you find out",[27,635,636],{},"Multi-AZ redundancy, Auto Scaling health checks, a tested disaster recovery plan: every pattern this topic has covered so far quietly assumes something. It assumes you find out a failure is happening, ideally before a user does, and it assumes someone can say afterward, in hard numbers, how reliable the system actually was. This lesson covers both halves: monitoring, which is how you find out, and SLAs, which are the documented promise about how often you shouldn't have had to.",[22,638,640],{"id":639},"monitoring-metrics-logs-and-alarms","Monitoring: metrics, logs, and alarms",[27,642,643],{},"3 building blocks cover almost everything a monitoring setup does. A metric is a number tracked over time, average CPU utilization, requests per second, error rate. A log is a record of a specific event, a line saying exactly what happened and when, useful for investigating after something already went wrong rather than watching a trend. An alarm watches a metric against a threshold and takes an action once that threshold is breached for a defined period.",[27,645,646],{},"Amazon CloudWatch is AWS's implementation of all 3: it collects metrics automatically from most AWS services, stores and lets you query logs, and lets you define alarms on top of either. A concrete example: an alarm watches average CPU utilization in 5-minute periods, and if it stays above 80% for 3 consecutive periods, the alarm triggers, which might page an on-call engineer or, tying back to the previous lesson, feed directly into an Auto Scaling target-tracking policy that launches more capacity. Azure Monitor and Google Cloud Operations play the equivalent role on their own platforms; the vocabulary shifts slightly, but metrics, logs, and alarms are the same 3 pieces everywhere.",[22,648,650],{"id":649},"sli-slo-sla-measuring-targeting-promising","SLI, SLO, SLA: measuring, targeting, promising",[27,652,653],{},"These 3 terms get used almost interchangeably in casual conversation, and the exam boundary between them is worth learning precisely.",[27,655,656,657,660,661,664,665,668],{},"A ",[40,658,659],{},"Service Level Indicator (SLI)"," is a quantitative measurement of how a service is actually performing, like the percentage of requests that succeed. A ",[40,662,663],{},"Service Level Objective (SLO)"," is the internal target a team sets for that SLI, like \"we aim for 99.95% successful requests.\" A ",[40,666,667],{},"Service Level Agreement (SLA)"," is the external, contractual version: a promise made to customers that, if missed, carries financial consequences, typically a service credit.",[27,670,671],{},"Think of an SLI as a car's speedometer reading, an SLO as the speed limit the driver privately commits to staying under, and an SLA as the promise made to a passenger that the trip won't exceed a certain speed, backed by a refund if it does. The comparison holds for the relationship between measuring, targeting, and promising, but it breaks on 1 point: an SLI isn't usually a single instant reading like a speedometer, it's typically aggregated over a window of time, an hour or a month, not a live glance at the dashboard.",[27,673,674],{},"Providers deliberately set the SLO stricter than the SLA. If a public SLA promises 99.9% uptime, the internal SLO driving day-to-day operations might be 99.95%, giving the team a buffer to notice and react before a missed internal target turns into a missed, compensable external promise.",[22,676,678],{"id":677},"the-nines-what-an-uptime-percentage-costs-in-real-downtime","The nines: what an uptime percentage costs in real downtime",[27,680,681],{},"Availability numbers get compared casually, \"we're at 4 nines,\" without always registering what that actually means in hours. Each additional nine divides the allowed downtime by roughly 10, which is why the jump from 99.9% to 99.99% is a far bigger engineering commitment than the numbers alone suggest.",[68,683,684,694],{},[71,685,686],{},[74,687,688,691],{},[77,689,690],{},"Uptime",[77,692,693],{},"Allowed downtime per year",[90,695,696,704,712,720],{},[74,697,698,701],{},[95,699,700],{},"99% (2 nines)",[95,702,703],{},"About 3.65 days",[74,705,706,709],{},[95,707,708],{},"99.9% (3 nines)",[95,710,711],{},"About 8.76 hours",[74,713,714,717],{},[95,715,716],{},"99.99% (4 nines)",[95,718,719],{},"About 52 minutes",[74,721,722,725],{},[95,723,724],{},"99.999% (5 nines)",[95,726,727],{},"About 5 minutes",[27,729,730],{},"Most SaaS products and APIs target 3 nines. 5 nines is reserved for systems where even a few minutes of annual downtime carries real financial or safety consequences, and it costs proportionally more to engineer.",[22,732,734],{"id":733},"worked-example-reading-a-real-sla","Worked example: reading a real SLA",[27,736,737],{},"The Amazon EC2 SLA is a useful, concrete case. It commits to a Region-level Monthly Uptime Percentage of at least 99.99%, and separately to an Instance-Level Uptime Percentage of at least 99.5% for individual instances. If actual Region-level uptime in a given month falls short, the credit tiers are 10% for 99.0% up to (but not including) 99.99%, 30% for 95.0% up to (but not including) 99.0%, and 100% below 95.0%.",[27,739,740],{},"Concretely: if Region-level EC2 uptime lands at 98.5% one month, that falls in the 95.0%-to-under-99.0% band, and the customer is eligible for a 30% credit on that service's bill for the month, applied automatically or on request depending on the provider, not a cash refund and not compensation for whatever revenue the outage cost the customer's own business.",[22,742,744],{"id":743},"what-an-sla-promises-and-what-it-does-not","What an SLA promises, and what it does not",[27,746,747],{},"It's tempting to treat \"backed by an SLA\" as \"this will never go down\" or as insurance against business losses. Neither is true. An SLA is a compensation mechanism for the provider's own failure to meet its own published commitment, paid out as a credit against future bills. It commonly excludes scheduled maintenance windows and factors outside the provider's control, and, just like the shared responsibility model from earlier in this domain, it only ever covers the provider's own service. An outage caused by a bug in the customer's own application code is the customer's reliability problem to monitor and fix; no provider SLA was ever written to cover it.",[22,749,751],{"id":750},"boundary-chaining-services-makes-the-overall-number-worse-not-better","Boundary: chaining services makes the overall number worse, not better",[27,753,754],{},"A workload rarely depends on just 1 service. Chain 3 services with individual availability of 99.99%, 99.95%, and 99.9%, and it's tempting to assume the strongest one helps pull the average up. It doesn't: composite availability multiplies the individual probabilities rather than averaging them, so 99.99% times 99.95% times 99.9% lands around 99.84%, worse than any single component in the chain. Every added dependency is a tax on overall reliability, which is exactly why architects count how many services a critical request path actually touches, not just how reliable each one is in isolation.",[22,756,758],{"id":757},"exam-cues-matching-a-scenario-to-the-right-term","Exam cues: matching a scenario to the right term",[68,760,761,769],{},[71,762,763],{},[74,764,765,767],{},[77,766,192],{},[77,768,195],{},[90,770,771,779,787,795,803],{},[74,772,773,776],{},[95,774,775],{},"\"Financially backed guarantee,\" \"service credit for downtime\"",[95,777,778],{},"SLA",[74,780,781,784],{},[95,782,783],{},"\"Internal target,\" \"error budget\"",[95,785,786],{},"SLO",[74,788,789,792],{},[95,790,791],{},"\"The actual measured percentage of successful requests\"",[95,793,794],{},"SLI",[74,796,797,800],{},[95,798,799],{},"\"How much downtime does X% allow\"",[95,801,802],{},"The nines table",[74,804,805,808],{},[95,806,807],{},"\"Multiple dependent services chained together\"",[95,809,810],{},"Composite availability, lower than any single component",[22,812,245],{"id":244},[27,814,815],{},"An SLA is a compensation contract set at a floor below what a provider privately targets for itself, never a guarantee that nothing will fail, and monitoring is what actually tells you, in real time, whether today is one of the days that floor gets tested. That closes out Security and Reliability: you can now name who owns which security task, how systems stay up through a failure, how they recover from one bigger than redundancy could absorb, and what a promise about uptime actually means when it doesn't hold. The next domain turns from what you know toward where it takes you: cloud careers and the certification path this course has been building toward all along.",{"title":250,"searchDepth":251,"depth":251,"links":817},[818,819,820,821,822,823,824,825,826],{"id":632,"depth":254,"text":633},{"id":639,"depth":254,"text":640},{"id":649,"depth":254,"text":650},{"id":677,"depth":254,"text":678},{"id":733,"depth":254,"text":734},{"id":743,"depth":254,"text":744},{"id":750,"depth":254,"text":751},{"id":757,"depth":254,"text":758},{"id":244,"depth":254,"text":245},[],[622,623,624,625],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas",{"passingScore":271,"questions":832},[833,841,849,853,861,870,874],{"question":834,"type":275,"options":835,"correctAnswer":837,"explanation":840},"A CloudWatch alarm watches average CPU utilization over 5-minute periods and triggers after 3 consecutive periods above 80%. What is the metric in this setup?",[836,837,838,839],"The 3 consecutive periods","The average CPU utilization value tracked over time","The action the alarm takes once triggered","The 80% threshold itself","A metric is the number being tracked over time, here average CPU utilization. The threshold (80%), the evaluation window (3 consecutive 5-minute periods), and the alarm itself are all built on top of that metric, not separate from it; an alarm is a rule that watches a metric and acts once the rule's condition holds.",{"question":842,"type":275,"options":843,"correctAnswer":845,"explanation":848},"Which of the following correctly orders SLI, SLO, and SLA by what each one represents?",[844,845,846,847],"SLI is a contractual promise; SLO is a measurement; SLA is an internal target","SLI is a quantitative measurement; SLO is an internal target based on that measurement; SLA is an external, often financially backed promise","SLA is a measurement; SLI is an internal target; SLO is a contractual promise","All 3 terms describe the same thing at different companies","The 3 terms sit in a clear chain: an SLI measures something real, like the percentage of successful requests; an SLO sets an internal goal for that SLI, like 99.95% success; an SLA turns a version of that goal into a contractual promise to customers, typically set a little looser than the SLO so there's a buffer before a missed SLO becomes a missed, compensable SLA.",{"question":850,"type":275,"options":851,"correctAnswer":711,"explanation":852},"A service maintains 99.9% uptime over a year. Approximately how much downtime does that allow?",[727,719,711,703],"Each additional nine in an uptime percentage divides the allowed downtime by roughly 10: 99% allows about 3.65 days a year, 99.9% allows about 8.76 hours, 99.99% allows about 52 minutes, and 99.999% allows about 5 minutes. That tenfold jump in engineering difficulty for each extra nine is exactly why providers price and design very differently around 99.9% versus 99.99% commitments.",{"question":854,"type":275,"options":855,"correctAnswer":857,"explanation":860},"Amazon EC2's Region-level SLA commits to at least 99.99% monthly uptime and offers a 10% service credit if actual uptime falls between 99.0% and 99.99%. If EC2 in a Region delivers 98.5% uptime one month, what does the SLA guarantee the customer?",[856,857,858,859],"Full reimbursement of any lost business revenue for that month","A 30% service credit on that service's bill for the month, since 98.5% falls in the 95.0% to less than 99.0% tier","A refund of the customer's entire monthly AWS bill across all services","Nothing, since 98.5% is close enough to the 99.99% commitment","98.5% uptime lands in the 95.0% to less than 99.0% band, which carries a 30% credit under this SLA's tiered structure, not the 10% tier just above it. That credit applies to the affected service's bill, not the customer's total spend and never to whatever revenue the customer's own business lost during the downtime, which is exactly the boundary the next question in this quiz tests directly.",{"question":862,"type":300,"options":863,"correctAnswers":868,"explanation":869},"Which of the following are true about what a cloud provider's SLA guarantees? (Select all that apply.)",[864,865,866,867],"It typically compensates with service credits toward future bills, not cash reimbursement for a customer's lost business","It guarantees the service will never experience any downtime","It commonly excludes scheduled maintenance and factors outside the provider's control","Meeting the SLA is usually easier for the provider than meeting its own internal SLO, since the SLA is typically set looser",[864,866,867],"An SLA is a compensation mechanism for the provider's own failure to meet a published commitment, not an insurance policy against a customer's business losses, and it never promises zero downtime, only a bounded, credited amount of it. Providers deliberately set their internal SLO stricter than the public SLA, so a missed SLO gives them a chance to react before it becomes a missed, compensable SLA.",{"question":871,"type":275,"options":872,"correctAnswer":320,"explanation":873},"A workload depends on 3 chained services with individual availability of 99.99%, 99.95%, and 99.9%. The overall system's effective availability is higher than any single component's availability, since the strongest component pulls the average up.",[319,320],"A composite availability is the product of the individual probabilities, not an average, so chaining dependent services always pulls the overall figure below the weakest link, not up toward the strongest one. Multiplying 99.99% by 99.95% by 99.9% lands around 99.84%, worse than any 1 component alone, which is why architects treat every added dependency as a tax on overall reliability.",{"question":875,"type":275,"options":876,"correctAnswer":878,"explanation":881},"A startup treats its cloud provider's published SLA as a guarantee that its own application will never go down. An outage happens due to a bug in the startup's own application code. Can the startup claim an SLA credit for this outage?",[877,878,879,880],"Yes, since the provider's SLA covers any downtime regardless of cause","No, since the provider's SLA covers the availability of the provider's own service, not failures caused by the customer's own code","Yes, but only if the startup contacts support within 24 hours","It depends only on which AWS Region the application runs in","This is the shared responsibility model reappearing in a new form: a provider's SLA is scoped to the infrastructure and services it operates, not to whatever a customer builds and runs on top of them. An outage rooted in the customer's own application code is the customer's own reliability problem to monitor, alarm on, and fix, not something any provider SLA was ever written to cover.",{"title":618,"description":619},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas","aZP7DSh_93EReBS9CJCCrTkPoqSFB0WHN46E-2emKn8"]