Hledání rovnováhy v AWS: Kdy dává smysl bořit architektonická dogmata a přestat optimalizovat?
Cloudové služby slibovaly flexibilitu a nákladovou efektivitu. Realita komplexních AWS infrastruktur však inženýrské týmy často nutí k pravidelným revizím a hledání úspor.
V ASSISTu se při návrhu a údržbě cloudových architektur neustále pohybujeme na tenkém ledě mezi dodržováním zavedených „best practices“ a zdravým pragmatismem.
Nedávno jsme v rámci interního architektonického fóra otevřeli poměrně radikální diskuzi:
Skutečně vždy potřebujeme striktní multi-account strukturu, nebo je čas některá dogmata přehodnotit?
Zde jsou klíčové technické a procesní poznatky, ke kterým jsme dospěli, a naše doporučení pro efektivnější FinOps. Mýtus izolovaných prostředí a skryté náklady „Idle Resources“.
Zlaté pravidlo cloudové architektury velí jasně: Oddělte produkční a neprodukční prostředí do samostatných AWS účtů (např. pomocí AWS Organizations). - Poskytuje to ultimátní izolaci, bezpečnost a zamezuje to ovlivnění limitů služeb.
Při detailním pohledu na provozní náklady se ale často ukáže úskalí tohoto přístupu. Neplatíte totiž za samotnou existenci AWS účtu, ale za takzvané baseline prostředky a služby, které v něm musí běžet, i když se dané prostředí zrovna aktivně nevyužívá.
Kde vznikají zbytečné náklady:
- Aktivní monitoring nad prázdným prostorem:
Nástroje pro APM a log management neustále provádějí polling a dotazují se na stav prostředků (např. kontejnerových registrů, databází), i když v neprodukčním účtu aktuálně neprobíhá žádná zátěž. - Duplikace síťové infrastruktury:
NAT Gatewaye, Load Balancery a VPN endpointy v každém izolovaném účtu generují fixní hodinové poplatky, které v součtu tvoří nezanedbatelnou část faktury.
Alternativní pohled: V určitých scénářích dává mnohem větší smysl konsolidace. Namísto udržování desítek účtů s vysokým provozním overheadem může být efektivnější využít jeden či dva hlavní účty s logickou izolací na úrovni velkých, dobře zabezpečených VPC (Virtual Private Cloud) s využitím striktních IAM politik.
Agresivní CI/CD jako náhrada za těžkopádná prostředí.
V diskuzi jsme narazili i na odvážnější myšlenku. Pokud má vývojový tým špičkově odladěné CI/CD pipelines, rozsáhlé automatizované testování a nasazuje v minimálních inkrementech, snižuje se reálná potřeba udržovat robustní (a drahá) pre-produkční prostředí. Se správným využitím feature flags a canary deploymentů lze aplikovat principy kontinuálního doručování mnohem příměji. Infrastruktura se pak stává štíhlejší a my neplatíme za servery, které většinu měsíce pouze čekají na to, až na nich proběhne manuální QA.
FinOps a zákon klesajícího užitku.
Nejdůležitější technicko-byznysový střet nastává ve chvíli, kdy proti sobě postavíme cloudové výdaje a čas inženýrů. Architektonická čistota a maximální optimalizace jsou skvělé cíle, ale podléhají neúprosnému zákonu klesajícího užitku.
Před každým velkým zásahem do infrastruktury (jako je přesun na nové účty či refaktorizace služeb) je nutné si položit otázku:
Převýší budoucí úspora na AWS faktuře náklady na čas seniorního DevOps inženýra, který bude tuto migraci provádět?
V určitém bodě je zkrátka racionálnější přestat infrastrukturu ladit o jednotky procent a ušetřený čas investovat do vývoje nových funkcionalit, které přinášejí reálnou hodnotu uživatelům.
Doporučení expertů z ASSISTu
Pokud aktuálně řešíte optimalizaci AWS nákladů, doporučujeme následující postup:
- Zmapujte si fixní overhead:
Než začnete škálovat instance dolů, podívejte se na služby, které platíte neustále. Konsolidujte NAT Gatewaye, zrevidujte retention logů a omezte polling monitorovacích nástrojů v neprodukčních prostředích. - Kriticky zhodnoťte multi-account strategii:
Pokud vaše neprodukční účty zejí většinu času prázdnotou, zvažte přechod na robustní izolaci na úrovni VPC a IAM v rámci menšího počtu účtů. - Spočítejte si inženýrské ROI:
Nikdy neoptimalizujte jen pro dobrý pocit z nižší faktury. Pokud vás ušetření 100 dolarů měsíčně stojí 3 dny práce cloud architekta, optimalizace nedává ekonomický smysl. - Investujte do CI/CD:
Čím více věříte své automatizaci a pipelinám, tím méně robustní statická prostředí potřebujete udržovat.
V ASSISTu věříme, že nejlepší architektura nevzniká tichým souhlasem s manuály, ale zdravou a odbornou oponenturou celého týmu.
