AWS Graviton 2026: คู่มือลดค่า Compute

อัปเดตล่าสุด: 26 กรกฎาคม 2026

การย้าย workload จาก x86 ไป AWS Graviton ปี 2026 ช่วยลดค่า Compute ได้ประมาณ 20-40% ทันทีสำหรับ EC2, RDS, Aurora, ElastiCache และ Lambda โดยเฉพาะเมื่อใช้ Graviton4 (ตระกูล r8g, c8g, m8g) ซึ่งให้ price-performance ดีกว่า Graviton3 อีก 30% สำหรับ managed service ส่วนใหญ่แค่เปลี่ยน instance type ก็จบ ส่วน container/EC2 ต้อง build multi-arch image และวางแผน rollout ด้วย Karpenter บทความนี้เป็น playbook ที่ผมใช้จริงกับลูกค้าที่เพิ่งตัดบิล EC2 ไป $47,000 ต่อเดือน

Graviton4 (r8g, c8g, m8g) ราคาสูงกว่า Graviton3 เพียง 5-10% แต่ throughput สูงกว่า 30% ทำให้ cost-per-request ต่ำกว่าทุก workload ที่ผม benchmark
ลำดับที่ถูกต้อง คือเริ่มจาก managed service (RDS, ElastiCache, Lambda) เพราะเป็น flip-a-switch ก่อน จากนั้นค่อย EKS/EC2 ซึ่งต้องทำ multi-arch image
Compute Savings Plans และ EC2 Instance Savings Plans ที่ซื้อไว้แล้วครอบคลุม Graviton โดยอัตโนมัติ ไม่ต้องซื้อใหม่ ไม่เสีย commitment
Docker buildx สร้าง image สำหรับ linux/amd64 และ linux/arm64 พร้อมกัน push ไป ECR เป็น manifest list เดียวได้เลย
ข้อจำกัดที่ต้องเช็คก่อนย้าย ได้แก่ Windows Server, ไบนารีที่ต้องใช้ AVX-512, driver kernel แบบเก่า และไลบรารีที่ยังไม่ compile arm64
ตัวอย่างเคสจริง คือ EKS cluster 180 nodes ย้ายไป m7g/r7g ประหยัดปีละ $562,000 โดยไม่แตะ application code เลย

AWS Graviton คืออะไร และประหยัดได้จริงเท่าไหร่?

AWS Graviton คือชิป CPU สถาปัตยกรรม ARM64 (Neoverse) ที่ AWS ออกแบบเองและใช้กับ EC2, RDS, Aurora, ElastiCache, OpenSearch, Lambda และ Fargate ปัจจุบัน (ปี 2026) รุ่นที่ใช้งานกันเยอะที่สุดคือ Graviton3 (ตระกูล c7g, m7g, r7g, x7g) และ Graviton4 ที่เพิ่งครบไลน์ปีที่แล้ว (r8g, c8g, m8g, x8g) โดยตัวเลขที่ AWS โฆษณาคือ price-performance ดีกว่า x86 รุ่นเดียวกันสูงสุด 40% และใช้พลังงานน้อยลง 60%

ตัวเลขจริงจาก workload ที่ผมย้ายให้ลูกค้าปี 2025-2026 อยู่ประมาณนี้:

Web server (nginx, Node.js, Go, Python): ประหยัด 28-32% หลังจากปรับ container ให้เป็น arm64
RDS PostgreSQL, MySQL, Aurora: ประหยัด 25-30% เปลี่ยน instance class อย่างเดียว
Redis / ElastiCache: ประหยัด 30-35% และ latency ต่ำลงเล็กน้อยด้วย
Batch / data processing (Spark on EMR, Airflow worker): ประหยัด 35-40% เพราะ CPU-bound เต็มๆ
Lambda (function invocations >1M/เดือน): ประหยัด 20% ต่อ ms + price-performance ดีขึ้น 34%

ตัวเลขที่หลายทีมพลาด คือ "Graviton ไม่ได้ถูกกว่าแค่ราคา on-demand" แต่ Graviton4 ยังให้ throughput ต่อ core สูงกว่า x86 รุ่นเดียวกัน 20-30% หมายความว่าคุณอาจใช้ instance น้อยลงในการรับ traffic เท่าเดิม ผมเคยเจอเคสที่ web tier ลดจาก 24 c6i.2xlarge เหลือ 16 c7g.2xlarge รับ RPS เท่าเดิม ประหยัดรวมเกือบ 45% (ค่า instance ต่อชั่วโมงลดลง บวกกับจำนวนลดลง)

Graviton3 กับ Graviton4 ต่างกันอย่างไร?

ถ้ายังไม่อยู่บน ARM ตอนนี้ คำถามคือควรข้ามไป Graviton4 เลยไหม คำตอบสั้นๆ ของผมคือ ใช่ ถ้าอยู่ใน region ที่มี เพราะราคาต่อชั่วโมงสูงกว่า Graviton3 เพียง 5-10% แต่ throughput สูงกว่า 30% ทำให้ cost-per-request ถูกกว่าเสมอ ตารางนี้เปรียบเทียบสิ่งที่คุณควรรู้ก่อนเลือก:

คุณสมบัติ	Graviton3 (7g)	Graviton4 (8g)
ตระกูล EC2	c7g, m7g, r7g, x7g, hpc7g	c8g, m8g, r8g, x8g
Core สูงสุดต่อ instance	64 vCPU	192 vCPU
Memory bandwidth	DDR5	DDR5 (+75% เทียบ 3)
Performance ต่อ core	baseline	+30%
ราคาต่อชั่วโมง	ถูกกว่า x86 ~20%	สูงกว่า 7g เพียง 5-10%
RDS support	ครบทุก engine หลัก	ครบทุก engine หลัก (+29% price/perf)
Region availability	ครอบคลุม 30+ region	ค่อยๆ ขยาย ~20 region
เหมาะกับ	ทุก workload ทั่วไป	Compute-bound, ML, in-memory DB

ข้อแนะนำจากงานจริง คือ ถ้าคุณ deploy ผ่าน Karpenter หรือ ASG mixed instance policy ให้ใส่ทั้ง 7g และ 8g ไปเลย Karpenter จะเลือก instance ที่ราคาต่ำสุดในขณะนั้นให้เอง ไม่ต้องเดาว่ารุ่นไหนคุ้มกว่า สำหรับ managed service (RDS, ElastiCache) ผมแนะนำให้ข้ามไป Graviton4 เมื่อ engine version รองรับ เพราะการ resize instance ในภายหลังต้องมี downtime สั้นๆ อยู่ดี

Workload แบบไหนที่ควรย้ายไปก่อน?

ผิดพลาดที่พบบ่อยที่สุดคือทีมเริ่มย้ายจาก EKS หรือ EC2 ก่อน ซึ่งต้องรื้อ CI/CD, rebuild image และทดสอบ compatibility ทั้งหมด กว่าจะได้ savings ก้อนแรกก็ผ่านไป 3 เดือน แถมทีม dev เริ่มไม่เชื่อมั่น ลำดับที่ถูกต้องคือเริ่มจาก zero-code migration ก่อน เพราะเก็บ 60-70% ของ savings ได้ในเวลา 1-2 sprint โดยไม่แตะโค้ด application เลย

Playbook 4 เฟสที่ผมใช้กับลูกค้าทุกราย:

Phase 1 (สัปดาห์ 1-2) Managed services: RDS, Aurora, ElastiCache, OpenSearch, DocumentDB เปลี่ยน instance class เป็น Graviton ผ่าน console หรือ Terraform ครั้งเดียวจบ downtime แค่ช่วง failover
Phase 2 (สัปดาห์ 2-3) Serverless: AWS Lambda สลับ architecture เป็น arm64 ผ่าน parameter เดียว ถ้าใช้ container image ต้องมี multi-arch build ก่อน
Phase 3 (สัปดาห์ 3-8) Stateless containers: ECS/Fargate และ EKS ย้าย service ที่เป็น pure Go, Node.js, Python, Java (JDK 17+) ก่อน เพราะ compatibility สูงมาก
Phase 4 (สัปดาห์ 8+) EC2 stateful และ legacy: service ที่มี native binary หรือ dependency แปลกๆ เช่น .NET Framework, driver พิเศษ ค่อยจัดการรอบสุดท้าย

ถ้าคุณยังไม่มีกลยุทธ์ Savings Plans ที่ครอบคลุม Graviton แนะนำอ่านบทความ Spot Instances, Savings Plans และ Reserved Instances ปี 2026 ก่อน เพราะ Compute Savings Plans ที่คุณมีจะ apply กับ Graviton โดยอัตโนมัติ ไม่ต้องซื้อใหม่

ย้าย RDS, Aurora และ ElastiCache แบบ zero-code

สิ่งที่หลายคนไม่รู้คือฐานข้อมูลมักเป็น line item ที่ใหญ่ที่สุดใน bill AWS ของทีม (บ่อยครั้งใหญ่กว่า EC2 ด้วยซ้ำ) และเป็น zero-code migration ที่คุ้มที่สุด สำหรับ RDS/Aurora ให้เปลี่ยน instance class จาก db.r6i ไป db.r7g หรือ db.r8g ผ่าน Terraform:

# RDS/Aurora Graviton migration ผ่าน Terraform
# ก่อน: db.r6i.2xlarge (x86, Intel Ice Lake)
# หลัง: db.r7g.2xlarge (Graviton3) ประหยัด ~28%

resource "aws_db_instance" "app_primary" {
  identifier             = "app-primary"
  engine                 = "postgres"
  engine_version         = "16.4"       # ต้องรองรับ ARM
  instance_class         = "db.r7g.2xlarge"  # เปลี่ยนจาก db.r6i.2xlarge
  allocated_storage      = 500
  storage_type           = "gp3"
  apply_immediately      = false        # รอ maintenance window
  # เก็บ snapshot ก่อน apply เสมอ
  backup_retention_period = 14
  deletion_protection    = true

  tags = {
    Environment = "prod"
    CostCenter  = "platform"
    GravitonMigrated = "2026-Q3"
  }
}

# Aurora cluster เปลี่ยน instance_class ของ writer + reader
resource "aws_rds_cluster_instance" "aurora_writer" {
  cluster_identifier = aws_rds_cluster.app.id
  instance_class     = "db.r7g.4xlarge"  # ประหยัดกว่า db.r6i ~26%
  engine             = "aurora-postgresql"
  # Aurora รองรับ zero-downtime patch (RDS Blue/Green)
}

ขั้นตอนแนะนำสำหรับ production RDS:

เช็คว่า engine version ปัจจุบันรองรับ Graviton (Postgres 12.7+, MySQL 8.0.17+, MariaDB 10.4.13+, Aurora ทุก version ใหม่)
ใช้ RDS Blue/Green Deployments สร้าง green environment เป็น r7g/r8g แล้ว switchover ใช้เวลา downtime ~30-60 วินาที
Monitor CPU utilization, latency (p50/p95/p99) และ connection count 24-48 ชั่วโมงหลัง cutover
เก็บ blue environment ไว้ 3-5 วันเผื่อ rollback ก่อน delete

สำหรับ workload ฐานข้อมูลอื่น (Redshift Serverless, DynamoDB on-demand, Timestream) ดู คู่มือลดค่าฐานข้อมูลคลาวด์ 2026 ที่ครอบคลุม pattern การลดต้นทุนแบบอื่นไว้ครบ

ย้าย AWS Lambda ให้ทำงานบน arm64

Lambda บน Graviton2/3 (arm64) ราคาต่อ GB-second ถูกกว่า x86 ประมาณ 20% และให้ price-performance ดีขึ้น 34% ตามที่ AWS ประกาศไว้ การย้ายทำได้ 3 แบบขึ้นกับ deployment method:

# วิธีที่ 1: Lambda ที่เขียน Python/Node.js/Ruby แบบ zip package
# แค่เปลี่ยน architecture ใน AWS SAM หรือ Terraform เท่านั้น

# terraform
resource "aws_lambda_function" "image_resize" {
  function_name = "image-resize"
  runtime       = "python3.13"
  handler       = "index.handler"
  architectures = ["arm64"]          # <-- เปลี่ยนจาก ["x86_64"]
  memory_size   = 1024
  timeout       = 30
  # โค้ด Python ทั่วไปทำงานได้ทันที
}

# วิธีที่ 2: Lambda container image ต้อง multi-arch build
# ตอน build container image ต้องใช้ buildx และ push manifest list
docker buildx build \
  --platform linux/arm64 \
  -t <ACCOUNT>.dkr.ecr.ap-southeast-1.amazonaws.com/image-resize:v42-arm64 \
  --push .

# วิธีที่ 3: Lambda ที่ใช้ Layer ที่มี compiled binary (เช่น psycopg2, Pillow)
# ต้อง rebuild layer สำหรับ arm64 หรือใช้ AWS-provided arm64 layer
# ตัวอย่าง Dockerfile สำหรับ compile layer:
FROM public.ecr.aws/lambda/python:3.13-arm64 AS builder
RUN pip install --target /opt/python psycopg2-binary Pillow

Gotcha ที่พบบ่อย: ถ้า Lambda function ของคุณ import ไลบรารีที่มี C extension (numpy, pandas, cryptography, lxml) ต้อง reinstall จาก wheel arm64 ผมแนะนำให้ pin runtime เป็น python3.13 หรือใหม่กว่า เพราะ AWS pre-compile ไลบรารีหลักไว้ให้อยู่แล้ว หากใช้ Node.js ให้ระวังโมดูล native เช่น node-canvas, sharp, bcrypt ต้องมี prebuilt binary สำหรับ arm64

ถ้าคุณยังไม่ได้ทำ FinOps สำหรับ serverless เป็นระบบ แนะนำอ่าน คู่มือลดค่า Serverless 2026 คู่กับบทความนี้ เพราะการเปลี่ยน architecture เป็นแค่ lever เดียวจากหลายตัว (memory tuning, provisioned concurrency, tiered pricing)

ย้าย EKS ไป Graviton ด้วย Karpenter และ Docker multi-arch

ส่วนที่ท้าทายที่สุดคือการย้าย EKS ซึ่งต้องแก้ 3 เรื่องพร้อมกัน คือ (1) CI/CD build multi-arch image, (2) node group รองรับ arm64 และ (3) tolerations/nodeSelector ควบคุมว่า pod ไหนไปรันบนอะไร ผมแนะนำใช้ Karpenter เพราะ manage node ตาม demand และเลือก instance type ที่ราคาถูกที่สุดในขณะนั้นได้อัตโนมัติ

ขั้นที่ 1: Build multi-arch image ด้วย docker buildx

# .github/workflows/build.yml
name: build-multiarch
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gh-actions-ecr
          aws-region: ap-southeast-1

      - uses: aws-actions/amazon-ecr-login@v2

      - uses: docker/setup-qemu-action@v3
      - uses: docker/setup-buildx-action@v3

      - name: Build & push multi-arch image
        run: |
          docker buildx build \
            --platform linux/amd64,linux/arm64 \
            --tag 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/api:${{ github.sha }} \
            --tag 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/api:latest \
            --cache-to type=gha,mode=max \
            --cache-from type=gha \
            --push .

ขั้นที่ 2: Karpenter NodePool ที่รองรับทั้ง x86 และ arm64

# karpenter-nodepool-graviton.yaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: [c7g, m7g, r7g, c8g, m8g, r8g, c7i, m7i, r7i]
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values: ["2", "4", "8", "16"]
        - key: kubernetes.io/arch
          operator: In
          values: [amd64, arm64]     # อนุญาตทั้งคู่ในช่วง transition
        - key: karpenter.sh/capacity-type
          operator: In
          values: [spot, on-demand]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: 2000

ขั้นที่ 3: ค่อยๆ push workload ไป arm64 โดยใส่ nodeSelector ทีละ service ให้ preferredDuringScheduling ไป arm64 ก่อน แล้วดู error rate 24 ชั่วโมง ถ้า healthy ค่อยเปลี่ยนเป็น required ตามคำแนะนำใน AWS blog: Migrating from x86 to Graviton on EKS with Karpenter แบบ progressive rollout

# Deployment ที่ prefer arm64 แต่ยัง fallback ไป amd64 ได้
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 8
  template:
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              preference:
                matchExpressions:
                  - key: kubernetes.io/arch
                    operator: In
                    values: [arm64]
      containers:
        - name: api
          image: 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/api:v42
          resources:
            requests: {cpu: 500m, memory: 512Mi}
            limits:   {cpu: 1000m, memory: 1Gi}

เมื่อทุก service มี multi-arch image แล้ว ให้ลบ amd64 ออกจาก NodePool เพื่อให้ Karpenter provision แต่ arm64 ล้วน (Graviton จะถูกกว่าเสมอ) ถ้ายังไม่ได้อ่านเรื่อง node autoscaling / consolidation ควรอ่าน คู่มือ Kubernetes Cost Optimization 2026 ประกอบ เพราะ Graviton + Karpenter + Bin-packing เป็น combo ที่ให้ผลลัพธ์ดีที่สุด

อะไรที่ย้ายไป Graviton ไม่ได้ และวิธี rollback

ไม่ใช่ทุก workload ที่ย้ายไป Graviton ได้ ผมเจอ 5 กลุ่มนี้บ่อยที่สุดที่ต้องคงบน x86:

Windows Server workloads: AWS ไม่ support Windows บน Graviton ยังต้องใช้ Intel/AMD เท่านั้น
Application ที่ใช้ AVX-512: เช่น video encoder บางตัว, งาน HPC scientific computing บาง library ต้อง fall back ไป c7i, c6i หรือ hpc7a
Native binary/proprietary agent: Oracle client (บาง version), APM agent, security agent, driver ที่ vendor ยังไม่ compile arm64
.NET Framework (Windows-based): .NET Core / .NET 6+ ทำงานได้บน arm64 แต่ .NET Framework 4.x ต้องอยู่ x86
Container base image ที่หายาก: image เก่าที่ยังไม่ push arm64 tag เช่น image legacy ของ enterprise product

Rollback plan ที่ควรมีก่อน production cutover:

เก็บ ASG/Launch Template เดิม (x86) ไว้อีก 7-14 วัน หลัง migration พร้อม scale เป็น 0 desired
Aurora/RDS: อย่า delete blue environment ทันที เก็บไว้ 3-5 วัน
Deployment: ใช้ Flagger หรือ Argo Rollouts ทำ progressive traffic shift ไม่ใช่ swap 100% ทีเดียว
Metrics ที่ต้อง monitor ได้แก่ latency p99, CPU throttling, memory usage, request error rate เพราะ Graviton behavior ต่างจาก x86 เล็กน้อยเรื่อง cache line size และ branch prediction
ถ้า Node.js app มี GC pause นานกว่าเดิม ให้ปรับ --max-old-space-size ลง 15-20% เพราะ ARM ใช้ page size ต่างกัน

วัดผลด้วย Compute Optimizer และ Graviton Savings Dashboard

AWS มีเครื่องมือฟรี 2 ตัวที่ควรใช้ควบคู่กันเสมอ ตัวแรกคือ AWS Compute Optimizer ที่แนะนำ Graviton equivalent ให้ทุก EC2, ASG, EBS volume และ Lambda function โดยดูจาก CloudWatch metrics 14 วันย้อนหลัง อีกตัวคือ Graviton Savings Dashboard ที่ deploy บน account ตัวเองผ่าน CloudFormation template ของ AWS Labs (ดู aws-graviton-getting-started บน GitHub) แสดง projected savings รายเดือนแบบเจาะรายละเอียด instance

Query ที่ผมใช้ทุกเดือนหลัง migration เพื่อ track savings จริงบน CUR 2.0:

-- Athena query บน Cost and Usage Report 2.0
-- แยก compute cost ระหว่าง Graviton (g/gd suffix) vs x86
SELECT
  bill_billing_period_start_date AS month,
  CASE
    WHEN regexp_like(line_item_usage_type, '(g|gd|gn|gt)\.') THEN 'Graviton'
    ELSE 'x86'
  END AS architecture,
  SUM(line_item_unblended_cost)  AS spend_usd,
  SUM(line_item_usage_amount)    AS hours_used
FROM cur2
WHERE line_item_product_code IN ('AmazonEC2','AmazonRDS','AmazonElastiCache')
  AND bill_billing_period_start_date >= date_add('month', -6, current_date)
GROUP BY 1, 2
ORDER BY 1, 2;

ผลลัพธ์จริงที่ผม report ให้ CTO ประจำเดือน มักออกมาแบบนี้: 3 เดือนแรก Graviton spend ค่อยๆ ขึ้นจาก 8% ไป 34% แล้วถึง 61% ของ total compute, blended cost per compute-hour ลดลง 22% รวมเดือนที่ 6 บิลรวมลดลง $47,000/เดือน ไม่รวม Savings Plans discount ที่ยัง apply ต่อ ถ้าอยากทำ anomaly detection ให้ระบบเตือนเมื่อ Graviton adoption ลดลงกะทันหัน (เช่น deploy ใหม่ที่พลาด multi-arch) แนะนำอ่าน Cloud Cost Anomaly Detection 2026 คู่กัน

คำถามที่พบบ่อย

การย้ายไป AWS Graviton ประหยัดได้เท่าไหร่?

โดยเฉลี่ยประหยัด 20-40% ต่อชั่วโมง instance เดียวกัน โดย workload ประเภท batch, container และฐานข้อมูลจะเห็นผลชัดเจนที่สุด (25-40%) ส่วน web/API server ทั่วไปจะได้ราว 20-30% ตัวเลขนี้ยังไม่รวมผลจาก throughput ที่สูงขึ้นซึ่งอาจทำให้ใช้ instance น้อยลงอีก 10-20%

ต้อง rebuild Docker image ใหม่ไหมเมื่อย้ายไป Graviton?

ใช่ ถ้า image เดิมเป็น linux/amd64 อย่างเดียว ต้อง build ใหม่เป็น multi-arch (linux/amd64 + linux/arm64) ด้วย docker buildx build --platform linux/amd64,linux/arm64 แล้ว push เป็น manifest list ไป ECR หลังจากนั้น Kubernetes จะเลือก layer arm64 ให้อัตโนมัติเมื่อ pod schedule ไปบน Graviton node

Compute Savings Plans ครอบคลุม Graviton หรือไม่?

ครอบคลุมทั้งหมด Compute Savings Plans และ EC2 Instance Savings Plans (ตระกูล instance เดียวกัน) apply กับ Graviton โดยอัตโนมัติ ไม่ต้องซื้อใหม่ ไม่เสีย commitment เดิม เป็นเหตุผลหนึ่งที่ทำให้ Compute Savings Plans เป็นตัวเลือกที่ยืดหยุ่นที่สุดสำหรับทีมที่ทำ FinOps ระยะยาว

RDS และ Aurora รองรับ Graviton ครบทุก engine หรือยัง?

รองรับครบทุก engine หลัก (PostgreSQL, MySQL, MariaDB, Aurora PostgreSQL, Aurora MySQL) ในทุก major version ที่ยัง supported ส่วน SQL Server ยังไม่มี Graviton support เพราะเป็น Windows-based สำหรับ Oracle รองรับบางเวอร์ชันเฉพาะ Graviton3 (db.r7g) ควรเช็คใน RDS console ว่า instance class ที่คุณต้องการเปิดใช้ในภูมิภาคของคุณหรือยัง

ควรข้ามจาก x86 ไป Graviton4 เลย หรือย้ายไป Graviton3 ก่อน?

ข้ามไป Graviton4 เลยถ้า region คุณมี instance ตระกูล 8g และ managed service (RDS 8g class) พร้อมใช้ เพราะราคาต่อชั่วโมงสูงกว่า Graviton3 เพียง 5-10% แต่ throughput ดีกว่า 30% cost-per-request จะถูกกว่าเสมอ ในกรณี Karpenter/ASG ให้ใส่ทั้ง 7g และ 8g ในรายการ instance ที่อนุญาต แล้วปล่อยให้ scheduler เลือกตัวที่ราคาถูกสุดในขณะนั้น