# ADR: Migrating Financial Workloads to EC2 R8i in Tokyo and Frankfurt

The availability of EC2 R8in, R8ib, R8idn, and R8idb instances in Tokyo, Frankfurt, and Ireland opens a real decision window for financial architectures that depend on sub-millisecond network latency, extreme EBS throughput, and data residency compliance. This ADR documents the reasoning behind adopting — or not — these instances for financial-grade workloads.

- URL: https://fernando.moretes.com/blog/adr-migrando-workloads-financeiros-para-ec2-r8i-no-tokyo-e-frankfurt-amazon-ec2-n

- Markdown: https://fernando.moretes.com/blog/adr-migrando-workloads-financeiros-para-ec2-r8i-no-tokyo-e-frankfurt-amazon-ec2-n/article.md?lang=en

- Published: 2026-07-11T09:03:29.373Z

- Category: AI & Agents

- Tags: ec2, r8i, financial-grade, adr, msk, eks, nitro, network-performance

- Reading time: 10 min

- Source: [Amazon EC2 network/EBS instances now available in additional regions](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r8in-r8ib-r8idn-r8idb)

---

On July 10, 2026, AWS expanded EC2 R8in, R8ib, R8idn, and R8idb instances to the Asia Pacific (Tokyo) and Europe (Frankfurt, Ireland) regions. For financial architectures already operating in these regions due to regulatory requirements — LGPD, GDPR, Japanese FSA — this is not a roadmap announcement. It is an immediate decision trigger.

## Context and Forces at Play

Institutional-grade financial workloads — order matching platforms, intraday risk engines, real-time price caches, settlement pipelines — share a characteristic that distinguishes them from conventional web systems: they are simultaneously **memory-bound**, **network-bound**, and **latency-sensitive**, and must operate within regulatory data residency windows that make region selection non-negotiable.

Before this expansion, R8i instances were only available in us-east-1, us-east-2, us-west-2, and ap-southeast-1 (via earlier announcements). This created a painful architectural asymmetry: the best compute nodes in the R family were geographically inaccessible to systems that must operate in Tokyo under Japanese FSA requirements or in Frankfurt/Ireland under GDPR and EBA guidelines.

The forces making this decision non-trivial are multiple. First, **migration cost**: moving an MSK Kafka cluster or a relational database primary node to a new instance type in production requires maintenance windows, performance regression testing, and SLO validation. Second, **regression risk**: the previous R6in/R6idn generation is still available and is a stable platform — the "if it isn't broken, don't fix it" argument carries real weight in environments where a P1 incident at 2 PM in Tokyo has regulatory consequences. Third, **absolute cost**: 48xlarge and 96xlarge instances carry price tags that justify rigorous ROI analysis, not reflexive adoption.

## Key Technical Capabilities — R8i vs R6i

- **43%** — Compute performance improvement per vCPU vs R6in/R6idn. Custom 6th-gen Intel Xeon Scalable processors, exclusive to AWS
- **600 Gbps** — Network bandwidth (R8in, R8idn) — highest among enhanced networking EC2. Enabled by 6th-generation Nitro Cards
- **300 Gbps** — EBS bandwidth (R8ib, R8idb) — highest among non-accelerated instances. Critical for database and data lake workloads with intensive I/O
- **EFA** — Elastic Fabric Adapter support on 48xlarge, 96xlarge, metal-48xl, and. Reduced latency and improved cluster performance for tightly coupled workloads

## Mapping Financial Workloads to R8i Sub-families

The R8i family is not monolithic — it has four variants with radically different I/O profiles, and the decision of which to use is as important as the decision to migrate.

**R8in** (network-optimized, no local NVMe): The most direct use case for Redis or Memcached-based real-time price cache systems. With 600 Gbps of network bandwidth and abundant memory, an R8in.48xlarge node can serve as the primary node of a self-managed ElastiCache cluster with synchronous replication to multiple AZs in Frankfurt without network being the bottleneck. For MSK (Kafka) pipelines that need brokers with high message ingestion capacity — think high-frequency market feeds with 10M+ events/second — the R8in eliminates the network contention that frequently appears as `NetworkIn` throttling on R6in instances under peak load.

**R8idn** (network + local NVMe): The natural candidate for self-managed Kafka brokers where you need extreme network throughput AND fast local storage for partition logs. In Tokyo, where exchange operators need Kafka brokers with P99 production latency < 2ms, the combination of 600 Gbps network with low-latency local NVMe eliminates two bottlenecks simultaneously.

**R8ib** (EBS-optimized, no NVMe): The canonical case here is Aurora PostgreSQL or RDS for position and reconciliation databases. With 300 Gbps of EBS bandwidth — the highest among non-accelerated instances — you can sustain heavy OLTP workloads with `io2 Block Express` volumes without EBS throughput being the limiting factor. This is relevant for T+1 settlement systems in Frankfurt that need to process batch reconciliations overnight within 2-3 hour windows.

**R8idb** (EBS + local NVMe): Institutional-scale data lakes that use S3 as the storage tier but need local scratch space for intermediate transformations — think Glue or Spark jobs that materialize 500GB+ risk datasets before writing aggregated results back to S3. The local NVMe here is not persistence; it is shuffle acceleration.

## Options Considered: R8i Instance Adoption Strategy

### Option A: Stay on R6in/R6idn — Conservative Stability

**Pros**
- Zero production performance regression risk
- Existing Savings Plans already cover costs
- No need for maintenance windows or SLO retesting

**Cons**
- Misses 43% compute efficiency per vCPU — real opportunity cost on large clusters
- Network bottlenecks during market spikes remain without structural solution
- R6i will eventually reach end of support — migration will be forced under worse conditions

**Verdict:** Valid only as a temporary position with a documented migration plan

### Option B: Big-Bang Migration — Full Immediate Replacement

**Pros**
- Immediate capture of performance and cost efficiency benefits
- Simplifies instance inventory — no managing two generations simultaneously

**Cons**
- High operational risk: multiple critical clusters migrating in parallel
- Requires Savings Plans invalidation and rebuilding — real transition cost
- In regulated financial environments, mass changes require Change Advisory Board (CAB) approval — process latency

**Verdict:** Not recommended for institutional-grade financial environments

### Option C: Phased Migration by Workload Criticality — Selected Approach

**Pros**
- Controlled risk: each phase has limited blast radius and defined rollback
- Allows benefit capture on highest-ROI workloads first (caches, Kafka brokers)
- Savings Plans can be scaled progressively — no abrupt transition penalty
- Compatible with CAB processes and regulatory maintenance windows

**Cons**
- Fleet heterogeneity period — two instance types to monitor and operate
- Full performance benefits take longer to materialize

**Verdict:** Recommended approach — balances value capture with operational risk management

### Option D: Selective Adoption Only for New Workloads (Greenfield)

**Pros**
- Zero impact on existing production systems
- Ideal for new AI/ML cache or 5G UPF services that don't yet have a performance baseline

**Cons**
- Does not resolve existing bottlenecks in R6i clusters already in production
- Increases fleet heterogeneity without a convergence plan

**Verdict:** Complementary to Option C, not a substitute

## The Decision: Phased Migration with SLO Validation Gates

The decision is to adopt **Option C** — phased migration by workload criticality — with explicit SLO validation gates between each phase. The central reasoning is that in regulated financial environments, the speed of new infrastructure adoption is secondary to **operational predictability**. A P1 incident caused by a poorly executed migration in Tokyo at 9 AM JST (market open) has consequences beyond the technical SLA — there are regulatory notifications, incident reports to the FSA, and potential reputational impact.

The phase sequencing is deliberate. **Phase 1** starts with real-time price caches (R8in) — these are the workloads with the highest migration ROI because they are stateless from a persistent data perspective, have trivial rollback (simply point the Auto Scaling Group back to the previous type), and the 600 Gbps network benefit is immediately measurable via `NetworkIn`/`NetworkOut` metrics in CloudWatch. **Phase 2** addresses Kafka brokers — MSK or self-managed (R8idn) — where risk is higher because Kafka has state (partition logs), but the rolling broker restart process is well-documented and tested. **Phase 3** covers database nodes (R8ib for Aurora/RDS, R8idb for data lake processing nodes) — these carry the highest risk and the highest EBS throughput benefit.

Each phase has a validation gate: 72 hours of production observation with defined SLOs (network latency P99, message throughput, EBS IOPS) before proceeding. If any SLO regresses more than 5% relative to the R6i baseline, the phase is rolled back and investigated before continuing. This is not excessive conservatism — it is the minimum operational standard for systems that process real financial transactions.

## R8i Phased Migration Decision Flow in a Financial Environment

Shows the three-phase migration sequencing, SLO validation gates, and the mapping of R8i sub-families to specific financial workloads in Tokyo and Frankfurt.

### 📋 Baseline — R6i (Current)

- R6in Brokers Kafka / MSK (messaging)
- R6ib DB Nodes Aurora / RDS (data)
- R6in Cache Redis / Memcached (storage)

### 🔀 Phase 1 — R8in: Network Cache (Tokyo / Frankfurt)

- R8in.48xlarge 600 Gbps Network Price Cache (compute)
- SLO Gate 1 NetworkIn P99 72h Observation (security)

### 🔀 Phase 2 — R8idn: Kafka Brokers (Tokyo / Frankfurt)

- R8idn.48xlarge 600 Gbps + NVMe Kafka Partition Logs (messaging)
- SLO Gate 2 Msg Throughput P99 72h Observation (security)

### 🔀 Phase 3 — R8ib/R8idb: DB & Data Lake (Frankfurt)

- R8ib.48xlarge 300 Gbps EBS Aurora / RDS (data)
- R8idb.48xlarge EBS + NVMe Glue / Spark Shuffle (storage)
- SLO Gate 3 EBS IOPS / Latency 72h Observation (security)

### 📊 Observability (CloudWatch + OpenTelemetry)

- CloudWatch NetworkIn/Out EBSBytesPerSec (ai)
- OpenTelemetry Collector Datadog Exporter (ai)

### Flows

- r6cache -> r8in_cache: Phase 1: ASG swap
- r8in_cache -> slo1: Validate SLO
- slo1 -> r8idn_kafka: Gate passed → Phase 2
- r6in -> r8idn_kafka: Rolling broker restart
- r8idn_kafka -> slo2: Validate SLO
- slo2 -> r8ib_db: Gate passed → Phase 3
- r6ib -> r8ib_db: Multi-AZ failover
- r8ib_db -> r8idb_lake: Parallel in Phase 3
- r8idb_lake -> slo3: Validate SLO
- r8in_cache -> cw: Network metrics
- r8idn_kafka -> cw: Kafka throughput
- r8ib_db -> otel: EBS IOPS / Latency
- cw -> otel: Unified metrics

## Specific Configurations That Determine Success or Failure

The instance decision is only the beginning. What differentiates a successful migration from a P1 incident are the specific configurations that frequently don't appear in product announcements.

**Placement Groups and EFA**: For 48xlarge, 96xlarge, metal-48xl, and metal-96xl sizes, EFA (Elastic Fabric Adapter) support is a performance multiplier for tightly coupled clusters — but it only works correctly when instances are in a **Cluster Placement Group** in the same AZ. In financial environments with multi-AZ requirements, this creates an architectural tension: you cannot have EFA and multi-AZ simultaneously in the same cluster. The solution is segmentation: use Cluster Placement Groups with EFA for the high-frequency processing tier (matching engine, risk calculation) and Spread Placement Groups for the persistence tier (Kafka brokers, database nodes).

**IAM and KMS for instances with local NVMe (R8idn, R8idb)**: Local NVMe is NOT encrypted by default by AWS — encryption is the responsibility of the operating system or application. In financial environments under GDPR (Frankfurt) or FSA (Tokyo), data at rest on local NVMe must be encrypted. The correct approach is to use `dm-crypt` with LUKS on Linux, with the key derived from a secret stored in AWS Secrets Manager and retrieved via the instance IAM Role with an `aws:SourceVpc` condition. Never hardcode the key directly in user-data.

**Auto Scaling and Instance Refresh**: When using Launch Templates for migration, configure `InstanceRefresh` with `MinHealthyPercentage: 90` and `CheckpointPercentages: [25, 50, 75, 100]` — this ensures the migration pauses at each checkpoint for validation before continuing. For Kafka clusters, configure `MaxBatchSize: 1` to ensure only one broker is replaced at a time, preserving availability of all partitions during migration.

**CloudWatch Alarms for SLO Gates**: Validation alarms must monitor `NetworkPacketsIn`, `EBSWriteBytes`, `EBSWriteOps`, and — critical for Kafka — the custom metric `UnderReplicatedPartitions` via JMX exported to CloudWatch via OTEL agent. A value of `UnderReplicatedPartitions > 0` for more than 60 seconds during a broker migration is an immediate rollback signal.

## Cost Analysis and Purchasing Model: Savings Plans vs On-Demand vs Spot

The availability of R8i instances in Tokyo and Frankfurt via **Savings Plans, On-Demand, and Spot** (as announced) opens three purchasing strategies with distinct trade-offs for financial environments.

**Compute Savings Plans** are the right choice for the capacity baseline of critical workloads — Kafka brokers, database nodes, price caches. The flexibility of Compute Savings Plans (vs. EC2 Instance Savings Plans) is crucial here: it automatically applies to R8in even if you purchased the plan while on R6in, without renegotiation. In terms of numbers: an R8in.48xlarge in Frankfurt with a 1-year Compute Savings Plan offers approximately 38-42% discount over On-Demand — on a 10-node cluster, this represents six-figure annual savings in USD.

**On-Demand** should be the entry position during migration phases — you don't want to be locked into a Savings Plan on an instance type that may need to be rolled back. Use On-Demand for the first 30 days post-migration of each phase, validating the performance baseline before converting to Savings Plan.

**Spot** has limited but real applicability in financial environments: batch risk processing jobs (overnight VaR calculation, stress testing), backtesting pipelines, and R8idb data lake transformations are legitimate Spot candidates. The key is using **Spot with instance type diversification** via `capacity-optimized` allocation strategy in the ASG — include R8idb, R8idn, and R6idn in the same pool to maximize Spot availability. For critical financial batch jobs, use the checkpointing pattern with Step Functions: every 15 minutes of processing, persist intermediate state to S3 with versioning enabled, so a Spot interruption doesn't discard more than 15 minutes of work.

An anti-pattern I see frequently: using Reserved Instances (RI) instead of Savings Plans for new instance generations. RIs are tied to a specific instance type and region — in a generation migration cycle, you get stuck. Compute Savings Plans are the correct choice for any workload that will go through a generation migration in the next 1-3 years.

> **Decision Consequences and Risks:** **1. Local NVMe does not persist across instance stops**: Any data stored on local NVMe of R8idn or R8idb is lost on an instance stop/start (not a reboot). In self-managed Kafka clusters, this means partition logs on local NVMe are destroyed if the instance is stopped — not just rebooted. The correct design is to use NVMe only for temporary writes and have partition logs replicated across at least 3 brokers, with `min.insync.replicas=2`. Never rely on local NVMe as the sole copy of persistent data.

**2. EFA requires security group reconfiguration**: EFA uses a different network interface type that does not follow standard security group rules for inter-node traffic. In environments with Zero Trust posture where all traffic is explicitly permitted, migrating to EFA can silently break inter-node communication if security groups are not updated to allow `All traffic` between placement group members via self-referencing security group rule.

**3. Reserved capacity cost in new regions**: Tokyo and Frankfurt historically have higher On-Demand prices than us-east-1. ROI analysis must be done with region-specific prices, not US prices as a proxy. An R8in.48xlarge in Tokyo may cost 15-20% more than the equivalent in us-east-1 — this affects the Savings Plan breakeven point.

**4. Regulatory compliance for data on NVMe**: In Frankfurt under GDPR, secure destruction of data on local NVMe requires specific sanitization procedures when decommissioning instances. AWS guarantees NVMe sanitization between different customers, but within the same instance lifecycle, encryption and sanitization responsibility belongs to the operator.

## AWS Well-Architected Framework Assessment

- **security**: Encrypt local NVMe with dm-crypt/LUKS and Secrets Manager keys. Use IAM Role with aws:SourceVpc condition for key retrieval. EFA requires explicit self-referencing security group rule. Audit access with CloudTrail for DescribeInstances and ModifyInstanceAttribute.
- **reliability**: Never use local NVMe as the sole copy of persistent data. min.insync.replicas=2 for Kafka. Instance Refresh with CheckpointPercentages for automatic rollback. CloudWatch alarm on UnderReplicatedPartitions > 0 for more than 60s.
- **performance**: Cluster Placement Groups with EFA for high-frequency tiers. Separate processing tiers (EFA+single-AZ) from persistence tiers (Spread+multi-AZ). Validate performance baseline with 72h of production observation before each migration gate.
- **sustainability**: 43% compute performance improvement per vCPU means the same throughput can be achieved with fewer instances — direct reduction in energy consumption. Evaluate consolidating R6i clusters into fewer R8i nodes before migrating to capture both the performance benefit and footprint reduction.

> **Architect's Note:** In practice, what convinces me to recommend the migration to R8in for price caches in Tokyo is not the 600 Gbps number itself — it's the fact that during market open spikes, the bottleneck I repeatedly see on R6in clusters is exactly `NetworkIn` throttling, not CPU or memory. The R8in solves the right problem. That said, the hardest lesson I've learned in instance migrations in financial environments is that the real risk is not in the new instance — it's in the **implicit assumption that the application's network behavior has been tested at speeds it has never seen before**. A Kafka broker that has never processed more than 50 Gbps of throughput may exhibit unexpected behavior when the network bottleneck disappears and the real disk or CPU throughput becomes visible for the first time. Always load test at the theoretical maximum throughput of the new instance before going to production — not just at historical throughput.

## Final Decision

**Adopt R8i instances in Tokyo and Frankfurt via phased migration with SLO gates.** The regional expansion of R8in/R8ib/R8idn/R8idb instances removes the last geographic barrier for regulated financial workloads that needed the R family's leading network and EBS capabilities. The 43% performance gain per vCPU and 600 Gbps network bandwidth are not incremental — they change the bottleneck profile of entire clusters. The decision to migrate is not if, but when and how. The answer to 'when' is: start Phase 1 (R8in caches) in the next planned maintenance cycle. The answer to 'how' is: phased migration with Instance Refresh, 72h SLO gates, NVMe encryption with LUKS, Compute Savings Plans (not RIs), and load testing to theoretical maximum throughput before each promotion to production. For greenfield workloads in Tokyo — especially AI/ML cluster caching or 5G UPF — R8in is the default instance choice starting today.

**Rating:** Adopt — Phased

## References

- [AWS What's New: Amazon EC2 R8in/R8ib/R8idn/R8idb now available in Tokyo, Frankfurt, Ireland (Jul 10, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r8in-r8ib-r8idn-r8idb)
- [Amazon EC2 Instance Types — R8i Family](https://aws.amazon.com/ec2/instance-types/)
- [AWS Nitro System — Nitro Cards and Enhanced Networking](https://aws.amazon.com/ec2/nitro/)
- [Elastic Fabric Adapter (EFA) — User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)
- [EC2 Instance Refresh — Auto Scaling User Guide](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html)
- [AWS Compute Savings Plans — Flexibility Across Instance Families](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html)
- [Amazon MSK Best Practices — Broker Sizing and Instance Types](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)