Episode 16: Disaster Recovery Architectures - Backup, Pilot Light, Warm Standby & Multi-Site | SAA-C03

Hey everyone, Balu here. Welcome back to TechTalk with Balu, your complete guide to asing the AWS Solutions Architect Associate exam. Today we are tackling episode 16, and this is a topic that exam writers absolutely love. We are covering disaster recovery architectures, that's backup and restore, pilot light, warm standby, and multi-site or hot site approaches. This is one of those topics that shows up in nearly every exam, often as part of complex scenario questions where you need to balance cost against recovery time. Let me paint a picture of why this matters. Imagine you are the architect for a financial services company. One Tuesday afternoon, an entire AWS region experiences a major outage. Your applications stop responding. Customers can't access their accounts anymore. The CEO is in your office within 10 minutes asking when services will be restored. What's your answer here five minutes? Is it five hours? Is it five days? Well, the answer depends entirely on how you designed your disaster recovery strategy. If you set up multi-site, you can be back online in seconds. If you only have nightly backups, you might be looking at hours or even days of downtime plus data loss. The strategy you choose has massive business implications and it shows up on the exam constantly. Today, we'll cover the two critical metrics that drive every DR decisions, RPO and RTO. Then we'll work through all four major DR strategies in order from cheapest with longest recovery time to the most expensive with fastest recovery time. We will then look at AWS services that support disaster recovery, including AWS backup, AWS elastic disaster recovery, database migration service, and schema conversion tool, and then we'll finally cover the patterns and traps that appear constantly on the exam. So, quick note. This episode continues the interactive format we introduced in the last episode. Throughout the episode, I will drop in pulse checks, traps, portlights and memory hooks to re-info key concepts. So, please pay attention to the process. There you chance to test yourself before I give you the answer. By the end of this episode, you will understand how to design DR architectures for any business requirement. And you'll be able to choose between strategies based on cost and recovery time constraints. So, let's dive straight in. Let's start with the basics. What exactly is disaster recovery in AWS terms? A disaster is any event that has a negative impact on a company's business continuity or its finances. Well, that's a broad definition, but it's intentionally so put. A disaster could be a natural event like a hurricane taking out a data center. It could be a regional AWS outage. It could be a cyber attack like ransomware encrypting your databases. It could also be a serious human error that is someone accidentally deleting a production database. Or it could be something subtle like data corruption that goes undetected for hours before someone noticing it. Disaster recovery or DR for short is the discipline of preparing for these events and being able to recover from them. The goal isn't just survival here. It's restoring service to your customers and your business within an acceptable timeframe within an acceptable amount of data loss. Now, there are different types of DR scenarios you might design for. The traditional approach is on premise to on premise your primary data center fails over to a secondary data center you also own. This is the old way and it's expensive because you are maintaining two complete data centers here. A more modern approach is hybrid that's on premise to AWS cloud. Your primary infrastructure runs on premise, but you use AWS as your DR site. This is often more cost effective because you only pay for AWS resources when you need them. And then there is the full cloud DR that's AWS region to another AWS region. Your primary infrastructure runs in one AWS region and you fail over to a second region. This is increasingly common as companies go cloud first these days. For the example, you'll see all the three scenarios, but the AWS region to region pattern shows up most often. So, memory hook here, think of DR as an insurance, the more comprehensive the policy, the more it costs, but the better you sleep at night. Your job as an architect is to match the policy to the actual risk and the business value. Now, let's look at RPO and RTO in detail, the two metrics that matter. Before we discuss the strategies themselves, we need to understand these two critical metrics that drive every DR decision. These are RPO and RTO and the exam tests these constantly. You absolutely must understand them. Let's start with RPO. It stands for recovery point objective. RPO answers the question, how much data can you afford to lose? More precisely, it's the maximum amount of data loss measured in time that's acceptable. Let me give you an example here. If your RPO is one hour, that means in a disaster scenario, you can lose up to one hour of data and still be okay here. So, you need to be backing up your data at least every hour here. If your RPO is 24 hours, you only need daily backups, but you might lose a full days worth of customer transactions or orders of whatever data your business runs on. A really small RPO, like seconds or zero, means continuous replication. Every transaction is replicated as it happens. This is expensive because you can imagine you need infrastructure capable of real time replication. A larger RPO like 24 hours means cheaper infrastructure because you only need periodic backups, but you lose more data in a disaster. Now for RTO. RTO stands for recovery time objective. RTO is different, RTO answers the question, how much downtime can you afford? It's the maximum acceptable amount of time between when the disaster happens and when your service is restored. If your RTO is one minute, your service can only be down for 60 seconds before it has to be backup. That requires infrastructure that's essentially always running, ready to take over. If your RTO is 24 hours, you have a full day to restore service. You can take more time to spin up resources, restore data and get things running here. Here's the picture to lock this all in your head. There's a disaster event at some point in time. Looking before the disaster, your data was being backed up periodically. The RPO tells you how far back you can recover to. That's the data loss window. Looking forward from the disaster, the RTO tells you how much downtime you accept before the service is restored. Now for a pulse check. Let me test you on this. If a company say their RPO is five minutes and their RTO is one hour, what does that actually mean? Pause and think about it for a moment. The answer is that they can tolerate losing up to five minutes of data in a disaster and they need the service restored within one hour of the disaster occurring. So they need backups every five minutes or continuous replication and they need a DR strategy that can spin up replacement infrastructure within an hour. Two different requirements driven by two different metrics here. The key insight is that smaller RPO and RTO equal more expensive solutions. And why is that? Because frequent backups cost money and pre-warmed infrastructure ready to take over instantly costs even more money. Every business decision in DR is a trade-off between cost and risk tolerance. Now for a trap spotlight, the exam loves to confuse you on RPO and RTO. Watch these for keywords. If the question mentions data loss, how much data can we lose or last backup, that is up you. If the question mentions downtime, time to restore, how long can VB down? That's RTO. Reading the questions carefully and identifying which metric is being asked is about as half of the battle done. Now for memory hook. RPO is about the past. Remember that. How far back can I go before the disaster? And RTO is about the future. How long until I am backup after the disaster? Past versus future. Data versus downtime. Now let's work through the four DR strategies in order from the cheapest with the longest recovery time to most expensive with the fastest recovery time. The first strategy, strategy number one, is backup and restore. This is the simplest DR strategy. You take regular backups of your data and store them somewhere safe. When disaster strikes, you provision new infrastructure and restore them from those backups. Nothing is running at the DR site until you need it. The key characteristics of backup and restore are high RPO and high RTO. And why is this the case? Because backups are typically taken on a schedule, maybe nightly, maybe every few hours. So if disaster strikes between backups, you lose all the data since the last backup. That's your appeal. And when disaster strikes, you have to actually create new infrastructure from scratch, restore the data, configure everything and bring it online. That takes time. That's your art you're there. But here's the upside. This is the cheapest DR strategy. You're only paying for storage of backups, not for running infrastructure. If your business can tolerate hours or even days of recovery time and significant data loss, the strategy makes sense. Let me walk you through what this looks like architecturally. Your production environment is running normally. Maybe it's on premise with corporate data centers or maybe it's running in another AWS project. region. You set up regular backups going to AWS. The backups can take many forms. For databases, you had used RDS automated backups and RDS snapshots. You might also schedule manual snapshots and copy them across regions for additional protection. For EBS volumes, you had take EBS snapshots regularly. These go to S3 automatically, which is managed by AWS. For easy-to-instances, you had create AMIs, Amazon machine images, which capture the state of your instances, including the boot volume and configuration. For S3 buckets, you might use cross-region replication to copy objects to a different region. For data warehouse, like Redshift, you had to use Redshift snapshots, which can be copied across regions. Now, for long-term archival, you had transitioned older backup to lower-cost storage ties, like S3 standard IA, S3 Glacier, or even Glacier Deep Archive using lifecycle policies. This dramatically reduces storage costs for backups you hope to never need. For on-premise to AWS scenarios, you have a few options. AWS Snowball is a physical device you fill with data and ship to AWS. AWS Storage Gateway is a hybrid cloud storage service that lets your on-premise applications use AWS storage. An AWS data sink is a service for moving large amounts of data between on-premise and AWS. When disaster strikes, you start by provisioning new infrastructure. That's new EC to instances, new RDS databases, new VPC configuration if needed and so on. Then you restore from your most recent backups. You might use cloud formation templates to automate this provisioning, and this is a huge time saver. Without automation, manual provision can take many hours with cloud formation. You might be able to restore in a fraction of that time. All right, for a pulse check, quick test, a small business runs an internal application that's used by employees during business hours only. If the application is down for a few hours, employees can do other work. Cost is a major concern, which DR strategy is best here. Let's pause and think. The answer is backup and restore. Why? Because the business can tolerate hours of downtime. That's high RTO is acceptable. They can probably tolerate losing a day's worth of data since the last backup, which is high RPU is acceptable. And cost is the primary constraint here. There is no point paying for one standby infrastructure if the business actually doesn't need the fast recovery time. Okay, on to a trap spotlight. The exam often tries to push you towards expensive DR strategies, even when they're not needed. Always look at the cost tolerance and recovery time requirements stated in the question. If the question emphasizes cost or mentions that downtime is acceptable, the answer might be backup and restore even though more expensive options exist. So don't overengineer the solution. Keep that in mind. On to a memory hook. Backup and restore is like keeping spare keys in a safe deposit box. They are cheap to maintain, but it takes time to drive to the bank when you are logged out. All right, now let's look at the second strategy, which is called pilot light. The name itself comes from a gas furnace that serves always a small flame burning ready to ignite the main burner when needed. It's the same concept here. In pilot light DR, a small version of application is always running in the cloud. Specifically, the critical core systems are always up typically your databases with continuously replicated data. Less critical systems like web servers, application servers, and so on are not running here. Now, when disaster strikes, you activate the rest of the system that spin up your web servers, app servers, and load balances. Since your critical databases are already running in half current data, you skip the time consuming database restore step entirely. The key characteristics, as you can guess are faster RTO than backup and restore and lower RPU because data is continuously replicated to the running database. The cost is moderate more than backup and restore because you're paying for that always on critical core, but less than warm standby because most of your infrastructure isn't running here. Let me walk you through the architecture. In your primary environment, your full application runs normally. In the DR region, you have a small version. Your RDS database in DR is running, receiving continuous replication from your primary database. So if your primary is RDS Postgres SQL, you might have a read replica running in the DR region, or you might be using Aurora Global Database for sub-second cross-region replication. Your EC2 application servers in DR are not running here. Your load balances may exist but aren't receiving traffic. Route 53 is then configured with health checks pointing at your primary region. As long as the primary is healthy, all traffic goes there. The DR region is just sitting in standby mode with the database running. When disaster strikes, here's what happens. Your monitoring detects the failure. You activate the DR plan. This can be automated or manual. The EC2 instances in DR start-up. The load balancer starts receiving traffic. The application connects to the already running database. Route 53 fails over from primary to DR and the service is restored. The RTO with pilot light is significantly faster than backup and restore. Instead of provisioning everything from scratch and restoring data, you only need to start the non-database systems. The database is already there with current data. We are typically talking about RTO of minutes to maybe an hour depending on how much you have automated. On for a pulse check, here's a scenario for you. An e-commerce company process orders 24/7. They can tolerate up to one hour of downtime and they can lose at most 15 minutes of order data. Cause matters but service availability is critical. Which strategy fits here? This is likely pilot light, the 15-minute RPU requires continuous replication of the database, which pilot light provides. The one hour RTO is achievable with pilot light because you only need to start application service and not restore the entire database. Cause is more than backup and restore but reasonable for the business needs here. Warm standby or multi-site would be an overkill for these requirements. Now on for a trap spot light. The exam sometimes describes pilot light without using the term. They describe the architecture instead. Watch for these signals. Database is always running in DR region with replication. Application service are not running until fail-over. Moderate RTO of minutes and lower cost and maintaining full DR infrastructure. When you see any of these patterns, even without the words pilot light, that's the answer. Alright for a memory hook, pilot light is like leaving the engine running on your car while you run into a store. The car isn't moving here but it's ready to go the moment you jump in. Hope you get that point. Now let's look at the third strategy which is warm standby. This is a step up from pilot light. It's got more capability, it costs more but there's faster recovery possible here. In warm standby, this full system is up and running in the DR region but at minimum size. So unlike pilot light where most servers are off, in warm standby everything is running. Just at small scale though. Maybe you have one easy to instance running where perfection has 50. The database is running. The load balance is running. Everything is there but it's just smaller. When disaster strikes, you don't need to spin up these new systems. You just need to scale up the existing ones. Your auto scaling groups grow from one instance to 50. Your traffic shifts over. The infrastructure is already there just size down for cost. The key characteristics are it's got very fast RTO since everything is already running. Low RTO since data is continuously replicated and higher cost than pilot light because more infrastructure is running here. Architecturally in your primary region you have to have the full production environment that's the load balancer, app servers in auto scaling, primary database, all running at full capacity. In the DR region you can have a parallel architecture. Load balancer, app servers running at minimum scale. RDE secondary receiving continuous replication. Route 53 manages DNS with health checks. When disaster strikes the fellow process stayed forward. Auto scaling scales up to production capacity. Route 53 fails over from primary to DR. Services restored typically all happens within minutes. A key consideration with warm standby is making sure your minimum scale can actually handle real traffic. If your DR site is running with one tiny instance and production has 50 massive instances, the moment you fail over the tiny instance gets crushed by the traffic before auto scaling can grow it. So you need to balance cost savings against the ability to absorb initial fail over traffic. The cost is significantly higher than pilot light because you're paying for compute capacity in two regions simultaneously. It's just that DR region's capacity is smaller here. For applications that need fast recovery but can tolerate some scaling delay, this is often the sweet spot. For a pulse check try this one. A SaaS company runs a B2B application used during business hours by enterprise customers. They have a strict SLA promising 99.9% uptime. Their RPO is 5 minutes and RTO is 15 minutes. What strategy do they need? Yep, the answer is warm standby. The 15 minute RTO requires more than starting up servers from scratch. It requires servers already running and just needing to scale up. The 5 minute RPO requires continuous data replication. The SLA pressure justifies the additional cost. Pilot light might be too slow because you have to wait for application servers to start and so forth. WAM standby has them already running and it's just smaller. On for a trap spotlight, don't confuse WAM standby with multi-site or hot-site, the key distinction is scale. WAM standby runs everything at minimum size, it can't handle production traffic without scaling. Multi-site runs everything at full production scale, it can handle production traffic immediately. The exam often tests this distinction by describing capacity requirements during failure. Finally on for a memory hook, think of WAM standby like keeping a backup band rehearsed and on stage but playing very softly, they can pick up where the main band left off but remember they need to warm up a bit first. The fourth and most expensive strategy is multi-site, also called hot-site or sometimes active. In multi-site you have full production scale running in multiple locations simultaneously. Both sides are active, both are taking traffic, both have full capacity. There's no standby, everything is hot and ready. The key characteristics are it's got very low RTO measured in minutes or even seconds, very low RPO measured in seconds because of continuous replication and the highest cost of any DR strategy because you're essentially paying for two complete production environments. Architectural in both regions you have full production, that's load balancers, app servers in auto scaling at full scale, databases with bidirectional or near bidirectional replication. Route 53 is weighted routing or latency-based routing sends traffic to both regions simultaneously. If one region fails, Route 53 detects it and routes all traffic to the surviving region. Users barely notice the disaster has happened. A common pattern for multi-site is using Aurora Global Database. You have an Aurora cluster in your primary region and secondary clusters in up to 10 other regions. Replication latency is under one second here. If your primary region fails, you can promote a secondary to be a new primary with very fast failover typically under a minute. This is the goal standard for multi-region database architectures. For DNS you had used Route 53 with help checks pointing at both regions. Failure routing or latency-based routing handles the redirection automatically based on the health status. For the application tier, auto scaling groups in both regions handle the compute. Both are receiving traffic in normal operations so they are both validated and known to be working. The cost is significant. You're essentially doubling your infrastructure costs here. For some businesses, financial services, healthcare, real-time trading, this cost is justified by the business requirements, but for most businesses it's an overkill. A subtle distinction worth knowing is that multi-site can be hybrid, that is it can have on premise plus cloud both active or an all AWS multi-region. The hybrid version is older and wherever now, the all AWS multi-region version is more commonly available today. For a pulse check, it's a scenario time. A real-time financial trading platform process millions of transactions per second. Any downtime longer than a few seconds is unacceptable. It would cost massive financial loss and regulatory issues. Cost is essentially no object. What DR strategy fits here? The answer is multi-site. The second level RTO requires both regions to be actively handling traffic. The need to never lose a transaction requires a real-time replication here, and the Kai cost is justified by the regulatory and financial stakes. Anything less than multi-site would create an acceptable risk for this kind of application. Now on for a trap spotlight. The example often try to make multi-site the answer when actually warm standby or pilot light would be more cost-effective generally, so pay attention to cost constraints in the question. If the question mentions minimize cost while meeting RTO of one hour, that's probably not multi-site. You're paying for capability you don't need there. Now on for a memory hook. Multi-site is like having identical twins running parallel marathons. If one stumbles, the other is already at the same point in the race. There is no recovery needed. Alright now let's go on to the full DR spectrum recap. Let me put together all for you with a very clear comparison. Going from the cheapest with the slowest recovery to the most expensive with the fastest recovery, the four strategies we have here and we've spoken about is backup and restore, pilot light, warm standby and multi-site. Backup and restore there is nothing running in DR just backup storage. RPU measured is in hours to days. RTU measured is also in hours to days. It's the cheapest option generally. Pilot light is for critical databases running with replication. Here the application servers are off. RPU is in minutes because of the database replication. RTU is in minutes to an hour and it costs moderately. Next we have the warm standby that's full system running at minimum size. RPU is in seconds to minutes. RTU is in minutes and it's generally higher cost. Then we finally had the multi-site which is full production scale in multiple regions. RPU is in seconds. RTU is in seconds to minutes and it's the highest cost. You notice a pattern here. As you move down the list, RTU gets faster. RPU gets smaller and the costs get higher. Your job as an architect is to find the right point on the spectrum for the business requirements at hand. Let's do a rapid fire around here. I'll give you a scenario you choose the strategy. Let's pause after each whilst I tell you the answer. Okay scenario one. Recomment is for a development environment that's used by engineers. It can handle downtime for a few days during disaster and that's completely fine. What strategy would you use? Yes, it's the backup and restore because cheapest is fine here. Scenario 2 is for an internal HR system used during business hours. The RTU is of 4 hours. That's acceptable. What's the strategy you want to use? It's likely backup and restore or pilot light depending on the data lost tolerance here. What is scenario 3? It's for an online store with thousands of customers. Lots of orders is unacceptable here. Down time of a few minutes though is acceptable. Yep, warm standby or multi-site. Probably warm standby for cost reasons. On to scenario 4, it's a stock trading platform with millions of transactions. Here, seconds matter. What's the strategy? Yep, multi-site, no question asked. Scenario 5, it's for a SaaS analytics dashboard. The RTU requirement of 30 minutes is acceptable. Moderate cost target. What is the strategy? Here, you want to go for pilot light. That's faster than backup and restore but not as expensive as warm standby. Well, how did you do? The pattern recognition is the key skill here, right? On to memory hook now, remember the spectrums as a sliding scale. Backup is the left, which is cheap and slow. Multi-site is the right, which is expensive and fast. Pilot light and warm standby are somewhere in the middle and the exam wants you to find the right point on the slider for the requirement stated. Okay, now let's go on to the next section where we cover the AWS services that support disaster recovery because the exam will test specific services. Let's start with the AWS backup. This is a fully managed service that centralizes and automates backups across AWS services. Before AWS backup, you had to write custom scripts or manage backups separately for each services that's RDS backups managed in RDS, EBS snapshots managed separately, DynamoDB backups manage in DynamoDB and so on. AWS backups brings all of this under one roof. AWS backup supports a long list of services that's easy to an EBS, S3, RDS and Aurora, and DynamoDB, DocumentDB and Neptune, EFS and FSX and storage gateway. It supports cross-region backups and cross-account backups, both of which are critical for DR scenarios. You use AWS backup by creating backup plans. A backup plan defines backup frequency every 12 hours daily, weekly, monthly or any Chrome expression here. It defines the backup window when transitions to call storage happen similar to S3 lifecycle policies and the retention period days, weeks, months, years or forever. A really powerful feature is tag-based backup policies. You tag resources with something like backup equals daily and AWS backup automatically backs up everything with that tag. This makes it easy to maintain consistent backup policies across hundreds or thousands of resources. AWS backup also supports point-in-time recovery for supported services. This is critical for ransomware scenarios or accidental deletions. You can restore to any moment in the recent past. Next, AWS elastic disaster recovery or what we call DRS. This used to be called cloud endure disaster recovery. It's specifically designed for protecting on-premise services, virtual machines and even servers from other clouds. The way it works is you install an AWS replication agent on your service. The agent continuously then replicates block-level changes to AWS. Replication happens in seconds, so RPU is very low here. AWS keeps low cost, EC2 instances and EBS volumes in a staging area, receiving the replicated data. When disaster strikes, AWS elastic disaster recovery spins up target EC2 instances with your replicated data. Recovery typically happens in minutes. And after the disaster is resolved, you can fail back to your original environment. This is a great service for protecting critical databases like Oracle, MySQL, SQL Server, and Enterprise applications like SAP. It's also valuable for protecting against ransomware attacks because replication is continuous and you can have multiple recovery points. You can roll back to before the ransomware encrypted your data, for example. Now let's talk about database migration service or DMS for short. While DMS is primarily a migration tool, it's relevant to DR because it can do continuous data replication using change data capture or CDC for short. DMS can migrate databases to AWS securely and quickly. The source database remains available during migration. DMS supports homogeneous migrations like Oracle to Oracle and heterogeneous migrations like Microsoft SQL Server to Aurora. For heterogeneous migrations, you typically use DMS together with the AWS schema conversion tool or SCT. SCT converts your database schema from one engine to another, for example, from SQL Server to MySQL or from Oracle to Postgres SQL or from Teradata to RedShift. Once SCT has converted the schema, DMS migrates the data. There is an important point to remember here that you don't need SCT if you're migrating the same database engine. Postgres SQL on-premise to Postgres SQL on RDS doesn't need schema conversion. The engine is basically the same. To run DMS, you need to create an EC2 instance that runs the DMS replication tasks. So DMS is not entirely serverless. It requires you to manage that instance. A few other DR services worth knowing, site-to-site VPN can serve as a backup for direct connect. If you rely on direct connect for connectivity between on-premise and AWS, having a backup VPN connection is important. Otherwise, a direct connect failure could cut off your AWS access. The VPN is much cheaper than a backup direct connect. Route 53 is critical for DR because it manages DNS and can fail over between regions automatically using health checks and fail over routing policies. Aurora Global Database provides cross-region replication with under one second latency, making it ideal for multi-side DR scenarios. And finally, cloud formation lets you codify entire environments as infrastructure as code, making it possible to recreate your environment quickly in another region during disaster recovery. Now for a trap spotlight. The exam loves to test the difference between AWS backup and AWS elastic disaster recovery. Here's the key distinction. AWS backup is for AWS native services. It backs up Adios, EBS, S3, DynamoDB, and so on. You get the point. AWS elastic disaster recovery on the other hand is for protecting non-AW's workloads. That's on-premise servers, VMs on VMware, or Hyper-V, or even servers on other clouds. So if the question is about protecting AWS resources, then think AWS backup. Whereas if the question is about protecting on-premise or non-AW's infrastructure, then think AWS elastic disaster recovery. For memory hook, AWS backup is for things inside of AWS. AWS elastic disaster recovery is for things outside AWS. That need to land safely inside AWS during a disaster. That's inside versus outside. All right, now let's look at exam traps and gotchas. Let's cover some common DR traps that catch people up on the exam. Trap number one, confusing RPO and ATO. This is one of the most common mistakes. So remember, RPO is data loss measured before the disaster. ATO is downtime measured after the disaster. That's past versus future. Keep that in mind. Trap number two is over-engineering DR strategies. The example sometimes try to push you towards multi-site when actually backup and restore or pilot light is sufficient. Read the requirements carefully. If cost is a constraint and the business can tolerate hours of downtime, don't pick multi-site just because it sounds fancy. Tip number three, confusing AWS backup and AWS elastic disaster recovery. AWS backup is for backing up AWS native services. Elastic disaster recovery on the other hand is for protecting non AWS infrastructure like on-premise servers and VMs. That's remember inside AWS versus outside AWS. Trap number four, forgetting SCT for heterogeneous migrations. If the question describes migrating from one database engine to a different engine, you need both DMS and SCT. If it's the same engine, only DMS is needed. Trap number five, confusing high availability with disaster recovery. High availability is about handling failures within a region, typically using multi-az. DR is about handling failures across regions. Adios multi-az is not a dear solution by itself. It's high availability. For DR, you need cross-region replication or read replicas. Trap number six, multi-site versus warm standby. The key distinction is scale. Warm standby is at minimum scale and needs to scale up before handling production traffic. Multi-site on the other hand is a full-production scale and can handle traffic immediately. So pay attention to whether the question mentions immediate full capacity. Trap number seven, site to site VPN as a direct connect backup. If a question describes direct connect with the need for backup connectivity, the cost-effective answer is often a site to site VPN and not a second direct connect. Trap number eight, DMS requires an EC2 instance. DMS is an entirely serverless, you create an EC2 instance to run the replication tasks. This shows up in cost comparison questions all the time. Trap number nine, Aurora Global Database Failure Time. Aurora Global Database provides cross-region replication with under one second latency and a failover in under a minute. This is a standard answer for fast multi-region database fail-overs scenarios. Trap number 10, cross-region replication for S3. If a question asks how to protect S3 data against regional failures, the answer is S3 cross-region replication, not just storing in multiple Asis. Multi-AZ is within a region. CRR is across regions. Do remember that. Trap number 11, automated easy to recovery wire cloud watch alarms. If a question asks how to handle EC2 hardware failure automatically, the answer is a cloud watch alarm on status check failed system with the recall action. This moves the instance to new hardware keeping the same IPs and the metadata. And finally for Trap number 12, infrastructure as code accelerates DR. If a question asks how to speed up recovery time when provisioning new infrastructure, cloud formation or elastic beanstalk for the entire environment recreation is the answer. Manual provision is normally slow, codify infrastructure is fast. Okay, now we are on to the final section, exam quick tips. Let me give you the rapid fire summary to lock all what we have discussed in your mind. RPO is data loss before disaster. RTO on the other hand is downtime after disaster. We spoke about that many times. Four strategies in order from cheapest to most expensive, slow as to fast recovery, backup and restore pilot light, warm standby, and finally multi site. Back up and restore nothing running in DR just backup storage hours to days RTO and RPO. This is the cheapest option pilot light critical database running in DR with replication application servers are off minutes to hours of RTO minutes RPO moderate in cost warm standby full system is running at minimum size in DR minutes RTO seconds to minutes RPO higher cost. Multi site full production scale in both regions active active seconds RTO and RPO often the highest cost. Use AWS backup for backing up AWS native services with centralized management. Use AWS elastic disaster recovery for protecting on premise and non AWS service replicating them to AWS for fast failure. DMS plus a city is used for cross engine database migration. DMS alone is used for same engine migration. Aurora global database is used for fastest cross region database replication and failure. Use route 53 health checks and failure routing for DNS level failure between regions. Use site to site VPN as a cheap backup for direct connect. Use cloud formation for codified infrastructure that can be recreated quickly during DR. So finally, let me leave you with a decision framework. If cost is the priority and downtime is acceptable, then think backup and restore. If database needs continuous replication but the cost matters, then think pilot light. If fast failure is needed but cost still matters a lot, then think warm standby. If you need seconds level recovery and cost is no object for you, then think multi site. If you want to protect your on premise service, then think elastic disaster recovery and for backing up AWS services, you want to use AWS backup. All right, so that is episode 16 on disaster recovery architectures. We covered a topic that's absolutely fundamental to AWS architecture work and heavily tested on the exam. So we started with two critical metrics are pure for for data loss and audio for downtime. That's the foundation of every DR decision. Then we work through all four DR strategies in order from the cheapest and slowest backup at restore through pilot light and warm standby up to the most expensive and fastest, which is multi-site or hot site. We covered the key AWS services that support DR, that's AWS backup for AWS resources, elastic disaster recovery for non-AWs workloads, DMS and SCT for database migrations, Aurora Global Database, Route 53 Failure, and CloudFormation for Automation. We work through 12 common exam traps and throughout the episode we used pull checks, traps, spotlights, and memory hooks to lock the concepts in. The big takeaway is that disaster recovery is all about trade-offs. Faster recovery and less data loss costs more money. Your job as an architect is to master strategy to the business requirements, not always picking the most capable strategy, but picking the right one for the cost and risk constraints in play. Master the straight off thinking and you will handle DR questions on the exam with confidence. We have now completed 16 main episodes covering the core of the solutions architect exam. The foundation is really comprehensive at this point, compute storage databases, networking serverless, messaging, content delivery monitoring, and now we looked at disaster recovery. You're well on your way to exam readiness here. Now if this episode helped DR strategies finally click for you, please do consider to leave a five star rating for this episode and share it with anyone studying for the AWS exam. It genuinely helps the channel grow. Also, I would appreciate if you let me know in the comments if the interactive format and the pulse checks and the memory hooks are working out for you and whether I should continue with this approach. Your feedback will shape the next episodes. So until next time, keep building, keep recovering and I will see you in the next episode. This is Baloo signing off, bye.