Ako optimalizovať náklady na Amazon EC2?

V konzole amazon ec2 (časť „správy“) môžete získať správy o nákladoch na amazon ec2 (nezahŕňa niektoré náklady na prenos údajov) a o využití vyhradenej inštancie.

Amazon's Elastic Cloud Computing (EC2) je stredobodom Amazon Web Services, celosvetovo najpoužívanejšieho riešenia cloudovej infraštruktúry ako služby. EC2 ponúka širokú škálu možností, ktoré sú spolu veľmi účinné. Na druhej strane je to tiež veľmi komplikované pre začiatočníkov a jeho nesprávne pochopenie môže znamenať výrazne vyššie výdavky na infraštruktúru. Táto stránka podrobne popisuje, ako lepšie zvládnuť správu svojich inštancií EC2, aby boli náklady zvládnuteľné. Cieľovým publikom tejto stránky sú jednotlivci alebo firmy, ktorých očakávané ročné náklady na EC2 sa pohybujú v rozmedzí 7460€-149000€. Vzhľadom na zložitosť materiálu tu nemusí mať zmysel investovať čas a energiu do optimalizácie nákladov s ročnými nákladmi nižšími ako 7460€. Ak sú vaše ročné náklady vyššie ako 149000€, pravdepodobne má zmysel najať ekvivalent inžiniera vývojárov na plný úväzok na správu vašich inštancií a nákladov Amazon EC2.

Časť 1 z 9: Pochopenie, či je ec2 pre vás to pravé

1
Pochopte, že ec2 nie je najlacnejší. Pokiaľ ide o pomery ceny a výkonu samotného hardvéru, EC2 nie je ani zďaleka najlacnejšou alternatívou na trhu. Dokonca aj účtovanie spoľahlivosti služby z neho nerobí nákladovo najkonkurencieschopnejšie.
- Ak očakávate veľký prenos údajov (odchádzajúcich z vášho servera), webové služby Amazon môžu byť v porovnaní s rôznymi poskytovateľmi virtuálnych súkromných serverov (VPS), akými sú Linode a Digital Ocean, dosť drahé. Dôvodom je, že AWS účtuje približne 9 centov za GB, čo je v prepočte približne 67€/TB, čo je suma, ktorú väčšina poskytovateľov VPS ponúka zadarmo pri svojich minimalistických mesačných plánoch (asi 3,70€ alebo 7,50€ mesačne). Inými slovami, ak máte jednoduchú webovú stránku, ktorá získava veľa návštevnosti, je nepravdepodobné, že by AWS bola pre vás tou správnou voľbou.
- Pokiaľ ide o výkon hardvéru, Amazon EC2 historicky ponúka horší výkon ako Linode a Digital Ocean pre servery s rovnakou cenou a podobnými hardvérovými špecifikáciami (pokiaľ ide o vCPU a pamäť). Čiastočne je to kvôli rozdielom v základnej architektúre.
2
Pochopte niektoré z kľúčových výhod systému ec2 a riešení infraštruktúry ako služby (iaas) vo všeobecnosti.
- Flexibilná, škálovateľná infraštruktúra, ktorú môžete prispôsobiť svojim meniacim sa potrebám.
- Schopnosť nasadzovať inštancie a programovo vykonávať zmeny v architektúre.
- Dostupnosť spotových inštancií.
- Veľký počet riadených služieb, ktoré, ak sa používajú spoločne v tej istej oblasti, nestoja nič (alebo veľmi málo) za prenos údajov.
3

Majte na pamäti, že ec2 nemusíte používať len preto, že používate niektoré ďalšie služby amazon. Mnoho ľudí napríklad používa Amazon S3 na lacné, flexibilné a nadbytočné veľkokapacitné úložisko, ale svoje stroje nespúšťa na EC2.

Časť 2 z 9: Pochopenie typov inštancií

1
Pochopte rôzne aspekty popisu typu amazonskej inštancie.
- Typický názov má tri časti: písmeno popisujúce triedu inštancií (R, M, C, T, G, D, I, P, X), číslo opisujúce generáciu (1, 2, 3, 4, 5), a reťazec popisujúci veľkosť v rámci tejto inštančnej triedy a generácie (malá, stredná, veľká, x veľká, 2x veľká, 4x veľká, 8 x veľká, 10 x veľká, 16 x veľká, 32 x veľká). Napríklad „r3,4xlarge“ je inštancia typu R, generácia 3 a veľkosť 4x veľká.
- Jednoduchý spôsob, ako si zapamätať, čo veľkosť znamená, je: „veľký“ znamená 2 vCPU, „xlarge“ znamená 4 vCPU a n xlarge znamená 4n vCPU. VCPU je jeden „hyper vlákno“ v žargóne spoločnosti Intel, výrobcu čipov. Naivne sa dá považovať za zodpovedajúce jednému jadru na prenosnom počítači alebo stolnom počítači; fyzicky povedané, čipy Intel používané poslednými generáciami inštancií EC2 majú na jedno jadro dve vCPU (alebo dve vlákna). V porovnaní s existujúcimi fyzickými servermi musíte znásobiť počet jadier fyzických serverov dvoma, aby ste získali správne číslo vCPU.
- Trieda inštancie udáva pomer medzi rôznymi časťami špecifikácií inštancie. Najrelevantnejším pomerom je pomer vCPU k RAM. Napríklad trieda inštancie C (kde C znamená optimalizovaná pre počítače) ponúka 1 vCPU na každé (približne) 2 gigabajty pamäte RAM. K Presné pomery mierne líšiť medzi rôznymi generáciami, pretože neskôr inštancia robiť lepšiu prácu vytláčali väčšiu hodnotu z hardvéru.
- Generácie sa tiež líšia v niektorých doplnkových funkciách, ktoré ponúkajú. Napríklad triedy C, M a R tretej generácie (C3, M3 a R3) majú všetky lokálne disky SSD, ale štvrtá generácia (C4, M4 a R4) ich nemá.
- Rozdiely vo veľkosti pre danú triedu inštancií a generáciu znamenajú rôzne množstvá každého zdroja, ale v rovnakom pomere (niektoré periférne aspekty špecifikácií, ako napríklad úložisko SSD a priepustnosť, sa nemenia lineárne). V prípade inštancií na požiadanie a vyhradených inštancií sa náklady lineárne líšia podľa veľkosti v rámci daného typu a generácie inštancie. V prípade spotového prípadu sa náklady nemusia stupňovať lineárne, pretože sú určené ponukou a dopytom, ale pre najbežnejšie typy inštancií je škálovanie blízke lineárnemu.
- Pre daný typ a generáciu inštancie je spravidla možné zmeniť typ rezervácie (potom, čo už bola rezervácia vykonaná), aby sa realokovala kapacita medzi rôznymi veľkosťami. Napríklad c3,2xveľkosť je dvojnásobkom kapacity c3.xlarge, takže je možné zmeniť rezerváciu 5 c3,2xlarge na 10 c3.xlarge alebo na 3 c3,2xlarge a 4 c3.xlarge.
- Majte na pamäti, že názvy typov inštancií nemajú žiadny hlbší význam, než len poskytnutie intuitívneho popisu špecifikácií. Napríklad C je "optimalizovaný pre výpočet", ale to všetko znamená, že pomer vCPU k pamäti je v prospech vCPU viac ako v pamäti. Neexistuje žiadna špecifická optimalizácia špecifická pre výpočty nad rámec toho, čo už špecifikácie odhaľujú.
- Priepustnosť siete nie je celkom lineárne.
2
Pochopte pomery troch hlavných tried inštancií. Presné pomery sa v rôznych generáciách trochu líšia.
- Trieda inštancie R je optimalizovaná pre pamäť a ponúka najviac pamäte na vCPU (tj. Najmenej vCPU na jednotku pamäte). Pomer je približne 7,5 GB/vCPU.
- Trieda inštancie M je stredná. Ponúka 3,75 GB/vCPU.
- Trieda inštancie C je optimalizovaná pre výpočty a ponúka najmenšiu pamäť na vCPU (tj najväčší počet vCPU na jednotku pamäte). Pomer je približne 1875 GB/vCPU.
3
Pochopte maximálne dostupné kapacity inštancií a identifikujte limity vertikálneho škálovania.
- Trieda inštancie M: M3 dosahuje veľkosť iba m3,2x (30 GB, 8 vCPU). M4 dosahuje veľkosť m4,16x (256 GB, 64 vCPU), ale chýba mu disk SSD.
- Trieda inštancie R: R3 dosahuje veľkosť až r3,8x (244 GB, 32 vCPU). R4 dosahuje až r4,16x (488 GB, 64 vCPU), ale chýba mu SSD.
- Trieda inštancie C: C3 dosahuje veľkosť až c3,8x (60 GB, 32 vCPU). C4 dosahuje až c4,8x (60 GB, 36 vCPU), ale chýba mu SSD. C5 (ktorý sa uvádza na trh v decembri 2016) bude mať veľkosť až c5,18x (144 GB, 72 vCPU) a tiež mu nebude chýbať SSD.
4
Pochopte ďalšie obmedzenia, s ktorými sa môžete stretnúť na základe operačného systému a AMI, ktoré chcete použiť.
- Väčšina poznámok v tomto článku, ako aj väčšina online diskusií o EC2, sa zameriava na prípad použitia inštancií Linux/Unix, ktoré nemajú žiadne licenčné náklady.
- Inštancie EC2 môžete nasadiť aj v iných operačných systémoch, ako je napríklad Windows. Tieto inštancie sú drahšie (konštantný typ inštancie a možnosť nákupu). Ponúkajú tiež menšiu flexibilitu pri zmene rezervácií. Neexistujú žiadne samostatné licenčné poplatky; Amazon platí za licencie a zahŕňa ich do inštančných nákladov.

V prípade dlhodobo fungujúcich inštancií sú náklady na EBS pomerne malé v porovnaní s nákladmi na inštancie.

Časť 3 z 9: Porozumenie požiadavkám aplikácie

1
Spustite svoju aplikáciu v niektorých inštanciách, aby ste zistili, ako používa rôzne zdroje (výpočtová technika, pamäť, lokálne úložisko, sieť) a aké sú prekážky.
- Využitie CPU a siete je uložené v metrikách v službe Amazon CloudWatch, systéme Amazonu na zaznamenávanie metrík. Prístup k nim je možný aj v konzole EC2.
- Využitie pamäte nie je možné sledovať pomocou konzoly Amazon EC2. Preto budete musieť sledovať využitie pamäte vo vašej aplikácii alebo prostredníctvom iného procesu protokolovania pamäte, ktorý nainštalujete do svojej inštancie. Jeden taký proces odporúčaný spoločnosťou Amazon (a ktorý je možné exportovať do služby CloudWatch) je collectd.
- Majte na pamäti, že údaje o využití CPU a siete už nie sú v konzole EC2 po ukončení vašich inštancií k dispozícii. Dajú sa však zobraziť v metrikách CloudWatch (v podstate dôvod, prečo ich nemôžete vidieť v konzole EC2, je ten, že inštancia tam už nie je uvedená).
- Metriky služby CloudWatch o využití procesora a siete (ako aj všetky ostatné vlastné metriky, ktoré exportujete) sa uchovávajú počas pohybujúceho sa okna 15 mesiacov, oproti pohyblivému oknu o 2 týždne skôr. Keďže zmena bola predstavená nedávno, odteraz môžete získať metriky iba za posledné tri mesiace.
2
Identifikujte kľúčové premenné, ktoré ovplyvňujú využitie zdrojov vašich aplikácií.
- V prípade aplikácií frontend je jednou z kľúčových premenných ovplyvňujúcich využitie zdrojov úroveň návštevnosti. Identifikujte, ako sa využitie vašich zdrojov (pamäťových aj výpočtových zdrojov) líši v závislosti od rôznych úrovní návštevnosti. Úrovne návštevnosti môžu kolísať denne a sezónne a môžu mať aj sekulárne trendy (tj. Dlhodobé trendy). Možno budete chcieť umelo simulovať vyššiu návštevnosť pomocou nástrojov, ako je Gatling alebo služieb, ako je Blitz.io.
- Veľkosť údajov, ktoré vaša aplikácia používa, sa môže tiež zmeniť bez ohľadu na úroveň návštevnosti. Ak napríklad vaša aplikácia slúži na webovú stránku, metriky súvisiace s veľkosťou webovej stránky (počet stránok, počet odlišných používateľských účtov) môžu ovplyvniť využitie zdrojov. Tieto metriky sa krátkodobo veľmi nelíšia, ale majú tendenciu sa v priebehu času zvyšovať, takže budete musieť extrapolovať zo súčasného používania alebo umelo simulovať väčšiu veľkosť webových stránok alebo viac používateľských účtov.
3
Identifikujte interakcie a kompromisy medzi využitím zdrojov vo svojom kóde.
- V prípade aplikácií, ktoré bežia na Java Virtual Machine (JVM), čím bližšie je vaša pamäť k úplnému využitiu, tým viac času a zdrojov sa vynakladá na zber odpadu. To môže spôsobiť raketové využitie CPU a zvýšenie latencie. K podobným javom môže dôjsť aj pri aplikáciách, ktoré bežia v iných prostrediach.
- Preto je obzvlášť dôležité sledovať a pochopiť, čo je pôvodnou príčinou prekážok. To, že sa využitie procesora vyšplhalo na 100%, neznamená, že problém bol s príliš malým počtom CPU. Problém môže byť v dôsledku príliš malej pamäte, ktorá spôsobuje, že zdroje CPU sú nútené do zberu odpadu.
4
Ak uvažujete o spustení rovnakých aplikácií na viacerých inštanciách (typických pre klientske rozhrania, ktoré obsluhujú vysoké záťaže), preskúmajte kompromisy medzi horizontálnym škálovaním (pri použití viacerých inštancií) a vertikálnym škálovaním (pri použití väčších inštancií). Zistite napríklad, či je lepšie použiť niekoľko x veľkých inštancií alebo dvakrát toľko veľkých inštancií.
- Limity (v prospech horizontálneho škálovania): Vertikálne škálovanie má pomerne prísne limity: veľkosť inštancií EC2, ktoré môžete použiť, je dosť nízka (pozri časť 2, krok 3). Vďaka škále infraštruktúry AWS sú limity horizontálneho škálovania oveľa väčšie (aj keď váš účet môže mať svoje vlastné limity stanovené AWS, môžete požiadať o zvýšenie limitu). Ak potrebujete výpočet 1000 vCPU, musíte použiť aspoň nejaké horizontálne škálovanie, pretože aj limity vertikálneho škálovania vás dostanú iba k 64 vCPU.
- Väčšia deliteľnosť a tým väčšia presnosť kapacity (v prospech horizontálneho škálovania): Použitie menších typov inštancií vám umožní presnejšie doladiť počet inštancií podľa kapacity premávky. Predpokladajme napríklad, že viete, že vaša požiadavka na návštevnosť by na obsluhu potrebovala 9 veľkých inštancií c3. Za predpokladu, že nedôjde k problémom so zdieľanou pamäťou alebo inými zdieľanými zdrojmi, ak by ste chceli používať inštancie c3.xlarge, potrebovali by ste ich 5, pretože nemôžete získať 4,5 inštancií, a teda efektívne plytvať ekvivalentom jednej c3.large v výpočtové zdroje. Ak by ste použili inštancie c3,2xlarge, potrebovali by ste 3 z nich, čím by ste efektívne vyhodili ekvivalent troch c3.large vo výpočtových zdrojoch. Ak použijete c3,4xlarge, budete potrebovať 2 z nich, čím efektívne miniete ekvivalent siedmich c3.large.Všimnite si toho, že to platí ako v prípade, že máte veľmi fixné potreby premávky, tak aj v prípade, že máte rôzne potreby premávky, ale máte dobrý systém automatického škálovania.
- Vylepšená dostupnosť (zmiešaná, ale spravidla v prospech horizontálneho škálovania): Horizontálne škálovanie umožňuje väčšiu dostupnosť, pretože ak dôjde k poklesu ktorejkoľvek inštancie, vaša kapacita sa dočasne zníži len o málo. Na rozdiel od toho, pri zvislom škálovaní každá jedna inštancia, ktorá klesá, veľmi poškodzuje kapacitu. Na druhej strane, horizontálne škálovanie môže znížiť dostupnosť, ak sú inštancie malé, majú menej vyrovnávacej pamäte na spracovanie jednej výpočtovo náročnej požiadavky a dočasne prestanú prijímať takúto požiadavku.
- Stabilita nákladov (zmiešaná, ale spravidla v prospech horizontálneho škálovania): Najmä pre spotové inštancie sú náklady stabilnejšie pre menšie inštancie z dôvodu väčšieho počtu ľudí, ktorí ich používajú. Nie je to však jednotná pravda.
- Zdieľaná pamäť (v prospech vertikálneho škálovania): Ak vaša aplikácia používa na spracovanie požiadaviek množstvo bežných údajov v pamäti, vertikálne škálovanie je lepšie, pretože umožňuje zdieľanie údajov v pamäti. Ak napríklad poskytujete vyhľadávací nástroj a ukladáte všetky indexy do pamäte RAM a tieto indexy zaberajú až 6 GB údajov. Ak použijete dve inštancie m3.large, duplikujete 6 GB na oboch počítačoch a na výpočet v každej inštancii vám zostane iba 1,5 GB (= 7,5 - 6). Na druhej strane, ak použijete jednu m3,2x veľkú, zostane vám na výpočet potrebných 9 GB pamäte. Aj keď neukladáte všetky údaje do pamäte, ale dopytujete sa na ne v úložisku údajov, zdieľaná pamäť vám môže stále pomôcť tým, že vám umožní ukladať prostriedky do vyrovnávacej pamäte. Všimnite si toho, že zváženie zdieľanej pamäte je tiež dôležité pri rozhodovaní medzi triedami inštancií, napr.určenie, či M alebo C dáva väčší zmysel.

Časť 4 z 9: Porozumenie regiónom AWS a zónam dostupnosti

1
Pochopte koncept oblasti AWS. Regióny AWS sú názvy zoskupení geograficky blízkych dátových centier Amazon Web Services. V apríli 2020 existuje dvanásť regiónov AWS (okrem AWS GovCloud): štyri v Európe, jeden v Kanade, sedem v ázijsko-tichomorskom regióne, päť v Európe, jeden na Blízkom východe a jeden v južnej Európe. Očakáva sa, že čoskoro budú v Európe pridané ďalšie oblasti AWS.
- Spiatočné časy v rámci oblasti AWS sú približne 2 milisekundy.
- Prenos údajov medzi rôznymi službami AWS v rámci regiónu, vrátane inštancií do a z inštancií EC2, je podstatne lacnejší ako medziregionálny prenos údajov, ale nie je úplne bezplatný.
- Ceny sa líšia podľa regiónu AWS, ale sú v rámci daného regiónu AWS rovnaké.
2
Pochopte koncept zóny dostupnosti AWS (AZ).
- AZ sú podskupinami v rámci AWS regiónov. Počet AZ na región sa pohybuje od 2 do 4.
- Všetky AZ sú navzájom izolované, takže poruchy v jednej AZ (napríklad požiare alebo výpadky elektriny) by nemali mať nepriaznivý vplyv na činnosť ostatných AZ.
- AZ pre inštanciu EC2 je špecifikovaná v čase vytvorenia inštancie.
- Zatiaľ čo ceny za inštancie na požiadanie a rezervované inštancie sú v rôznych zónach dostupnosti v regióne rovnaké, trhy okamžitých inštancií sa v rôznych zónach dostupnosti líšia.
- Rezervácie boli kedysi viazané na konkrétnu zónu dostupnosti. Od septembra 2016 je možné rezervovať daný rozsah zóny dostupnosti alebo rozsah regiónu. Rezervácia nie je viazaná na zónu dostupnosti, ak je to dané oblasťou. Predtým rezervované inštancie majú rozsah zóny dostupnosti, ale je možné ich zmeniť na rozsah oblasti.

Že používate niektoré ďalšie služby amazon — Majte na pamäti, že ec2 nemusíte používať len preto, že používate niektoré ďalšie služby amazon.

Časť 5 z 9: Pochopenie toho, ako úložisko elastických blokov (EBS) ovplyvňuje náklady

1
Pochopte dva rôzne druhy diskových úložísk, ktoré amazon ponúka pre svoje inštancie ec2.
- Elastic Block Storage (EBS) je vysokovýkonný úložný zväzok replikovaný v zóne dostupnosti. Daný EBS môže byť súčasne pripojený maximálne k jednej inštancii EC2, ale inštanciu, ku ktorej je pripojený, je možné zmeniť. EBS môže pretrvávať, aj keď je inštancia zastavená, a (ak je to uvedené pri spustení), aj keď je inštancia ukončená.
- Úložisko inštancie je lokálne úložisko spojené s konkrétnou inštanciou. Ponúka rýchlejší vstup/výstup, ale bez redundancie a bez vytrvalosti.
- V závislosti od obrázka Amazon Machine Image (AMI) použitého na spustenie inštancie môže byť koreňovým objemom inštancie buď obchod EBS, alebo inštančný obchod. Predchádzajúce typy inštancií sa nazývajú bootovacie inštancie EBS alebo inštancie podporované EBS.
- Inštancie novej generácie (C4, M4, R4 a C5) neponúkajú úložisko inštancií. Podporujú iba EBS.
2
Pochopte nákladové dôsledky používania inštancií podporovaných systémom ebs.
- Náklady na inštanciu EBS závisia od jej veľkosti, ako je uvedené pri vytváraní zväzku.
- EBS taktiež účtuje poplatky za I/O. Existuje niekoľko rôznych typov EBS s rôznymi modelmi oceňovania. Pri bežných EBS sa I/O poplatky vyskytujú vždy, keď dôjde k I/O. V prípade siete gp2, ktorá je navrhnutá pre vysokú priepustnosť, sa vám účtuje poplatok za poskytnutú priepustnosť, nie za skutočné využitie, ale so systémom preklopenia kreditu.
- V prípade inštancií podporovaných EBS objemy EBS pretrvávajú, aj keď je inštancia zastavená. V prípade dlhodobo fungujúcich inštancií sú náklady na EBS pomerne malé v porovnaní s nákladmi na inštancie. Avšak v prípadoch, ktoré sú spustené iba niekoľko hodín denne a na zvyšok času sa zastavia, môžu objemy EBS predstavovať značnú časť celkových nákladov.
- V závislosti od nastavení použitých pri spustení EBS objem EBS môže, ale nemusí pretrvávať aj po ukončení inštancie. Ak objem pretrváva, môže to spôsobiť značný únik nákladov, ak sa objemy EBS nevyrovnajú.
- Ak často poskytujete nové inštancie a EBS po ukončení inštancie automaticky neukončíte, EBS môže spôsobiť značný únik nákladov.
3
Pochopte, ako fungujú snímky EBS. Snímka EBS ukladá snímku aktuálneho obsahu EBS do S3.
- Zatiaľ čo EBS je viazaný na zónu dostupnosti, snímka EBS je k dispozícii v celom regióne, takže ho možno získať v akejkoľvek zóne dostupnosti v rámci regiónu. Dá sa tiež prenášať medzi regiónmi.
- Aj keď sú snímky EBS uložené v S3, metaúdaje na ich získanie sú uložené v systéme EBS. Nie je k nim priamy prístup ako k objektom S3. Aj keď sú teda podkladové údaje uložené veľmi nadbytočne, snímky majú iba 99,9% spoľahlivosť (na rozdiel od 99,99%+ pre S3).
- Snímky EBS je možné prenášať medzi regiónmi. Za prenos údajov medzi regiónmi sa účtujú obvyklé poplatky.
- Úložisko pre snímky EBS je prírastkové, takže ak sa snímka EBS nasníma viackrát, medzi snímky sa uloží iba zmenený obsah. Proces vymazania je však inteligentný a rekonštruuje neskoršie snímky pred odstránením predchádzajúcich.

Časť 6 z 9: pochopenie možností nákupu

1
Inštancie na požiadanie sú najdrahšie, ale najľahšie sa s nimi začína.
- Inštancie na požiadanie je možné kedykoľvek roztočiť a účtujú sa podľa typu inštancie a času, počas ktorého je inštancia spustená.
- Inštancie na požiadanie je možné kedykoľvek zastaviť a reštartovať. Za zastavenie sa inštancii neúčtuje žiaden poplatok. Lokálne úložisko (ak existuje) inštancie je zničené a akákoľvek verejná IP spojená s inštanciou sa uvoľní (pokiaľ nešlo o elastickú IP adresu). Elastické blokové úložisko (EBS) súvisiace s inštanciou je však zachované a AWS zaň stále účtuje poplatky.
- Inštancie na požiadanie môže používateľ kedykoľvek ukončiť. Po ukončení inštancie na požiadanie môže, ale nemusí byť odstránené zodpovedajúce úložisko elastických blokov. To závisí od nastavení uvedených pri spustení.
- AWS nezastaví ani nezastaví inštancie na požiadanie, aj keď inštancie môžu byť príležitostne nedostupné z dôvodu zhoršenia hardvéru alebo iných problémov s dátovým centrom.
- Inštancie na požiadanie majú tiež nárok na ochranu pred ukončením, vďaka ktorej je pre používateľa trochu ťažšie omylom ukončiť inštanciu.
2
Spotové inštancie sú podstatne lacnejšie ako inštancie na požiadanie.
- V čase vytvorenia používateľ, ktorý vytvára inštanciu, okrem určenia zóny dostupnosti a typu inštancie uvádza aj maximálnu spotovú cenu.
- Pokiaľ je aktuálna spotová cena pre túto zónu dostupnosti a typ inštancie nižšia ako maximálna spotová cena, inštanciu je možné vytvoriť a nebude ukončená. Akonáhle však aktuálna cena presiahne cenu spotovej inštancie, inštancia sa ukončí.
- Cena, ktorá sa skutočne účtuje za jednotku času, je aktuálna spotová cena a nie maximálna spotová cena.
- Bodové inštancie nemožno zastaviť. Ukončiť ich môže iba používateľ alebo AWS z cenových dôvodov.
- Po vytvorení inštancie nie je možné okamžitú cenu za spotovú inštanciu zmeniť.
- História okamžitých cien inštancií podľa regiónu, zóny dostupnosti a typu inštancie je k dispozícii na Amazone a dá sa použiť na rozhodovanie o inteligentných ponukách.
- Existujú obmedzenia počtu spotových inštancií, ktoré môže daný používateľ vytvoriť pre daný typ inštancie a zónu dostupnosti. Tieto limity sú vo všeobecnosti oveľa prísnejšie než limity súvisiace s celkovým počtom inštancií, pretože v dôsledku zmätku môžu ľudia vytvárať nezodpovedne točiace sa spotové inštancie s vysokými spotovými cenami (a spôsobujúce nárast celkových cien). Tieto limity je však spravidla možné na požiadanie zvýšiť podľa dostupnosti kapacity.
- V prípade niektorých typov inštancií a zón dostupnosti, najmä v prípade typu I, môže roztočenie okamžitých inštancií trvať veľa času kvôli nízkej celkovej kapacite miesta, napriek nominálne nízkej spotovej cene.
3
Rezerváciu je možné vykonať na 1 alebo 3 roky s tromi typmi platobných plánov: žiadne vopred, čiastočné vopred a všetky vopred.
- Po vykonaní rezervácie nie je možné zmeniť niektoré aspekty rezervácie. Patrí sem časové obdobie rezervácie, typ plánu platieb, operačný systém, typ prenájmu (vyhradené oproti predvolenému) a región.
- V prípade štandardných rezervovaných inštancií (štandardné RI) nemožno zmeniť triedu inštancie a generáciu (napríklad R3, C3, M3, M4).
- V prípade štandardných RI môžete zmeniť veľkosť inštancie v rámci rovnakej triedy inštancie a generácie. Veľkosť inštancie je možné zmeniť, pričom celková kapacita zostane rovnaká. Napríklad rezerváciu pre tri inštancie m3.xlarge je možné zmeniť na rezerváciu pre jednu inštanciu m3,2xlarge a jednu inštanciu m3.xlarge.
- Ak majú vaše rezervácie rozsah zón dostupnosti, musíte prepnúť zónu dostupnosti alebo zmeniť rozsah oblasti, aby ste mohli rezerváciu použiť v inej zóne dostupnosti.
- Všimnite si toho, že zmena veľkosti inštancií, získanie rozsahu oblasti alebo zmena zóny dostupnosti nie je možné pre rezervácie viazané na operačné systémy, ktoré majú licenčné náklady, ako napríklad operačné systémy Windows.
- Rezervácia nie je viazaná na žiadny konkrétny prípad. V skutočnosti sú inštancie, na ktoré sa vzťahujú výhrady, vytvorené rovnakým spôsobom ako inštancie na požiadanie. Rezervácie fungujú tak, že každú hodinu, kedy sa účtuje fakturácia, sa existujúce inštancie na požiadanie, ktoré sa používajú, porovnávajú s aktuálne aktívnymi rezerváciami. Ak platí niektorá z rezervácií, potom pre uvedené prípady platia znížené ceny na základe rezervácií. V opačnom prípade platí plná cena na požiadanie.
- V prípade rezervovaných inštancií (konvertibilných RI) je možné zmeniť triedu inštancie a generáciu. Ak nová konfigurácia stojí viac ako stará, zaplatíte rozdiel, ak stojí menej, AWS vám rozdiel nevráti, ale nadbytočnú kapacitu môžete predať na trhu vyhradených inštancií.

Vyhradených inštancií sa náklady lineárne líšia podľa veľkosti v rámci daného typu — V prípade inštancií na požiadanie a vyhradených inštancií sa náklady lineárne líšia podľa veľkosti v rámci daného typu a generácie inštancie.

Časť 7 z 9: Práca na robustnej architektúre nezávislej na inštancii

1

Vyhnite sa mentalite servera snehových vločiek. Investujte viac času a úsilia do písania skriptov (pomocou nástrojov ako Ansible alebo Chef), ktoré vám umožňujú jediným príkazom nasadiť nové inštancie pre vaše aplikácie. Urobte tento skript dostatočne flexibilným, aby ste mohli nasadiť inštancie na požiadanie aj na mieste s rovnakým skriptom.
2

Ak vaša aplikácia spracováva premenlivé záťaže z webového prenosu v reálnom čase, vložte inštancie za elastický nástroj na vyrovnávanie zaťaženia (ELB).
3

Skúste automatické škálovanie a použite ho, ak je to možné. Automatické škálovanie vám umožňuje zvýšiť kapacitu inštancie v reálnom čase v reakcii na zvýšenie záťaže. Nastavenie je trochu práca navyše.
4

Uchovávajte všetky kritické dlhotrvajúce údaje mimo jednotlivých inštancií ec2 (s potenciálnou výnimkou špeciálnych inštancií určených pre dátové úložiská, ktoré pravidelne zálohujete). Pokiaľ je to možné, použite S3 alebo databázy na akékoľvek údaje s dlhou životnosťou.
5
Vaše skripty by mali byť schopné bezproblémovo spracovať aktualizácie vašej aplikácie. Aktualizácie by mohli spracovať ktorýmkoľvek z nasledujúcich spôsobov:
- Samotné aplikácie je možné aktualizovať na živej produkčnej inštancii bez toho, aby ste museli túto inštanciu prepnúť do režimu offline. Aj keď to môže platiť pre niektoré typy aktualizácií, nemali by ste sa na to spoliehať, pretože je to jediný spôsob, akým je možné aktualizovať aplikáciu.
- Nasadia sa nové inštancie s aktualizovaným kódom aplikácie a spoja sa s nástrojom na vyrovnávanie zaťaženia a staré inštancie sa potom odpojia od nástroja na vyrovnávanie zaťaženia a ukončia sa. Pri tomto druhu aktualizácie je kapacita počas aktualizácie dočasne väčšia. Všimnite si toho, že nadbytočná kapacita inštancie bude mimo vyhradenej kapacity, a preto nové inštancie, ak budú na požiadanie, budú počas prechodu účtované plnou sadzbou na požiadanie.
- Všetky existujúce inštancie sa aktualizujú. Ak je súčasné produkčné zaťaženie možné zvládnuť menej ako celou sadou inštancií, potom je možné inštancie aktualizovať jednu po druhej: každá inštancia sa odpojí od nástroja na vyrovnávanie zaťaženia, aktualizuje sa a potom sa znova pripojí k nástroju na vyrovnávanie zaťaženia. Pri tomto druhu aktualizácie je kapacita počas aktualizácie dočasne menšia. Ak sa produkčné zaťaženie líši podľa dennej doby, tento druh aktualizácie je možné vykonať v čase, keď je produkčné zaťaženie nízke.
6

Nastavte alarmy pre nástroje na vyrovnanie zaťaženia, aby boli schopné detekovať príliš málo zdravých hostiteľov, neobvyklé vzorce návštevnosti alebo veľký počet chýb.
7

Rozložte inštancie do viacerých zón dostupnosti v rámci oblasti, aby ste získali väčšiu odolnosť proti poškodeniu konkrétnej zóny dostupnosti. Pre ELB viazanú na tento región je možné aktivovať akúkoľvek zónu dostupnosti v danej oblasti.
8

Použite kontroly stavu 53 a núdzové prerušenie trasy 53 na redundanciu medzi regiónmi pri živom podávaní.

Prečítajte si tiež: Ako urobiť Mirepoix?

Časť 8 z 9: Nastavenie sledovania a monitorovania

1

V konzole amazon ec2 (časť „správy“) môžete získať správy o nákladoch na amazon ec2 (nezahŕňa niektoré náklady na prenos údajov) a o využití vyhradenej inštancie. Informácie môžete rozdeliť podľa regiónu, zóny dostupnosti, triedy inštancie, typu inštancie a možnosti nákupu a pozrieť sa na využitie na hodinovej alebo dennej báze. Údaje neprúdia okamžite a môžu byť oneskorené o 24-48 hodín.
2

Váš účet AWS má prístup k fakturačným údajom, ktoré poskytujú úplné rozdelenie nákladov. Nastavte upozornenie na fakturáciu, aby sa údaje začali odosielať do služby Amazon CloudWatch. Potom môžete nastaviť ďalšie upozornenia pomocou služby CloudWatch. Údaje CloudWatch prichádzajú ako dátové body každých niekoľko hodín, ale neobsahujú podrobný rozpis.
3

Z účtu AWS si môžete kedykoľvek stiahnuť podrobné rozpis podľa hodín a typu služby. Tieto údaje zvyčajne meškajú až 6 hodín, v prípade niektorých služieb však môžu byť ešte oneskorenejšie.

Váš účet AWS má prístup k fakturačným údajom, ktoré poskytujú úplné rozdelenie nákladov.

Časť 9 z 9: Robte a zlepšujte svoje nákupné rozhodnutia

1

Spojte všetky faktory a začnite sa rozhodovať. Musíte zistiť kombináciu inštancií, ktoré budete používať, podľa triedy inštancie, typu inštancie, oblasti, zóny dostupnosti a možnosti nákupu.
2
V ideálnom prípade sa snažte mať všetky svoje inštancie buď rezervované, alebo inštančné. Nemala by existovať žiadna vyhradená kapacita na požiadanie, iba veľmi dočasne pri vytváraní nových inštancií, ktoré by nahradili existujúce.
- Pretože si však rezervácie vyžadujú dlhodobý záväzok, môže mať zmysel použiť inštancie na požiadanie namiesto toho pre kritické aplikácie, kde sú podrobnosti o typoch inštancií a potrebnej kapacite stále nejasné.
- Vo všeobecnosti rezervácie najviac šetria na exotickejších inštanciách (ako sú inštancie D, I alebo P), ale sú pre ne tiež najrizikovejšie, pretože tieto prípady majú veľmi špecifické prípady použitia, kde sú cenné.
3

Monitorujte náklady nad všetky ostatné veci, ktoré monitorujete. Zaistite, aby boli náklady súčasťou údajov, ktoré si pravidelne prezeráte. Zopakujte si svoje kapacitné rozhodnutia na základe toho, čo stále objavujete.