Hei! Tuumailin tuossa ja minulla olisi muutama ehdotus IT-alustan kuukausittaisten kustannusten alentamiseksi!
Kustannustehokkuus on aina muodissa, mutta tällaisena poikkeusaikana jokainen idea löysien kustannusten karsimiseksi kuulostaa erittäin hyvältä idealta. Joten sinunkin kannattaa tarttua tähän tarjoukseen ja perehtyä asiaan pintaa syvemmältä.
Pilvipalvelut on alue, jossa pienistä puroista voi kertyä yllättäen suuri joki, tai mitättömältä tuntuvan asian sivuvaikutuksena voi syntyä merkittäviä kustannuksia, joiden syy-seuraussuhde ei välttämättä ole itsestään selvä ja tilanteeseen ei siksi uskalleta puuttua. Lisäksi pilvipalveluiden peruslaskutusmalli pohjautuu käytön mukaiseen laskutukseen, joten voi helposti harhautua kuvittelemaan, että kustannustasolle ei mahda mitään - erityisesti kun kustannuksen aiheuttaja on usein eri taho kuin laskun maksaja.
Seuraavassa muutamia vinkkejä, joiden avulla pääset tilanteen päälle AWS:n kustannusten optimoinnissa yleisimmin käytettyjen palvelujen osalta ja säästät organisaatiollesi mahdollisesti jopa tuhansia euroja kuukaudessa!
Yleiset AWS:n kustannushallinnan vinkit
Poista unohtuneet resurssit eri tileiltä ja alueilta
Kuulostaa triviaalilta neuvolta, mutta ei sitä todellisuudessa ole. On hyvin tyypillistä, että palvelun kehittämisen alkuvaiheessa tai tutustuessa AWS-ympäristöön yksittäisiä palveluja tulee nostettua ylös usealle eri regioonalle ympäri maailmaa. Voi esim. olla että alat kehittämään uutta palvelua yhdelle regioonalle, mutta huomaat jossain vaiheessa kehitystyötä, että kyseisellä regioonalla ei vielä ole saatavilla kaikkia tarvitsemiasi palveluja ja siirrät kehitystyön toiselle regioonalle, ja palvelut unohtuvat resursseja kuluttamaan myös aiemmalle regioonalle.
Sama pätee myös eri AWS-tileille. Mikäli olet yhdistänyt useita AWS-tilejä laskutuksen näkökulmasta yhden organisaation ja konsolidoidun laskutuksen alle, voi eri tileille jäädä päälle palveluja, joita kukaan ei käytännössä enää tarvitse. Ja koska laskun maksajalla ei välttämättä ole varmuutta yksittäisten tilien käyttöasteesta ja -tarpeesta, voi laskulle päätyä vuodesta toiseen turhia kustannuksia. Lukemalla artikkelia eteenpäin saat vinkkejä siitä, minkälaiset resurssit useimmiten unohtuu päälle ja laskuja kerryttämään vaikka pääosa palveluista olisikin ajettu alas.
Kannattaa harkita myös Service Control Policyjen käyttöönottoa organisaatiossa. Niiden avulla voit helposti esimerkiksi määrittää, mille regioonille resursseja voidaan organisaatiossa ylipäätään luoda. Tämän avulla pidät huolen, että jatkossa palveluita ei vahingossa luoda vääriin konesaleihin.
Sammuta kehitysympäristöt yöksi ja viikonlopuksi
Hyvin tyypillisesti palvelukehittäjille perustetaan AWS:ään omat käyttäjätilit, jotta kukin kehittäjä voi kehittää omalla vastuulla olevia osia kokonaisuudesta eristettynä muiden kehitystehtävistä. Ja yhtä tyypillisesti kehitysympäristöt ovat päällä 24/7 vaikka kehittäjät tarvitsevat ympäristöjä yleensä 8/5. Kuulostaa siis säästökohteelta.
Mikäli kehitettävässä palvelukokonaisuudessa on komponentteja, joiden käytöstä maksetaan minuutti- tai tuntipohjaista veloitusta, voi kehitysympäristöjen kustannukset nousta aivan turhaa suuriksi. Esimerkiksi EC2-instanssit tai EC2-instansseja hyödyntävät palvelut, kuten ElasticSearch, voivat generoida kuukaudessa helposti usean kymmenen euron kustannuksen ja jos tällaisia palveluita on käytössä useita, voi kuukausikustannus olla satoja euroja. Ja jos kehitystiimin koko on vaikka 15 henkilöä, voi pelkästään kehitystilien kuukausikustannukset olla tuhansissa euroissa per kuukausi. Tällöin on merkitystä sillä, maksetaanko tätä summaa täysien vuorokausien mukaan vai vain kolmasosa siitä.
Kehitysympäristönkin infrastruktuuri kannattaa hallita koodilla, jolloin ympäristö on helppo ajaa päivän päätteeksi alas ja aamulla taas takaisin ylös. Suosittelemme siis Cloudformationin, Terraformin tai vaikka Elastic Beanstalkin hyödyntämistä kehitysympäristöissä.
Ota AWS Savings Plan käyttöön
Kun olet saanut varmuuden siitä, että AWS tulee olemaan palvelusi tuotantoalustana tulevat vuodet ja olet alkanut saada tuntumaa palvelun tuotantokäytön vaatimasta kapasiteetista, kannattaa ottaa käyttöön AWS Savings Plan. Yksinkertaisuudessaan Savings Planin idea on se, että kun sitoudut käyttämään AWS:n palveluja tietyllä volyymilla seuraavat 1-3 vuotta, saat merkittävän alennuksen palveluiden hinnoittelusta sopimuskaudeksi.
EC2:n kustannusäästövinkit
Right-sizing - älä maksa turhasta
Tulevan kapasiteettitarpeen ennustaminen etukäteen on vaikeaa. Ja koska perussopimusmallilla maksat AWS:ssä vain siitä kapasiteetista, jota kulloinkin käytät, ei ennustamiseen kannatakaan käyttää etukäteen aikaa. Mutta kun olet saanut palvelun tuotantoon, kannattaa palvelun kapasiteetin sopivuutta käyttötarpeeseen monitoroida aktiivisesti.
Oleellista monitoroinnissa ja palvelun optimoinnissa on ymmärtää palvelun vaatimat kapasiteettitarpeet ja niiden muutokset. Eli onko palvelulla jatkuvasti tasainen kuorma vai selkeitä kuormapiikkejä? Palvelu kannattaa optimoida niin, että käytössä oleva konetyyppi ja sen resurssit riittävät juuri sopivasti palvelun normaalikuorman pyörittämiseen, ja kuormapiikkitilanteissa palvelu voidaan monistaa useammalle EC2-instanssille autoscaling-ominaisuuden avulla.
Aseta on/off-ajat
Jos palvelun ei tarvitse olla käynnissä jatkuvasti, älä pidä sitä käynnissä jatkuvasti. Jos on riittävää, että palvelu esimerkiksi päivittää raportteja kerran vuorokaudessa yöaikaan, ei palvelusta kannata maksaa päiväsaikaan lainkaan.
Optimoi EC2-instanssien hinnat
Spot instances -hinnoittelumalli soveltuu käyttöön tilanteissa, joissa haluat saada EC2-kapasiteettia käyttöösi mahdollisimman edullisesti ja operaatioiden valmiiksi saaminen ei ole kovin aikakriittistä. Eli esimerkiksi tilanteissa, jossa sinun tulee suorittaa suurta laskentakapasiteettia vaativa datankäsittelytehtävä kuluvan kuukauden aikana, mutta sen tarkemmin ei ole väliä, milloin datankäsittely tapahtuu eikä operaatio mene pieleen vaikka laskenta keskeytyisi yllättäen päiväksi tai pariksi.
Spot instances -hinnoittelun käyttö perustuu siihen, että valitset haluamasi resurssityypin ja rajahinnan, jonka suostut kapasiteetista maksamaan. Kun kysyntä ja tarjonta kohtaa, saat palvelun käyttöösi, usein jopa kymmeniä prosentteja edullisemmin kuin vastaavan koneen listahinta.
Spot instances -hinnoiteltuja palveluita käytettäessä kannattaa huomioida, että hinnan muuttuessa tai kapasiteetin loppuessa instanssi voidaan terminoida milloin vain. Uuden juuri samanlaisen instanssin saaminen käyttöön ei välttämättä onnistu, mutta jos vaihtoehtoiset konetyypit kelpaa ja Availability Zonella ei ole niin väliä, saat useimmiten kyllä rautaa alle ja operaation jatkumaan.
Jos taas palvelusi kapasiteettitarve on tasainen ja tiedät tarvitsevasi resursseja seuraavat 1-3 vuotta, kannattaa hinnoittelumalliksi valita Reserved Instances. Tällöin sitoudut käyttämään EC2-konetta 1-3 vuoden ajanjakson ajan, ja saa tästä vastineeksi merkittävän alennuksen palvelun hinnasta.
Hinnoitteluvaihtoehtojen lisäksi kannattaa aika-ajoin tarkistaa käytettävissä olevat EC2-instanssien perustyypit ja hinnat. AWS julkaisee säännöllisesti uusia sukupolvia EC2-konetyypeistä ja vaihtaa samalla eri konetyyppien hinnoitteluja. Voi siis olla, että instanssiesi hankintahetken jälkeen konetyypeissä on tapahtunut kehitystä, ja saisitkin nyt paremman hinta-tehosuhteen vaihtamalla toiseen konetyyppiin.
Poista orvoiksi jääneet resurssit
Kun EC2-instanssin tai laajempimittaisen palvelukokonaisuuden käyttötarve loppuu, jokainen varmastikin muistaa ajaa EC2-instanssit alas ja ehkä jopa terminoida ne. Mutta EC2:n käyttöön liittyviä muita resursseja jää helposti roikkumaan ympäristöön, ja osa niistä generoi kustannuksia. Seuraavassa muutamia tärppejä yleisimmistä kukkaron tyhjentäjistä:
EBS-instanssit: Oletuksena EC2-koneeseen kytketty root-volume tuhotaan automaattisesti EC2-koneen tuhoamisen yhteydessä, mutta muut EBS-levyt eivät oletuksena automaattisesti tuhoudu. Ja root-volumekin on voitu konfiguroida niin, että se ei tuhoudu automaattisesti. Erityisen mittavaksi kustannukset voivat muodostua, jos EBS-levyjä jää “roikkumaan” autoscaling-tilanteissa - eli joka kerta kun palvelua skaalataan ylöspäin, otetaan uusia EBS-levyjä käyttöön mutta joka kerta kun palvelua skaalataan alaspäin, voi levyt jäädäkin orpoina generoimaan kustannuksia.
EBS-snapshotit: Myös varmuuskopiot maksavat ja on huomioitavaa, että EBS-levyn tuhoaminen ei automaattisesti poista tallennettuja EBS-snapshotteja. Tämän vuoksi snapshotit voivat helposti unohtua kustannuksia generoimaan vaikka itse palvelu on jo tuhottu ja unohdettu.
Elastic IP -osoitteet: EIP:t jäävät hyvin helposti roikkumaan ympäristöön siitä yksinkertaisesta syystä, että niiden käyttö ei maksa, mutta niiden käyttämättömyys maksaa. Tämä johtuu siitä, että AWS:lläkin on käytössään vain rajallinen IP-avaruus ja käyttämättömät osoitteet pitää saada kiertoon osoitteiden tarvitsijoille. Eli jos olet jo tuhonnut EIP:tä hyödyntävän EC2-instanssin, muista myös käydä poistamassa itse EIP-osoite.
Load balancerit: Kuormantasaajatkin generoivat kustannuksia, ja ne jäävät helposti poistamatta käytöstä, vaikka niihin kytketyt resurssit olisivatkin jo poistettu. Kannattaa siis käydä läpi erilaiset kuormantasaajat ja tarkistaa, onko niihin kytkettynä palveluja ja kulkeeko kuormantasaajien läpi liikennettä. Turhat kuormantasaajat kannattaa poistaa kuluttamasta rahaa.
S3:n kustannussäästövinkit
S3 tarjoaa kaikkiaan kuusi erilaista versiota palvelustaan eri käyttöskenaarioita varten ja luonnollisesti erilaisella hinnoittelulla. Ja kuten arvata saattaa, oletuksena käytössä oleva S3 Standard ei ole se edullisin vaihtoehto.
Jos esimerkiksi et tarvitse 99,99% saatavuutta ja tallennettua dataa luetaan harvakseltaan, kannattaa valita käyttöön esim. S3 Standard IA (Infrequent Access) -tallennusluokka, jossa on Standardia alhaisempi datan säilytyshinta, mutta oma hintansa datan lukemiselle. Jos taas käytät tallennustilaa arkistointityyppiseen käyttöön ja sinulle riittää 12h datan noutoaika, kannattaa ehdottomasti valita edullisin S3 Deep Glacier -tallennusluokka.
Jos epäilet, että osa tallennetusta datasta on tiheässä käytössä mutta osaa käytetään harvakseltaan, tai että dataa käytetään välillä intensiivisesti ja välillä harvemmin, kannattaa käyttöön ottaa S3 Intelligent-Tiering, joka pientä lisähintaa vastaan automaattisesti analysoi datankäyttöä ja siirtää harvemmin käytettyjä objekteja edullisempaan tallennusluokkaan.
Voit myös itse määrittää S3:een tallennetun datan elinkaarimallin. S3 Lifecycle -määritysten avulla voit määrittää datan esimerkiksi siirrettäväksi edullisempaan tallennusluokkaan, kun objektin ikä on 30pv, tai voit merkata datan automaattisesti poistettavaksi, kun objektia on säilytetty 2v.
Analysoi ja optimoi DynamoDB:n käyttöä
DynamoDB:n hinnoittelu perustuu datan kirjoitukseen ja lukemiseen. Jotta pystyt arvioimaan fiksuimman hinnoittelumallin DynamoDB:hen, analysoi CloudWatchissa ConsumedReadCapacityUnits- ja ConsumedWriteCapacityUnits-metriikoita. Mikäli metriikat kertovat tasaisesta kuormasta, on kustannustehokkain hinnoittelumalli Provisioned Capacity Mode. Tällöin hinnoittelu pohjautuu ennustamiisi kirjoitus- ja lukumääriin ja voit itse määrittää DynamoDB:n autoscaling-ominaisuudet reagoimaan mikäli tauluun kohdistuu yllättäviä kuormituspiikkejä.
Jos taas metriikka kertoo purskeisuudesta tai kausittain paljon vaihtelevista luku- ja kirjoitusmääristä, kannattaa hinnoittelumalliksi valita On-demand Capacity Mode. Tällöin sinun ei tarvitse etukäteen ennustaa kirjoitus- ja lukumääriä, vaan maksat jokaisesta kutsusta erikseen ja DynamoDB hoitaa palvelun skaalauksen automaattisesti vastaamaan kysyntää.
Taklaa virheet palveluistasi
Reliability & health engineering kannattaa. Jos palveluusi ilmaantuu vikaantuvia komponentteja tai logiikkaa, ne kannattaa laittaa nopeasti kuntoon. Esimerkkinä SQS-jonot ja Dead Letter Queue -konfiguraation puuttuminen.
Äkkiseltään voisi kuvitella, että DLQ:lla ei ole juurikaan yhteyttä kustannussäästöihin, mutta käytännössä totuus on usein päinvastainen. Jos jonoon päätyy virheellinen viesti ja sitä yritetään käsitellä logiikkakerroksessa, esim. Lambdassa tai EC2-koneella, virheellisen viestin käsittely oletettavasti epäonnistuu ja viesti palaa jonoon. Jos jonopalvelussa ei ole konfiguroitu DLQ:ta, viesti voi jäädä loputtomaan limboon jonon ja logiikkapalvelun välille.
Jos virheellisiä viestejä ilmaantuu jonoon vain yksittäisiä ja harvakseltaan, ei tämä välttämättä ole itsessään ongelma kustannusnäkökulmasta - muutamat tuhannet ylimääräiset käsittelykerrat Lambda-funktiossa tuskin paljon kustannuksia lisää. Mutta lompakon kiusaksi voikin välillisesti muodostua error-logien räjähdysmäinen kasvu ja sitä kautta CloudWatchin kustannusten merkittävä kasvu - CloudWatchin päivähinta pompsahtaa hetkessä muutamista senteistä kymmeniin euroihin.
Loggaus ja hälytykset kuntoon
Edellä mainitut ovat vain esimerkkejä paikoista, joissa kustannuksia voidaan säästää. Riippuen arkkitehtuuristasi vastaavanlaisia säästämisen paikkoja voi olla paljon erilaisia.
Yhteenvetävänä suosituksena myös kustannussäästöjen näkökulmasta suosittelemme kunnollisen loggaus- ja analysointityökalun käyttöönottoa osana AWS-palveluita. Esimerkiksi Datadog on erinomainen palvelu, joka valvoo herkeämättä AWS-infrastruktuurisi tilaa ja lokeja. Analysointityökalun avulla pääset nopeasti havainnoimaan arkkitehtuurisi hitaasti toimivia komponentteja ja löytämään niiden juurisyyt ja pystyt helposti havainnoimaan potentiaalisia ongelmatekijöitä jo ennen kuin ne näkyvät millään tavalla loppukäyttäjille.
Ehkä yksi parhaista tällaisten työkalujen ominaisuuksista on mahdollisuus asettaa hälytyksiä erilaisten virhe- ja ongelmatilanteiden varalle. Näin järjestelmä valvoo ympäristöäsi ja proaktiivisesti ilmoittaa, mikäli lokeihin alkaa ilmestymään normaalia enemmän virheitä, tai jos palveluun alkaa yhtäkkiä tulemaan merkittävästi normaalitoimintaa enemmän kyselyitä.
Kunnollisella monitorointityökalulla voit nopeastikin säästää merkittäviä summia AWS:n kuukausikuluissa, jotka muuten olisivat saattaneet jäädä kokonaan huomaamatta.
NordHero on kustannustehokkaiden pilviarkkitehtuurien asiantuntija. Ota rohkeasti yhteyttä, niin autamme kustannussäästökohteiden löytämisessä ympäristöstäsi!