AWS Organizations on AWS:n natiivipalvelu, jolla hallitset useita AWS-tilejä yhden hallintotilin (management account) alta, ja samalla saat konsolidoidun laskutuksen, jaetut volyymialennukset, jaetut Savings Plans- ja Reserved Instances -varaukset sekä keskitetyn governance-kerroksen Service Control Policyilla (SCP). Käytännössä monitilihallinta on edellytys sille, että kustannukset saadaan kohdistettua tiimeille, tuotteille ja ympäristöille ilman, että jokaisesta laskusta tulee mysteeri. Tässä oppaassa käyn läpi vuoden 2026 parhaat käytännöt, sudenkuopat ja esimerkit tuotantotason monitiliympäristöistä.
AWS Organizations konsolidoi laskutuksen: kaikki jäsentilit (member accounts) maksavat yhden laskun hallintotilin kautta, ja volyymialennukset (S3, tiedonsiirto) lasketaan koko organisaation käytöstä.
Savings Plans ja Reserved Instances jakautuvat oletuksena kaikkien jäsentilien kesken. Voit kytkeä tämän pois yksittäisille tileille billing-asetuksista, jos haluat estää tuotannon varausten "syömisen" kehitysympäristöissä.
Cost Allocation Tags pitää aktivoida hallintotilillä Billing-konsolissa ennen kuin ne näkyvät Cost Explorerissa tai CUR 2.0 -raporteissa. Tilien omat aktivoinnit eivät riitä.
Organizational Units (OU) -rakenne on FinOps-näkökulmasta sama asia kuin kustannuskeskusrakenne: suunnittele se ympäristön (prod/dev), tiimin tai tuotteen mukaan, ei satunnaisesti.
Cost Categories on AWS:n alikäytetty tehoase: voit luoda virtuaalisia ryhmittelyjä tilien, tagien ja palveluiden yli ilman, että koskaan kosket tageihin.
CUR 2.0 (Cost and Usage Report) on totuuden lähde. Cost Explorer on käyttöliittymä, mutta CUR menee Athenan, QuickSightin ja oman BI-pinon kautta hallintaan.
Mikä on AWS Organizations ja miksi monitilirakenne kannattaa?
AWS Organizations on ilmainen palvelu, joka kytkee useita AWS-tilejä yhteen hallintotilin (management account, ennen "master account") alle. Rakenne muodostaa puun: juuri (root) → Organizational Unitit (OU) → jäsentilit. Itse olen tällä hetkellä konsultoimassa organisaatiota, jossa on 187 jäsentiliä, ja vakuutan, että ilman Organizations-rakennetta laskutus, varausten jakaminen ja security baselinet eivät yksinkertaisesti skaalaudu.
Miksi useita tilejä? Tili on AWS:ssä tiukin eristysraja. IAM-rajoja voi kiertää inhimillisillä virheillä, mutta tilirajat eivät vuoda. Yleinen baseline-rakenne on: yksi tili per ympäristö per työtaakka (prod / staging / dev), erilliset tilit security toolingille, log archive -tilille ja shared services -tilille. AWS:n oma Control Tower -palvelu ohjaa tähän malliin, ja se on minusta järkevä lähtökohta, jopa pienemmille organisaatioille.
Kustannusnäkökulmasta monitilirakenne tarjoaa kolme asiaa, jotka ovat lähes mahdottomia yhden tilin mallissa: luonnollinen kustannusten kohdistaminen (jokaisella tiimillä oma tili = oma rivi laskussa), blast radius -rajaus (väärä Bedrock-kokeilu ei polta koko organisaation budjettia) ja quota-eristys (yhden tilin EC2-kiintiön loppuminen ei jäädytä muita).
Miten konsolidoitu laskutus toimii käytännössä?
Konsolidoitu laskutus tarkoittaa, että hallintotili saa yhden kuukausilaskun, joka sisältää kaikkien jäsentilien käytön. Mutta tärkeämpää kuin yksinkertaisuus on volyymietu: AWS laskee tiered-hinnoittelun (esim. S3-tallennus, CloudFront-egress, Lambda-kutsut) koko organisaation yhteenlasketusta käytöstä, ei tilikohtaisesti.
Käytännön esimerkki S3 Standardin tiered-hinnoittelusta (us-east-1, 2026): ensimmäiset 50 TB maksavat $0,023/GB, seuraavat 450 TB maksavat $0,022/GB. Jos sinulla on viisi tiliä, joissa kullakin on 30 TB dataa, yhden tilin näkökulmasta olet aina ylimmässä portaassa. Konsolidoinnin jälkeen 150 TB:stä 50 TB on ylimmässä portaassa ja 100 TB on alemmassa, eli säästö on noin $1 000/kk pelkästään tästä yhdestä palvelusta.
AWS:n virallinen Consolidated Billing -dokumentaatio listaa palvelut, joissa volyymietu lasketaan organisaatiotasolla. Kannattaa tarkistaa lista vuosittain, se laajenee.
OU-rakenteen suunnittelu kustannusnäkökulmasta
OU eli Organizational Unit on Organizations-puun "kansio". OUt itsessään eivät vaikuta laskutukseen, mutta ne ovat ainoa rakenne, johon SCP-politiikat ja Cost Categoriesin sääntöjen automaatiot voivat tarttua. Suunnittele OU-puu kuin kustannuskeskusrakenne. Jälkikäteen siirtäminen on mahdollista, mutta tekee historiaraportoinnista sotkuista.
Suositan tätä OU-baselinea isompaan organisaatioon:
Tagaus ei korvaa OU-rakennetta. Olen nähnyt yrityksiä, joissa kaikki ajaa "Workloads"-OU:ssa ja erottelu tehdään tageilla, ja sitten kahden vuoden kuluttua kustannusraportit ovat täynnä reikiä, koska kukaan ei muista tagata uusia resursseja. OU = rakenteellinen eristys; tagit = täydentävä metadata. Lue myös syvemmin pilviresurssien tagaus ja kustannusten kohdistaminen -opas, joka kattaa tagaustrategian yli pilvipalveluiden.
Voiko Savings Planeja ja Reserved Instanceja jakaa tilien välillä?
Kyllä, ja oletuksena ne jakautuvat. AWS soveltaa Savings Plans- ja RI-alennuksia organisaationlaajuisesti: jos hallintotilillä ostettu 3-vuotinen Compute Savings Plan kattaa $10/tunti ja jäsentilin tuotannossa kuluu $7/tunti compute-aikaa, loput $3/tunti voidaan soveltaa toisen jäsentilin käyttöön. Tämä on iso etu, ja samalla iso riski, jos ei hallita.
Käytännön ongelma: jos kehitysympäristössä joku käynnistää ison EC2-rumman, jäsentilin näkökulmasta lasku on alhainen, koska RI-etu "imeytyy" siihen ennen tuotantoa. Tuotantotiimi näkee yllättäen on-demand-laskutusta omilla resursseillaan.
Ratkaisu: Billing-konsolista (hallintotilillä) voi kytkeä yksittäisten tilien RI/Savings Plans -jakamisen pois päältä. Suosittelen tätä mallia:
Sandbox-OU:n tilit: jakaminen pois päältä (estää kalliiden varausten "kohdistumisen" leikkityöhön).
Non-Prod-OU: jakaminen päällä, mutta seuraa Cost Explorerista varausten utilisointia tileittäin.
Prod-OU: jakaminen päällä. Tämä on koko jutun pointti.
Yksityiskohtaisemman vertailun ostopäätökseen löydät kirjoituksesta AWS Savings Plans vs Reserved Instances 2026. Se kattaa myös, milloin Compute SP voittaa EC2 Instance SP:n ja milloin standardi-RI on edelleen järkevä valinta.
Kustannusten kohdistaminen: tagit, Cost Categories ja CUR 2.0
Kustannusten kohdistamiseen on AWS:ssä kolme työkalua, ja niitä kannattaa käyttää kerroksittain, ei toisistaan riippumatta.
1. Cost Allocation Tags
Tagit ovat resurssikohtaista metadataa. Niitä on kahta lajia: AWS-luodut (esim. aws:createdBy) ja käyttäjän määrittelemät. Kummatkin pitää aktivoida erikseen hallintotilin Billing-konsolissa kohdassa "Cost allocation tags". Pelkkä tagin lisääminen resurssiin ei riitä, ennen aktivointia se ei näy kustannusraporteilla. Tämä on yksi yleisimmistä virheistä, joita näen kentällä.
2. Cost Categories
Cost Categories on virtuaalinen ryhmittely sääntöjen perusteella. Voit luoda kategorian "Tiimi", joka mappaa tilit ja tagit sääntöihin: "tilit 123, 456 → Maksuliikennetiimi", "kaikki resurssit joilla tag Team=ml → ML-tiimi". Tämä on erityisen hyödyllinen, kun tagaus on epätäydellistä. Voit täydentää kuilun tilipohjaisella säännöllä. AWS Cost Categories -dokumentaatio kattaa syntaksin ja säännönlogiikan tarkemmin.
3. CUR 2.0 (Cost and Usage Report)
CUR 2.0 (julkaistu vuoden 2024 lopulla, vakaa 2026) on AWS:n yksityiskohtaisin laskutusvienti: rivi per resurssikäyttötunti. Vie se S3-bucketiin, kytke Athena ja kirjoita kyselyt itse. Cost Explorer on hyvä Quick look -työkalu, mutta isompaa allokointimallia varten tarvitset CUR:n. Esimerkkikysely Athenalla, joka erittelee kustannukset OU:n mukaan (oletetaan että line_item_usage_account_id on mapattu OU:hun erillisessä taulussa):
SELECT
ou.ou_name,
cur.product_servicecode,
SUM(cur.line_item_unblended_cost) AS unblended_cost
FROM cur_2026_06 cur
LEFT JOIN account_to_ou ou
ON cur.line_item_usage_account_id = ou.account_id
WHERE cur.line_item_usage_start_date >= DATE '2026-06-01'
AND cur.line_item_line_item_type = 'Usage'
GROUP BY ou.ou_name, cur.product_servicecode
ORDER BY unblended_cost DESC
LIMIT 50;
Suosittelen pitämään account_to_ou -mapping-taulun versionhallinnassa (Terraform tai oma skripti). OU-siirrot tapahtuvat, ja historiallinen totuus pitää säilyttää.
SCP-politiikat ja kustannus-governance
Service Control Policies (SCP) eivät anna oikeuksia, ne rajoittavat niitä. SCP voi koskea OU:ta tai yksittäistä tiliä, ja se asettaa kovan katon sille, mitä kyseisen tilin IAM-roolit voivat tehdä, vaikka roolilla itsellään olisi täydet oikeudet. Kustannusnäkökulmasta SCP on tehokas estotyökalu.
Esimerkki SCP:stä, joka estää kalliiden GPU-instanssityyppien käynnistämisen Non-Prod-OU:ssa:
Tämä yksittäinen politiikka voi säästää organisaatiossa kymmeniä tuhansia euroja kuukaudessa, jos joku kehittäjä erehtyy klikkaamaan väärää instanssityyppiä testiympäristössä. Yhdessä konsultoinnissani estimme näin $34 000 kuukausittaisen "vahinkokulun" kun lähestyttiin malli-FT-aikaa.
Muita hyödyllisiä SCP-kuvioita ovat region-rajoitukset (estä käyttö regionissa, jossa data residency ei ole sallittu) ja Marketplacen tilaustenkielto Sandbox-OU:lle. AWS:n SCP-syntaksiopas käy läpi täydellisen referenssikielen.
Showback vs chargeback monitilimallissa
Kun olet saanut kustannukset kohdistettua, herää seuraava kysymys: maksaako tiimi laskunsa oikeasti, vai näkeekö se vain raportin? Tämä on showback (näytä) vs chargeback (laskuta) -keskustelu, ja se on FinOps-organisaation kypsyysmittari.
Showback on lähtötila. Tiimi saa kuukausittaisen raportin "tiimisi käyttö oli €18 432" ilman, että rahaa todella siirtyy. Tavoite on luoda kustannustietoisuus. Chargeback siirtää rahaa: keskitetty IT-budjetti veloittaa tiimien kustannuspaikkoja. Tämä vaatii laskentahallinnolta sisäisen veloituslogiikan, mutta tuottaa selvästi voimakkaamman insentiivin optimoida.
Monitilirakenne tukee kumpaakin mallia, mutta chargeback on huomattavasti helpompi, koska AWS-tili = kustannuskeskus = yksiselitteinen lasku. Olen suositellut keskikokoisille (€500 k–€5 M vuosittainen pilvikulu) organisaatioille seuraavaa polkua: 0–6 kk showback, 6–12 kk hybridi (chargeback isoille OU:lle, showback pienille), 12+ kk täysi chargeback yksikön kypsyyden mukaan. Lisää FinOps-kypsyyden polkua käsittelee yleisemmällä tasolla FinOps ja pilvikustannusten optimointi 2026 -opas.
Yleisimmät virheet monitilihallinnassa
Listataan virheet, jotka olen nähnyt toistuvasti, ja jotka maksavat eniten korjata jälkikäteen:
Hallintotilillä ajetaan työtaakkoja. Tämä rikkoo eristysrajaa ja tekee security incident -tilanteista pahempia kuin niiden tarvitsisi olla.
Cost Allocation Tagit on määritelty mutta ei aktivoitu. Resurssit on tägätty, mutta Billing-konsolista aktivointi puuttuu, ja siksi raportit ovat tyhjiä.
OU-rakenne on liian litteä. Kaikki 80 tiliä ovat suoraan rootissa. SCP:itä ei voi soveltaa luokitellusti, ja Cost Categories on monimutkainen ylläpitää.
RI/Savings Plans -jakaminen on päällä Sandboxiin. Tuotanto-RI:t "imeytyvät" kehitykseen, tuotantoraportointi näyttää on-demand-laskuja.
CUR:ää ei viedä tai sitä ei käytetä. Kaikki raportointi tehdään Cost Explorerista, joka rajoittuu 13 kuukauteen ja ei salli omia liittymiä.
Budget-hälytyksiä ei ole. AWS Budgets on ilmainen (toiset 62 ensimmäistä budjettia / hallintotili), mutta moni unohtaa konfiguroida tilikohtaiset rajat.
Lopetetut tilit jäävät rootiin. Suspended-OU pitää käytöstä poistetut tilit erillään ja estää niiden uudelleenkäytön vahingossa.
Usein kysytyt kysymykset
Mikä ero on AWS Organizationsilla ja AWS Control Towerilla?
Organizations on perustaso: monitilirakenne, konsolidoitu laskutus ja SCP:t. Control Tower on Organizationsin päälle rakennettu opinionated baseline: se luo automaattisesti Log Archive- ja Audit-tilit, käyttää IAM Identity Centeriä ja soveltaa "guardrails"-suosituksia. Control Tower käyttää Organizations API:a alla, et voi saada Control Toweria ilman Organizationsia.
Voiko olemassa olevan AWS-tilin liittää jälkikäteen Organizationsiin?
Kyllä. Hallintotili lähettää kutsun (invite), jonka jäsentilin root-käyttäjä tai oikeutettu IAM-käyttäjä hyväksyy. Liittymisen jälkeen tili saa välittömästi konsolidoidun laskutuksen edut. Mikään olemassa oleva resurssi ei katkea, mutta SCP:t alkavat heti vaikuttaa, joten testaa rajoituspolitiikat ensin Non-Prod-OU:lla.
Miten hallintotili eroaa member accountista billing-näkökulmasta?
Hallintotili (management account) maksaa kaikki laskut ja näkee koko organisaation kustannukset Cost Explorerissa. Member-tilit näkevät vain oman käyttönsä. Jäsentileille voi myöntää oikeuden nähdä omia kustannuksiaan IAM-politiikalla (aws-portal:View*), mutta hallintotili on aina ainoa, joka näkee koko organisaation näkymän.
Maksaako AWS Organizations mitään?
Organizations itse on ilmainen. Et maksa erikseen jäsentileistä, OU:ista tai SCP:istä. Maksat vain niistä AWS-palveluista, joita kunkin jäsentilin sisällä käytetään. Jotkin lisäpalvelut kuten Control Tower tai Security Hub voivat tuoda omia kustannuksiaan, mutta peruspalvelu on ilmainen.
Voiko Organizations-rakennetta peruuttaa, jos se osoittautuu vääräksi?
Kyllä, mutta hitaasti. Jäsentilit voi poistaa organisaatiosta yksitellen, niistä tulee uudelleen itsenäisiä tilejä. Kuitenkin historialliset kustannustiedot säilyvät hallintotilin Cost Exploreriin asti, kunnes 13 kuukauden retention loppuu. Suunnittele OU-rakenne huolella ensimmäisellä yrityksellä; suuret uudelleenjärjestelyt aiheuttavat sotkuista historiaraportointia.
Käytännön opas S3-kustannusten leikkaamiseen 2026: storage class -hinnat, Intelligent-Tiering vs lifecycle-säännöt, Storage Lens ja yleisimmät piilolaskut. Esimerkit ja JSON-konfiguraatiot us-east-1-hinnoilla.
Opi toteuttamaan tehokas pilviresurssien tagausstrategia AWS:ssä, Azuressa ja GCP:ssä. Terraform-koodiesimerkit, tagien pakottaminen käytännöillä ja laskutusintegraatio — kaikki kustannusten kohdistamisen rakennuspalikat yhdessä oppaassa.
