EC2 Graviton4 新内存优化实例 GA：r8g 实测迁移全记录

背景

上个月老板扔过来一个任务："数据库连接池服务器 r6i.4xlarge 的账单太贵了，想办法降。" 查了一下 Cost Explorer，光 r6i 系列每月就烧掉不少。刚好赶上亚马逊云科技 5 月放出 Graviton4 的新内存优化实例族（r8g），决定做个迁移验证。

Graviton4 是什么

Graviton4 是亚马逊云科技自研的第四代 ARM 处理器。相比 Graviton3：

• 单核性能提升约 30%
• 内存带宽提升约 75%
• 每 vCPU 可用内存更大

r8g 系列是基于 Graviton4 的内存优化实例，定位替换 r6i/r6a/r7i 场景。

迁移步骤

1. 确认兼容性

先检查现有应用是否支持 ARM64：

# 检查当前架构
uname -m
# x86_64 → 需要重新编译或确认容器镜像有 arm64 版本

# 如果是容器化应用，检查镜像
docker manifest inspect your-image:latest | grep architecture

我们的场景是 Java 21 + Spring Boot 容器化部署，直接换 ARM64 基础镜像就行：

# 从 amazoncorretto:21 换成 arm64 版本
FROM amazoncorretto:21-al2023
# 其余不变，Java 字节码跨平台

2. 创建测试实例

aws ec2 run-instances \
  --instance-type r8g.4xlarge \
  --image-id ami-0xxx  \  # AL2023 ARM64 AMI
  --subnet-id subnet-xxx \
  --security-group-ids sg-xxx

3. 压测对比

用 wrk 做 HTTP 负载测试，同样的请求量：

指标	r6i.4xlarge	r8g.4xlarge	变化
QPS	12,400	16,800	+35%
P99 延迟	45ms	28ms	-38%
CPU 使用率	78%	52%	-33%

内存带宽测试（STREAM benchmark）：

# r6i.4xlarge
Copy: 38,200 MB/s
# r8g.4xlarge  
Copy: 66,800 MB/s  # +75%

4. Auto Scaling Group 灰度切换

# 创建新的启动模板版本
aws ec2 create-launch-template-version \
  --launch-template-id lt-xxx \
  --source-version 3 \
  --launch-template-data '{"InstanceType":"r8g.4xlarge","ImageId":"ami-arm64"}'

# ASG 混合实例策略，逐步替换
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name prod-pool \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "Overrides": [
        {"InstanceType": "r8g.4xlarge", "WeightedCapacity": "1"},
        {"InstanceType": "r6i.4xlarge", "WeightedCapacity": "1"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandPercentageAboveBaseCapacity": 100
    }
  }'

先 50/50 混部跑一周，监控无异常后全量切换。

踩过的坑

坑 1：依赖库没有 ARM64 版本

有一个 native JNI 库只编译了 x86_64。解决方案：

# 在 Graviton 实例上重新编译
sudo yum install -y gcc make
cd /path/to/native-lib
make clean && make ARCH=aarch64

坑 2：AMI 选错了

第一次用了 x86_64 的 AMI 启动 r8g 实例，直接报错 UnsupportedOperation。ARM 实例只能用 arm64 AMI。

坑 3：Spot 价格历史不够

r8g 刚 GA，Spot 市场供给还不稳定。前两周建议用 On-Demand，等 Spot 池子稳定了再切。

适合迁移的场景

• Java/Python/Go/Node.js 应用 — 这些语言天然跨架构
• 容器化微服务 — 多架构镜像 build 一下就完事
• Redis/Memcached 缓存集群 — 内存带宽敏感
• 数据库连接池/中间件 — 内存密集

不适合的场景

• 重度依赖 x86 专有指令集（AVX-512 等）的 HPC 计算
• 有大量无法重编译的闭源 x86 二进制依赖
• Windows 工作负载（Graviton 只支持 Linux）

我的建议

1. 先跑 Cost Explorer — 看你的 r6i/r6a/r7i 开销占比，超过 EC2 账单 15% 就值得评估
2. 容器化应用优先迁 — 改一行 Dockerfile 的事
3. 用 ASG 混合实例灰度 — 不要一刀切，先跑一周看稳定性
4. 监控关注点 — CPU 使用率、内存带宽、JIT 编译耗时（Java 首次启动可能慢几秒）

---

参考：亚马逊云科技 2026/5 月 EC2 Graviton4 实例族 GA 公告