Unit 1: Cloud Fundamentals and Security

I. Orientation

Cloud disaster recovery (DR) is the design of systems that continue operating or can be restored after failures involving infrastructure, software, data, regions, or human actions. AWS resilience planning connects business requirements to measurable recovery objectives and uses managed services to reduce recovery effort.

• Recovery Point Objective (RPO): The maximum acceptable data loss measured in time; an RPO of 5 minutes requires data replication or backups at least every 5 minutes.
• Recovery Time Objective (RTO): The maximum acceptable service restoration time; an RTO of 30 minutes permits longer recovery than an RTO of 2 minutes.
• Durability: The probability that stored data will not be lost, commonly improved through replication, versioning, and independent copies.
• Availability: The proportion of time a service is usable; multi-AZ deployment improves availability but does not automatically provide regional disaster recovery.
• Blast radius: The set of resources affected by one failure; separate accounts, Availability Zones (AZs), and Regions reduce shared blast radius.
• Shared responsibility: AWS secures the underlying cloud infrastructure, while customers configure identity, data protection, applications, monitoring, and recovery procedures.
• Resilience principle: Recovery architecture should be tested, automated, observable, and matched to the business value of the workload.

II. AWS-Native Disaster Recovery Mechanisms and Service Orchestration for Data Durability and Operational Resilience

A. Purpose and operating model

AWS-native DR combines durable storage, replicated infrastructure, health detection, and automated recovery workflows. Service orchestration coordinates these components so that recovery is a repeatable process rather than a collection of manual actions.

B. AWS-native disaster recovery mechanisms and service orchestration for data durability and operational resilience

• Durable storage: Amazon S3 provides multi-AZ object durability by default; S3 Versioning preserves prior object versions, while S3 Object Lock can prevent deletion during a defined retention period.
• Database protection: Amazon RDS automated backups support point-in-time recovery. Read replicas and Amazon Aurora Global Database provide lower-latency replication to another Region, although cross-Region replication is generally asynchronous.
• Block and file recovery: Amazon EBS snapshots are incremental and stored in Amazon S3. AWS Backup centrally manages backup plans, retention rules, vaults, and cross-Region or cross-account copies for supported services.
• Compute reconstruction: Amazon Machine Images (AMIs), launch templates, and infrastructure-as-code tools such as AWS CloudFormation allow EC2 capacity to be recreated consistently.
• DNS failover: Amazon Route 53 health checks and failover routing can direct users from an unhealthy primary endpoint to a recovery endpoint. DNS time-to-live (TTL) affects how quickly clients observe the change.
• Health detection: Elastic Load Balancing, Amazon CloudWatch alarms, AWS Health events, and application-level checks identify failed instances, unhealthy targets, or degraded services.
• Workflow coordination: AWS Systems Manager Automation, AWS Step Functions, and AWS Lambda can sequence tasks such as restoring a database, deploying compute, updating configuration, and changing Route 53 records.
• Access control: AWS Identity and Access Management (IAM), AWS Organizations, Service Control Policies, and separate recovery accounts limit who can alter backups or execute failover operations.
• Auditability: AWS CloudTrail records API activity, while AWS Config evaluates resource configuration. Together they help prove that backup and recovery controls are operating as designed.
• Operational testing: AWS Fault Injection Service can introduce controlled failures, and recovery drills can measure actual RTO, RPO, alarm behavior, and runbook correctness.

C. Applications and limitations

• Application dependency order: A typical workflow restores networking and secrets, then databases, application services, and public routing; starting the web tier before its database may produce an apparently healthy but unusable service.
• Automation boundary: Automation can repeat known actions, but ambiguous data corruption or security incidents may require human approval before failover.
• Cost trade-off: Cross-Region replicas and continuously running recovery capacity cost more than periodic backups; protection should reflect business impact.
• Consistency requirement: Replication does not guarantee application-consistent data unless transactions, queues, and dependent services are coordinated.

III. Recovery Architecture Pattern: Backup and Restore

A. Definition and operating principle

Backup and Restore stores recoverable copies of data and reconstructs the environment only after a disaster. It is the least expensive major DR pattern, but normally has the highest RTO because infrastructure and services must be provisioned during recovery.

B. Recovery architecture pattern: Backup and Restore

• Backup creation: AWS Backup can run scheduled backups, such as daily RDS snapshots and weekly EBS snapshots, under a centralized backup plan.
• Independent copies: Cross-Region and cross-account copies protect against Region failure, accidental deletion, and compromised production credentials. The recovery account should restrict deletion permissions.
• Data restoration: S3 objects can be restored directly or from archived storage classes. RDS point-in-time recovery creates a new database instance from transaction logs and a selected timestamp.
• Environment rebuilding: CloudFormation templates, AMIs, container images, and parameter stores define the application environment. Rebuilding from declarations reduces configuration drift.
• Traffic recovery: After validation, Route 53 can change the DNS record or failover policy to expose the recovered endpoint.
• RPO and RTO relationship: If backups run every 24 hours, the theoretical maximum backup-based RPO is approximately 24 hours, while restoration duration determines RTO.
• Worked example: A service with a 4-hour RTO may accept nightly backups. During a regional outage, the team copies the latest recovery-point data, deploys the stack in a second Region, restores RDS, validates the application, and changes Route 53 routing.

C. Applications and limitations

• Best fit: Backup and Restore suits development systems, low-criticality applications, compliance archives, and workloads whose business can tolerate hours of downtime.
• Primary limitation: Recovery capacity is absent or minimal before the incident, so restoring large databases, container images, and network dependencies may take substantial time.
• Security limitation: A backup is not useful if it is encrypted with unavailable keys or controlled by the same compromised account; retain protected copies and test key recovery.
• Testing requirement: A backup job marked “successful” does not prove recoverability. Periodic restoration tests must verify data integrity and application startup.

IV. Recovery Architecture Pattern: Pilot Light

A. Definition and operating principle

Pilot Light keeps the most essential components continuously available, usually replicated data and core configuration, while application and compute capacity remains stopped or minimal. During failure, the remaining infrastructure is activated and scaled.

B. Recovery architecture pattern: Pilot Light

• Minimal running core: A cross-Region Aurora replica, RDS read replica, or replicated data store acts as the continuously maintained foundation; it is the “pilot light” that enables rapid expansion.
• Infrastructure readiness: VPCs, subnets, security groups, IAM roles, KMS keys, and CloudFormation stacks are prepared in the recovery Region even when EC2 instances are not running.
• Activation sequence: Promote the database if required, deploy application instances through an Auto Scaling group, load configuration from Systems Manager Parameter Store, and register targets with the load balancer.
• Replication behavior: Asynchronous replication can leave recent transactions behind the primary. The actual RPO depends on replication lag and the point at which the secondary becomes authoritative.
• Routing: Route 53 failover or an application global-routing service directs traffic after health checks confirm that the recovery stack is ready.
• Worked example: An order system maintains an Aurora Global Database secondary in another Region. After primary failure, automation promotes the secondary, launches the application tier from an AMI, runs smoke tests, and switches the database endpoint and DNS routing.

C. Applications and limitations

• Best fit: Pilot Light is appropriate when data loss must be limited but the business can wait for compute activation, often producing an RTO of minutes to hours.
• Capacity risk: A dormant environment may expose scaling, quota, image, or dependency problems during an emergency; recovery capacity and service quotas should be rehearsed.
• Configuration risk: If application versions and infrastructure templates are not kept current, the recovery Region may contain accurate data but incompatible software.
• Operational distinction: Pilot Light has core components running; it is faster than Backup and Restore but slower than Warm Standby because most serving capacity is created during failover.

V. Recovery Architecture Pattern: Warm Standby

A. Definition and operating principle

Warm Standby maintains a reduced but functional copy of the production system in a recovery Region. It continuously receives data and can serve limited traffic, then scales to normal capacity during a disaster.

B. Recovery architecture pattern: Warm Standby

• Reduced capacity: The recovery environment may run two application instances where production runs ten, or use smaller instance types. It must still contain all critical tiers and dependencies.
• Continuous readiness: Load balancers, compute, databases, queues, secrets, monitoring, and deployment artifacts remain configured and operational rather than being created from zero.
• Scaling action: Auto Scaling policies or deployment automation increases capacity after failover. Scaling limits should account for the recovery Region’s quotas and available instance types.
• Data synchronization: Aurora Global Database, DynamoDB global tables, S3 replication, or application-level replication can maintain current data, with conflict and consistency behavior understood in advance.
• Traffic transition: Route 53 health checks, Global Accelerator, or another global entry point can shift traffic while the warm environment is scaled and verified.
• Worked example: A customer portal runs at 25% capacity in a second Region, with Aurora replication and synchronized S3 assets. During a primary outage, the database is promoted if necessary, Auto Scaling raises capacity, and Global Accelerator sends users to the recovery Region.
• Operational readiness: Monitoring and patching must cover the standby environment; an unpatched warm system can fail for a second reason during the original incident.

C. Applications and limitations

• Best fit: Warm Standby suits important production services requiring an RTO of minutes and a lower RPO than backup-only designs.
• Cost balance: It costs more than Pilot Light because compute and supporting services run continuously, but it generally provides faster and more predictable recovery.
• Capacity limitation: Reduced standby capacity may not handle a sudden full workload until scaling completes; admission control, queueing, or temporary feature reduction may be needed.
• Consistency limitation: Readiness does not eliminate data replication lag or application session issues. Stateless sessions, shared caches, and idempotent operations simplify regional transition.

VI. Recovery Architecture Pattern: Multi-Site (Active-Active) Configurations

A. Definition and operating principle

Multi-Site (Active-Active) configurations run production workloads in two or more Regions at the same time. Traffic is distributed across healthy sites, so a failed site is removed from service rather than started from a dormant state.

B. Recovery architecture pattern: Multi-Site (Active-Active) configurations

• Traffic distribution: Route 53 latency, weighted, or geolocation routing can distribute requests; AWS Global Accelerator provides static anycast IP addresses and health-based regional routing.
• Independent failure domains: Each Region should have separate networking, compute, data services, deployment pipelines, and operational monitoring so one failure does not disable all sites.
• Data model: DynamoDB global tables support multi-Region, multi-active writes with defined conflict-resolution behavior. Other databases may use single-writer replication, partitioned ownership, or application-level conflict handling.
• Stateless application design: User sessions should be stored in a replicated service such as DynamoDB or ElastiCache with an appropriate architecture, rather than only in one Region’s instance memory.
• Deployment discipline: Blue/green or canary releases must be applied consistently across active Regions; a defective release can otherwise create a global outage.
• Failure handling: Health checks remove unhealthy targets, while queues, retries, circuit breakers, and idempotency prevent a failed Region from causing duplicate or uncontrolled requests.
• Worked example: A global API runs in two Regions behind Global Accelerator. DynamoDB global tables replicate customer records, each Region processes traffic, and health checks withdraw one Region’s endpoints when its application checks fail.
• RPO and RTO: With synchronous or near-real-time multi-site data handling, RPO can approach zero for some operations, and RTO can be seconds or minutes; actual values depend on detection, routing, and consistency design.

C. Applications and limitations

• Best fit: Active-active is justified for mission-critical services where prolonged downtime is unacceptable and the organization can fund complex operations.
• Consistency challenge: Concurrent writes can conflict, especially for inventory, payments, or account balances. Conflict resolution must be explicit and tested rather than assumed.
• Cost and complexity: Multiple full environments, replicated data, global observability, and cross-Region networking create the highest operating cost and maintenance burden.
• Failure-isolation requirement: A shared identity provider, deployment pipeline, encryption key, or control-plane dependency can become a hidden single point of failure.
• Testing requirement: Regular regional evacuation exercises should verify traffic withdrawal, data convergence, replay safety, capacity, and restoration of the failed site.