ADR: S/4HANA in Hong Kong — X2idn Landed, Migrate Now or Wait for X8i?

The scenario is concrete: a financial core on S/4HANA, a HANA database with about 1.3 TiB of data in memory, and a contractual plus regulatory obligation to keep data and processing in Hong Kong. Until this week, anyone needing more than 1 TiB of certified memory in that Region effectively had the X1 family — Xen instances that AWS's own storage reference flags with the note 'we suggest migrating to a Nitro instance type'.

AWS's SAP certification table lays the gap bare. x1.32xlarge: 1,952 GiB, 131,500 SAPS, 25 Gbps network, 14,000 Mbps storage. x2idn.32xlarge: 2,048 GiB, 196,050 SAPS, 100 Gbps, 80,000 Mbps. That is not an incremental upgrade — it is 49% more SAPS and 5.7× the EBS bandwidth inside the same memory envelope.

The forces pulling on the decision:

Data residency: the workload does not leave ap-east-1. Singapore and Tokyo already have X8i; Hong Kong does not appear on any page I opened.

Restart window: changing instance type means stopping the database and reloading 1.3 TiB into memory. Every change is a window negotiated with the business, and I do not want to negotiate two in the same year without cause.

Capacity: a 128-vCPU instance in a small Region is exactly the profile that returns InsufficientInstanceCapacity on failover day.

Cost to maintain: the on-call rota is the same for X1, X2idn or X8i; what changes is how many I/O incidents and capacity tickets it handles per quarter.

The wrong question is 'is X2idn faster than X1?'. The answer is yes and it decides nothing. The right question is: knowing X8i is not in Hong Kong and has no date, is it worth migrating now and possibly migrating again, or holding on X1?

I considered four paths. Scale-out was ruled out up front: for OLTP (S/4HANA) the scale-out certification in AWS's table only exists on the high-memory U family, capped at 4 nodes; X2idn and X2iedn are certified for scale-out only on OLAP.

Option A — stay on X1. Zero window now, zero regression risk. The price is operating 14,000 Mbps of storage with a database whose delta merges and savepoints already compete for I/O at month-end close. Every quarter on X1 is one more quarter of tuning that does not survive the migration.

Option B — X2idn in ap-east-1 now. x2idn.32xlarge is certified for production OLTP with Standard sizing. You gain 49% SAPS and the EBS bandwidth to leave the defensive-tuning regime. You accept it is a 2022 generation and that X8i will arrive someday.

Option C — wait for X8i in Hong Kong. AWS announced X8i in January 2026 with 50% more SAPS and 3.4× the memory bandwidth of X2i, and has been expanding Region by Region. The problem is that 'someday' is not a date. Waiting means staying on X1 indefinitely, and the wait has a monthly cost.

Option D — X8i in Singapore. Technically the best instance; regulatorily, a non-starter. Data residency is not a negotiable non-functional requirement — it is the requirement that made the workload exist in this Region.

Option B has an honest flaw: if X8i lands in ap-east-1 in six months, I will have done two migrations in a year. The question that settles it is: what does each extra month on X1 cost compared with a second migration window? The matrix below records the reasoning.

I choose Option B and record C as its successor. The reasoning that closes the ledger: a second migration costs one window; staying on X1 costs every month. When that second window comes, it will be between two Nitro generations with the same EBS layout — far cheaper than leaving Xen.

Size: x2idn.32xlarge, not x2idn.24xlarge. 1.3 TiB in 1,536 GiB is 85% occupancy — HANA needs headroom for delta merges and yearly growth; 2,048 GiB buys two years. A detail many skip: in AWS's table, x2idn.16xlarge and x2idn.24xlarge carry OLAP with Workload sizing (per-workload approval); only the 32xlarge is Standard in both categories.

Storage: I follow AWS's 2 TiB reference — /hana/data 2,500 GiB gp3 at 8,100 IOPS and 875 MB/s; /hana/log 500 GiB gp3 at 3,000 IOPS and 300 MB/s; /hana/shared 1,024 GiB. All encrypted with our own KMS CMK, with the ec2:Encrypted condition on the policy of whoever creates volumes. The 2×1900 GB local NVMe stays out of the data path.

Capacity: one immediate-use On-Demand Capacity Reservation per node, in each AZ, with platform SUSE Linux matching the AMI's PlatformDetails exactly. Paired with a Compute Savings Plan, which is what brings the discount — the reservation alone brings none. Before creating it I request a raise of the X-family On-Demand quota in ap-east-1: an active reservation counts against the quota even while empty.

High availability: synchronous HANA System Replication across two AZs, a Pacemaker cluster moving the overlay IP in the route table. Instances and reservations carry the tag sap:role=hana-primary|hana-secondary, and an SCP with aws:RequestedRegion restricted to ap-east-1 makes residency independent of human discipline.

A decision is only recorded once its consequences are written down. These are the ones I take on.

A second migration is scheduled without a date. When X8i shows up in ap-east-1 — I confirm with aws ec2 describe-instance-type-offerings --region ap-east-1 --filters Name=instance-type,Values=x8i.*, not with an announcement — the path is: swap the secondary first, let HSR resync, take over, then swap the old primary. The 2 TiB EBS layout is the same across both generations, so the window is a takeover, not a full reload.

An empty reservation is a full bill. An immediate-use ODCR bills from creation, occupied or not. If the secondary sits stopped for two days of maintenance, the reservation keeps billing. I alarm on reservation utilization and ReservationState; a reservation with no instance for more than 24h opens a FinOps incident, not an infra one.

The quota becomes a project dependency. Active reservations count against the family's On-Demand quota. Two x2idn.32xlarge are 256 vCPUs; without the raise approved beforehand, the second reservation fails and the cluster is born with a single node.

Local NVMe does not exist for the database. The 2×1900 GB vanish on stop/start. At most they serve as scratch space for exports; any runbook mentioning them for persistent data is a defect.

The signals I watch: HANA log write latency (the KPI SAP measures in microseconds), VolumeQueueLength and VolumeThroughputPercentage on data volumes, HSR ReplicationStatus, and takeover time measured in a quarterly failover test. If the test does not run, high availability is a hypothesis.