Unit 1: Cloud Fundamentals and Security - Subjective Questions

Disaster recovery (DR) is the set of policies, architectures, tools, and procedures used to restore applications and data after an outage, cyberattack, data corruption event, or regional disaster.

• Recovery Time Objective (RTO): The maximum acceptable time required to restore a service after disruption.
• Recovery Point Objective (RPO): The maximum acceptable amount of data loss measured in time.
• Data durability: The probability that stored data remains intact and retrievable over time. AWS improves durability through redundant storage across devices and Availability Zones.
• Operational resilience: The ability of a workload to continue operating or recover quickly when failures occur.

If a failure occurs at time and the latest recoverable copy was created at , then the actual recovery point gap is:

A successful recovery design should satisfy:

Similarly, if the service is restored at time , then:

The selected DR pattern must ensure that both actual values remain within business-approved targets.

AWS-native services can be combined into a coordinated recovery workflow:

• Amazon S3: Stores durable backups, supports versioning, lifecycle policies, Object Lock, and cross-Region replication.
• AWS Backup: Centrally manages backup plans, schedules, retention periods, vaults, and cross-account or cross-Region copies.
• Amazon EBS snapshots: Protect block-storage volumes through incremental snapshots.
• Amazon RDS and Amazon Aurora: Provide automated backups, snapshots, Multi-AZ deployment, read replicas, and cross-Region replication.
• AWS Elastic Disaster Recovery: Replicates servers and enables rapid recovery in a staging area.
• Amazon Route 53: Performs health checks and redirects traffic to healthy endpoints.
• Elastic Load Balancing and Auto Scaling: Distribute requests and replace or scale failed compute resources.
• AWS CloudFormation or AWS CDK: Re-create infrastructure consistently through Infrastructure as Code.
• AWS Step Functions, Lambda, and Systems Manager Automation: Coordinate restoration, validation, scaling, and failover steps.
• Amazon CloudWatch and AWS CloudTrail: Provide monitoring, alarms, audit records, and operational visibility.

The services should be orchestrated so that failure detection triggers an approved recovery workflow, resources are restored in dependency order, data integrity is validated, and traffic is redirected only after health checks succeed.

In the Backup and Restore pattern, application data, system configurations, and infrastructure definitions are backed up and stored in a secure recovery location. Most application infrastructure in the recovery Region is not continuously running.

Recovery process:

1. Detect and declare the disaster.
2. Provision networking, compute, security, and platform services in the recovery Region.
3. Restore databases, file systems, and storage volumes from backups.
4. Deploy application code and configuration.
5. Validate application and data integrity.
6. Redirect users to the restored environment.

Advantages:

• Lowest ongoing infrastructure cost among the four major DR patterns.
• Suitable for non-critical systems with relaxed RTO and RPO requirements.
• Provides long-term recovery from logical corruption or ransomware.
• Can use immutable, cross-account, and cross-Region backups.

Limitations:

• Usually has the highest RTO because infrastructure and data must be restored.
• RPO depends on backup frequency.
• Restoration of large datasets can take significant time.
• Recovery may fail if backups and runbooks are not tested regularly.

This pattern is appropriate when cost is more important than immediate recovery.

A Backup and Restore implementation plan can include the following stages:

1. Classify resources: Identify critical databases, EBS volumes, file systems, S3 buckets, configurations, and application artifacts.
2. Define objectives: Assign RTO, RPO, retention, compliance, and recovery priority to each workload.
3. Configure AWS Backup: Create backup plans, schedules, lifecycle rules, vaults, and resource assignments.
4. Protect storage: Enable S3 Versioning, Object Lock where required, EBS snapshots, RDS automated backups, and database snapshots.
5. Copy backups: Use cross-Region and cross-account backup copies to reduce correlated risk.
6. Secure recovery points: Apply AWS KMS encryption, least-privilege IAM roles, vault access policies, and Multi-Party Approval where appropriate.
7. Capture infrastructure: Store CloudFormation, AWS CDK, or Terraform templates in a protected source repository.
8. Automate restoration: Use Step Functions, Lambda, or Systems Manager Automation to restore resources in dependency order.
9. Validate recovery: Run integrity checks, application tests, security checks, and business transaction tests.
10. Redirect traffic: Update Route 53 records only after the restored environment passes health checks.
11. Test regularly: Conduct scheduled restore exercises and record achieved RTO and RPO.

The plan must include a documented failback process so that services can later return to the primary Region safely.

AWS Backup is a managed service that centralizes backup configuration and monitoring across supported AWS resources.

• Backup plans: Define backup frequency, backup windows, retention periods, lifecycle transitions, and copy actions.
• Resource assignments: Select protected resources using identifiers, tags, accounts, or organizational policies.
• Backup vaults: Logical containers that store and control access to recovery points.
• Lifecycle rules: Move eligible backups to lower-cost storage and delete them after the required retention period.
• Cross-Region copies: Protect against a complete regional disruption.
• Cross-account copies: Isolate backups from compromise of the workload account.
• Vault Lock: Enforces write-once, read-many controls and prevents unauthorized deletion or retention changes.
• Audit Manager: Evaluates backup activity against organizational policies and compliance requirements.

A strong design uses separate production and backup accounts, AWS KMS encryption, restricted vault policies, centralized monitoring, and regular restore tests. A backup is operationally valuable only if it can be restored within the required RTO and RPO.

These controls ensure that backups are usable, secure, and compliant:

• Backup testing: Confirms that recovery points are complete, uncorrupted, compatible, and restorable within the target RTO.
• Immutability: Prevents backups from being changed or deleted by attackers or accidental administrative actions. AWS Backup Vault Lock and S3 Object Lock can provide this protection.
• Encryption: Protects backup confidentiality at rest and in transit. AWS KMS keys should be available to authorized recovery roles in the recovery account or Region.
• Retention policies: Preserve recovery points for the period required by business and regulatory rules while controlling storage cost.
• Version diversity: Daily, weekly, monthly, and long-term recovery points help recover from corruption that remained undetected for an extended period.
• Isolation: Cross-account storage reduces the risk that one compromised account destroys both production data and backups.

Testing should include file-level restoration, full database restoration, application startup, integrity validation, security validation, and measurement of actual RTO and RPO.

The Pilot Light pattern keeps only the most critical core of an application active in the recovery Region. It is similar to a small flame that can be expanded when needed.

Normally active components may include:

• Continuous or frequent replication of critical data.
• A minimal database deployment or replication target.
• Core networking, IAM roles, security groups, and KMS keys.
• Infrastructure templates, application images, and configuration artifacts.
• Monitoring and replication services.

Components commonly started during failover:

• Application servers and containers.
• Larger database instances or additional replicas.
• Auto Scaling groups and load balancers.
• Supporting services needed for production traffic.

Failover actions:

1. Stop or confirm the status of primary-side writes.
2. Promote replicated data stores where required.
3. Deploy or scale application resources.
4. Apply current configuration and secrets.
5. Run health and integrity tests.
6. Redirect traffic using Route 53 or another traffic-management service.

Pilot Light generally provides lower RTO and RPO than Backup and Restore, but it costs more because replication and core services operate continuously.

Backup and Restore emphasizes economy, whereas Pilot Light balances cost and recovery speed. Pilot Light is not immediately production-ready; compute capacity and other application components must still be activated during failover.

Pilot Light failover can be implemented as an event-driven, controlled workflow:

1. Detect failure: CloudWatch alarms, Route 53 health checks, or external monitoring identify loss of service.
2. Approve disaster declaration: A manual approval or automated policy prevents unnecessary regional failover.
3. Start orchestration: EventBridge invokes Step Functions or Systems Manager Automation.
4. Protect data consistency: The workflow verifies replication lag, blocks unsafe writes, and promotes the recovery database.
5. Deploy infrastructure: CloudFormation or AWS CDK provisions application servers, load balancers, queues, and supporting services.
6. Scale capacity: Auto Scaling groups increase from zero or minimal capacity to the required production capacity.
7. Apply configuration: Systems Manager Parameter Store or Secrets Manager supplies protected configuration and credentials.
8. Validate services: Lambda functions or test runners execute health checks and synthetic transactions.
9. Redirect traffic: Route 53 changes weighted or failover records after validation succeeds.
10. Record and notify: CloudTrail, CloudWatch Logs, SNS, and incident-management tools preserve evidence and notify operators.

The workflow should be idempotent, auditable, and capable of stopping or rolling back if a validation step fails.

In Warm Standby, a complete but reduced-capacity version of the production environment runs continuously in the recovery Region.

Characteristics:

• Application, database, networking, security, and monitoring components are already deployed.
• Data is continuously or frequently replicated from the primary Region.
• The environment can process limited traffic or remain ready for health validation.
• Compute instances, containers, and databases operate at smaller capacity than production.
• During a disaster, the recovery environment is scaled up and becomes the primary environment.

It differs from a normal production deployment because it does not initially have enough capacity to handle the full workload. It also differs from Pilot Light because the complete application stack is already running rather than only the critical data and core services.

Benefits: Lower RTO, frequent validation, and simpler activation than Pilot Light.

Limitations: Higher continuous cost, replication complexity, and the need to ensure that reduced capacity does not prevent successful failover or testing.

Failover procedure:

1. Confirm that the primary environment is unavailable or unsafe.
2. Verify replication status and determine the latest consistent recovery point.
3. Promote the standby database or change the replication role.
4. Increase database, compute, container, and cache capacity.
5. Confirm that queues, secrets, certificates, and dependent services are available.
6. Run health checks and synthetic business transactions.
7. Redirect traffic through Route 53, Global Accelerator, or another routing layer.
8. Monitor errors, latency, capacity, and data consistency.

Failback procedure:

1. Rebuild or repair the original primary environment.
2. Establish replication from the active recovery Region back to the repaired Region.
3. Allow data to synchronize and verify replication lag.
4. Schedule a controlled change window.
5. Quiesce or coordinate writes where required.
6. Reverse the database role and gradually shift traffic.
7. Validate the restored primary environment.
8. Return the recovery environment to reduced standby capacity.

Failback should not be treated as an immediate reversal. It is a planned migration that must preserve transactions and avoid split-brain operation.

Choose Pilot Light when:

• The business needs faster recovery than Backup and Restore.
• Continuous full application operation in a second Region is too expensive.
• Infrastructure can be deployed and scaled reliably through automation.

Choose Warm Standby when:

• Downtime must be limited to a short period.
• The organization can fund an always-running secondary stack.
• The application requires frequent recovery testing or immediate operational validation.

The final selection should be based on measured recovery performance rather than the pattern name alone.

In a Multi-Site Active-Active pattern, two or more sites serve production traffic simultaneously. The sites may be in different AWS Regions to provide resilience against regional failure.

Request-routing requirements:

• Route 53 latency-based, geolocation, geoproximity, weighted, or failover routing can direct clients.
• AWS Global Accelerator can route traffic through the AWS global network to healthy regional endpoints.
• Each site requires independent load balancing, scaling, monitoring, and security controls.
• Health checks must remove unhealthy endpoints without routing traffic to partially failed systems.

Data-management requirements:

• Data must be replicated between active sites.
• The design must define conflict resolution, write ownership, consistency expectations, and behavior during network partitions.
• Services such as DynamoDB global tables or suitable cross-Region database architectures may be used.
• Stateless application tiers and globally unique transaction identifiers simplify operation.

Benefits: Very low RTO, potentially near-zero RPO for supported data designs, continuous resource utilization, and reduced dependence on manual failover.

Challenges: Highest cost and complexity, replication latency, conflict handling, data residency requirements, and risk of propagating logical corruption to every active site.

Amazon Route 53 supports disaster recovery by evaluating endpoint health and controlling DNS responses.

Relevant routing policies:

• Failover routing: Sends traffic to a primary endpoint and uses a secondary endpoint when the primary becomes unhealthy.
• Weighted routing: Distributes traffic according to assigned percentages and supports gradual migration or recovery testing.
• Latency-based routing: Directs users to the Region expected to provide the lowest latency.
• Geolocation routing: Routes users according to their geographic location.
• Geoproximity routing: Adjusts traffic distribution based on resource and user location.
• Multi-value answer routing: Returns multiple healthy records to improve endpoint availability.

Health checks can monitor endpoints directly or use calculated checks that combine multiple signals. CloudWatch alarms may also be associated with health evaluation.

Important limitations include DNS caching and time-to-live values, which can delay traffic changes. Health checks should measure meaningful application functions rather than only network connectivity. For rapid network-level redirection, AWS Global Accelerator may complement Route 53.

Active-Active systems allow concurrent activity in multiple Regions, creating several data challenges:

• Replication latency: A write accepted in one Region may not immediately appear in another.
• Concurrent updates: Two sites may update the same item before replication completes.
• Conflict resolution: The system may use last-writer-wins, version numbers, timestamps, application-defined merging, or a designated write owner.
• Network partitions: Sites may remain available but lose communication, creating divergent data.
• Transaction boundaries: Multi-record or cross-Region transactions are more difficult than local transactions.
• Duplicate processing: Retried requests can produce duplicate events or transactions.
• Logical corruption: Incorrect writes may be replicated rapidly to every active site.

Mitigation techniques include:

• Use globally unique identifiers and idempotency keys.
• Partition data so that each item has a preferred write Region.
• Use conditional writes, version checks, and application-level conflict resolution.
• Design event consumers to be idempotent.
• Monitor replication lag and failed replication events.
• Retain immutable backups for point-in-time recovery.
• Select eventual or strong consistency according to business requirements.

The application must explicitly define how it behaves when consistency, availability, and partition tolerance cannot all be maximized simultaneously.

Selection factors:

• Business-approved RTO and RPO.
• Financial impact of downtime and data loss.
• Infrastructure and operational cost.
• Database replication capabilities.
• Application support for stateless operation and conflict resolution.
• Regulatory, security, and data-residency obligations.
• Team maturity in automation, testing, monitoring, and incident response.

No pattern automatically guarantees a particular RTO or RPO. The actual values must be measured through realistic disaster recovery exercises.

A Pilot Light pattern is generally appropriate because the organization requires faster recovery than a traditional restore process but cannot fund a full active secondary environment.

Recommended architecture:

• Replicate the database continuously or at intervals shorter than 15 minutes.
• Maintain core networking, IAM roles, security groups, KMS keys, and replication components in the recovery Region.
• Store machine images, container images, application packages, and Infrastructure as Code templates in both Regions.
• Configure Auto Scaling groups with zero or minimal capacity where the service permits it.
• Use CloudFormation, Step Functions, Lambda, or Systems Manager Automation to deploy and scale the application.
• Configure Route 53 failover routing and application-level health checks.
• Use AWS Backup for immutable recovery points in addition to replication.
• Run scheduled recovery exercises to verify completion within 30 minutes.

The replication interval must satisfy:

The combined time for disaster declaration, data promotion, infrastructure activation, validation, and traffic redirection must satisfy:

If tests cannot meet this limit, Warm Standby should be considered.

A secure DR architecture should apply layered controls:

• Least-privilege IAM: Recovery roles should have only the permissions needed to copy, restore, promote, scale, and route resources.
• Cross-account isolation: Backups should be copied to a dedicated backup or recovery account to reduce the effect of production-account compromise.
• Encryption: Use AWS KMS for backups, snapshots, databases, queues, and object storage. Key policies must authorize approved recovery roles.
• Key availability: Ensure that encrypted data can be decrypted in the destination account and Region using correctly configured keys.
• Immutable recovery points: Use AWS Backup Vault Lock or S3 Object Lock to resist deletion and ransomware.
• Network security: Re-create VPC segmentation, security groups, network ACLs, private endpoints, and controlled egress.
• Secret protection: Replicate or securely retrieve secrets through Secrets Manager or Systems Manager Parameter Store.
• Audit and detection: Enable CloudTrail, AWS Config, GuardDuty, Security Hub, and centralized log storage.
• Separation of duties: Require independent approval for destructive actions and major failover operations.
• Compliance controls: Apply retention, data-residency, and access policies consistently across Regions and accounts.

Security controls must be tested during DR exercises because unavailable keys, secrets, certificates, or permissions can prevent recovery even when data backups are valid.

Infrastructure as Code (IaC), monitoring, and automated runbooks reduce manual errors and make recovery repeatable.

Infrastructure as Code:

• CloudFormation, AWS CDK, or other tools define networking, compute, databases, security policies, and application dependencies.
• Version-controlled templates provide consistent recovery environments.
• Drift detection identifies unapproved differences between documented and actual infrastructure.

Monitoring:

• CloudWatch metrics, logs, alarms, and dashboards detect failures and replication problems.
• Route 53 health checks evaluate endpoint availability.
• CloudTrail records recovery actions for auditing.
• Backup and replication reports show whether protection objectives are being met.

Automated runbooks:

• Step Functions coordinates multi-step workflows.
• Systems Manager Automation performs operational tasks on AWS resources and instances.
• Lambda executes validation, configuration, or routing actions.
• EventBridge connects alarms and events to approved workflows.

Automation should include checkpoints, retries, timeouts, rollback behavior, notifications, and manual approval for high-risk actions. Runbooks must be tested regularly so that hidden dependencies and obsolete configuration are discovered before a real disaster.

Assume the application contains a web tier, application tier, and relational database tier. A Warm Standby design can provide low RTO and RPO.

Primary Region:

• Route 53 or Global Accelerator directs clients to an Application Load Balancer.
• The web and application tiers run across multiple Availability Zones using EC2 Auto Scaling, ECS, or EKS.
• Amazon RDS or Aurora runs with Multi-AZ protection.
• S3 stores static assets with versioning enabled.
• CloudWatch, CloudTrail, and AWS Config provide monitoring and audit evidence.

Recovery Region:

• A complete VPC, load balancer, application stack, and database environment operate at reduced capacity.
• Database changes are replicated cross-Region using an appropriate database capability.
• S3 data is copied through cross-Region replication where required.
• Container images and application artifacts are available locally.
• AWS Backup creates cross-account, encrypted, immutable recovery points.

Orchestration:

1. Health checks and alarms detect a regional outage.
2. An approved Step Functions workflow verifies replication status.
3. The recovery database is promoted.
4. Auto Scaling increases web and application capacity.
5. Automated tests validate authentication, database access, and business transactions.
6. Route 53 or Global Accelerator redirects traffic.
7. CloudWatch monitors errors, latency, saturation, and replication state.

Resilience and durability:

• Multi-AZ design handles local failures without regional failover.
• Cross-Region replication supports rapid regional recovery.
• Immutable backups protect against corruption and ransomware.
• Infrastructure as Code enables repeatable rebuilding.
• Regular exercises verify RTO, RPO, security, and failback readiness.

The architecture should also document controlled failback, dependency recovery order, escalation procedures, and the business authority responsible for declaring a disaster.