Backup

AWS RDS DB Snapshot, Backup & Restore

RDS Automated Backups vs Manual Snapshots
~ Last updated on : ~ jayendrapatil ~ 16 Comments

RDS BackUp, Restore and Snapshots

  • RDS creates a storage volume snapshot of the DB instance, backing up the entire DB instance and not just individual databases.
  • RDS provides two different methods Automated and Manual for backing up the DB instances.
  • RDS backups are stored securely in Amazon S3.

Automated backups

  • Backups of the DB instance are automatically created and retained.
  • RDS Backups are incremental. The first snapshot of a DB instance contains the data for the full database. Subsequent snapshots of the same database are incremental, which means that only the data that has changed after your most recent snapshot is saved.
  • Automated backups are enabled by default for a new DB instance.
  • Automated backups occur during a daily user-configurable period of time, known as the preferred backup window.
    • If a preferred backup window is not specified when a DB instance is created, RDS assigns a default 30-minute backup window which is selected at random from an 8-hour block of time per region.
    • Changes to the backup window take effect immediately.
    • Backup window cannot overlap with the weekly maintenance window for the DB instance.
  • Backups created during the backup window are retained for a user-configurable number of days, known as the backup retention period
    • If the backup retention period is not set, RDS defaults the period retention period to one day, if created using RDS API or the AWS CLI, or seven days if created from AWS Console.
    • Backup retention period can be modified with valid values are 0 (for no backup retention) to a maximum of 35 days.
  • Manual snapshot limits (100 per region) do not apply to automated backups.
  • If the backup requires more time than allotted to the backup window, the backup will continue to completion.
  • An immediate outage occurs if the backup retention period is changed
    • from 0 to a non-zero value as the first backup occurs immediately or
    • from a non-zero value to 0 as it turns off automatic backups, and deletes all existing automated backups for the instance.
  • RDS uses the periodic data backups in conjunction with the transaction logs to enable restoration of the DB Instance to any second during the retention period, up to the LatestRestorableTime (typically up to the last few minutes).
  • During the backup window,
    • for Single AZ instance, storage I/O may be briefly suspended while the backup process initializes (typically under a few seconds) and a brief period of elevated latency might be experienced.
    • for Multi-AZ DB deployments, there is No I/O suspension since the backup is taken from the standby instance
  • The first backup is a full backup, while the others are incremental.
  • Automated backups don’t occur while a DB snapshot copy is running in the same AWS Region for the same database.
  • Automated DB backups are deleted when
    • the retention period expires
    • the automated DB backups for a DB instance are disabled
    • the DB instance is deleted
  • When a DB instance is deleted,
    • a final DB snapshot can be created upon deletion; which can be used to restore the deleted DB instance at a later date.
    • RDS retains the final user-created DB snapshot along with all other manually created DB snapshots
    • all automated backups are deleted and cannot be recovered
  • NOTE: RDS can be configured to retain the automated backups on RDS instance deletion.
  • For the MySQL DB engine, automated backups are only supported for the InnoDB storage engine. Use of these features with other MySQL storage engines, including MyISAM, can lead to unreliable behavior while restoring from backups.

Point-In-Time Recovery

  • In addition to the daily automated backup, RDS archives database change logs. This enables recovery of the database to any point in time during the backup retention period, up to the last five minutes of database usage.
  • Disabling automated backups also disables point-in-time recovery
  • RDS stores multiple copies of the data, but for Single-AZ DB instances these copies are stored in a single availability zone.
  • If for any reason a Single-AZ DB instance becomes unusable, point-in-time recovery can be used to launch a new DB instance with the latest restorable data

Cross-Region Automated Backup Replication

  • RDS supports replicating automated backups to another AWS Region for disaster recovery.
  • With Cross-Region Automated Backup replication, RDS replicates snapshots and transaction logs to the chosen destination AWS Region.
  • In the event the primary AWS Region becomes unavailable, the automated backup can be restored to a point in time in the secondary AWS Region to quickly resume operations.
  • You can replicate up to 20 backups to each destination AWS Region for each AWS account.
  • Cross-Region automated backup replication is not supported for Multi-AZ DB clusters.
  • Provides cross-Region DR capability with RPO of minutes.
  • Available for RDS for MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2.

DB Snapshots (User Initiated – Manual)

  • DB snapshots are manual, user-initiated backups that enable a DB instance backup to a known state, and restore to that specific state at any time.
  • RDS keeps all manual DB snapshots until explicitly deleted.
  • Manual DB snapshots have a limit of 100 per region (can be increased by requesting a quota increase).

DB Snapshots Creation

  • DB snapshot is a user-initiated storage volume snapshot of DB instance, backing up the entire DB instance and not just individual databases.
  • DB snapshots enable backing up of the DB instance in a known state as needed, and can then be restored to that specific state at any time.
  • DB snapshots are kept until explicitly deleted.
  • Creating DB snapshot on a Single-AZ DB instance results in a brief I/O suspension that typically lasts no more than a few minutes.
  • Multi-AZ DB instances are not affected by this I/O suspension since the backup is taken on the standby instance

DB Snapshot Restore

  • DB instance can be restored to any specific time during this retention period, creating a new DB instance.
  • DB restore creates a New DB instance with a different endpoint.
  • RDS uses the periodic data backups in conjunction with the transaction logs to enable restoration of the DB Instance to any second during the retention period, up to the LatestRestorableTime (typically up to the last few minutes).
  • Option group associated with the DB snapshot is associated with the restored DB instance once it is created. However, the option group is associated with the VPC, so would apply only when the instance is restored in the same VPC as the DB snapshot.
  • Default DB parameter and security groups are associated with the restored instance. After the restoration is complete, any custom DB parameter or security groups used by the restored instance should be associated explicitly.
  • A DB instance can be restored with a different storage type than the source DB snapshot. In this case, the restoration process will be slower because of the additional work required to migrate the data to the new storage type e.g. from GP2 to Provisioned IOPS
  • A DB instance can be restored with a different edition of the DB engine only if the DB snapshot has the required storage allocated for the new edition for e.g., to change from SQL Server Web Edition to SQL Server Standard Edition, the DB snapshot must have been created from a SQL Server DB instance that had at least 200 GB of allocated storage, which is the minimum allocated storage for SQL Server Standard edition
  • NEW (Feb 2026): RDS now supports viewing and modifying backup retention period and preferred backup window settings prior to and upon restoring database snapshots, providing visibility into backup configurations before initiating restore operations.

DB Snapshot Copy

  • RDS supports two types of DB snapshot copying.
    • Copy an automated DB snapshot to create a manual DB snapshot in the same AWS region. Manual DB snapshots are not deleted automatically and can be kept indefinitely.
    • Copy either an automated or manual DB snapshot from one region to another region. By copying the DB snapshot to another region, a manual DB snapshot is created that is retained in that region
  • For each AWS account, you can copy up to 20 DB snapshots at a time from one AWS Region to another.
  • Automated backups cannot be shared. They need to be copied to a manual snapshot, and the manual snapshot can be shared.
  • Manual DB snapshots can be shared with other AWS accounts and snapshots shared can be copied by other AWS accounts.
  • Snapshot Copy Encryption
    • DB snapshot that has been encrypted using an AWS Key Management Service (AWS KMS) encryption key can be copied.
    • Copying an encrypted DB snapshot results in an encrypted copy of the DB snapshot
    • When copying, DB snapshot can either be encrypted with the same KMS encryption key as the original DB snapshot, or a different KMS encryption key to encrypt the copy of the DB snapshot.
    • An unencrypted DB snapshot can be copied to an encrypted snapshot, a quick way to add encryption to a previously unencrypted DB instance.
    • Encrypted snapshot can be restored only to an encrypted DB instance.
    • If a KMS encryption key is specified when restoring from an unencrypted DB cluster snapshot, the restored DB cluster is encrypted using the specified KMS encryption key.
    • Copying an encrypted snapshot shared from another AWS account requires access to the KMS encryption key that was used to encrypt the DB snapshot.
    • AWS supports copying encrypted DB snapshots between accounts and across multiple regions seamlessly.
  • NEW (Oct 2025): AWS Backup now supports copying database snapshots across AWS Regions and accounts using a single copy action. This feature supports Amazon RDS, Aurora, Neptune, and DocumentDB snapshots, eliminating the need for sequential copying steps.

DB Snapshot Sharing

  • Manual DB snapshots or DB cluster snapshots can be shared with up to 20 other AWS accounts.
  • Manual snapshots shared with other AWS accounts can copy the snapshot, or restore a DB instance or DB cluster from that snapshot.
  • Manual snapshots can also be shared as public, which makes the snapshot available to all AWS accounts. Care should be taken when sharing a snapshot as public so that none of the private information is included
  • Shared snapshot can be copied to another region.
  • However, following limitations apply when sharing manual snapshots with other AWS accounts:
    • When a DB instance or DB cluster is restored from a shared snapshot using the AWS CLI or RDS API, the Amazon Resource Name (ARN) of the shared snapshot as the snapshot identifier should be specified.
    • DB snapshot that uses an option group with permanent or persistent options cannot be shared.
    • A permanent option cannot be removed from an option group. Option groups with persistent options cannot be removed from a DB instance once the option group has been assigned to the DB instance.
  • DB snapshots that have been encrypted “at rest” using the AES-256 encryption algorithm can be shared
  • Users can only copy encrypted DB snapshots if they have access to the AWS Key Management Service (AWS KMS) encryption key that was used to encrypt the DB snapshot.
  • AWS KMS encryption keys can be shared with another AWS account by adding the other account to the KMS key policy.
  • However, KMS key policy must first be updated by adding any accounts to share the snapshot with, before sharing an encrypted DB snapshot
  • NEW (2026): RDS for Oracle and SQL Server now support cross-account snapshot sharing for database instances with additional storage volumes (up to 256 TiB total across multiple volumes).

DB Snapshot Export to S3

  • RDS can export DB snapshot data to an Amazon S3 bucket in Apache Parquet format.
  • Supported engines: RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, Aurora PostgreSQL-Compatible, and Aurora MySQL.
  • By default, all data in the snapshot is exported. However, you can choose to export specific sets of databases, schemas, or tables.
  • After export, the data can be analyzed directly using tools like Amazon Athena or Amazon Redshift Spectrum.
  • Useful for data archiving, compliance, analytics, and machine learning use cases.
  • Export eliminates the need to restore a snapshot to query data, reducing costs and complexity.
  • Supported for Multi-AZ deployments with two readable standbys (since June 2024).

AWS Backup Integration

  • AWS Backup provides a centralized, policy-based backup service for RDS instances.
  • Periodic snapshots created by AWS Backup are considered manual backups in Amazon RDS and are taken according to backup plan schedules.
  • AWS Backup Vault Lock provides Write Once Read Many (WORM) immutability for backup data through retention policies, protecting against accidental or malicious deletion.
  • Logically Air-Gapped Vaults (GA Aug 2024): Stores immutable backup copies that are locked by default and further protected through encryption using AWS-owned keys. Provides ransomware protection by isolating backups in service-owned accounts.
  • AWS Backup supports RDS Multi-AZ clusters across 17 Regions (expanded March 2026), providing lifecycle management and immutable backups.
  • Single-Action Cross-Region/Cross-Account Copy (Oct 2025): Copy RDS snapshots across regions and accounts in one step, eliminating sequential copying.

RDS Automated Backups vs Manual Snapshots

RDS Automated Backups vs Manual Snapshots

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Amazon RDS automated backups and DB Snapshots are currently supported for only the __________ storage engine
    1. InnoDB
    2. MyISAM
  2. Automated backups are enabled by default for a new DB Instance.
    1. TRUE
    2. FALSE
  3. Amazon RDS DB snapshots and automated backups are stored in
    1. Amazon S3
    2. Amazon EBS Volume
    3. Amazon RDS
    4. Amazon EMR
  4. You receive a frantic call from a new DBA who accidentally dropped a table containing all your customers. Which Amazon RDS feature will allow you to reliably restore your database to within 5 minutes of when the mistake was made?
    1. Multi-AZ RDS
    2. RDS snapshots
    3. RDS read replicas
    4. RDS automated backup
  5. Disabling automated backups ______ disable the point-in-time recovery.
    1. if configured to can
    2. will never
    3. will
  6. Changes to the backup window take effect ______.
    1. from the next billing cycle
    2. after 30 minutes
    3. immediately
    4. after 24 hours
  7. You can modify the backup retention period; valid values are 0 (for no backup retention) to a maximum of ___________ days.
    1. 45
    2. 35
    3. 15
    4. 5
  8. Amazon RDS automated backups and DB Snapshots are currently supported for only the ______ storage engine
    1. MyISAM
    2. InnoDB
  9. What happens to the I/O operations while you take a database snapshot?
    1. I/O operations to the database are suspended for a few minutes while the backup is in progress.
    2. I/O operations to the database are sent to a Replica (if available) for a few minutes while the backup is in progress.
    3. I/O operations will be functioning normally
    4. I/O operations to the database are suspended for an hour while the backup is in progress
  10. True or False: When you perform a restore operation to a point in time or from a DB Snapshot, a new DB Instance is created with a new endpoint.
    1. FALSE
    2. TRUE
  11. True or False: Manually created DB Snapshots are deleted after the DB Instance is deleted.
    1. TRUE
    2. FALSE
  12. A user is running a MySQL RDS instance. The user will not use the DB for the next 3 months. How can the user save costs?
    1. Pause the RDS activities from CLI until it is required in the future
    2. Stop the RDS instance
    3. Create a snapshot of RDS to launch in the future and terminate the instance now
    4. Change the instance size to micro
  13. A company needs to ensure their RDS database backups are protected from ransomware and accidental deletion. Which AWS service feature provides immutable, WORM-compliant backup storage?
    1. RDS automated backup retention
    2. RDS Multi-AZ deployment
    3. AWS Backup Vault Lock
    4. RDS snapshot sharing
  14. A disaster recovery team needs to be able to restore their RDS database in a secondary AWS Region. Which RDS feature provides cross-Region point-in-time recovery capability?
    1. RDS Read Replicas
    2. Cross-Region Automated Backup Replication
    3. RDS Manual Snapshot Copy
    4. RDS Multi-AZ Deployment
  15. An analytics team needs to query data from an RDS snapshot without restoring the entire database. What is the most cost-effective approach?
    1. Restore the snapshot to a new RDS instance and run queries
    2. Export the snapshot data to S3 in Parquet format and use Athena to query
    3. Create a read replica from the snapshot
    4. Copy the snapshot to another region and restore there

References

AWS Disaster Recovery – Whitepaper

~ Last updated on : ~ jayendrapatil ~ 16 Comments

AWS Disaster Recovery Whitepaper

📋 Content Update Notice (June 2026)

This post has been updated to reflect the latest AWS DR whitepaper “Disaster Recovery of Workloads on AWS: Recovery in the Cloud” which replaces the original AWS Disaster Recovery whitepaper. Key updates include AWS Elastic Disaster Recovery (DRS), AWS Backup, AWS Resilience Hub, deprecation of OpsWorks and AWS Import/Export, and rebranding of Amazon Glacier to S3 Glacier storage classes.

AWS Disaster Recovery Whitepaper is one of the very important Whitepaper for both the Associate & Professional AWS Certification exam

Disaster Recovery Overview

  • AWS Disaster Recovery whitepaper “Disaster Recovery of Workloads on AWS: Recovery in the Cloud” highlights AWS services and features that can be leveraged for disaster recovery (DR) processes to significantly minimize the impact on data, system, and overall business operations.
  • It outlines best practices to improve your DR processes, from minimal investments to full-scale availability and fault tolerance, and describes how AWS services can be used to reduce cost and ensure business continuity during a DR event
  • Disaster recovery (DR) is about preparing for and recovering from a disaster. Any event that has a negative impact on a company’s business continuity or finances could be termed a disaster. One of the AWS best practice is to always design your systems for failures
  • Resiliency is a shared responsibility between AWS and the customer. AWS is responsible for “Resiliency of the Cloud” (infrastructure), while customers are responsible for “Resiliency in the Cloud” (workload architecture)

Disaster Recovery Key AWS services

  1. Region
    • AWS services are available in multiple regions around the globe, and the DR site location can be selected as appropriate, in addition to the primary site location
    • Each AWS Region is fully isolated and consists of multiple Availability Zones, which are physically isolated partitions of infrastructure
    • All traffic between AZs is encrypted and interconnected with high-bandwidth, low-latency networking
  2. Storage
    • Amazon S3
      • provides a highly durable (99.999999999%) storage infrastructure designed for mission-critical and primary data storage.
      • stores Objects redundantly on multiple devices across multiple facilities within a region
      • supports cross-region replication for DR scenarios
    • Amazon S3 Glacier Storage Classes (formerly Amazon Glacier)
      • S3 Glacier Instant Retrieval – millisecond retrieval for archives that need immediate access
      • S3 Glacier Flexible Retrieval (formerly S3 Glacier) – retrieval times of minutes to hours, suitable for backup data
      • S3 Glacier Deep Archive – lowest cost storage, retrieval time of 12-48 hours for long-term archive
      • Note: Amazon Glacier (original standalone vault-based service) no longer accepts new customers as of December 15, 2025. Use S3 Glacier storage classes instead.
    • Amazon EBS
      • provides the ability to create point-in-time snapshots of data volumes.
      • Snapshots can then be used to create volumes and attached to running instances
      • Snapshots can be copied across regions for cross-region DR
    • AWS Storage Gateway
      • a service that provides seamless and highly secure integration between on-premises IT environment and the storage infrastructure of AWS.
      • Supports File Gateway (S3 File Gateway, FSx File Gateway), Volume Gateway (cached and stored), and Tape Gateway
    • AWS Snow Family (formerly AWS Import/Export)
      • accelerates moving large amounts of data into and out of AWS by using portable storage devices for transport bypassing the Internet
      • ⚠️ Important: Effective November 7, 2025, AWS Snowball Edge devices are only available to existing customers. New customers should explore:
        • AWS DataSync – for online data transfers
        • AWS Data Transfer Terminal – secure physical locations for high-speed data upload using 100 GbE connections
        • AWS Partner solutions – for specialized transfer needs
    • AWS Backup
      • Fully managed service that centralizes and automates data protection across AWS services and hybrid workloads
      • Define central backup policies (backup plans) that work across compute, storage, and database services
      • Supports cross-region and cross-account backup for DR
      • Provides ransomware detection and recovery capabilities
      • Includes compliance insights and analytics for data protection policies
  3. Compute
    • Amazon EC2
      • provides resizable compute capacity in the cloud which can be easily created and scaled.
      • EC2 instance creation using Preconfigured AMIs
      • EC2 instances can be launched in multiple AZs, which are engineered to be insulated from failures in other AZs
  4. Networking
    • Amazon Route 53
      • is a highly available and scalable DNS web service
      • includes a number of global load-balancing capabilities that can be effective when dealing with DR scenarios for e.g. DNS endpoint health checks and the ability to failover between multiple endpoints
    • Amazon Route 53 Application Recovery Controller (ARC)
      • Provides readiness checks and routing controls to manage application failover across AZs and Regions
      • Zonal Shift – temporarily moves traffic away from an impaired Availability Zone within minutes
      • Zonal Autoshift – AWS automatically shifts traffic away from an AZ when a potential failure is detected
      • No additional charge for zonal autoshift
    • Elastic IP
      • addresses enables masking of instance or Availability Zone failures by programmatically remapping
      • addresses are static IP addresses designed for dynamic cloud computing.
    • Elastic Load Balancing (ELB)
      • performs health checks and automatically distributes incoming application traffic across multiple EC2 instances
    • Amazon Virtual Private Cloud (Amazon VPC)
      • allows provisioning of a private, isolated section of the AWS cloud where resources can be launched in a defined virtual network
    • Amazon Direct Connect
      • makes it easy to set up a dedicated network connection from on-premises environment to AWS
  5. Databases
    • RDS, DynamoDB, Redshift provided as a fully managed RDBMS, NoSQL and data warehouse solutions which can scale up easily
    • DynamoDB offers global tables with multi-region, active-active replication
    • RDS provides Multi-AZ and Read Replicas and also ability to snapshot data from one region to other
    • Amazon Aurora Global Database provides cross-region replication with RPO typically measured in seconds and RTO in under a minute for failover
  6. Deployment Orchestration
    • CloudFormation
      • gives developers and systems administrators an easy way to create a collection of related AWS resources and provision them in an orderly and predictable fashion
      • Infrastructure as Code (IaC) enables rapid re-creation of environments in DR regions
    • Elastic Beanstalk
      • is an easy-to-use service for deploying and scaling web applications and services
    • OpsWorks (EOL – May 26, 2024)
      • ⚠️ AWS OpsWorks reached End of Life on May 26, 2024 and has been disabled for both new and existing customers.
      • The OpsWorks console, API, CLI, and CloudFormation resources have been discontinued in all AWS Regions.
      • Migration alternatives: AWS Systems Manager, AWS CloudFormation, AWS CDK, or third-party tools like Ansible, Puppet, or Chef directly.
  7. Disaster Recovery Services
    • AWS Elastic Disaster Recovery (AWS DRS)
      • Minimizes downtime and data loss with fast, reliable recovery of on-premises and cloud-based applications
      • Achieves RPOs in seconds and RTOs in minutes (typically 5-20 minutes)
      • Uses lightweight staging environment with minimal resources to keep costs down
      • Supports automated failover and failback
      • Supports physical, VMware vSphere, Microsoft Hyper-V, and cloud infrastructure sources
      • Provides point-in-time recovery capability for ransomware protection
      • Supports servers with up to 60 volumes
      • Supports AWS Outposts for on-premises recovery
      • Note: AWS DRS replaced CloudEndure Disaster Recovery (CEDR), which was discontinued on March 31, 2024
    • AWS Resilience Hub
      • Central location to define resilience goals, assess resilience posture, and implement recommendations
      • Continuously validates and tracks the resilience of AWS workloads
      • Assesses whether RTO and RPO targets can be met
      • Provides automated DR testing and compliance reporting
      • Integrates with AWS Well-Architected Framework for improvement recommendations
      • Next generation (GA May 2026) includes generative AI-based SRE resilience journey

Key factors for Disaster Planning

Disaster Recovery RTO RPO Defination

Recovery Time Objective (RTO) – The time it takes after a disruption to restore a business process to its service level, as defined by the operational level agreement (OLA) for e.g. if the RTO is 1 hour and disaster occurs @ 12:00 p.m (noon), then the DR process should restore the systems to an acceptable service level within an hour i.e. by 1:00 p.m

Recovery Point Objective (RPO) – The acceptable amount of data loss measured in time before the disaster occurs. for e.g., if a disaster occurs at 12:00 p.m (noon) and the RPO is one hour, the system should recover all data that was in the system before 11:00 a.m.

Disaster Recovery Scenarios

  • Disaster Recovery scenarios can be implemented with the Primary infrastructure running in your data center in conjunction with the AWS
  • Disaster Recovery Scenarios still apply if Primary site is running in AWS using AWS multi region feature.
  • Combination and variation of the below is always possible.
  • Use AWS Resilience Hub to continuously validate and track the resilience of your workloads, including whether you are likely to meet your RTO and RPO targets.

Disaster Recovery Scenarios Options

  1. Backup & Restore (Data backed up and restored)
  2. Pilot Light (Only Minimal critical functionalities)
  3. Warm Standby (Fully Functional Scaled down version)
  4. Multi-Site Active/Active

For the DR scenarios options, RTO and RPO reduces with an increase in Cost as you move from Backup & Restore option (left) to Multi-Site option (right)

Note: For a disaster event based on disruption or loss of one physical data center for a well-architected, highly available workload, you may only require a backup and restore approach. If your definition of a disaster goes beyond the disruption of a physical data center to that of a Region or if you are subject to regulatory requirements, then consider Pilot Light, Warm Standby, or Multi-Site Active/Active.

Backup & Restore

AWS can be used to backup the data in a cost effective, durable and secure manner as well as recover the data quickly and reliably.

Backup phase

In most traditional environments, data is backed up to tape and sent off-site regularly taking longer time to restore the system in the event of a disruption or disasterBackup Restore - Backup Phase

  1. Amazon S3 can be used to backup the data and perform a quick restore and is also available from any location
  2. AWS Snow Family (for existing customers) or AWS Data Transfer Terminal (for new customers) can be used to transfer large data sets bypassing the Internet
  3. Amazon S3 Glacier storage classes can be used for archiving data – use S3 Glacier Flexible Retrieval for hours or S3 Glacier Instant Retrieval for millisecond access
  4. AWS Storage Gateway enables snapshots (used to created EBS volumes) of the on-premises data volumes to be transparently copied into S3 for backup. It can be used either as a backup solution (Volume Gateway – stored volumes) or as a primary data store (Volume Gateway – cached volumes)
  5. AWS Direct Connect can be used to transfer data directly from On-Premise to Amazon consistently and at high speed
  6. Snapshots of Amazon EBS volumes, Amazon RDS databases, and Amazon Redshift data warehouses can be stored in Amazon S3
  7. AWS Backup can centrally manage backup policies across all AWS services with automated scheduling, retention management, and cross-region/cross-account copying

Restore phase

Data backed up then can be used to quickly restore and create Compute and Database instances

Backup Restore - Recovery PhaseKey steps for Backup and Restore:
1. Select an appropriate tool or method to back up the data into AWS.
2. Ensure an appropriate retention policy for this data.
3. Ensure appropriate security measures are in place for this data, including encryption and access policies.
4. Regularly test the recovery of this data and the restoration of the system.

Pilot Light

In a Pilot Light Disaster Recovery scenario option a minimal version of an environment is always running in the cloud, which basically host the critical functionalities of the application for e.g. databases

In this approach :-

  1. Maintain a pilot light by configuring and running the most critical core elements of your system in AWS for e.g. Databases where the data needs to be replicated and kept updated.
  2. During recovery, a full-scale production environment, for e.g. application and web servers, can be rapidly provisioned (using preconfigured AMIs and EBS volume snapshots) around the critical core
  3. For Networking, either a ELB to distribute traffic to multiple instances and have DNS point to the load balancer or preallocated Elastic IP address with instances associated can be used
  4. AWS Elastic Disaster Recovery (DRS) can automate the pilot light approach with continuous replication and rapid failover capabilities
Preparation phase steps :
  1. Set up Amazon EC2 instances or RDS instances to replicate or mirror data critical data
  2. Ensure that all supporting custom software packages available in AWS.
  3. Create and maintain AMIs of key servers where fast recovery is required.
  4. Regularly run these servers, test them, and apply any software updates and configuration changes.
  5. Consider automating the provisioning of AWS resources.
  6. Use AWS Resilience Hub to validate your DR posture and ensure RTO/RPO targets can be met.
Pilot Light Scenario - Preparation Phase

Recovery Phase steps :

  1. Start the application EC2 instances from your custom AMIs.
  2. Resize existing database/data store instances to process the increased traffic for e.g. If using RDS, it can be easily scaled vertically while EC2 instances can be easily scaled horizontally
  3. Add additional database/data store instances to give the DR site resilience in the data tier for e.g. turn on Multi-AZ for RDS to improve resilience.
  4. Change DNS to point at the Amazon EC2 servers.
  5. Install and configure any non-AMI based systems, ideally in an automated way.

Pilot Light Scenario - Recovery Phase

Warm Standby

  • In a Warm standby DR scenario a scaled-down version of a fully functional environment identical to the business critical systems is always running in the cloud
  • This setup can be used for testing, quality assurances or for internal use.
  • In case of an disaster, the system can be easily scaled up or out to handle production load.

Preparation phase steps :

  1. Set up Amazon EC2 instances to replicate or mirror data.
  2. Create and maintain AMIs for faster provisioning
  3. Run the application using a minimal footprint of EC2 instances or AWS infrastructure.
  4. Patch and update software and configuration files in line with your live environment.

Warm Standby - Preparation PhaseRecovery phase Steps:

  1. Increase the size of the Amazon EC2 fleets in service with the load balancer (horizontal scaling).
  2. Start applications on larger Amazon EC2 instance types as needed (vertical scaling).
  3. Either manually change the DNS records, or use Route 53 automated health checks to route all the traffic to the AWS environment.
  4. Consider using Auto Scaling to right-size the fleet or accommodate the increased load.
  5. Add resilience or scale up your database to guard against DR going down

Warm Standby - Recovery Phase

Multi-Site Active/Active

  • Multi-Site is an active-active configuration DR approach, where in an identical solution runs on AWS as your on-site infrastructure.
  • Traffic can be equally distributed to both the infrastructure as needed by using DNS service weighted routing approach.
  • In case of a disaster the DNS can be tuned to send all the traffic to the AWS environment and the AWS infrastructure scaled accordingly.
  • Route 53 Application Recovery Controller (ARC) can manage failover with readiness checks and routing controls for multi-site architectures.

Preparation phase steps :

  1. Set up your AWS environment to duplicate the production environment.
  2. Set up DNS weighting, or similar traffic routing technology, to distribute incoming requests to both sites.
  3. Configure automated failover to re-route traffic away from the affected site. for e.g. application to check if primary DB is available if not then redirect to the AWS DB
Multi-Site - Preparation Phase

Recovery phase steps :

  1. Either manually or by using DNS failover, change the DNS weighting so that all requests are sent to the AWS site.
  2. Have application logic for failover to use the local AWS database servers for all queries.
  3. Consider using Auto Scaling to automatically right-size the AWS fleet.Multi-Site - Recovery Phase

AWS Elastic Disaster Recovery (AWS DRS)

  • AWS Elastic Disaster Recovery (DRS) is the primary AWS service for disaster recovery, replacing CloudEndure Disaster Recovery which was discontinued in March 2024.
  • Provides continuous block-level replication of source servers to a lightweight staging area in the target AWS Region
  • Achieves RPOs in seconds and RTOs in minutes (typically 5-20 minutes)
  • Uses cost-effective AWS resources – you only pay for the full recovery site during drills or actual recovery
  • Supports recovery from:
    • Physical infrastructure (on-premises)
    • VMware vSphere environments
    • Microsoft Hyper-V workloads
    • Other cloud providers (e.g., Azure to AWS)
    • AWS EC2 instances (cross-region DR)
  • Point-in-time recovery – launch previous versions of servers from before a ransomware attack without paying ransom
  • Automated failover and failback – reduces RTO and eliminates manual intervention
  • Supports source servers with up to 60 volumes
  • Supports AWS Outposts for on-premises DR targets
  • Integrates with AWS CloudTrail, IAM, and CloudWatch for security and monitoring
  • Can be used alongside any DR scenario (Pilot Light, Warm Standby, Multi-Site) for automated recovery

AWS Resilience Hub

  • Central service for defining resilience goals, assessing resilience posture, and implementing improvements
  • Continuously validates and tracks whether workloads can meet defined RTO and RPO targets
  • Provides automated resilience assessments based on the AWS Well-Architected Framework
  • Generates compliance evidence for auditors without manually spinning up DR environments
  • Detects drift in infrastructure and triggers remediation
  • Sends notifications to operators to launch recovery processes during outages
  • Available at no additional charge in the AWS Management Console
  • Supports multi-account application resilience assessment
  • Next Generation (GA May 2026): Includes generative AI-based SRE resilience journey for structured alignment on resilience policy expectations

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of these Disaster Recovery options costs the least?
    1. Pilot Light (most systems are down and brought up only after disaster)
    2. Fully Working Low capacity Warm standby
    3. Multi site Active-Active
  2. Your company currently has a 2-tier web application running in an on-premises data center. You have experienced several infrastructure failures in the past two months resulting in significant financial losses. Your CIO is strongly agreeing to move the application to AWS. While working on achieving buy-in from the other company executives, he asks you to develop a disaster recovery plan to help improve Business continuity in the short term. He specifies a target Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 1 hour or less. He also asks you to implement the solution within 2 weeks. Your database is 200GB in size and you have a 20Mbps Internet connection. How would you do this while minimizing costs?
    1. Create an EBS backed private AMI which includes a fresh install or your application. Setup a script in your data center to backup the local database every 1 hour and to encrypt and copy the resulting file to an S3 bucket using multi-part upload (while AMI is a right approach to keep cost down, Upload to S3 very Slow)
    2. Install your application on a compute-optimized EC2 instance capable of supporting the application’s average load synchronously replicate transactions from your on-premises database to a database instance in AWS across a secure Direct Connect connection. (EC2 running in Compute Optimized as well as Direct Connect is expensive to start with also Direct Connect cannot be implemented in 2 weeks)
    3. Deploy your application on EC2 instances within an Auto Scaling group across multiple availability zones asynchronously replicate transactions from your on-premises database to a database instance in AWS across a secure VPN connection. (While VPN can be setup quickly asynchronous replication using VPN would work, running instances in DR is expensive)
    4. Create an EBS backed private AMI that includes a fresh install of your application. Develop a CloudFormation template which includes your AMI and the required EC2. Auto-Scaling and ELB resources to support deploying the application across Multiple Availability Zones. Asynchronously replicate transactions from your on-premises database to a database instance in AWS across a secure VPN connection. (Pilot Light approach with only DB running and replicate while you have preconfigured AMI and autoscaling config. Note: Today, AWS Elastic Disaster Recovery (DRS) could also achieve this more easily with automated failover.)
  3. You are designing an architecture that can recover from a disaster very quickly with minimum down time to the end users. Which of the following approaches is best?
    1. Leverage Route 53 health checks to automatically fail over to backup site when the primary site becomes unreachable
    2. Implement the Pilot Light DR architecture so that traffic can be processed seamlessly in case the primary site becomes unreachable
    3. Implement either Fully Working Low Capacity Standby or Multi-site Active-Active architecture so that the end users will not experience any delay even if the primary site becomes unreachable
    4. Implement multi-region architecture to ensure high availability
  4. Your customer wishes to deploy an enterprise application to AWS that will consist of several web servers, several application servers and a small (50GB) Oracle database. Information is stored, both in the database and the file systems of the various servers. The backup system must support database recovery, whole server and whole disk restores, and individual file restores with a recovery time of no more than two hours. They have chosen to use RDS Oracle as the database. Which backup architecture will meet these requirements?
    1. Backup RDS using automated daily DB backups. Backup the EC2 instances using AMIs and supplement with file-level backup to S3 using traditional enterprise backup software to provide file level restore (RDS automated backups with file-level backups can be used. Note: AWS Backup can now centrally manage all of these backups.)
    2. Backup RDS using a Multi-AZ Deployment Backup the EC2 instances using AMIs, and supplement by copying file system data to S3 to provide file level restore (Multi-AZ is more of a High Availability solution, not a backup solution)
    3. Backup RDS using automated daily DB backups. Backup the EC2 instances using EBS snapshots and supplement with file-level backups to Amazon S3 Glacier using traditional enterprise backup software to provide file level restore (S3 Glacier Flexible Retrieval (formerly Glacier) retrieval time may not meet the 2 hours RTO depending on retrieval option selected)
    4. Backup RDS database to S3 using Oracle RMAN. Backup the EC2 instances using AMIs, and supplement with EBS snapshots for individual volume restore. (Will use RMAN only if Database hosted on EC2 and not when using RDS)
  5. Which statements are true about the Pilot Light Disaster recovery architecture pattern?
    1. Pilot Light is a hot standby (Cold Standby)
    2. Enables replication of all critical data to AWS
    3. Very cost-effective DR pattern
    4. Can scale the system as needed to handle current production load
  6. An ERP application is deployed across multiple AZs in a single region. In the event of failure, the Recovery Time Objective (RTO) must be less than 3 hours, and the Recovery Point Objective (RPO) must be 15 minutes. The customer realizes that data corruption occurred roughly 1.5 hours ago. What DR strategy could be used to achieve this RTO and RPO in the event of this kind of failure?
    1. Take hourly DB backups to S3, with transaction logs stored in S3 every 5 minutes
    2. Use synchronous database master-slave replication between two availability zones. (Replication won’t help to backtrack and would be sync always)
    3. Take hourly DB backups to EC2 Instance store volumes with transaction logs stored In S3 every 5 minutes. (Instance store not a preferred storage)
    4. Take 15 minute DB backups stored in S3 Glacier with transaction logs stored in S3 every 5 minutes. (S3 Glacier Flexible Retrieval does not meet the RTO)
  7. Your company’s on-premises content management system has the following architecture:
    – Application Tier – Java code on a JBoss application server
    – Database Tier – Oracle database regularly backed up to Amazon Simple Storage Service (S3) using the Oracle RMAN backup utility
    – Static Content – stored on a 512GB gateway stored Storage Gateway volume attached to the application server via the iSCSI interface

    Which AWS based disaster recovery strategy will give you the best RTO?

    1. Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Generate an EBS volume of static content from the Storage Gateway and attach it to the JBoss EC2 server.
    2. Deploy the Oracle database on RDS. Deploy the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3 Glacier. Generate an EBS volume of static content from the Storage Gateway and attach it to the JBoss EC2 server. (S3 Glacier retrieval does not help to give best RTO)
    3. Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Restore the static content by attaching an AWS Storage Gateway running on Amazon EC2 as an iSCSI volume to the JBoss EC2 server. (No need to attach the Storage Gateway as an iSCSI volume can just create an EBS volume)
    4. Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Restore the static content from an AWS Storage Gateway-VTL running on Amazon EC2 (VTL is Virtual Tape library and doesn’t fit the RTO)
  8. [New] A company wants to implement disaster recovery for their on-premises application with an RPO of seconds and RTO of minutes. They want to minimize idle DR resources and costs. Which AWS service should they use?
    1. AWS Backup with cross-region copy (AWS Backup provides RPO in hours, not seconds)
    2. AWS Elastic Disaster Recovery (DRS) (DRS provides RPO in seconds and RTO in minutes using continuous replication with minimal staging resources)
    3. Amazon S3 Cross-Region Replication with CloudFormation templates (This is a Backup & Restore approach, not suitable for seconds RPO)
    4. Multi-Site Active-Active with Route 53 failover (Achieves the RPO/RTO but does not minimize costs – full duplicate environment runs at all times)
  9. [New] Which AWS service provides a centralized way to define resilience goals, assess whether applications can meet their RTO and RPO targets, and provides recommendations for improvement?
    1. AWS CloudWatch
    2. AWS Config
    3. AWS Resilience Hub (Resilience Hub provides centralized resilience assessment, RTO/RPO validation, and improvement recommendations based on the Well-Architected Framework)
    4. AWS Systems Manager
  10. [New] A company wants to automatically shift traffic away from an impaired Availability Zone without manual intervention. Which AWS service provides this capability?
    1. Amazon Route 53 weighted routing
    2. AWS Global Accelerator
    3. Amazon Route 53 Application Recovery Controller (ARC) with Zonal Autoshift (ARC Zonal Autoshift automatically moves traffic away from an AZ when AWS detects a potential failure, at no additional charge)
    4. Elastic Load Balancing cross-zone load balancing

References