Help, mijn cloud kosten gaan “door het dak”

Leave a reply

Veel bedrijven en organisaties zijn inmiddels naar de cloud gemigreerd. Vaak had dat een technische insteek. Het was dan het een IT project en geen organisatie aangelegenheid. Nu draaien de workloads in de cloud en gaat de aandacht uit naar zaken als governance en Cloud Operations. Inmiddels wordt de organisatie geconfronteerd met hogere kosten dan gedacht. Ook zijn de kosten onvoorspelbaar fluctuerende ze sterk. Hoe kunnen we de kosten verlagen en grip houden hierop? Het is noodzakelijk dat we eerst begrijpen welke aspecten er aan cloud kosten zitten voordat we ze kunnen begrijpen.

Gebruik

De eerste factor die invloed heeft op kosten is het daadwerkelijke gebruik. Hiermee bedoelen we de hoeveelheid resources die in gebruik zijn. Hoe meer resources we afnemen hoe hoger de kosten. Daarom is het is dus belangrijk het gebruik van resources te beperken. Controle op ongebruikte resources is dan voor de hand liggend. Hierbij kan bijvoorbeeld gedacht worden aan EBS block volumes die niet meer gebruikt worden, of database read replica’s zonder master database. Maar ook kunnen er wellicht kleinere EC2 instances gebruikt worden.

Maar ook under-utilisation is verlies. We gebruiken dan namelijk meer resources dan nodig. Daardoor betalen we dus te veel. Hetzelfde geldt ook voor storage tiering (onderscheid maken tussen verschillende kwaliteitsniveaus van opslag). Is de hoge durability (hoe groot is de kans dat we bestanden kwijt raken), availability (de beschikbaarheid van bestanden en gegevens) en performance (hoe snel kan ik bestanden lezen en schrijven) wel echt nodig, of kan het met minder? Een lagere availability, durability en performance leidt tot lagere kosten. Storage classificatie is dan een voorwaarde.

Is meer goedkoper?

AWS hanteert een volumekorting. Simpel gesteld, hoe meer we afnemen, hoe hoger de korting. Dit gaat met staffels, voorbeeld hiervan zijn te vinden op: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-discounts.html Meer algemene informatie over pricing voorbeeld kan je vinden op: https://aws.amazon.com/s3/pricing/. 

Hoewel een hogere afname een hogere korting tot gevolg heeft, worden de totale kosten natuurlijk niet lager. Het is daarom verstandig toch niet meer te gebruiken dan noodzakelijk. Met andere woorden, eerst kijken we naar het gebruik, daarna speelt pas volumekorting.

Maar we kunnen nog meer met volumekorting. Vaak hebben organisaties meerdere AWS accounts (een multi account structuur is een AWS best practice https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/). Het is handig om alle kosten van die AWS accounts samen te voegen in een centrale master billing account. Dat is feitelijk niets anders dan een AWS account die alleen gebruikt wordt voor kosten / billing. Hiermee ontstaat inzicht in kosten op een centrale plaats (handig wanneer er veel AWS accounts zijn). Maar belangrijker, de kosten worden daadwerkelijk samengevoegd waardoor de staffelkorting eerder bereikt wordt.

Slimme inkoop

Als organisaties geen commitment willen aangaan over de afname van resources, dan kiezen zij voor “On demand” (pay-as-you-go). Dit wil zeggen dat we resources kunnen afnemen of teruggeven wanneer het de klant uitkomt. Dit geeft AWS de grootste onzekerheid, want de afname is slecht te voorspellen. Klanten van AWS kopen hiermee flexibiliteit. Deze flexibiliteit heeft een prijs.

Reserved Instances

Soms weet een organisatie wel dat ze instance(s) voor langere tijd wil afnemen. Bijvoorbeeld bij continue workloads zoals databases, of ERP systemen. Deze instances kunnen zij Reserved inkopen, de zogenaamde Reserved Instances (RI – https://aws.amazon.com/ec2/pricing/reserved-instances/).  Als resources voor dergelijke workloads voor langere tijd worden afgenomen, dan verstrekt AWS korting. We hebben hierbij de keuze voor een commitment van 1 jaar tot 3 jaar. Zijn we daarnaast ook nog bereid de kosten (gedeeltelijk) vooraf te betalen, dan is er nog meer korting (de keuze is hier, no-up front, partially up front en all up front).

Hoe hoger het bedrag dat we bereid zijn upfront te betalen, hoe hoger de korting. Met deze Reserved Instances ligt het commitment bij de klant en levert zij flexibiliteit in, maar daar staat korting tegenover.

Spot Instances

Aanvullend op Reserved Instances kunnen bedrijven ook bieden op de overcapaciteit (Spot Instances https://aws.amazon.com/ec2/spot/) die AWS heeft. Deze overcapaciteit wordt aan de hand van vraag en aanbod verkocht. De verkoopprijs fluctueert dus. De biedprijs is feitelijk de maximale prijs die een organisatie bereid is te betalen voor de instance. Stijgt de verkoopprijs boven de geboden prijs, dan neemt AWS de instance weg. Daalt de verkoopprijs onder de geboden waarden, dan krijg de klant de instance weer. Deze spot instances zijn daardoor geschikt voor tijdelijke workloads, of niet-tijdkritische workloads. De werkelijke kosten van Spot Instances liggen beduidend lager dan de On-Demand prijs.

De On-Demand instances, Reserved Instances en Spot Instances zijn tegelijkertijd en door elkaar heen te gebruiken. Reserved Instances kunnen verder nog verkocht en gekocht worden op de AWS marketplace.

Zoals blijkt, kan slim inkopen van resources de kosten drukken. Zeker wanneer dit voor een grote organisatie wordt gedaan en het om veel van dezelfde instances (types) gaat. Maar ook hier geldt, eerst bepalen of resources echt nodig zijn (en niet overbemeten zijn).

Savings plans

Waar de inkoop van Reserved Instances zich richt op korting op een per instance basis, kan er ook gekozen worden voor Savings Plans (https://aws.amazon.com/savingsplans/pricing/). Dit heeft 2 verschijningsvormen. Er kan gekozen worden voor een Compute Savings Plan waarbij een korting kan worden verkregen op de Compute (EC2) Service ongeacht de instances familie, size, Availability Zone, Regio of Operating System.

Ook bestaat er een EC2 Savings Plan waarbij korting verkregen wordt op alle EC2 instances in een specifieke regio en van een specifieke instance familie, ongeacht de Availability Zone, Size, Operating System of tenancy. Deze keuze geeft je nog steeds de vrijheid om bijvoorbeeld van Windows naar Linux te migreren op dezelfde instance types en te profiteren van de korting van het Savings Plan.

Er kunnen meerdere Savings Plans naast elkaar gebruikt worden en ook Reserved Instances kunnen gebruikt blijven worden. Het advies van AWS is echter, wanneer de termijn van de Reserved Instances is verlopen gebruik te maken van een Savings Plan, het levert dezelfde korting maar kent meer flexibiliteit.

Private Pricing – Enterprise Discount Program

Organisaties die een jaarlijkse AWS spend hebben van meer dan een miljoen dollar kunnen in aanmerking komen voor Private Pricing (https://aws.amazon.com/pricing/enterprise/). Met dit programma kan een klant commitment aangaan voor 1 tot 3 jaar voor de totale spend op AWS. Eventueel kan gekozen worden om een deel (of het geheel) van die spend vooraf te voldoen. Hoe groter het commitment en hoe meer upfront wordt betaald, hoe groter de korting. Het Enterprise Discount programma kent vaste korting percentages. Voorwaarde hiervoor is ook dat de klant Enterprise Support afneemt bij AWS (https://aws.amazon.com/premiumsupport/plans/enterprise/). De kosten voor Enterprise Support zijn afhankelijk van de maandelijkse AWS spend. Het is daarom een afweging (rekensom) of Enterprise Support en Private Pricing tegen elkaar opwegen. De organisatie zal moeten bepalen welke waarde AWS Enterprise Support voor haar heeft.

Maar hoe krijgen we de kosten nu lager?

Organisaties die zich geconfronteerd zien met onverwacht hogere kosten zullen daar actie op willen ondernemen. Het zinvol dat men zich eerst richt op het “Gebruik”. Een “Right Sizing” actie ligt dan voor de hand. Welke resources worden niet (meer) gebruikt, welke instances kunnen periodiek uit? Instances kunnen geautomatiseerd uit- en aangezet worden. Dit scheelt in de kosten. Wellicht handig om ontwikkel- en testsystemen wel geautomatiseerd te stoppen, maar ze niet meer geautomatiseerd aan te zetten. Alleen wanneer ze echt nodig zijn kunnen ze handmatig gestart worden. Een dergelijke “Opschoon” actie kan behoorlijk kosten besparen, maar hoe zorg ik ervoor dat de kosten niet toch later weer oplopen?

Cloud Economics

“The Million Dollar Question” is natuurlijk, hoe houden we de kosten laag? Een eenmalig actie is niet voldoende om de kosten permanent in de grip te houden. De essentie hierbij is dat de organisatie zich gaat realiseren dat “Kosten” een design parameter zijn en dat daarmee de architect, developer, operator verantwoordelijk zijn voor de kosten en het in de hand houden daarvan. Deze verantwoordelijkheid moet duidelijk zijn voor alle betrokkenen en zij hebben daarbij de nodige tooling nodig, zoals bijvoorbeeld inzicht in de kosten per workload. Zonder inzicht, geen grip.

Om Cloud Economics een permanent deel te laten worden van het design en beheerproces kan het Well Architected Framework (https://aws.amazon.com/architecture/well-architected/) van AWS gebruikt worden. Dit framework kent een 5 tal onderwerpen (Pillars) met achterliggende vragen. Worden alle vragen in het ontwerp beantwoord, dan strookt het ontwerp met AWS Design Principles en AWS Best Practices. Niet verwonderlijk is een van de onderwerpen (Pillars) hierin “Cost Optimization”.

Door het Well Architected Framework in de organisatie te adopteren borgt men dat kosten permanent bij de juiste personen op de “agenda” staan. Aardig detail is dat het Well Architected Framework als Service in de AWS console te vinden is. Hiermee kunnen de vragen eenvoudig beantwoord worden en kunnen ook opeenvolgende reviews van dezelfde workload bewaard worden.

Cloud Economics een organisatie aangelegenheid

Zoals uit dit betoog mag geconcludeerd, ligt de verantwoordelijkheid voor kosten in de Cloud (en het in de hand houden daarvan) op de werkvloer. En toch zijn de cloud kosten een organisatie aangelegenheid. Product eigenaren moeten zicht krijgen op de Cloud kosten van de workloads waarvoor zij verantwoordelijk zijn. De CFO moet begrijpen hoe jaarlijkse budgetten en pay-as-you-go met elkaar te verenigen zijn. Een forecast / prognose model kan hier bijvoorbeeld bij helpen. En als laatste, ook AWS kan ons helpen en doet dat ook.

Paradigmaverschuivingen door Cloud

Leave a reply

Toen ik me (zo’n twee jaar geleden) ging verdiepen in Cloud Computing werd mij snel duidelijk dat ik er vooroordelen over had die niet met de werkelijkheid overeenkwamen. Zo dacht ik tot die tijd  bijvoorbeeld dat het duurder zou zijn dan on premise. En ook dat het alleen geschikt zou zijn voor webserver workloads. En dat het so-wie-so niet geschikt was voor enterprise workloads. Bovendien dacht ik dat Windows workloads op Azure en Linux workloads op AWS gedraaid moeten worden. Ik zag Cloud een beetje als hosting 2.0. Dit bleken vooroordelen omdat ze allemaal niet waar zijn. Nadat ik deze vooroordelen bij mijzelf had opgespoord en structureel verwijderd, werd de Cloud al veel aantrekkelijker.

Nog interessanter werd het toen ik de grote verschillen ontdekte tussen Cloud Computing en legacy IT. Deze verschillen zijn opmerkelijk en ik vind het serieuze paradigma verschuiving.

Dynamisch

Zo waren we gewend om workloads van voldoende hardware (capaciteit) te voorzien zodat klanten voldoende performance ervaren. Deze resources waren veelal ruimschoots voldoende. Te veel resources was geen probleem en bij een tekort aan resources kochten we hardware bij. Virtualisatie maakte dit proces eenvoudiger, maar niet fundamenteel anders. Maar, zowel “Under utilisation” als “Over utilisation” zijn beiden feitelijk verlies. In het eerste geval had ik meer resources gekocht dan nodig was en in het andere geval is de performance niet optimaal en raken mijn klanten ontevreden. Cloud stelt ons juist in staat resources dynamisch toe te wijzen en dus beide vormen van verlies te vermijden. Hiermee kan Cloud goedkoper zijn dan on premise. Het is aan ons om het slim in te richten.

Kosten

Het kiezen van de meest geschikte Cloud service (of combinatie van services) en het juist toepassen ervan is dus key. De consequentie hiervan is dat IT architecten, engineers en developers daarmee verantwoordelijk worden voor het kostenefficiënt zijn van de applicatie. Want was eerder een budgetaanvraag een managementbeslissing, nu zijn de kosten een gevolg van het ontwerp. Da applicatie moet niet gewoon functioneren, maar deze moet ook kostenefficiënt zijn. Kostenefficiëntie is hiermee een design criterium geworden. Amazon AWS heeft hiervoor een hulpmiddel, het: “Well Architected Framework”. Dit framework kent een 5 tal pilaren waarvan “Cost Efficiency” er een is. Development teams zouden er goed aan doen dit framework te gebruiken tijdens het ontwerp en bouwen van applicaties en omgevingen.

Capex versus Opex

Een andere verschuiving is dat kosten niet vooraf vallen (Capital Expenditures), maar achteraf vallen (Operational Expenditures). Dit, op het eerste gezicht, simpele verschil heeft verstrekkende gevolgen. Financiële bestuurders van bedrijven (en IT afdelingen) waren gewend jaarlijks budgetten te maken waarin de kosten voor het komende jaar ingeschat wordt. Dat werkt nu anders. Alle kosten komen achteraf en bovendien kunnen ze fluctueren als gevolg van het dynamisch toewijzen van resources. Maar hoe komen we dan in control van de kosten? De Cloud biedt gelukkig veel mogelijkheden hiervoor, zoals gedetailleerde overzichten van kosten van services, het kunnen isoleren van applicaties in een eigen AWS account en het kunnen instellen van budget alerts. Bestuurders zullen deze nieuwe mogelijkheden leren gebruiken. Ik ben ervan overtuigd dat zodra dat lukt, zij voor het eerst echt in control komen van IT kosten en zij ook niet anders meer willen.

Experimenteren

Er is nog een ingrijpende verandering als gevolg van de “Pay-as-You-go” methode. Experimenteren wordt eenvoudiger en goedkoper. Enterprise features (zoals bijvoorbeeld een Content Management Systeem – CDN) zijn beschikbaar, laagdrempelig en tijdelijk te gebruiken. Dit tijdelijke gebruik is erg  kostenefficiënt. Experimenteren wordt hierdoor gestimuleerd. De keerzijde ervan is dat je ook snel moet beslissen of een experiment geen succes wordt (“Fail fast”). Waar voorheen dure en tijdrovende pakketselecties werden gedaan, loont het zich nu kleine Proof of Concepts (PoC’s) te doen met alle versies van een applicatie die je maar overweegt. Wat niet naar wens werkt ruim je snel weer op.

Alles code

Voor infrastructuur engineers belooft Cloud ook een behoorlijke verandering te zijn. Waar we ons voorheen konden profileren met kennis van hardware en appliances, willen bedrijven nu standaardiseren op native Cloud services. In de meeste gevallen is dit efficiënter en daardoor kosteneffectiever. Bovendien bouwen we de infrastructuur middels code en templates. Infrastructuur wordt code en daarbij adopteren we de werkwijze van developers met bijvoorbeeld CI/CD pipelines en code repositories.

IT feestje

Zoals uit de voorgaande paradigmaverschuivingen blijkt veranderd er toch wel veel in vergelijk met hoe we tot nu toe te werk gingen. De grootste en belangrijkste paradigma verschuiving is naar mijn idee dat Cloud iets voor de gehele organisatie is.

Amazon AWS heeft inmiddels de ervaring dat bij bedrijven die Cloud zien als een “IT feestje” het geen succes wordt. De veranderingen raken immers  alle geledingen van de organisatie, of dat nu de IT afdeling zelf is, HR, financiën of de business. Het is daarom doorslaggevend of we in staat zijn de gehele organisatie te betrekken in het uitnutten van Cloud. Ook hiervoor heeft Amazon AWS hulpmiddelen. Zo is er het “Cloud Adoption Framework” (CAF). In de CAF worden technisch en organisatorische gezichtspunten gebruikt om de obstakels voor Cloud adoptie in kaart te brengen. Hiervoor worden alle stakeholders betrokken en kan bijvoorbeeld gebruik worden gemaakt van de “Cloud Discovery Workshop” om een eerste start te maken met de CAF.

IT 2.0

Mijn vooroordelen over Cloud ben ik inmiddels wel kwijt, maar ik heb er paradigmaverschuivingen voor terug gekregen. Deze verschuivingen maken Cloud voor mij juist extra interessant omdat het aspect “Organisatie” veel prominenter meedoet en dat vond ik altijd al belangrijk. Zo zullen de IT en de business nu wel moeten samenwerken. Dat is iets dat mij al jaren verstandig leek. Zonder deze samenwerking wordt het geen succes. Dit is voor veel mensen ook niet nieuw, maar nu is het echt noodzaak geworden, helemaal bezien in het licht van “Digital Transformation” (https://aws.amazon.com/government-education/digital-transformation/). Gelukkig biedt Amazon AWS hier ook hulpmiddelen, zoals het “Cloud Adoption Framework” (https://aws.amazon.com/professional-services/CAF/getstarted/)  (en de bijbehorende “Cloud Discovery Workshop”) en het “Well Architected Framework” (https://aws.amazon.com/architecture/well-architected/). Voor mij wordt de IT hiermee met sprongen interessanter.

AWSome for the enterprise

Leave a reply

Inmiddels is iedereen er wel van overtuigd. Public Cloud is de toekomst in het IT landschap. Aanvankelijk verzonnen we redenen om niet naar de cloud te moeten. We vonden de cloud bijvoorbeeld niet secure. De data stond niet in Nederland en het was alleen geschikt voor websites. Ook was het voornamelijk bedoeld voor start ups, en ehh, oh ja, de cloud was te duur. Toch zijn er door de jaren heen steeds meer bedrijven die kozen voor de Public Cloud. Blijkbaar waren onze redenen drogredenen. Of misschien hadden we de feiten onjuist, een soort alternatieve waarheden? Nu we deze vooroordelen achter ons hebben gelaten, kunnen we naar de Cloud. Of gelooft u nog steeds dat de mens niet op de maan is geweest en dat Elvis nog steeds leeft?

Natuurlijk verloopt de adoptie niet bij alle bedrijven even snel. Het is alleen niet meer de vraag “Of we naar de Cloud gaan”, maar “Wanneer”. Een interessante observatie daarbij is dat Amazon’s AWS verreweg de grootste aanbieder is van Public Cloud diensten. Interessant omdat Amazon geen speler was in het IT landschap. Ze begon ooit als webshop voor boeken, maar bouwde al snel een infrastructuur waar haar klanten ook graag gebruik van maakten. Inmiddels is ze de grootste aanbieder van Public Cloud diensten. AWS (Amazon Web Services) is vele malen groter dan alle overige Cloud aanbieders bij elkaar. Maar hoe maken we AWS geschikt voor grote bedrijven?

Multi account structuur

Wanneer je snel aan de slag wilt met Public Cloud, dan is een Amazon AWS account zo aangelegd. Voor zo’n account is slechts een credit card nodig en je bent “In business”. Alle AWS diensten staan je vervolgens ter beschikking. Ook echte enterprise features zoals Content Delivery Networks en uitgebreide security tools. Dat klinkt allemaal prima, maar gaan grote bedrijven er zo ook mee om? Is het echt een kwestie van account aanleggen credit-card-klaar? Misschien dat bedrijven op deze wijze starten, maar na verloop van tijd kiezen zij voor een structuur die past bij een enterprise.

Grote bedrijven hebben bijvoorbeeld behoefte om applicaties van elkaar gescheiden te houden. Ook willen ze uitgebreid gebruikersbeheer (met gedelegeerde rechten) te kunnen uitvoeren of IT architectuur uitgangspunten te kunnen afdwingen (zoals off site backups). Daarnaast willen ze security maatregelen kunnen treffen (zoals off site audit trails) en overzicht te houden over de kosten (consolidated billing). In AWS is dit mogelijk door meerdere accounts aan elkaar te koppelen, waarbij sommige account generieke voorzieningen verzorgen, de multi account structuur.

Root account

Nu is het belangrijk om te weten dat de eerste user die je aanlegt de root user is. Dit is de enige user binnen het AWS account waarmee alles gedaan kan worden. Het is ook de enige die het gehele account kan opgeheffen. Het dagelijks gebruik van deze root user is daarom ook af te raden. Deze root user credentials kunnen beter in een kluis worden opgeslagen. Voor het dagelijkse gebruik van de AWS console (de web toegang tot alle AWS diensten) worden gewone user accounts gemaakt.

Operationele- versus non-operationele accounts

Bij het gebruik van meerder AWS accounts wordt een onderscheid gemaakt tussen operationele accounts (zoals bijvoorbeeld een account waarin de productieomgeving van een specifieke applicatie draait) en non-operationele accounts (zoals bijvoorbeeld een account waarin alleen gebruikersbeheer wordt gedaan). AWS biedt daarom de mogelijkheid de accounts op een zinvolle manier te integreren zoals bijvoorbeeld de kosten in een billing account te verzamelen. Hiermee kunnen zaken effectief van elkaar gescheiden worden. Door de verschillende operationele accounts van elkaar te isoleren kunnen bijvoorbeeld fijnmazig rechten worden gegeven aan beheerders. Ook kunnen de omgevingen elkaar niet beïnvloeden, praktisch, want dit zorgt voor een hoger security niveau.

Welke non-operationele account zijn er nodig?

Multi Account structuur

Multi account structuur in de Amazon AWS Public Cloud

Billing

Het is praktisch om alle kosten centraal te verzamelen, ook wel consolidated billing genoemd. Dit gebeurd in een “Billing account”. De billing account wordt niet gebruikt voor productietaken, maar alleen voor de financiële afhandeling van de kosten. Zo “Hangen” alle accounts aan dezelfde credit card, of worden alle kosten middels een enkele factuur afgerekend. De voordelen hiervan zijn dat de volumekorting van AWS over het gehele bedrag wordt verkregen en dat gebruikers met een financiële verantwoordelijkheid alleen toegang krijgen tot deze billing account. Zij hebben geen toegang nodig tot een operationele account en houden toch overzicht over de kosten. Deze kosten worden overigens in groot detail inzichtelijk gemaakt, ze zijn per account en per resource type of tag te bekijken. Zo is te zien wat de kosten van storage zijn, of wat de kosten zijn van een ontwikkel account.

IAM

Naast de billing account is er een “Identity and Access Management (IAM) Account”. Dit is het account waar het gebruikersbeheer uitvoert wordt. Het enige dat in deze account gemaakt wordt zijn users, groepen en rollen. De overige accounts (zoals operationele accounts) hebben geen gebruikers. Vanuit de IAM account krijgen users rechten binnen andere accounts. De voordelen hiervan zijn evident, centraal gebruikersbeheer, een centrale account waarop users inloggen en geen users in de andere accounts. Deze manier van werken leidt ook tot een hogere mate van security en een beter controleerbaarheid daarvan. Voor de duidelijkheid, de users waarover we hier spreken zijn users die werken binnen de webconsole van AWS en niet de eindgebruikers van applicaties.

Audit

Vanuit security standpunt bezien is het wenselijk dat een audit trail veiliggesteld wordt voor het geval een applicatie of account gecompromitteerd raakt. In zo’n geval moet het audit trail aantoonbaar onveranderd zijn en op een andere plaats opgeslagen zijn. Speciaal hiervoor is de “Audit Account”. Dit account bestaat uit S3 buckets (object store – opslag van files) waarin de audit informatie wordt weggeschreven. Ieder operationeel account heeft een eigen S3 bucket waarin alleen dat account mag schrijven, ze mag er niet lezen en niet verwijderen. Uiteraard worden de kosten verhaald op de account die de betreffende S3 bucket gebruikt en netjes verzameld in de billing account.

Backup

De bovenstaande constructie wordt ook gebruikt voor backups. Bedrijven willen graag dat backups aantoonbaar veilig worden opgeslagen, liefst met aparte credentials. Dus waarom zou niet dezelfde constructie gebruikt kunnen worden als bij de audit account? En dat is precies waarom er een “Backup Account” gemaakt wordt. Deze account heeft alleen S3 buckets voor de verschillende operationele accounts waarin zij een backup mogen schrijven. Ook hier kunnen zij de backups niet lezen of verwijderen. De kosten van iedere bucket wordt verhaald op de betreffende operationele account en verzameld in de billing account.

Shared

Soms zijn er generieke diensten die beschikbaar gesteld moeten worden aan de operationele accounts, zoals bijvoorbeeld een GIT repository (een versiebeheersysteem voor software en configuratie files), een Puppetmaster (state config software) of centrale opslag van gedeelde informatie. Het gebruik van een zogenaamde “Shared Account” dan erg handig.

My Organization

Inmiddels heeft Amazon een nieuwe dienst gelanceerd die het opzetten en beheren van een multi account structuur vereenvoudigen, “My Organization”. Organizations geeft overzicht over de gekoppelde accounts (de billing account is leidend). Centraal kunnen bijvoorbeeld beperkingen op andere accounts aangelegd worden.

Tot slot

Er is inmiddels een goed beeld geschetst over een enterprise structuur in AWS. De non-operationele accounts zorgen voor overzicht, inzicht en betere isolatie van enterprise functies. Middels uitgebreide autorisatie kunnen users rechten krijgen op de verschillende functionele gebieden die zo gecreëerd zijn. De hier beschreven non-operationele accounts zijn wel de belangrijkste, maar er is geen beletsel er nog meer te maken als dat opportuun mocht zijn.

Met het ondersteunen van een dergelijke enterprise structuur toont Amazon aan dat Public Cloud klaar is for the enterprise, maar dan wel met de juiste inrichting.