AWS Graviton миграция ARM64: EC2 RDS La…

Актуализирано: 12 юли 2026 г.

Миграцията към AWS Graviton е най-бързият начин да намалиш EC2, RDS и Lambda сметките си с 20–40% през 2026 г. без да пренаписваш нито един ред код. Graviton4 инстанциите (M8g, C8g, R8g, X8g) предлагат 30% по-добра производителност спрямо Graviton3 и 40% по-добро съотношение цена/производителност спрямо x86, а за повечето workloads смяната се свежда до промяна на типа инстанция или до един параметър в Lambda конфигурацията. Честно казано, ако още не си пробвал, ще се изненадаш колко е безболезнено. В този наръчник ще прегледаме реални benchmark-и, стъпка-по-стъпка миграционен план за EC2/RDS/Lambda и как да комбинираш Graviton със Compute Savings Plans за композирани спестявания.

Graviton4 (M8g, C8g, R8g) дава 40% по-добро price/performance спрямо x86 еквиваленти като m7i и c7i, при 20% по-ниска почасова цена.
За 70–90% от workload-ите миграцията изисква само смяна на instance type; Lambda преминава на ARM64 с една конфигурационна промяна и няма промени в кода.
RDS/Aurora на Graviton поддържа MySQL 8.0+, PostgreSQL 12+, MariaDB 10.5+ и Aurora, докато Oracle и SQL Server остават на x86.
AWS Graviton Savings Dashboard анализира твоя CUR за 1 час и класифицира ресурси в "Typically Easy" срещу "Requires Additional Planning".
Compute Savings Plans се прилагат автоматично върху Graviton инстанции, така че комбинацията дава ефективни спестявания от 40–55%.
Windows, GPU (P/G/Inf), Oracle DB и .NET Framework (не .NET 6+) НЕ са съвместими, така че планирай изключения предварително.

Какво е AWS Graviton и защо е важен за FinOps

AWS Graviton е семейство ARM-базирани процесори, проектирани от AWS специално за EC2, изградени върху Arm Neoverse ядра. Актуалното поколение е Graviton4, базирано на Neoverse V2, което захранва инстансите M8g (general purpose), C8g (compute-optimized), R8g/X8g (memory-optimized) и I8g (storage-optimized). Според официалната страница на AWS Graviton над 120,000 клиенти вече използват Graviton в production.

Разликата с x86 не е просто цената. В x86 vCPU е логическо ядро от hyperthreading, като две vCPU-та споделят един физически. В Graviton всеки vCPU е физическо ядро, което елиминира noisy-neighbor ефекти при steady-state натоварване и дава по-предсказуемо latency. За FinOps това означава, че не само плащаш по-малко за час, но и по-често можеш да смалиш инстанцията си (right-size), защото реалната производителност на един Graviton vCPU е по-висока от един x86 vCPU при CPU-bound workloads.

За FinOps екип Graviton миграцията седи над Savings Plans в йерархията на оптимизациите: първо намаляваш on-demand цената чрез смяна на архитектурата, а после прилагаш reservation-based discount отгоре. Двата ефекта се композират, не се дублират. Ако вече използваш Compute Savings Plan, той автоматично покрива и новите Graviton инстанции, така че не се налага да купуваш нови ангажименти.

Колко можеш да спестиш с миграция към Graviton?

Директният отговор: 20–40% на почасова цена при on-demand, което се превръща в 15–25% реални спестявания след Savings Plan discount. В моята работа с клиенти виждам следните типични резултати за реални production workloads:

Метрика	x86 (m7i.2xlarge)	Graviton4 (m8g.2xlarge)	Разлика
Почасова цена (us-east-1, on-demand)	$0.4032	$0.3226	-20%
CPU производителност (SPECrate2017_int)	референс	+30%	+30%
Price/performance	референс	+40%	+40%
Енергийна консумация	референс	-60%	-60%
vCPU архитектура	hyperthreaded	физически ядра	N/A
Максимална RAM (M8g)	N/A	до 3 TiB (X8g)	N/A

Ето един конкретен пример от полето. Fintech екип, с който работих миналото тримесечие, мигрира REST API от m5.large към m6g.large и вижда 23% намаление на compute разходите при идентични P95 latency. Едно enterprise разгръщане мигрира 60% от workload-ите за няколко седмици и намали месечната сметка от $50,000 на $27,500, което е 45% спестяване след композиране с Savings Plans. За контекст: според моите изчисления средно enterprise с 1,000+ инстанции може да очаква $150,000+ годишни спестявания само от EC2 частта.

Как да мигрирам EC2 workloads към Graviton4 (стъпка по стъпка)

Миграцията на EC2 workload към Graviton минава през пет фази: анализ на съвместимостта, изграждане на ARM64 AMI, canary rollout през Auto Scaling Group, benchmark срещу x86 baseline, и накрая пълна замяна. Ключово е да не мигрираш всичко наведнъж. Започваш със stateless слоеве (web, API, batch workers) и оставяш databases за по-късно, когато имаш увереност.

Стъпка 1: Оценка на съвместимостта с Porting Advisor

AWS Graviton Porting Advisor е CLI инструмент, който сканира source код и открива x86-specific зависимости, хардкоднати assembly или библиотеки без ARM64 wheels. Особено полезен е за C/C++, Go, Python native extensions и .NET проекти.

# Инсталиране и стартиране на Porting Advisor
git clone https://github.com/aws/porting-advisor-for-graviton.git
cd porting-advisor-for-graviton
pip install -r requirements.txt

# Сканирай Python codebase
python3 src/porting-advisor.py \
  --root /path/to/your/repo \
  --output report.html \
  --output-format html

# Резултатът категоризира findings като:
# - MAJOR: изисква код промяна (напр. inline x86 assembly)
# - MINOR: трябва рекомпилация или подмяна на dependency
# - INFO: съвместимо, но с performance забележки

Стъпка 2: Изграждане на ARM64 контейнер образи

Ако workload-ите ти са контейнеризирани, използвай docker buildx за multi-arch images. Един и същ tag работи и на x86, и на ARM64 nodes, така че избягваш поддържане на отделни production pipelines.

# Настрой buildx builder с multi-platform поддръжка
docker buildx create --name multi-arch-builder --use
docker buildx inspect --bootstrap

# Изгради и push-ни multi-arch image
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag 123456789012.dkr.ecr.us-east-1.amazonaws.com/api:v2.4.0 \
  --push \
  .

# Провери manifest-а
docker buildx imagetools inspect \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/api:v2.4.0
# Трябва да покаже И linux/amd64, И linux/arm64 варианти

Стъпка 3: Launch template с Graviton AMI

За Auto Scaling Group workloads създай нова версия на launch template с Graviton-съвместим AMI (Amazon Linux 2023 arm64, Ubuntu ARM64 или Bottlerocket ARM64) и подходящ instance type.

# Създай нова версия на launch template с m8g instance
aws ec2 create-launch-template-version \
  --launch-template-name api-fleet \
  --source-version 12 \
  --launch-template-data '{
    "ImageId": "ami-0abcd1234567890ef",
    "InstanceType": "m8g.large",
    "InstanceRequirements": {
      "VCpuCount": {"Min": 2, "Max": 4},
      "MemoryMiB": {"Min": 8192},
      "CpuManufacturers": ["amazon-web-services"]
    }
  }'

# Пусни rolling update на ASG
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name api-fleet-asg \
  --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

Ако не си сигурен в правилното sizing на новата Graviton инстанция, стартирай Compute Optimizer преди миграцията. Компонентът дава ARM64-specific препоръки от Q3 2024 насам и често предлага по-малка инстанция от директното 1:1 съответствие. За подробности виж нашето ръководство за right-sizing на облачни ресурси.

Миграция на RDS и Aurora към Graviton инстанции

Databases са често най-големият единичен ред в AWS сметката, което прави RDS Graviton миграцията с изключително висок ROI. Според AWS benchmarks Graviton4-базирани Aurora инстанции дават до 40% по-добро performance и 29% по-добро price/performance спрямо x86 еквиваленти. Смяната е буквално change на DB instance class, без промени в схемата, без промени в приложението.

Поддържани engines на Graviton:

MySQL: 8.0.32+
PostgreSQL: 12.11+ (13, 14, 15, 16 препоръчани)
MariaDB: 10.5.17+
Aurora MySQL: 3.02+
Aurora PostgreSQL: 13.6+

Не се поддържат: Oracle Database и SQL Server (обвързани с x86-only binaries на съответните вендори).

Миграция на RDS instance class

# Провери текущия instance class и engine version
aws rds describe-db-instances \
  --db-instance-identifier prod-postgres-primary \
  --query 'DBInstances[0].[DBInstanceClass,EngineVersion]'
# Output: ["db.r6i.4xlarge", "15.4"]

# Приложи модификация към Graviton R8g еквивалент
aws rds modify-db-instance \
  --db-instance-identifier prod-postgres-primary \
  --db-instance-class db.r8g.4xlarge \
  --apply-immediately

# За production използвай blue/green deployment за zero-downtime
aws rds create-blue-green-deployment \
  --blue-green-deployment-name prod-postgres-graviton-migration \
  --source arn:aws:rds:us-east-1:123456789012:db:prod-postgres-primary \
  --target-db-instance-class db.r8g.4xlarge

Как да мигрирам Lambda функции към ARM64

Lambda миграцията към Graviton2 е най-лесната печалба в целия AWS каталог. Сменяш един параметър и получаваш 20% по-ниска цена плюс до 34% по-добро price/performance. Няма instance type, няма AMI, няма rebuild, само декларираш ARM64 архитектурата.

# AWS CLI: смяна на архитектурата на съществуваща функция
aws lambda update-function-configuration \
  --function-name process-orders \
  --architectures arm64

# За container-based Lambda: изгради ARM64 image
docker buildx build \
  --platform linux/arm64 \
  --tag 123456789012.dkr.ecr.us-east-1.amazonaws.com/lambda-orders:v3 \
  --push \
  .

aws lambda update-function-code \
  --function-name process-orders \
  --image-uri 123456789012.dkr.ecr.us-east-1.amazonaws.com/lambda-orders:v3 \
  --architectures arm64

Ако използваш IaC (Terraform, CDK или SAM), декларирай архитектурата в кода:

# SAM template.yaml
Resources:
  ProcessOrdersFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: functions/process-orders/
      Handler: index.handler
      Runtime: python3.12
      Architectures:
        - arm64          # тук е цялата миграция
      MemorySize: 512
      Timeout: 30

Внимавай с Lambda layers. Ако използваш публичен layer (например pandas, numpy), трябва да е ARM64-compatible версията. AWS SDK layers са ARM64-ready от 2022 г. Ако имаш собствен layer с native binaries (например psycopg2 за PostgreSQL), рекомпилирай го върху ARM64 build environment преди публикуване. Аз лично се удрях точно в тази стена при първата си Lambda миграция, защото изградената wheel на моя build server беше x86 и Lambda просто гърмеше с invalid ELF header без ясно съобщение.

Кои workloads не се поддържат на Graviton

Не всеки workload може да мигрира. Ето изчерпателен списък какво остава на x86 през 2026 г.:

Windows Server: няма ARM64 Windows AMI за EC2. Стой на x86 инстанции (M7i, C7i, R7i).
GPU workloads: P4d, P5, G5, G6, Inf1, Inf2 не са налични в ARM варианти. За AI/ML inference и training оставаш на x86 хост с GPU accelerator.
Oracle Database: Oracle не публикува ARM64 binaries за RDS.
SQL Server: Microsoft не поддържа ARM64 SQL Server на Linux.
.NET Framework (не .NET 6+): classic .NET 4.x е Windows-only. Модерен .NET 6/7/8 работи безупречно на Graviton, защото Microsoft публикува ARM64 runtimes.
x86-specific instruction sets: workloads използващи AVX-512, TSX или Intel-specific SIMD оптимизации ще имат performance регресия. Vector similarity search и някои HPC натоварвания попадат тук.
Legacy proprietary binaries без source: ако третостранен вендор доставя само x86 ELF, не можеш да го портираш.

Комбиниране на Graviton със Savings Plans за максимални спестявания

Един от най-често пропусканите въпроси: "Ако купя Compute Savings Plan сега върху x86, губя ли отстъпката като мигрирам към Graviton?" Отговорът е не. Compute Savings Plans се прилагат гъвкаво върху всяко EC2, Fargate и Lambda usage независимо от instance family, размер, регион или архитектура. Мигрираш от m7i.2xlarge към m8g.2xlarge и SP отстъпката те следва автоматично.

Това дава композиран ефект. Graviton намалява on-demand rate-а с 20%, а Compute SP отгоре дава още 20–28% (за 1-year no upfront) или 30–40% (за 3-year all upfront). В моите таблици това изглежда така:

Сценарий	Ефективна цена/час	Спестяване спрямо x86 on-demand
m7i.2xlarge on-demand (базова линия)	$0.4032	0%
m7i.2xlarge + 1yr Compute SP no upfront	$0.2854	-29%
m8g.2xlarge on-demand	$0.3226	-20%
m8g.2xlarge + 1yr Compute SP no upfront	$0.2283	-43%
m8g.2xlarge + 3yr Compute SP all upfront	$0.1613	-60%

Практическа препоръка. Не купувай нови SP ангажименти преди да си направил Graviton миграцията, защото рискуваш да over-commit-неш върху завишена x86 baseline. Първо мигрирай, изчакай 2 седмици за стабилизация, после купи SP върху реалната Graviton консумация. Ако вече имаш активен SP, той автоматично покрива Graviton, така че не е нужно да го анулираш.

Canary миграция и rollback стратегия

Никога не мигрирай production наведнъж. Ето препоръчания от мен трифазен canary подход:

Staging benchmark (седмица 1): deploy Graviton версия paralelno с x86, пусни k6/JMeter load test с идентичен traffic profile. Сравни P50/P95/P99 latency, error rate, memory footprint. Стандарт: Graviton трябва да е ≤ x86 latency при ≥ x86 throughput.
Canary в production (седмица 2): през Auto Scaling Group Mixed Instance Policy започни с 10% ARM64 / 90% x86. Мониторирай 48 часа. Ако KPIs се държат, покачи на 25%, после 50%.
Пълна миграция (седмица 3-4): 100% Graviton след 7 дни на 50/50 без регресии.

# Mixed Instance Policy в ASG: 10% Graviton canary
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name api-fleet-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "api-fleet",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m7i.large", "WeightedCapacity": "1"},
        {"InstanceType": "m8g.large", "WeightedCapacity": "1"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 0,
      "OnDemandPercentageAboveBaseCapacity": 100,
      "SpotAllocationStrategy": "capacity-optimized"
    }
  }'

Rollback планът трябва да е документиран преди първия canary. За EC2/ASG: revert launch template към предишната версия и trigger instance refresh. За Lambda: update-function-configuration --architectures x86_64. За RDS: ако използваш blue/green deployment, "switchover" операцията е обратима до 5 минути. За Kubernetes на EKS с Karpenter, node pool taints и topology spread constraints ти позволяват gradual drain без прекъсване. Виж нашето ръководство за Kubernetes оптимизация с Karpenter, KEDA и VPA за конкретни YAML примери.

Често задавани въпроси

Каква е реалната икономия от миграция към AWS Graviton?

20–40% на почасова цена при on-demand и 15–25% нетни спестявания след Savings Plan discount. При enterprise скала с 1,000+ инстанции това означава $150,000+ годишно само за EC2. Комбинирано с 3-year all-upfront Compute SP спестяванията достигат 60% спрямо x86 on-demand baseline.

Работи ли Compute Savings Plan върху Graviton инстанции?

Да, автоматично. Compute Savings Plans се прилагат върху всяко EC2, Fargate и Lambda usage независимо от instance family, размер, регион или архитектура. Мигрираш към Graviton и SP отстъпката се композира с ARM64 price reduction.

Мога ли да пусна Windows Server на Graviton?

Не. Няма ARM64 Windows AMI за EC2 през 2026 г. Windows workloads остават на x86 инстанции (M7i, C7i, R7i). За .NET workloads обаче, .NET 6 и по-нов работи безупречно на Graviton под Linux, което често е по-евтината пътека.

Трябва ли да променям код на Python или Node.js приложение за Graviton?

За чисти Python/Node.js приложения не. Native extensions обикновено имат ARM64 wheels (NumPy, Pandas, sharp, bcrypt). За container images обаче трябва да rebuild-неш с multi-arch docker buildx, защото Docker image манифестите са architecture-specific.

Кой е най-безопасният начин за миграция на production към Graviton?

Three-phase canary: (1) side-by-side benchmark в staging с идентичен load profile, (2) 10% към 25% към 50% traffic split през Auto Scaling Group Mixed Instance Policy в production за 2 седмици, (3) 100% Graviton след 7 дни на 50/50 без регресии. Rollback планът трябва да е документиран преди първия canary.

Съвместим ли е RDS Aurora с Graviton?

Да, за Aurora MySQL 3.02+ и Aurora PostgreSQL 13.6+. Миграцията е промяна на DB instance class (например db.r6i.4xlarge към db.r8g.4xlarge). За zero-downtime препоръчвам blue/green deployment, защото switchover отнема до 5 минути и е обратим. Oracle и SQL Server engines НЕ се поддържат.