Cloud & Infraestrutura

Como Usar Aurora: Global Database, Serverless v2 e Cluster Endpoints em Produção

8 min de leitura

Como Usar Aurora: Global Database, Serverless v2 e Cluster Endpoints em Produção

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. Failover e

<h2>Aurora: Database Global, Serverless v2 e Endpoints em Produção</h2>

<p>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.</p>

<h2>Aurora Global Database: Replicação e Disaster Recovery</h2>

<h3>O que é Aurora Global Database</h3>

<p>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.</p>

<p>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.</p>

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

import pymysql

Cliente Aurora usando endpoint regional

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

Criar Global Database

response = rds_client.create_db_global_cluster(

GlobalClusterIdentifier=&#039;my-global-db&#039;,

Engine=&#039;aurora-mysql&#039;,

EngineVersion=&#039;8.0.mysql_aurora.3.02.0&#039;

)

Adicionar cluster secundário em outra região

rds_secondary = boto3.client(&#039;rds&#039;, region_name=&#039;eu-west-1&#039;)

rds_secondary.create_db_cluster(

DBClusterIdentifier=&#039;my-cluster-secondary&#039;,

Engine=&#039;aurora-mysql&#039;,

GlobalClusterIdentifier=&#039;my-global-db&#039;,

DBClusterInstanceClass=&#039;db.serverless&#039;

)

Conectar ao endpoint de leitura global (read-only)

connection = pymysql.connect(

host=&#039;my-global-db.cluster-ro-[region].rds.amazonaws.com&#039;,

user=&#039;admin&#039;,

password=&#039;your-password&#039;,

database=&#039;mydb&#039;

)</code></pre>

<h3>Failover e Promoção</h3>

<p>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.</p>

<h2>Serverless v2: Escalabilidade Elástica e Custos Dinâmicos</h2>

<h3>Arquitetura e Auto-Scaling</h3>

<p>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.</p>

<p>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.</p>

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

import time

rds = boto3.client(&#039;rds&#039;)

Criar cluster Serverless v2

cluster = rds.create_db_cluster(

DBClusterIdentifier=&#039;serverless-app&#039;,

Engine=&#039;aurora-mysql&#039;,

EngineVersion=&#039;8.0.mysql_aurora.3.02.0&#039;,

EngineMode=&#039;provisioned&#039;, # Serverless v2 usa &#039;provisioned&#039; com scaling

ServerlessV2ScalingConfigurationDetails={

&#039;MinCapacity&#039;: 0.5,

&#039;MaxCapacity&#039;: 2.0,

&#039;TimeoutAction&#039;: &#039;ForceApplyCapacityChange&#039;,

&#039;SecondsUntilAutoPause&#039;: 300 # Auto-pause após 5 min ocioso

},

MasterUsername=&#039;admin&#039;,

MasterUserPassword=&#039;YourPassword123!&#039;,

DatabaseName=&#039;myapp&#039;

)

Ajustar scaling em runtime

rds.modify_db_cluster(

DBClusterIdentifier=&#039;serverless-app&#039;,

ServerlessV2ScalingConfigurationDetails={

&#039;MinCapacity&#039;: 1.0,

&#039;MaxCapacity&#039;: 4.0

}

)

Monitorar capacidade usada (CloudWatch)

cloudwatch = boto3.client(&#039;cloudwatch&#039;)

metrics = cloudwatch.get_metric_statistics(

Namespace=&#039;AWS/RDS&#039;,

MetricName=&#039;ServerlessDatabaseCapacity&#039;,

Dimensions=[{&#039;Name&#039;: &#039;DBClusterIdentifier&#039;, &#039;Value&#039;: &#039;serverless-app&#039;}],

StartTime=int(time.time()) - 3600,

EndTime=int(time.time()),

Period=300,

Statistics=[&#039;Average&#039;, &#039;Maximum&#039;]

)</code></pre>

<h3>Otimização de Custos e Comportamento</h3>

<p>Serverless v2 é ideal para startups, ambientes de teste e SaaS multi-tenant. Monitorar <code>ServerlessDatabaseCapacity</code> 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.</p>

<h2>Cluster Endpoints: Roteamento Inteligente de Conexões</h2>

<h3>Tipos de Endpoints</h3>

<p>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.</p>

<p>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.</p>

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

from contextlib import contextmanager

class AuroraConnectionPool:

def __init__(self, cluster_name, region):

self.writer_endpoint = f&#039;{cluster_name}.cluster.{region}.rds.amazonaws.com&#039;

self.reader_endpoint = f&#039;{cluster_name}.cluster-ro.{region}.rds.amazonaws.com&#039;

self.credentials = {

&#039;user&#039;: &#039;admin&#039;,

&#039;password&#039;: &#039;your-password&#039;,

&#039;database&#039;: &#039;myapp&#039;

}

@contextmanager

def write_connection(self):

&quot;&quot;&quot;Conexão para escrita (transações, INSERT/UPDATE/DELETE)&quot;&quot;&quot;

conn = pymysql.connect(

host=self.writer_endpoint,

**self.credentials

)

try:

yield conn

finally:

conn.close()

@contextmanager

def read_connection(self):

&quot;&quot;&quot;Conexão para leitura (SELECT queries paralelizáveis)&quot;&quot;&quot;

conn = pymysql.connect(

host=self.reader_endpoint,

**self.credentials

)

try:

yield conn

finally:

conn.close()

Uso em produção

pool = AuroraConnectionPool(&#039;my-app-db&#039;, &#039;us-east-1&#039;)

Escrita

with pool.write_connection() as conn:

cursor = conn.cursor()

cursor.execute(&#039;INSERT INTO users (name, email) VALUES (%s, %s)&#039;,

(&#039;João Silva&#039;, &#039;joao@example.com&#039;))

conn.commit()

Leitura (distribui entre réplicas)

with pool.read_connection() as conn:

cursor = conn.cursor()

cursor.execute(&#039;SELECT COUNT(*) FROM orders WHERE created_at &gt; DATE_SUB(NOW(), INTERVAL 1 DAY)&#039;)

result = cursor.fetchone()

print(f&#039;Pedidos hoje: {result[0]}&#039;)</code></pre>

<h3>Custom Endpoints para Padrões Avançados</h3>

<p>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.</p>

<pre><code class="language-python">rds = boto3.client(&#039;rds&#039;)

Criar custom endpoint para analytics

rds.create_db_cluster_endpoint(

DBClusterIdentifier=&#039;my-app-db&#039;,

DBClusterEndpointIdentifier=&#039;analytics-endpoint&#039;,

EndpointType=&#039;CUSTOM&#039;,

StaticMembers=[&#039;instance-2&#039;, &#039;instance-3&#039;], # Réplicas específicas

Tags=[

{&#039;Key&#039;: &#039;Purpose&#039;, &#039;Value&#039;: &#039;BigQueryAnalytics&#039;}

]

)

Conectar ao endpoint customizado

analytics_endpoint = &#039;analytics-endpoint.cluster-custom.us-east-1.rds.amazonaws.com&#039;</code></pre>

<h2>Conclusão</h2>

<p>Três aprendizados fundamentais: <strong>Primeiro</strong>, Aurora Global Database remove acepções geográficas — implante com confiança globalmente, sabendo que failover automático está presente. <strong>Segundo</strong>, Serverless v2 transforma custos de capex para opex: pague pelo que usa, escalando automaticamente. <strong>Terceiro</strong>, separar writer e reader endpoints não é luxo, é arquitetura: ler de réplicas escala leitura exponencialmente sem impactar transações críticas.</p>

<p>Na produção, monitore <code>ServerlessDatabaseCapacity</code>, <code>DatabaseConnections</code> e <code>AuroraBinlogReplicaLag</code> (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.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/" target="_blank" rel="noopener noreferrer">AWS RDS Aurora Documentation</a></li>

<li><a href="https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html" target="_blank" rel="noopener noreferrer">Aurora Global Database Replication</a></li>

<li><a href="https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html" target="_blank" rel="noopener noreferrer">Aurora Serverless v2 Scaling</a></li>

<li><a href="https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.DB.html" target="_blank" rel="noopener noreferrer">RDS Endpoints and Connection Management</a></li>

<li><a href="https://docs.aws.amazon.com/wellarchitected/latest/userguide/workload-review.html" target="_blank" rel="noopener noreferrer">AWS Well-Architected Framework: Database Services</a></li>

</ul>

Comentários

Mais em Cloud & Infraestrutura

Well-Architected Framework: Os Seis Pilares na Prática na Prática
Well-Architected Framework: Os Seis Pilares na Prática na Prática

Well-Architected Framework: Os Seis Pilares na Prática O AWS Well-Architected...

Dominando EC2 em Profundidade: Instance Types, AMIs e Placement Groups em Projetos Reais
Dominando EC2 em Profundidade: Instance Types, AMIs e Placement Groups em Projetos Reais

Instance Types: Escolhendo a Máquina Correta Os tipos de instância EC2 são or...

Dominando AWS Config e CloudTrail: Compliance, Auditoria e Rastreabilidade em Projetos Reais
Dominando AWS Config e CloudTrail: Compliance, Auditoria e Rastreabilidade em Projetos Reais

AWS Config: Fundação da Compliance Contínua O AWS Config é um serviço que mon...