Als Cloud engineer is het uitrollen van resources in Azure heel eenvoudig. Met slechts enkele klikken in de Azure-portal kun je een Azure SQL-server, database en/of virtuele machine opzetten. Dit maakt het een veelgebruikte aanpak bij het starten van migratie naar de Cloud. Vaak begint een persoon of groep in de organisatie met het uitvoeren van een Proof of Concept (PoC) in Azure om bepaalde functionaliteiten te testen en vervolgens te presenteren.
Hierdoor ontstaan er binnen één organisatie meerdere projecten en/of PoC’s die zonder beleid of structuur worden neergezet in de Cloud. In het begin is dit nog te overzien, maar na verloop van tijd wordt dit onoverzichtelijk en ongestructureerd. Hier kan het Cloud Adoption Framework (CAF) onder andere goed bij helpen. Het CAF biedt een scala aan documentatie wat kan helpen bij het implementeren, migreren, beheren en optimaliseren van de cloudomgeving.
In deze blog zoom ik in op het gereed maken van cloudomgevingen, leg ik uit wat het CAF kan bieden en waarom elke organisatie dit framework zou moeten gebruiken. Daarnaast geef ik wat tips en voorbeelden die wij bij CloudNation gebruiken om structuur en beleid uit te voeren in de Azure cloud.
Het CAF is een framework vanuit Microsoft waarin best practices, documentatie en hulpprogramma’s aangeboden worden om te helpen bij cloud implementaties. Via deze link kom je bij de Microsoft documentatie over alles wat het framework te bieden heeft.
Het framework geeft voorbeelden hoe je structuur in je cloudomgeving kan neerzetten. Dit wordt gedaan door middel van Azure landingzone architectuur. Deze architectuur maakt gebruik van subscripties om cloud resources binnen de omgeving van elkaar te scheiden. Applicaties kunnen gebruik maken van gezamenlijke resources die vanuit het platform worden aangeboden. Denk hierbij aan platform resources zoals de Azure Firewall, VPN-gateway en DNS zones. De resources worden in de connectiviteit subscriptie gezet en wordt ook wel de hub genoemd.
De landingzone architectuur is opgezet zodat deze schaalbaar en toepasbaar is voor alle resources en toekomstige applicaties die in Azure gebouwd kunnen gaan worden. Denk hierbij aan applicaties voor je front-end of je data-omgevingen. Deze applicaties hebben hun eigen subscriptie met hun eigen virtual netwerk.
De subscripties worden verdeeld onder managementgroepen. Op deze managementgroepen plaatsen wij Azure policies om het beleid uit te zetten
Bij CloudNation passen wij het CAF toe door middel van Infrastucture as Code (IaC). In deze Code zetten wij een fundatie in de cloud neer. Deze fundatie zorgt voor de structuur.
Praktisch houdt dit in dat wij de managementgroepen maken, subscripties in de juiste managementgroep plaatsen en zorgen dat er connectiviteit is tussen de netwerken binnen de subscripties. De manier waarop deze connectiviteit plaats vindt is afhankelijk van de wensen van onze klanten. Denk hierbij bijvoorbeeld aan Virtual WAN met virtual hubs of een hub-spoke model met virtual network peerings. Dit is de basis en kan natuurlijk verder worden uitgebreid aan de hand van de benodigdheden van de organisatie.
Hieronder is de conceptuele Azure landing zone architectuur van Microsoft te zien. De managementgroepen en subscripties komen terug in het midden van de afbeelding. Daarbij zien we nu ook de ‘landingzone zone A2 subscriptie’ (spoke), die connectiviteit heeft met de connectivity subscriptie (hub). De A2 subscriptie kan gezien worden als één van de vele spokes van het hub-spoke model. Elke spoke heeft zijn eigen subscriptie en virtuele netwerk en kan gebruik maken van de resources in de hub. De hub is het centrale punt waar al het internetverkeer langs komt en dit is de plek waar de Azure firewall, VPN-gateway, ExpressRoute en/of Azure DNS geplaatst is.
Bron: What is an Azure landing zone? - Cloud Adoption Framework | Microsoft Learn
Het uitrollen van deze fundatie doen wij met Terraform. Dit is een bekende Infrastructure as Code tool waarmee wij alle resources in Azure uitrollen. Elke klant is anders, maar er zijn ook altijd veel overeenkomsten. Om te zorgen dat we klant specifieke resources moeten kunnen ondersteunen maar tegelijkertijd ook bepaalde standaardisatie willen toepassen, maken we gebruik van de CAF Enterprise Scale module in Terraform. Deze module is aanpasbaar zodat we dit kunnen toepassen voor elke klanten omgeving. De module helpt bij het zetten van de fundatie zoals hierboven beschreven en zorgt tegelijkertijd voor dat we beleid toepassen. In deze module is het namelijk mogelijk om Azure policy's te definiëren.
Bij CloudNation hebben we een basisset aan policies die we altijd gebruiken. Eén daarvan is het zetten van de toegestane locaties waarin de Azure resources mogen staan. De locaties die we hierin zetten zijn dan bijvoorbeeld ‘westeurope’ en ‘northeurope’. Deze policy zetten we meestal op de hoogste managementgroep, zodat alle managementgroepen daaronder en dus alle subscripties moeten voldoen aan deze voorwaarde. Als iemand een resource in een niet toegestane locatie wil uitrollen, bijvoorbeeld in ‘East US’, dan wordt dit tegengehouden door de policy en is het uitrollen niet mogelijk.
Een aantal andere policies die we vaak toepassen zijn; het aanzetten van microsoft defender voor elke resource type, zorgen dat elke resource zijn logging naar de centrale log analytics workspace stuurt, automatische zetten van bepaalde tagging, aanzetten van azure monitor van alle virtuele machines, toegestane soorten van virtuele machines en blokkeren van het gebruik van public ip addressen. Dit is een greep van policy's die voor het beleid zorgen. Sommige policies voeren iets uit binnen de cloudomgeving, zoals het zetten van de logging naar de workspace. Andere policy's zorgen er juist voor dat iets wordt geblokkeerd. De policy voor de toegestane soorten (sku's) virtuele machine gebruiken we vaak zodat we er zeker van zijn dat niet extreem dure virtuele machine worden uitgerold, dit voorkomt verrassingen op de factuur.
Policies kunnen gezien worden als een soort vangrails voor de cloudomgeving. Binnen de vangrails kan iedereen werken, zodra iemand of een resource erbuiten wil dan wordt dit tegengehouden. Er zullen altijd specifieke gevallen zijn waardoor er uitzonderingen moeten worden gemaakt, ook dit is mogelijk. Er kunnen ‘exemptions’ worden gemaakt voor specifieke resources, subscripties of managementgroepen zodat specifieke gevallen ook mogelijk zijn.
Managementgroepen hebben een activity log. Alle policy wijzigingen worden hierin bijgehouden voor de desbetreffende managementgroep. Dit kan handig zijn voor het troubleshooten als een policy bijvoorbeeld bepaalde blokkades veroorzaakt.
Als je iets wilt blokkeren met een Azure policy dan is het slim om het effect van de policy eerst op ‘audit’ te zetten. In de Azure portal is zichtbaar welke resources beïnvloed worden door deze policy zodat je de policy op een later moment op ‘deny’ kan zetten. Zo kan je zien wat de invloed zou kunnen zijn voor dat je de policy implementeert.
Het hebben van een betrouwbare en flexibele fundatie wat tegelijkertijd beleid uitvoert, zorgt voor overzicht en structuur in de cloudomgeving. Hierdoor kom je minder snel voor verassingen te staan en ben je in controle over wat er allemaal wel en niet mag binnen deze omgeving. Dit geeft veilligheid en vertrouwen in de cloud voor nu en in de toekomst. Het CAF biedt meer dan alleen het gereed maken van de cloudomgeving. Ik raad dan ook aan om af en toe eens de documentatie hiervan te lezen.
Op maandag 24 juli heeft Microsoft de Azure OpenAI Landing Zone reference architectuur beschikbaar gesteld. Deze architectuur sluit perfect aan op de Landing zones die vanuit het CAF worden voorgesteld. Dit is een mooi voorbeeld dat je met het CAF goed voorbereid bent voor de toekomst.
Azure OpenAI Landing Zone reference architecture (microsoft.com)
De volgende blog wordt technischer, hierin laat ik zien hoe je met terraform de fundatie met policy's kan uitrollen.