Stratégie a osvedčené postupy 10 min čítania

Migrácia na AWS Graviton: Kompletný playbook na úsporu 20–40 % nákladov na EC2 v roku 2026

Graviton4 prináša až o 40 % nižšie ceny a o 30 % vyšší výkon ako porovnateľné x86 inštancie. Tento praktický playbook ukazuje krok za krokom, ako migrovať EC2, ECS, EKS, Lambda aj RDS workloady na ARM64 a kombinovať úspory so Savings Plans v roku 2026.

Editorial Team

Ak ste v roku 2026 ešte nepresunuli aspoň časť svojich EC2 workloadov na AWS Graviton, pravdepodobne preplácate niekde medzi 20 a 40 %. A úprimne, to už nie je malý detail v účte. Graviton4 (konkrétne inštancie r8g, m8g, c8g) dnes ponúka najlepší pomer cena/výkon v celom ekosystéme AWS — a keď ho skombinujete s Compute Savings Plans, účet sa dokáže scvrknúť ešte výraznejšie.

Tento playbook nie je ďalší marketingový prehľad. Je to konkrétny postup, ktorý sme overili pri migrácii desiatok produkčných služieb: ako identifikovať vhodné kandidáty, ako postaviť multi-arch Docker images, ako bezpečne prepnúť ECS/EKS deploymenty a (hlavne) kde sú tie reálne pasce, ktoré dokumentácia AWS veľmi rada zamlčiava.

Prečo Graviton v roku 2026 dáva ekonomický zmysel

Krátky kontext, ak niekto prichádza k téme prvýkrát: Graviton sú vlastné ARM64 procesory od AWS (pochádzajúce z Annapurna Labs, ktorú Amazon kúpil už v roku 2015). V roku 2026 je v produkcii už štvrtá generácia — Graviton4 — a oproti Graviton3 prináša naozaj pekný skok:

  • Až o 30 % vyšší výkon na vCPU pre bežné workloady — web servery, mikroslužby, databázy.
  • Až o 40 % nižšiu hodinovú cenu v porovnaní s ekvivalentnými Intel Xeon inštanciami (rad m7i/c7i) alebo AMD EPYC (m7a/c7a).
  • O 50–60 % lepšiu energetickú efektivitu. Áno, viem, znie to ako ESG buzzword, ale ak máte interný carbon-cost dashboard, čísla sa vám zrazu začnú páčiť.
  • Plnú kompatibilitu so Savings Plans a Reserved Instances. Úspory sa skladajú: Graviton (~20 %) + 1-ročný Compute SP no-upfront (~28 %) ≈ reálne ~42 % oproti on-demand x86.

Najdôležitejšie číslo, ktoré si stojí za to zapamätať: hodinová cena m8g.large v regióne eu-central-1 je aktuálne $0.0784, zatiaľ čo m7i.large stojí $0.1008. Pri 730 hodinách mesačne je to rozdiel $16.35 na jednu inštanciu. Vynásobte to tisíckou inštancií vo flotile a dostanete sumu, ktorú väčšina CFO naozaj nechce nechať ležať na stole.

Kedy Graviton NIE JE správna voľba

Skôr ako sa pustíte do migrácie, vylúčte tieto prípady. Ušetríte si týždne zbytočnej práce:

  • Komerčný softvér viazaný na x86_64 — staršie verzie Oracle DB, niektoré SAP komponenty, proprietárne ML knižnice (klasika: Intel MKL bez ARM verzie).
  • Workloady s ťažkými AVX-512 inštrukciami — HPC simulácie, niektoré video kodeky. Graviton má SVE2, ale migrácia si vyžiada rekompiláciu a poctivé benchmarky.
  • Windows Server. Graviton podporuje iba Linux. Pre Windows zostávate na x86 a hotovo.
  • Krátke ad-hoc Lambda funkcie. Pri behoch pod 100 ms je rozdiel v cene zanedbateľný a réžia údržby dvoch architektúr prevyšuje úsporu.
  • Závislosti na natívnych Node.js/Python balíčkoch bez ARM wheels — overte si to cez pip download --platform manylinux2014_aarch64, či sú prebuildnuté wheels naozaj k dispozícii.

Krok 1: Audit – ktoré workloady sú vhodní kandidáti

Začnite s AWS Compute Optimizer, ktorý od roku 2024 ponúka explicitné Graviton recommendations. Tento dotaz cez AWS CLI vám vráti zoznam inštancií s odporúčaním migrácie:

aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=RecommendationSourceType,values=Ec2Instance \
  --query 'instanceRecommendations[?recommendationOptions[?contains(instanceType, `g.`) || contains(instanceType, `8g`)]].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].savingsOpportunity.savingsOpportunityPercentage]' \
  --output table

Doplnkovo si v Cost Explorer vyfiltrujte „Usage Type Group: EC2 Running Hours“ a zoraďte podľa nákladov. Platí stará dobrá Paretovka — top 20 % najdrahších inštancií zvyčajne tvorí 80 % účtu. Tam začnite.

Rýchly checklist pre kandidáta na migráciu

  1. Beží na Linuxe (Amazon Linux 2023, Ubuntu 22.04+, Debian 12+, RHEL 9+)?
  2. Je aplikácia v interpretovanom jazyku (Python, Node.js, Java, Ruby, Go) alebo má čisto open-source závislosti?
  3. Beží v kontajneri, prípadne cez systemd bez špeciálnych ovládačov?
  4. Máte CI/CD pipeline, ktorá vie postaviť multi-arch images?

Ak ste si odpovedali 4× áno, ide o nízkorizikovú migráciu a odhadom ju dokončíte za 2 až 5 dní — aj pri netriviálnej službe.

Krok 2: Multi-arch Docker images cez Buildx

Najčastejšia chyba, ktorú u zákazníkov vidíme: tímy si myslia, že musia paralelne udržiavať dva tagy – :latest-amd64 a :latest-arm64. Nemusia. Docker Buildx s prepínačom --platform vytvorí manifest list, ktorý automaticky doručí správnu architektúru podľa runtime hostiteľa. Jednoduché, elegantné, a hlavne žiadny extra tooling.

# Inicializácia builderu (raz)
docker buildx create --name multiarch --driver docker-container --use
docker buildx inspect --bootstrap

# Build a push v jednom kroku
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag 123456789.dkr.ecr.eu-central-1.amazonaws.com/api:1.4.2 \
  --push \
  .

V GitHub Actions to vyzerá takto (skrátený workflow):

name: build-and-push
on:
  push:
    tags: ['v*']
jobs:
  build:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-qemu-action@v3
      - uses: docker/setup-buildx-action@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/gh-ecr-push
          aws-region: eu-central-1
      - uses: aws-actions/amazon-ecr-login@v2
      - uses: docker/build-push-action@v6
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: 123456789.dkr.ecr.eu-central-1.amazonaws.com/api:${{ github.ref_name }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Pozor na cache. Bez cache-from/cache-to sa ARM64 build cez QEMU emuláciu vie natiahnuť 5–10×. Ak to bolí – a verte mi, bolí – zvážte natívny ARM runner. GitHub od roku 2024 ponúka ubuntu-24.04-arm a buildy na ňom bežia 3–4× rýchlejšie.

Bežné problémy s natívnymi závislosťami

  • Python: pip install stiahne ARM wheels automaticky, ak sú publikované. Pre numpy, pandas, cryptography, psycopg2-binary už ide všetko hladko od roku 2023. Pri menších balíčkoch si to overte cez pip index versions <balík>.
  • Node.js: Problém zvykli mať node-gyp moduly (bcrypt, sharp). V roku 2026 už majú prebuildy pre linux-arm64, takže npm ci --ignore-scripts väčšinou postačí.
  • Java: V podstate nemusíte robiť nič — JVM je platform-independent. Len overte, že používate Corretto 17/21 alebo Temurin. Obe majú natívne ARM64 buildy s lepším výkonom než nejaká Rosetta-style emulácia.
  • Go: GOOS=linux GOARCH=arm64 go build a máte hotovo. Žiadny vendor lock-in, žiadne prekvapenia.

Krok 3: Migrácia ECS/EKS workloadov

ECS na Fargate

V task definition stačí pridať pole runtimePlatform.cpuArchitecture:

{
  "family": "api-service",
  "runtimePlatform": {
    "cpuArchitecture": "ARM64",
    "operatingSystemFamily": "LINUX"
  },
  "cpu": "1024",
  "memory": "2048",
  "containerDefinitions": [{
    "name": "api",
    "image": "123456789.dkr.ecr.eu-central-1.amazonaws.com/api:1.4.2",
    "essential": true
  }]
}

Fargate Graviton stojí oproti x86 Fargate o ~20 % menej a kombinácia so Spot Fargate (FARGATE_SPOT) dokáže v dev/staging prostrediach uštrieť ďalších 50–70 %. Pre preview environmenty, ktoré bežia niekoľko hodín denne, je to jednoducho no-brainer.

EKS s Karpenter

V EKS odporúčame Karpenter (od 2024 GA), ktorý na rozdiel od Cluster Autoscaler vie inteligentne miešať architektúry. Tu je ukážka NodePool, ktorý preferuje Graviton, ale s fallbackom na x86:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: graviton-preferred
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64", "amd64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["m", "c", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["6"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  weight: 100
  limits:
    cpu: "1000"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Aby Karpenter správne plánoval, vaše Pody musia mať buď nodeSelector: kubernetes.io/arch: arm64 (keď je deployment čisto ARM-only), alebo vôbec žiadny arch selector — multi-arch image vyrieši zvyšok.

Krok 4: Lambda na ARM64

Migrácia Lambda funkcie je skoro triviálna. Doslova jedno pole v konfigurácii:

# Terraform
resource "aws_lambda_function" "api" {
  function_name = "order-processor"
  role          = aws_iam_role.lambda.arn
  package_type  = "Image"
  image_uri     = "123456789.dkr.ecr.eu-central-1.amazonaws.com/order-processor:1.0.0"
  architectures = ["arm64"]
  memory_size   = 1024
  timeout       = 30
}

Lambda na ARM64 je o 20 % lacnejšia za GB-sekundu a podľa našich vlastných meraní je zhruba o 15–25 % rýchlejšia pre Node.js a Python workloady. Čiže reálna úspora po zarátaní kratších run timov býva často 30 až 40 %. Osobne — keď mám v tíme niekoho nového na FinOps úlohe, toto je prvý ticket, ktorý mu dám. Win za pár minút, morálka stúpa.

Krok 5: RDS, Aurora a ElastiCache

Manažované databázy sú často najjednoduchší quick win. Migrácia je vlastne iba zmena db_instance_class počas údržbového okna:

Pôvodná inštancia (x86)Graviton ekvivalentÚspora
db.m6i.largedb.m7g.large~10 %
db.r6i.xlargedb.r7g.xlarge~10 %
db.m6i.4xlarge (Aurora)db.r7g.4xlarge~15 % + lepší výkon
cache.r6g.largecache.r7g.large~5–8 %

Postup pre RDS:

  1. Vytvorte read replicu na Graviton inštancii: aws rds create-db-instance-read-replica --db-instance-identifier prod-db-replica --source-db-instance-identifier prod-db --db-instance-class db.r7g.xlarge
  2. Otestujte aplikáciu proti read replica endpointu (smoke test, performance test — nebuďte leniví).
  3. Vykonajte failover cez Multi-AZ promotion alebo plánovaný blue/green deployment (ten od 2023 podporuje aj engine upgrade).
  4. Po stabilizácii zmažte starú x86 inštanciu. Nenechávajte ju tam „pre istotu“, len platíte dvakrát.

Krok 6: Kombinácia so Savings Plans

Dôležité pochopenie: Graviton úspora nie je alternatívou k Savings Plans. Sú komplementárne. Optimálna stratégia pre rok 2026 vyzerá nasledovne:

  1. Najprv dokončite migráciu na Graviton (zmení sa pomer m7i:m8g vo vašej flotile).
  2. Počkajte 14 až 30 dní, kým sa stabilizuje nový usage profile.
  3. Použite Compute Savings Plans (nie EC2 Instance SP!) — sú architektonicky agnostické, takže pokrývajú x86 aj ARM aj Fargate aj Lambda naraz.
  4. Začnite s 1-ročným no-upfront commitmentom na 60 až 70 % vašej baseline spotreby. To je to „bezpečné“ číslo, ktoré minimalizuje riziko under-utilization.

Reálna kalkulácia pre fiktívnu firmu so 100× m7i.large bežiacich 24/7:

  • Pôvodná cena (on-demand x86): 100 × $0.1008 × 730 h = $7 358/mes
  • Po migrácii na m8g.large: 100 × $0.0784 × 730 h = $5 723/mes (–22 %)
  • + 1-ročný Compute SP no-upfront na 70 %: efektívna cena ~$4 240/mes (–42 % oproti východisku)
  • Ročná úspora: okolo $37 400. To už je jeden slušný engineering plat.

Monitoring a verifikácia úspor

Po migrácii nezabudnite nasadiť dashboard, ktorý sleduje aspoň tieto veci:

  • Cost per request / cost per transaction — to je kľúčová metrika, ktorá izoluje efekt migrácie od bežného rastu trafficu.
  • p95/p99 latencia pred a po. Graviton4 by mal byť rovnaký alebo lepší. Ak je horší, problém takmer určite leží v aplikácii — typicky neoptimalizovaná ARM kompilácia natívnej knižnice.
  • CPU utilization. Ak po migrácii spadne pod 30 %, idete o triedu nižšie a získate ďalších 50 %.
  • AWS Cost Anomaly Detection alert na neplánovaný návrat na x86. Vývojári totiž občas omylom naspäť deployujú starý image a nikto si to nevšimne, kým nepríde faktúra.

Časté chyby a ako sa im vyhnúť

  • Migrácia all-at-once. Vždy najprv dev → staging → 10 % canary v prod → plný rollout. Aspoň 3 dni medzi jednotlivými krokmi.
  • Zabudnúť na sidecar containery — Datadog agent, Envoy, Fluent Bit. Overte, či majú multi-arch image. Ak nie, držte ich na samostatnom node poole (a v ticketi si napíšte, že to treba riešiť).
  • Hardcoded amd64 v Helm chartoch alebo Kustomize. Vygrepujte celý repozitár na amd64 a x86_64. Budete prekvapení, koľko takých riadkov niekde prežíva z dôb, na ktoré už nikto nepamätá.
  • RDS bez read replica testu. Niektoré query plány sa na Graviton správajú trochu inak (hlavne parallel query). Testujte aspoň 24 hodín na replike ešte pred failoverom.
  • Ignorovanie Savings Plans recompute. Po migrácii sa môžu staré EC2 Instance SP stať „uneaten“ – cez Cost Explorer si overte coverage a v prípade potreby ich nechajte dobehnúť a nahraďte Compute SP.

FAQ – často kladené otázky

Aký je rozdiel medzi Graviton3 a Graviton4 z hľadiska úspor?

Graviton4 (rad 8g) ponúka oproti Graviton3 (7g) zhruba o 30 % vyšší výkon na vCPU pri rovnakej alebo mierne vyššej cene. Pre väčšinu workloadov to znamená, že môžete prejsť o veľkosť nižšie (napríklad z m7g.xlarge na m8g.large) a získať ďalších 30 až 40 %. Ak migrujete čerstvo, choďte rovno na 8g — naozaj nemá zmysel zastaviť sa na 7g.

Funguje Graviton s Kubernetes a Helm chartmi tretích strán?

Áno, ale overte si to. Hlavné CNCF projekty (Prometheus, Grafana, Istio, Argo CD, cert-manager, ingress-nginx) majú multi-arch images od roku 2023. Komerčné produkty ako Datadog, New Relic alebo Splunk Forwarder tiež. Problémy občas vznikajú pri menších OSS toolkitoch a operátoroch — pre tie použite nodeAffinity a držte ich na x86 nodoch. Nič dramatické.

Stratím Reserved Instances, keď prejdem na Graviton?

Ak máte Standard RI, tak áno — sú totiž viazané na konkrétnu inštančnú rodinu (napríklad m7i) a Graviton ich nepokryje. Convertible RI sa dajú vymeniť za ekvivalent v Graviton rade. Najlepšie riešenie: nekupujte už žiadne nové EC2 RI a namiesto toho investujte do Compute Savings Plans, ktoré sú omnoho flexibilnejšie.

Koľko trvá migrácia priemernej mikroslužby?

Pri stateless službe v jazyku ako Go, Python či Node.js a CI/CD s Buildx hovoríme o 2 až 5 dňoch práce jedného developera vrátane testov a postupného rolloutu. Pri Java/JVM aplikáciách s GraalVM native image alebo vlastnými JNI knižnicami to vie narásť na 1 až 2 týždne. Stateful databázy migrujte zvlášť cez blue/green deployment.

Oplatí sa Graviton aj pre malé firmy s účtom pod $1 000/mesiac?

Pre účet pod $500/mes je opportunity cost migrácie zvyčajne vyšší než samotná úspora. Pre účet $1 000 až 5 000/mes začnite tým najjednoduchším — Lambda na ARM64 (zmena jedného poľa) a každý nový workload rovno na Graviton. Pri účtoch nad $5 000/mes je úplná migrácia takmer vždy ekonomicky výhodná, aj keď zaberie jeden či dva sprinty engineering času.

Záver

Migrácia na AWS Graviton je v roku 2026 jedna z najlepších „pákových“ optimalizácií, ktoré FinOps tím vie vôbec vykonať. Jeden technický projekt s merateľnou úsporou 20 až 40 %, ktorá sa kumulatívne skladá so Savings Plans aj Spot kapacitou. Ak máte v cloude EC2, EKS alebo RDS workloady na x86, toto si jednoducho zaslúži miesto v najbližšom OKR cykle.

Začnite auditom cez Compute Optimizer, vyberte 2 až 3 nízkorizikové stateless služby ako pilot a v priebehu jedného kvartálu rozšírte migráciu na celú flotilu. Ušetrené prostriedky potom reinvestujte do toho, čo reálne posúva produkt dopredu — nie do hodín procesorov, ktoré beztak robia rovnakú prácu lacnejšie a efektívnejšie.

O Autorovi Editorial Team

Our team of expert writers and editors.

Súvisiace Články