Cloud & Infraestrutura

O que Todo Dev Deve Saber sobre Alta Disponibilidade e Disaster Recovery na AWS: RTO, RPO e Estratégias

9 min de leitura

O que Todo Dev Deve Saber sobre Alta Disponibilidade e Disaster Recovery na AWS: RTO, RPO e Estratégias

Entendendo RTO e RPO: Os Pilares da Resiliência Recovery Time Objective (RTO) e Recovery Point Objective (RPO) são as duas métricas fundamentais que definem sua estratégia de disaster recovery. RTO é o tempo máximo aceitável para restaurar um serviço após uma falha, enquanto RPO é a quantidade máxima de dados que você está disposto a perder, medida em tempo. Se seu RTO é 1 hora e RPO é 15 minutos, significa que deve recuperar o sistema em até 1 hora e não pode perder mais de 15 minutos de dados. Essas métricas não são técnicas — são decisões de negócio que impactam diretamente seus custos e arquitetura. Na AWS, você implementa RTO através de redundância ativa (multi-AZ, multi-região) e RPO através de estratégias de backup e replicação. Uma aplicação crítica de e-commerce tem RTO de minutos e RPO de segundos, enquanto um sistema administrativo pode tolerar horas. Conhecer essa diferença evita over-engineering (gastos desnecessários) e under-engineering (riscos inaceitáveis). Estratégias de

<h2>Entendendo RTO e RPO: Os Pilares da Resiliência</h2>

<p>Recovery Time Objective (RTO) e Recovery Point Objective (RPO) são as duas métricas fundamentais que definem sua estratégia de disaster recovery. RTO é o tempo máximo aceitável para restaurar um serviço após uma falha, enquanto RPO é a quantidade máxima de dados que você está disposto a perder, medida em tempo. Se seu RTO é 1 hora e RPO é 15 minutos, significa que deve recuperar o sistema em até 1 hora e não pode perder mais de 15 minutos de dados. Essas métricas não são técnicas — são decisões de negócio que impactam diretamente seus custos e arquitetura.</p>

<p>Na AWS, você implementa RTO através de redundância ativa (multi-AZ, multi-região) e RPO através de estratégias de backup e replicação. Uma aplicação crítica de e-commerce tem RTO de minutos e RPO de segundos, enquanto um sistema administrativo pode tolerar horas. Conhecer essa diferença evita over-engineering (gastos desnecessários) e under-engineering (riscos inaceitáveis).</p>

<h2>Estratégias de Alta Disponibilidade na AWS</h2>

<h3>Multi-AZ e Load Balancing</h3>

<p>A estratégia mais comum é distribuir sua aplicação entre múltiplas Availability Zones. O AWS Application Load Balancer (ALB) distribui tráfego automaticamente, e se uma AZ cair, as instâncias nas outras AZs continuam servindo requisições. Isso reduz RTO para alguns segundos.</p>

<pre><code class="language-python">import boto3

Criar ALB com Multi-AZ

elb_client = boto3.client(&#039;elbv2&#039;, region_name=&#039;us-east-1&#039;)

response = elb_client.create_load_balancer(

Name=&#039;meu-alb-prod&#039;,

Subnets=[&#039;subnet-az1-123&#039;, &#039;subnet-az2-456&#039;], # Subnets em AZs diferentes

SecurityGroups=[&#039;sg-123456&#039;],

Scheme=&#039;internet-facing&#039;

)

print(f&quot;ALB criado: {response[&#039;LoadBalancers&#039;][0][&#039;LoadBalancerArn&#039;]}&quot;)

Registrar instâncias em target group

response = elb_client.register_targets(

TargetGroupArn=&#039;arn:aws:elasticloadbalancing:...&#039;,

Targets=[

{&#039;Id&#039;: &#039;i-1234567890abcdef0&#039;, &#039;Port&#039;: 80},

{&#039;Id&#039;: &#039;i-0987654321fedcba0&#039;, &#039;Port&#039;: 80}

]

)</code></pre>

<h3>Auto Scaling e Health Checks</h3>

<p>Auto Scaling garante que você sempre tenha instâncias saudáveis rodando. Quando uma instância falha no health check, é substituída automaticamente, minimizando downtime.</p>

<pre><code class="language-python">asg_client = boto3.client(&#039;autoscaling&#039;, region_name=&#039;us-east-1&#039;)

Criar Auto Scaling Group

asg_client.create_auto_scaling_group(

AutoScalingGroupName=&#039;meu-asg-prod&#039;,

LaunchTemplate={&#039;LaunchTemplateId&#039;: &#039;lt-123456&#039;, &#039;Version&#039;: &#039;$Latest&#039;},

MinSize=2,

MaxSize=10,

DesiredCapacity=3,

VPCZoneIdentifier=&#039;subnet-az1-123,subnet-az2-456&#039;,

HealthCheckType=&#039;ELB&#039;,

HealthCheckGracePeriod=300

)

print(&quot;Auto Scaling Group criado com health checks habilitados&quot;)</code></pre>

<h2>Disaster Recovery: Backup e Replicação em Multi-Região</h2>

<h3>Estratégia de Backup com AWS Backup</h3>

<p>Para RPO eficiente, implemente backups automatizados. AWS Backup orquestra snapshots de RDS, EBS e outras soluções, permitindo restauração rápida em caso de corrupção de dados ou exclusão acidental.</p>

<pre><code class="language-python">backup_client = boto3.client(&#039;backup&#039;, region_name=&#039;us-east-1&#039;)

Criar plano de backup

response = backup_client.create_backup_plan(

BackupPlan={

&#039;BackupPlanName&#039;: &#039;plano-backup-producao&#039;,

&#039;Rules&#039;: [

{

&#039;RuleName&#039;: &#039;backup-diario&#039;,

&#039;TargetBackupVaultName&#039;: &#039;backup-vault-prod&#039;,

&#039;ScheduleExpression&#039;: &#039;cron(0 5 ? *)&#039;, # 5h da manhã todo dia

&#039;StartWindowMinutes&#039;: 60,

&#039;CompletionWindowMinutes&#039;: 180,

&#039;Lifecycle&#039;: {

&#039;DeleteAfterDays&#039;: 30,

&#039;MoveToColdStorageAfterDays&#039;: 7

}

}

]

}

)

print(f&quot;Plano de backup criado: {response[&#039;BackupPlanId&#039;]}&quot;)

Designar recurso para backup

backup_client.create_backup_selection(

BackupPlanId=response[&#039;BackupPlanId&#039;],

BackupSelection={

&#039;SelectionName&#039;: &#039;backup-rds-producao&#039;,

&#039;IamRoleArn&#039;: &#039;arn:aws:iam::123456789012:role/BackupRole&#039;,

&#039;Resources&#039;: [&#039;arn:aws:rds:us-east-1:123456789012:db:meu-banco&#039;]

}

)</code></pre>

<h3>Replicação Multi-Região com DMS</h3>

<p>Para Disaster Recovery com RTO baixo, replique dados em tempo real para outra região usando AWS Database Migration Service (DMS). Isso permite failover automático se a região primária cair.</p>

<pre><code class="language-python">dms_client = boto3.client(&#039;dms&#039;, region_name=&#039;us-east-1&#039;)

Criar replicação contínua

response = dms_client.create_replication_task(

ReplicationTaskIdentifier=&#039;replicacao-rds-dr&#039;,

SourceEndpointArn=&#039;arn:aws:dms:us-east-1:...source...&#039;,

TargetEndpointArn=&#039;arn:aws:dms:us-west-2:...target...&#039;,

ReplicationInstanceArn=&#039;arn:aws:dms:us-east-1:...instance...&#039;,

MigrationType=&#039;cdc&#039;, # Change Data Capture para replicação contínua

TableMappings=&#039;{&quot;rules&quot;:[{&quot;rule-type&quot;:&quot;selection&quot;,&quot;rule-id&quot;:&quot;1&quot;,&quot;rule-name&quot;:&quot;1&quot;,&quot;object-locator&quot;:{&quot;schema-name&quot;:&quot;%&quot;,&quot;table-name&quot;:&quot;%&quot;},&quot;rule-action&quot;:&quot;include&quot;}]}&#039;

)

print(f&quot;Replicação iniciada: {response[&#039;ReplicationTask&#039;][&#039;ReplicationTaskArn&#039;]}&quot;)</code></pre>

<h3>Route53 Health Checks e Failover</h3>

<p>Implementar failover automático em nível de DNS garante que clientes sejam direcionados para a região ativa, reduzindo RTO significativamente.</p>

<pre><code class="language-python">route53_client = boto3.client(&#039;route53&#039;, region_name=&#039;us-east-1&#039;)

Criar health check para endpoint primário

health_check = route53_client.create_health_check(

HealthCheckConfig={

&#039;Type&#039;: &#039;HTTPS&#039;,

&#039;ResourcePath&#039;: &#039;/health&#039;,

&#039;FullyQualifiedDomainName&#039;: &#039;api-us-east-1.exemplo.com&#039;,

&#039;Port&#039;: 443,

&#039;RequestInterval&#039;: 30,

&#039;FailureThreshold&#039;: 3

}

)

Criar registro com failover automático

route53_client.create_hosted_zone(Name=&#039;exemplo.com&#039;, CallerReference=&#039;ref-001&#039;)

route53_client.change_resource_record_sets(

HostedZoneId=&#039;Z123456ABCDEF&#039;,

ChangeBatch={

&#039;Changes&#039;: [

{

&#039;Action&#039;: &#039;CREATE&#039;,

&#039;ResourceRecordSet&#039;: {

&#039;Name&#039;: &#039;api.exemplo.com&#039;,

&#039;Type&#039;: &#039;A&#039;,

&#039;TTL&#039;: 60,

&#039;SetIdentifier&#039;: &#039;api-us-east-1-primary&#039;,

&#039;Failover&#039;: &#039;PRIMARY&#039;,

&#039;AliasTarget&#039;: {

&#039;HostedZoneId&#039;: &#039;Z35SXDOTRQ7X7K&#039;,

&#039;DNSName&#039;: &#039;alb-us-east-1.elasticloadbalancing.amazonaws.com&#039;,

&#039;EvaluateTargetHealth&#039;: True

},

&#039;HealthCheckId&#039;: health_check[&#039;HealthCheck&#039;][&#039;Id&#039;]

}

},

{

&#039;Action&#039;: &#039;CREATE&#039;,

&#039;ResourceRecordSet&#039;: {

&#039;Name&#039;: &#039;api.exemplo.com&#039;,

&#039;Type&#039;: &#039;A&#039;,

&#039;TTL&#039;: 60,

&#039;SetIdentifier&#039;: &#039;api-us-west-2-secondary&#039;,

&#039;Failover&#039;: &#039;SECONDARY&#039;,

&#039;AliasTarget&#039;: {

&#039;HostedZoneId&#039;: &#039;Z1H1FL5HABSF5&#039;,

&#039;DNSName&#039;: &#039;alb-us-west-2.elasticloadbalancing.amazonaws.com&#039;,

&#039;EvaluateTargetHealth&#039;: True

}

}

}

]

}

)

print(&quot;Failover automático configurado no Route53&quot;)</code></pre>

<h2>Implementação Prática: RTO/RPO em Produção</h2>

<p>Defina explicitamente seus SLOs (Service Level Objectives) antes de implementar qualquer estratégia. Para uma aplicação de SaaS com RPO de 1 hora e RTO de 30 minutos, você precisa de backups a cada 30 minutos e redundância ativa que permita recuperação em menos de 30 minutos. Teste regularmente seus planos de disaster recovery — um backup que nunca foi testado é um backup que não funciona. Use AWS Resilience Hub para validar automaticamente sua resiliência em relação aos objetivos definidos.</p>

<pre><code class="language-python">resilience_hub = boto3.client(&#039;resiliencehub&#039;, region_name=&#039;us-east-1&#039;)

Registrar aplicação no Resilience Hub

app = resilience_hub.create_app(

name=&#039;meu-app-producao&#039;,

assessmentSchedule=&#039;Monthly&#039;

)

Iniciar avaliação de resiliência

assessment = resilience_hub.start_app_assessment(

appArn=app[&#039;app&#039;][&#039;appArn&#039;]

)

print(f&quot;Avaliação de resiliência iniciada: {assessment[&#039;appAssessment&#039;][&#039;assessmentArn&#039;]}&quot;)</code></pre>

<h2>Conclusão</h2>

<p>Os três pontos principais que você deve levar desta aula são: primeiro, RTO e RPO são métricas de negócio antes de serem técnicas — defina-as com stakeholders, não com arquitetos; segundo, alta disponibilidade (Multi-AZ, ALB, Auto Scaling) e disaster recovery (backup, replicação multi-região, failover DNS) são camadas distintas que trabalham juntas; terceiro, implemente monitoramento contínuo e testes regulares de recuperação — a melhor arquitetura falha se ninguém souber como usá-la em uma crise real. Comece simples, meça, otimize.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html" target="_blank" rel="noopener noreferrer">AWS Well-Architected Framework - Reliability Pillar</a></li>

<li><a href="https://aws.amazon.com/disaster-recovery/" target="_blank" rel="noopener noreferrer">AWS Disaster Recovery Strategies</a></li>

<li><a href="https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html" target="_blank" rel="noopener noreferrer">AWS Resilience Hub User Guide</a></li>

<li><a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/rto-rpo-patterns.html" target="_blank" rel="noopener noreferrer">RTO and RPO in AWS Documentation</a></li>

<li><a href="https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html" target="_blank" rel="noopener noreferrer">AWS Database Migration Service Best Practices</a></li>

</ul>

Comentários

Mais em Cloud & Infraestrutura

O que Todo Dev Deve Saber sobre EBS e EFS: Block Storage vs File Storage em Casos Reais
O que Todo Dev Deve Saber sobre EBS e EFS: Block Storage vs File Storage em Casos Reais

O Que Todo Dev Deve Saber sobre EBS e EFS A escolha entre armazenamento em bl...

Route 53: DNS, Health Checks e Roteamento de Tráfego Global na Prática
Route 53: DNS, Health Checks e Roteamento de Tráfego Global na Prática

Fundamentos do Route 53: DNS na AWS O Route 53 é o serviço de DNS gerenciado...

Guia Completo de AWS Security Hub: Postura de Segurança Centralizada
Guia Completo de AWS Security Hub: Postura de Segurança Centralizada

Introdução ao AWS Security Hub O AWS Security Hub é um serviço centralizado q...