ADR: S/4HANA em Hong Kong: X2idn chegou, migrar agora ou esperar X8i?
cerca de 7 min · áudio gerado ao tocar
Em 11 de setembro de 2026 a AWS ligou as instâncias X2idn na região Asia Pacific (Hong Kong). Para quem lê release note, é uma linha. Para quem opera um S/4HANA que precisa ficar em Hong Kong por regra de residência de dados, é a primeira vez em que ap-east-1 oferece uma instância Nitro de 2 TiB certificada para HANA de produção, e isso destrava uma decisão que estava parada em cima de X1 há anos. Este é o registro de decisão que eu escreveria hoje para esse cenário: contexto, opções, escolha e, principalmente, o que a escolha custa manter.
Contexto e forças
O cenário é concreto: um core financeiro em S/4HANA, base HANA com cerca de 1,3 TiB de dados em memória, obrigação contratual e regulatória de manter dados e processamento em Hong Kong. Até esta semana, quem precisava de mais de 1 TiB certificado nessa região tinha na prática a família X1, instâncias Xen que a própria referência de armazenamento da AWS marca com a nota 'sugerimos migrar para um tipo Nitro'.
A tabela de certificação SAP da AWS deixa a diferença nua. x1.32xlarge: 1.952 GiB, 131.500 SAPS, 25 Gbps de rede, 14.000 Mbps de armazenamento. x2idn.32xlarge: 2.048 GiB, 196.050 SAPS, 100 Gbps, 80.000 Mbps. Não é upgrade incremental, é 49% mais SAPS e 5,7× mais banda de EBS no mesmo envelope de memória.
As forças que puxam a decisão:
Residência de dados: a carga não sai de ap-east-1. Singapura e Tóquio já têm X8i; Hong Kong, em nenhuma página que abri, aparece na lista.
Janela de reinício: trocar tipo de instância é parar o banco e recarregar 1,3 TiB em memória. Cada troca é uma janela negociada com o negócio, e eu não quero negociar duas no mesmo ano sem motivo.
Capacidade: instância de 128 vCPU em região pequena é exatamente o perfil que devolve InsufficientInstanceCapacity no dia do failover.
Custo de manter: o plantão é o mesmo para X1, X2idn ou X8i; o que muda é quantos incidentes de I/O e quantos tickets de capacidade ele atende por trimestre.
A pergunta errada é 'X2idn é mais rápido que X1?'. A resposta é sim e não decide nada. A pergunta certa é: sabendo que X8i não está em Hong Kong e sem data para estar, vale migrar agora e talvez migrar de novo, ou segurar no X1?
As opções na mesa
Considerei quatro caminhos. Scale-out não entrou: para OLTP (S/4HANA) a certificação de scale-out na tabela da AWS só existe na família U de alta memória, com máximo de 4 nós; X2idn e X2iedn são certificados em scale-out apenas para OLAP.
Opção A, ficar no X1. Zero janela agora, zero risco de regressão. O preço é operar 14.000 Mbps de armazenamento com um banco cujo delta merge e cujo savepoint já competem por I/O em fechamento de mês. Cada trimestre no X1 é um trimestre a mais de tuning que não sobrevive à migração.
Opção B: X2idn em ap-east-1 agora. x2idn.32xlarge está certificado para OLTP produtivo com sizing Standard. Ganha-se 49% de SAPS e a banda de EBS para sair do regime de tuning defensivo. Aceita-se que é geração de 2022 e que X8i vai chegar um dia.
Opção C, esperar X8i em Hong Kong. A AWS anunciou X8i em janeiro de 2026 com 50% mais SAPS e 3,4× a banda de memória do X2i, e vem expandindo região a região. O problema é que 'um dia' não é data. Esperar significa continuar no X1 por tempo indeterminado, e a espera tem custo por mês.
Opção D: X8i em Singapura. Tecnicamente a melhor instância; regulatoriamente, inviável. A residência de dados não é um requisito não funcional negociável, é o requisito que fez a carga existir nessa região.
A opção B tem um defeito honesto: se X8i chegar em ap-east-1 em seis meses, terei feito duas migrações em um ano. A pergunta que resolve isso é: quanto custa cada mês a mais no X1 comparado a uma segunda janela de migração? A matriz abaixo registra o raciocínio.
Opções consideradas
A: Ficar no X1 (x1.32xlarge)
- Nenhuma janela de migração agora
- Configuração conhecida, runbooks maduros
- Geração Xen; a própria AWS sugere migrar para Nitro
- 14.000 Mbps de EBS e 131.500 SAPS, teto de I/O em fechamento de mês
- Cada mês adiciona tuning que a migração descarta
Rejeitada: adia o custo, não o elimina
B: X2idn agora (x2idn.32xlarge)
- Certificado OLTP produtivo, sizing Standard, 2.048 GiB
- 196.050 SAPS, 100 Gbps de rede, 80.000 Mbps de EBS
- Disponível hoje em ap-east-1; capacidade reservável via ODCR
- Geração de 2022; provável segunda migração para X8i
- NVMe local é efêmero, inútil para /hana/data
Escolhida: resolve o gargalo hoje e mantém a trilha para X8i
C: Esperar X8i em Hong Kong
- Uma migração só, para a instância mais forte
- 50% mais SAPS e 3,4× banda de memória vs X2i (dados da AWS)
- Sem data; nenhuma página aberta lista ap-east-1
- Cada mês de espera é um mês no X1
Rejeitada como plano; mantida como próximo passo
D: X8i em Singapura
- Melhor instância disponível hoje na Ásia
- Viola a residência de dados, o requisito que criou a carga
- Latência entre regiões para o app tier que fica em Hong Kong
Inviável
Decisão: X2idn agora, com trilho para X8i
Escolho a opção B e registro a C como sucessora. O raciocínio que fecha a conta: uma segunda migração custa uma janela; ficar no X1 custa todo mês. Quando a segunda janela vier, ela será entre duas gerações Nitro com o mesmo layout de EBS, bem mais barata que sair do Xen.
Tamanho: x2idn.32xlarge, não x2idn.24xlarge. 1,3 TiB em 1.536 GiB são 85% de ocupação: HANA precisa de folga para delta merge e crescimento anual; 2.048 GiB dão dois anos de folga. Detalhe que muita gente ignora: na tabela da AWS, x2idn.16xlarge e x2idn.24xlarge têm OLAP com sizing Workload (exige aprovação por carga), só o 32xlarge é Standard nas duas categorias.
Armazenamento: sigo a referência da AWS para 2 TiB: /hana/data 2.500 GiB gp3 com 8.100 IOPS e 875 MB/s; /hana/log 500 GiB gp3 com 3.000 IOPS e 300 MB/s; /hana/shared 1.024 GiB. Todos criptografados com KMS CMK própria, com a condição ec2:Encrypted na policy de quem cria volumes. O NVMe local de 2×1900 GB fica fora do caminho de dados.
Capacidade: uma On-Demand Capacity Reservation de uso imediato por nó, em cada AZ, com plataforma SUSE Linux idêntica ao PlatformDetails da AMI. Combinada com um Compute Savings Plan, que é o que traz o desconto, a reserva sozinha não dá nenhum. Antes de criar, peço aumento da cota On-Demand da família X em ap-east-1: reserva ativa conta contra a cota mesmo vazia.
Alta disponibilidade: HANA System Replication síncrona entre duas AZs, cluster Pacemaker movendo o overlay IP na route table. Os nomes de instância e de reserva recebem a tag sap:role=hana-primary|hana-secondary, e uma SCP com aws:RequestedRegion restrita a ap-east-1 garante que a residência não dependa de disciplina humana.
Alvo da decisão: S/4HANA em X2idn, duas AZs de ap-east-1
O app tier fala com um overlay IP; o Pacemaker move a rota entre o primário e o secundário. Cada nó roda dentro de uma Capacity Reservation própria.
- Overlay IP · route table /32
- Pacemaker · fence + move route
- x2idn.32xlarge · 2.048 GiB · 196.050 SAPS
- EBS gp3 · KMS CMK · data 2.500 GiB 875 MB/s · log 500 GiB
- ODCR AZ a · platform SUSE Linux
- x2idn.32xlarge · HSR sync target
- EBS gp3 · KMS CMK · mesmo layout
- ODCR AZ b · platform SUSE Linux
- S3 backup (Backint) · lifecycle + Object Lock
- X8i em ap-east-1 · quando chegar
Consequências: o que passa a ser operado
Uma decisão só está registrada quando as consequências estão escritas. Estas são as que assumo.
Uma segunda migração está agendada sem data. Quando X8i aparecer em ap-east-1, confirmo com aws ec2 describe-instance-type-offerings --region ap-east-1 --filters Name=instance-type,Values=x8i.*, não com anúncio, o caminho é trocar o secundário primeiro, deixar a HSR sincronizar, fazer takeover e trocar o antigo primário. O layout de EBS para 2 TiB é o mesmo nas duas gerações, então a janela é de takeover, não de recarga completa.
Reserva vazia é conta cheia. ODCR de uso imediato cobra desde a criação, ocupada ou não. Se o secundário ficar dois dias parado para manutenção, a reserva continua cobrando. Alarmo a utilização das reservas e o ReservationState; reserva sem instância por mais de 24h abre incidente de FinOps, não de infra.
A cota vira dependência de projeto. Reservas ativas contam contra a cota On-Demand da família. Duas x2idn.32xlarge são 256 vCPUs; sem o aumento aprovado antes, a segunda reserva falha e o cluster nasce com um nó só.
O NVMe local não existe para o banco. Os 2×1900 GB somem em stop/start. Servem no máximo para área temporária de exportação; qualquer runbook que os mencione para dados persistentes é defeito.
Os sinais que vigio: latência de escrita de log da HANA (KPI que a SAP mede em microssegundos), VolumeQueueLength e VolumeThroughputPercentage dos volumes de data, ReplicationStatus da HSR, e o tempo de takeover medido em teste trimestral de failover. Se o teste não roda, a alta disponibilidade é uma hipótese.
Duas falhas silenciosas desta decisão
Plataforma da reserva diferente da AMI: uma AMI SLES for SAP reporta PlatformDetails: SUSE Linux; se a Capacity Reservation for criada como Linux/UNIX, a instância sobe fora da reserva sem erro nenhum, você paga a reserva vazia e a instância On-Demand, e só descobre na fatura. Confira com aws ec2 describe-images --query Images[*].PlatformDetails antes de criar. Segunda: o x2idn.32xlarge tem sizing OLAP Standard, mas os tamanhos menores da família têm OLAP com sizing Workload, quem dimensiona um BW/4HANA em x2idn.24xlarge sem passar pelo processo de sizing por carga está fora do suporte SAP sem saber.
Eu migraria na próxima janela de fechamento trimestral, não antes, e criaria as duas Capacity Reservations no dia em que a decisão fosse aprovada, mesmo que a migração fosse seis semanas depois, porque capacidade de 128 vCPU em região pequena não se pede na véspera. A lição que carrego de plataformas financeiras: a instância que você adia por causa da próxima geração custa todo mês em tuning defensivo, e a próxima geração nunca chega na sua região na data que você imaginou. Migre para o que existe, deixe a segunda migração escrita no ADR com o comando que a dispara, e teste o failover a cada trimestre, o resto é hipótese.
Veredito
Migre para x2idn.32xlarge em ap-east-1 agora quando: a carga tem obrigação de residência em Hong Kong, precisa de mais de 1 TiB certificado para OLTP e hoje roda em X1. Segure quando: a base cabe em 768 GiB (então r7i.24xlarge ou r8i.24xlarge resolvem com mais SAPS por vCPU) ou quando a residência permite Singapura ou Tóquio, onde X8i já existe. Em qualquer caso, registre a próxima migração no ADR, reserve capacidade com a plataforma correta e trate a espera por X8i como o que ela é, um custo mensal sem data de término.
Referências
Continue lendo
Post-mortems, ADRs e deep dives de arquitetura no seu email, do jeito que um arquiteto lê.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este estudo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.