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 Alta Disponibilidade na AWS
Multi-AZ e Load Balancing
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.
import boto3
# Criar ALB com Multi-AZ
elb_client = boto3.client('elbv2', region_name='us-east-1')
response = elb_client.create_load_balancer(
Name='meu-alb-prod',
Subnets=['subnet-az1-123', 'subnet-az2-456'], # Subnets em AZs diferentes
SecurityGroups=['sg-123456'],
Scheme='internet-facing'
)
print(f"ALB criado: {response['LoadBalancers'][0]['LoadBalancerArn']}")
# Registrar instâncias em target group
response = elb_client.register_targets(
TargetGroupArn='arn:aws:elasticloadbalancing:...',
Targets=[
{'Id': 'i-1234567890abcdef0', 'Port': 80},
{'Id': 'i-0987654321fedcba0', 'Port': 80}
]
)
Auto Scaling e Health Checks
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.
asg_client = boto3.client('autoscaling', region_name='us-east-1')
# Criar Auto Scaling Group
asg_client.create_auto_scaling_group(
AutoScalingGroupName='meu-asg-prod',
LaunchTemplate={'LaunchTemplateId': 'lt-123456', 'Version': '$Latest'},
MinSize=2,
MaxSize=10,
DesiredCapacity=3,
VPCZoneIdentifier='subnet-az1-123,subnet-az2-456',
HealthCheckType='ELB',
HealthCheckGracePeriod=300
)
print("Auto Scaling Group criado com health checks habilitados")
Disaster Recovery: Backup e Replicação em Multi-Região
Estratégia de Backup com AWS Backup
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.
backup_client = boto3.client('backup', region_name='us-east-1')
# Criar plano de backup
response = backup_client.create_backup_plan(
BackupPlan={
'BackupPlanName': 'plano-backup-producao',
'Rules': [
{
'RuleName': 'backup-diario',
'TargetBackupVaultName': 'backup-vault-prod',
'ScheduleExpression': 'cron(0 5 ? * * *)', # 5h da manhã todo dia
'StartWindowMinutes': 60,
'CompletionWindowMinutes': 180,
'Lifecycle': {
'DeleteAfterDays': 30,
'MoveToColdStorageAfterDays': 7
}
}
]
}
)
print(f"Plano de backup criado: {response['BackupPlanId']}")
# Designar recurso para backup
backup_client.create_backup_selection(
BackupPlanId=response['BackupPlanId'],
BackupSelection={
'SelectionName': 'backup-rds-producao',
'IamRoleArn': 'arn:aws:iam::123456789012:role/BackupRole',
'Resources': ['arn:aws:rds:us-east-1:123456789012:db:meu-banco']
}
)
Replicação Multi-Região com DMS
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.
dms_client = boto3.client('dms', region_name='us-east-1')
# Criar replicação contínua
response = dms_client.create_replication_task(
ReplicationTaskIdentifier='replicacao-rds-dr',
SourceEndpointArn='arn:aws:dms:us-east-1:...source...',
TargetEndpointArn='arn:aws:dms:us-west-2:...target...',
ReplicationInstanceArn='arn:aws:dms:us-east-1:...instance...',
MigrationType='cdc', # Change Data Capture para replicação contínua
TableMappings='{"rules":[{"rule-type":"selection","rule-id":"1","rule-name":"1","object-locator":{"schema-name":"%","table-name":"%"},"rule-action":"include"}]}'
)
print(f"Replicação iniciada: {response['ReplicationTask']['ReplicationTaskArn']}")
Route53 Health Checks e Failover
Implementar failover automático em nível de DNS garante que clientes sejam direcionados para a região ativa, reduzindo RTO significativamente.
route53_client = boto3.client('route53', region_name='us-east-1')
# Criar health check para endpoint primário
health_check = route53_client.create_health_check(
HealthCheckConfig={
'Type': 'HTTPS',
'ResourcePath': '/health',
'FullyQualifiedDomainName': 'api-us-east-1.exemplo.com',
'Port': 443,
'RequestInterval': 30,
'FailureThreshold': 3
}
)
# Criar registro com failover automático
route53_client.create_hosted_zone(Name='exemplo.com', CallerReference='ref-001')
route53_client.change_resource_record_sets(
HostedZoneId='Z123456ABCDEF',
ChangeBatch={
'Changes': [
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': 'api.exemplo.com',
'Type': 'A',
'TTL': 60,
'SetIdentifier': 'api-us-east-1-primary',
'Failover': 'PRIMARY',
'AliasTarget': {
'HostedZoneId': 'Z35SXDOTRQ7X7K',
'DNSName': 'alb-us-east-1.elasticloadbalancing.amazonaws.com',
'EvaluateTargetHealth': True
},
'HealthCheckId': health_check['HealthCheck']['Id']
}
},
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': 'api.exemplo.com',
'Type': 'A',
'TTL': 60,
'SetIdentifier': 'api-us-west-2-secondary',
'Failover': 'SECONDARY',
'AliasTarget': {
'HostedZoneId': 'Z1H1FL5HABSF5',
'DNSName': 'alb-us-west-2.elasticloadbalancing.amazonaws.com',
'EvaluateTargetHealth': True
}
}
}
]
}
)
print("Failover automático configurado no Route53")
Implementação Prática: RTO/RPO em Produção
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.
resilience_hub = boto3.client('resiliencehub', region_name='us-east-1')
# Registrar aplicação no Resilience Hub
app = resilience_hub.create_app(
name='meu-app-producao',
assessmentSchedule='Monthly'
)
# Iniciar avaliação de resiliência
assessment = resilience_hub.start_app_assessment(
appArn=app['app']['appArn']
)
print(f"Avaliação de resiliência iniciada: {assessment['appAssessment']['assessmentArn']}")
Conclusão
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.