Rpo Rto Confusion — AWS DevOps Engineer (DOP-C02)

When both zero-downtime and a sub-60-second rollback RTO are explicit requirements for an ECS workload, blue/green deployment (retaining the original task set for instant ALB listener re-route) must be chosen over rolling update (which requires launching new tasks to roll back, making rollback latency minutes rather than seconds).

Whether to use CodeDeploy ECS rolling update or CodeDeploy ECS blue/green — the 60-second rollback RTO is the deciding constraint because rolling update has no independent stable target group to atomically reroute to, while blue/green can flip the ALB listener rule back in seconds.

Whether a 90-second rollback RTO can be satisfied by CodeDeploy in-place rolling deployment on EC2 or whether blue/green deployment with ALB traffic rerouting to the original Auto Scaling group is required to meet both the zero-downtime and sub-90-second rollback constraints simultaneously.

Whether to use per-service CodeDeploy blue/green deployments with independent rollback groups — which atomically restore the prior known-good target group (satisfying both rollback initiation speed and clean rollback-destination state) — versus a shared rolling deployment that meets rollback initiation time but restores services to a partially-applied mixed state rather than a clean prior artifact version.

Whether to use per-service CodePipelines with CodeDeploy blue/green traffic shifting or a single shared CodePipeline with CodeDeploy rolling updates — determined by whether the rollback mechanism provides a deterministic sub-2-minute recovery time regardless of fleet size.

Whether to replicate artifacts using CodeArtifact cross-region replication plus ECR cross-region replication — preserving dependency-resolution graphs, package metadata, and image-scan results alongside binaries — or to consolidate onto S3 CRR, which replicates object bytes quickly enough to satisfy the RTO but cannot replicate the metadata layer required to satisfy the 5-minute RPO for full build reproducibility.

Whether CloudFormation StackSets alone satisfies both a self-service provisioning RTO and a continuous drift-detection RPO, or whether two separate services — Service Catalog portfolios for RTO and AWS Config continuous evaluation for RPO — are required because StackSets drift detection is on-demand and provisioning is admin-gated.

Whether to enforce infrastructure parameter guardrails at authoring time (CDK constructs or CloudFormation modules, which harden defaults at synthesis or template-creation time) or at provisioning time (Service Catalog portfolios with launch constraints, which block parameter overrides at the moment a developer initiates a stack deployment) — the scenario's 'no parameter override during provisioning' constraint disqualifies authoring-time approaches because a developer with template access can still override values at stack-create time.

Whether detection latency (the 2-minute non-compliance visibility window, analogous to RPO) requires AWS Config change-triggered evaluation, independent of whether the chosen remediation path (analogous to RTO) can meet the 10-minute SLA.

Whether to retain EC2 Auto Scaling, which provides steady-state Multi-AZ HA but cannot deliver sub-60-second new-capacity provisioning during burst events, or migrate to Lambda fronted by API Gateway, which provides sub-second concurrent scaling that satisfies both the scale-out RTO and the zero-request-loss RPO in burst scenarios.

Whether to derive dashboard metrics through a continuous in-stream mechanism (CloudWatch Logs metric filter emitting a custom CloudWatch metric) or through a periodic batch query mechanism (CloudWatch Logs Insights scheduled query), given a hard sub-60-second dashboard freshness requirement and a lowest-operational-overhead constraint.

Whether to use AWS Config continuous evaluation paired with a managed SSM Automation document via Config auto-remediation — satisfying both the detection-frequency constraint (no polling gap, RPO-equivalent) and the automated end-to-end remediation SLA (deterministic, code-free execution, RTO-equivalent) — versus a solution that captures compliance state reliably but routes remediation through a notification or custom-code path that cannot guarantee the time-bound automated fix.

Whether EventBridge's native retry policy plus a Lambda dead-letter queue satisfies the zero-event-loss delivery guarantee within the 90-second latency ceiling, or whether inserting SQS between EventBridge and Lambda is required to prevent event loss—recognising that the SQS polling model trades deterministic push latency for buffered pull latency, potentially violating the 90-second processing window (RTO analog) while adding queue-management overhead the scenario does not justify.

Choose between AWS Config auto-remediation invoking a managed SSM Automation document (declarative, no custom code, purpose-built MTTR path) versus routing Config compliance-change events through EventBridge to a custom Lambda function (imperative, adds cold-start latency, custom IAM surface, and bespoke failure-handling code), where the stated MTTR constraint plus the zero-custom-code requirement together disqualify the Lambda path.

Match the rollback tool to the exact failure layer — application deployment (CodeDeploy) versus infrastructure stack (CloudFormation) — given a hard five-minute RTO that infrastructure-layer rollback cannot satisfy for running ECS task sets.

Whether the stated RPO of 30 seconds can be met by RDS cross-region read replica replication lag or requires Aurora Global Database's physical storage replication, which provides RPO under one second regardless of write throughput.

Given explicit RPO (15 min) and RTO (30 min) constraints against a large Aurora dataset with a cost-efficiency preference, determine which DR tier — backup-restore or continuous replication with automated promotion — satisfies both targets simultaneously, and recognize that snapshot recency addresses RPO but does not bound restore duration for the RTO.