# ADR: S/4HANA em Hong Kong — X2idn chegou, migrar agora ou esperar X8i? Em 11 de setembro de 2026 a AWS habilitou as instâncias X2idn em Asia Pacific (Hong Kong). Para um core financeiro em S/4HANA que não pode sair da região, é a primeira instância Nitro de 2 TiB certificada para HANA produtivo ali — 49% mais SAPS e 5,7× mais banda de EBS que o x1.32xlarge. Este ADR registra por que eu migro agora, aceitando uma segunda migração para X8i quando ela chegar. - URL: https://fernando.moretes.com/blog/adr-s-4hana-em-hong-kong-x2idn-chegou-migrar-agora-ou-esperar-x8i-amazon-ec2-x - Markdown: https://fernando.moretes.com/blog/adr-s-4hana-em-hong-kong-x2idn-chegou-migrar-agora-ou-esperar-x8i-amazon-ec2-x/article.md?lang=pt - Published: 2026-09-12T10:15:24.220Z - Category: IA & Agentes - Tags: SAP HANA, EC2 X2idn, ADR, ap-east-1, Capacity Reservations, EBS gp3, High Availability, FinOps - Reading time: 7 min - Source: [Amazon EC2 X2idn instances are now available in Asia Pacific (Hong Kong)](https://aws.amazon.com/about-aws/whats-new/2026/09/ec2-x2idn-asia-pacific-hong-kong/) --- 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) **Pros** - Nenhuma janela de migração agora - Configuração conhecida, runbooks maduros **Cons** - 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 **Verdict:** Rejeitada: adia o custo, não o elimina ### B — X2idn agora (x2idn.32xlarge) **Pros** - 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 **Cons** - Geração de 2022; provável segunda migração para X8i - NVMe local é efêmero — inútil para /hana/data **Verdict:** Escolhida: resolve o gargalo hoje e mantém a trilha para X8i ### C — Esperar X8i em Hong Kong **Pros** - 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) **Cons** - Sem data; nenhuma página aberta lista ap-east-1 - Cada mês de espera é um mês no X1 **Verdict:** Rejeitada como plano; mantida como próximo passo ### D — X8i em Singapura **Pros** - Melhor instância disponível hoje na Ásia **Cons** - 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 **Verdict:** 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. ### 📡 Rede — endpoint estável - Overlay IP route table /32 (network) - Pacemaker fence + move route (security) ### 🟧 AWS — AZ a (primário) - x2idn.32xlarge 2.048 GiB · 196.050 SAPS (compute) - EBS gp3 · KMS CMK data 2.500 GiB 875 MB/s · log 500 GiB (storage) - ODCR AZ a platform SUSE Linux (security) ### 🟧 AWS — AZ b (secundário) - x2idn.32xlarge HSR sync target (compute) - EBS gp3 · KMS CMK mesmo layout (storage) - ODCR AZ b platform SUSE Linux (security) ### 📤 Proteção e futuro - S3 backup (Backint) lifecycle + Object Lock (storage) - X8i em ap-east-1 quando chegar (external) ### Fluxos - app -> oip: SQL porta 3xx15 - oip -> p: rota ativa - pcmk -> oip: failover: troca rota - p -> s: HSR síncrona - p -> pebs: /hana/data /hana/log - s -> sebs: /hana/data /hana/log - crA -> p: garante capacidade - crB -> s: garante capacidade - p -> s3: backup diário + logs - s -> x8i: próxima migração: secundário primeiro ## 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. > **Nota do curador:** 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. **Rating:** Adotar agora / Adopt now ## Referências - [AWS What's New — Amazon EC2 X2idn instances are now available in Asia Pacific (Hong Kong)](https://aws.amazon.com/about-aws/whats-new/2026/09/ec2-x2idn-asia-pacific-hong-kong/) - [Amazon EC2 X2i instances — sizes, memory, NVMe, network and EBS bandwidth](https://aws.amazon.com/ec2/instance-types/x2i/) - [SAP on AWS — SAP HANA certified and non-certified instances (SAPS, sizing, scale-out limits)](https://docs.aws.amazon.com/sap/latest/general/sap-hana-aws-ec2.html) - [SAP HANA on AWS — EBS storage reference layouts by memory size](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-storage-config-reference-layout.html) - [Amazon EC2 User Guide — On-Demand Capacity Reservations (platform matching, quotas, billing)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) - [AWS What's New — Announcing Amazon EC2 memory-optimized X8i instances (Jan 2026)](https://aws.amazon.com/about-aws/whats-new/2026/01/aws-amazon-ec2-x8i-generally-available) - [AWS News Blog — New Amazon EC2 X2idn and X2iedn instances for memory-intensive workloads (2022)](https://aws.amazon.com/blogs/aws/new-amazon-ec2-x2idn-and-x2iedn-instances-for-memory-intensive-workloads-with-higher-network-bandwidth/)