Aurora: Database Global, Serverless v2 e Endpoints em Produção
Amazon Aurora representa a evolução das bases de dados relacionais na nuvem. Este artigo aborda três pilares críticos para implementações em produção: replicação global, arquitetura serverless com escalabilidade automática e estratégia inteligente de roteamento de conexões através de endpoints. Dominar esses conceitos diferencia uma implementação robusta de uma que colapsará sob carga.
Aurora Global Database: Replicação e Disaster Recovery
O que é Aurora Global Database
Aurora Global Database permite replicação de leitura e escrita em múltiplas regiões AWS com latência sub-segundo. Diferente de read replicas convencionais, oferece failover automático e RPO (Recovery Point Objective) praticamente zero. A região primária aceita leitura e escrita; regiões secundárias aceitam apenas leitura.
Uma implementação típica envolve uma região primária (us-east-1) e uma secundária para disaster recovery (eu-west-1). Durante uma falha regional, você promove a secundária em minutos. O custo é mais alto que read replicas tradicionais, mas a disponibilidade justifica em aplicações críticas.
import boto3
import pymysql
# Cliente Aurora usando endpoint regional
rds_client = boto3.client('rds', region_name='us-east-1')
# Criar Global Database
response = rds_client.create_db_global_cluster(
GlobalClusterIdentifier='my-global-db',
Engine='aurora-mysql',
EngineVersion='8.0.mysql_aurora.3.02.0'
)
# Adicionar cluster secundário em outra região
rds_secondary = boto3.client('rds', region_name='eu-west-1')
rds_secondary.create_db_cluster(
DBClusterIdentifier='my-cluster-secondary',
Engine='aurora-mysql',
GlobalClusterIdentifier='my-global-db',
DBClusterInstanceClass='db.serverless'
)
# Conectar ao endpoint de leitura global (read-only)
connection = pymysql.connect(
host='my-global-db.cluster-ro-[region].rds.amazonaws.com',
user='admin',
password='your-password',
database='mydb'
)
Failover e Promoção
Em caso de desastre, a promoção manual é executada em segundos. Configure alarmes CloudWatch para detectar falhas de aplicação na região primária e dispare um Lambda que promova a secundária automaticamente. Teste esse processo em staging regularmente — documentação sem prática é ilusão.
Serverless v2: Escalabilidade Elástica e Custos Dinâmicos
Arquitetura e Auto-Scaling
Serverless v2 elimina o provisionamento manual de instâncias. O cluster dimensiona automaticamente entre ACU (Aurora Capacity Units) mínimas e máximas baseado na demanda. Uma ACU equivale aproximadamente a 2GB de RAM. Para aplicações com picos irregulares, isso reduz custos em até 70% comparado a instâncias provisionadas.
Você não gerencia mais tamanho de instância (db.r5.large, etc). Define apenas os limites de capacidade: mínimo (recomendado 0.5 ACU) e máximo. Aurora escalará horizontalmente em segundos quando a CPU ou conexões excederem thresholds internos.
import boto3
import time
rds = boto3.client('rds')
# Criar cluster Serverless v2
cluster = rds.create_db_cluster(
DBClusterIdentifier='serverless-app',
Engine='aurora-mysql',
EngineVersion='8.0.mysql_aurora.3.02.0',
EngineMode='provisioned', # Serverless v2 usa 'provisioned' com scaling
ServerlessV2ScalingConfigurationDetails={
'MinCapacity': 0.5,
'MaxCapacity': 2.0,
'TimeoutAction': 'ForceApplyCapacityChange',
'SecondsUntilAutoPause': 300 # Auto-pause após 5 min ocioso
},
MasterUsername='admin',
MasterUserPassword='YourPassword123!',
DatabaseName='myapp'
)
# Ajustar scaling em runtime
rds.modify_db_cluster(
DBClusterIdentifier='serverless-app',
ServerlessV2ScalingConfigurationDetails={
'MinCapacity': 1.0,
'MaxCapacity': 4.0
}
)
# Monitorar capacidade usada (CloudWatch)
cloudwatch = boto3.client('cloudwatch')
metrics = cloudwatch.get_metric_statistics(
Namespace='AWS/RDS',
MetricName='ServerlessDatabaseCapacity',
Dimensions=[{'Name': 'DBClusterIdentifier', 'Value': 'serverless-app'}],
StartTime=int(time.time()) - 3600,
EndTime=int(time.time()),
Period=300,
Statistics=['Average', 'Maximum']
)
Otimização de Custos e Comportamento
Serverless v2 é ideal para startups, ambientes de teste e SaaS multi-tenant. Monitorar ServerlessDatabaseCapacity em CloudWatch previne surpresas na fatura. Auto-pause reduz custos de inatividade, mas adiciona latência ao acordar o cluster (20-30s). Desabilite para aplicações críticas 24/7.
Cluster Endpoints: Roteamento Inteligente de Conexões
Tipos de Endpoints
Aurora oferece quatro tipos de endpoints: writer (apenas escrita), reader (apenas leitura distribuída entre réplicas), custom (flexível, você seleciona instâncias), e instance-specific (conexão direta em uma réplica). Em produção, você típicamente usa writer para transações e reader para analytics/relatórios.
O reader endpoint distribui conexões round-robin entre todas as réplicas disponíveis. Isso escala leitura automaticamente: adicione réplicas (até 15) sem mudar código. O writer endpoint sempre aponta para a instância primária — mude apenas durante failover ou promoção.
import pymysql
from contextlib import contextmanager
class AuroraConnectionPool:
def __init__(self, cluster_name, region):
self.writer_endpoint = f'{cluster_name}.cluster.{region}.rds.amazonaws.com'
self.reader_endpoint = f'{cluster_name}.cluster-ro.{region}.rds.amazonaws.com'
self.credentials = {
'user': 'admin',
'password': 'your-password',
'database': 'myapp'
}
@contextmanager
def write_connection(self):
"""Conexão para escrita (transações, INSERT/UPDATE/DELETE)"""
conn = pymysql.connect(
host=self.writer_endpoint,
**self.credentials
)
try:
yield conn
finally:
conn.close()
@contextmanager
def read_connection(self):
"""Conexão para leitura (SELECT queries paralelizáveis)"""
conn = pymysql.connect(
host=self.reader_endpoint,
**self.credentials
)
try:
yield conn
finally:
conn.close()
# Uso em produção
pool = AuroraConnectionPool('my-app-db', 'us-east-1')
# Escrita
with pool.write_connection() as conn:
cursor = conn.cursor()
cursor.execute('INSERT INTO users (name, email) VALUES (%s, %s)',
('João Silva', 'joao@example.com'))
conn.commit()
# Leitura (distribui entre réplicas)
with pool.read_connection() as conn:
cursor = conn.cursor()
cursor.execute('SELECT COUNT(*) FROM orders WHERE created_at > DATE_SUB(NOW(), INTERVAL 1 DAY)')
result = cursor.fetchone()
print(f'Pedidos hoje: {result[0]}')
Custom Endpoints para Padrões Avançados
Para casos específicos — analytics pesado em uma réplica dedicada, isolamento de workloads, ou testes A/B — crie custom endpoints. Um custom endpoint seleciona instâncias específicas do cluster, ignorando o load balancing do reader padrão.
rds = boto3.client('rds')
# Criar custom endpoint para analytics
rds.create_db_cluster_endpoint(
DBClusterIdentifier='my-app-db',
DBClusterEndpointIdentifier='analytics-endpoint',
EndpointType='CUSTOM',
StaticMembers=['instance-2', 'instance-3'], # Réplicas específicas
Tags=[
{'Key': 'Purpose', 'Value': 'BigQueryAnalytics'}
]
)
# Conectar ao endpoint customizado
analytics_endpoint = 'analytics-endpoint.cluster-custom.us-east-1.rds.amazonaws.com'
Conclusão
Três aprendizados fundamentais: Primeiro, Aurora Global Database remove acepções geográficas — implante com confiança globalmente, sabendo que failover automático está presente. Segundo, Serverless v2 transforma custos de capex para opex: pague pelo que usa, escalando automaticamente. Terceiro, separar writer e reader endpoints não é luxo, é arquitetura: ler de réplicas escala leitura exponencialmente sem impactar transações críticas.
Na produção, monitore ServerlessDatabaseCapacity, DatabaseConnections e AuroraBinlogReplicaLag (para Global DB) continuamente. Teste failover trimestralmente. Comece simples (cluster único, Serverless v2), evolua para Global quando tiver tráfego justificável. Essa progressão evita complexidade desnecessária.