Hoe kun je ongebruikte cloudbronnen opsporen die geld verspillen?

U kunt ongebruikte cloudresources opsporen door te zoeken naar terugkerende patronen waarbij de bezettingsgraad bijna nul is: virtuele machines die wel draaien maar geen verkeer verwerken, opslagvolumes die van alle instances zijn losgekoppeld, en load balancers die naar lege doelgroepen verwijzen. De meeste cloudproviders maken deze gegevens standaard zichtbaar, maar om die inzichten om te zetten in actie is een consistent evaluatieproces en duidelijke verantwoordelijkheid nodig. In dit artikel worden de meest voorkomende vormen van cloudverspilling besproken, hoe je ze kunt opsporen en hoe je kunt voorkomen dat ze zich opnieuw opstapelen.

Welke soorten cloudresources blijven het vaakst ongebruikt?

De meest voorkomende ongebruikte cloudresources zijn inactieve virtuele machines, verweesde opslagvolumes, niet-gekoppelde IP-adressen, vergeten snapshots en load balancers of NAT-gateways zonder actief verkeer. Deze soorten resources zijn verantwoordelijk voor het overgrote deel van de vermijdbare cloudverspilling in AWS-, Azure- en GCP-omgevingen.

Elk van deze categorieën heeft een andere onderliggende oorzaak:

• Inactieve virtuele machines: Servers die voor een project, een testomgeving of een proof of concept in gebruik zijn genomen en die na afloop van het werk nooit zijn uitgeschakeld.
• Weesopslagvolumes: Permanente schijven die ooit aan een VM waren gekoppeld, maar die zijn blijven bestaan nadat de VM was verwijderd. Hiervoor worden voor onbepaalde tijd kosten in rekening gebracht.
• Niet-toegewezen IP-adressen: Gereserveerde openbare IP-adressen die niet langer aan een actieve resource zijn gekoppeld. De meeste cloudproviders brengen kosten in rekening voor gereserveerde IP-adressen die niet worden gebruikt.
• Verouderde momentopnames: Back-ups op een bepaald tijdstip die zijn gemaakt voor noodherstel of migratie en nooit zijn opgeruimd, waardoor ze zich in de loop van maanden of jaren hebben opgestapeld.
• Niet-gebruikte load balancers en NAT-gateways: Netwerkcomponenten die nog steeds actief waren nadat de diensten die ze ondersteunden, buiten gebruik waren gesteld.

Het patroon is bij al deze gevallen hetzelfde: er werd een resource toegewezen voor een specifiek doel, dat doel is voorbij, maar niemand nam de verantwoordelijkheid op zich om de resource weer vrij te maken. Zonder duidelijke verantwoordelijkheid stapelt de verspilling in de cloud zich stilletjes op.

Waarom is het zo moeilijk om ongebruikte clouduitgaven op te sporen?

Onbenutte clouduitgaven zijn moeilijk op te sporen, omdat factuurgegevens voor de cloud zeer gedetailleerd en versnipperd zijn, waardoor het lastig is om een post op een factuur te koppelen aan het team of de applicatie die ervoor verantwoordelijk is. Als er niemand is die duidelijk de verantwoordelijkheid voor een resource draagt, merkt niemand het op wanneer deze niet langer van nut is.

Verschillende factoren versterken dit probleem nog. Ten eerste zijn cloudomgevingen zeer schaalbaar. Teams wijzen resources toe op basis van de vraag, vaak zonder een formeel proces voor het buiten gebruik stellen ervan. Ten tweede kun je aan de hand van factuurgegevens alleen niet vaststellen of een resource daadwerkelijk waarde oplevert. Een virtuele machine die actief is en in rekening wordt gebracht, verschilt op het eerste gezicht niet van een machine die actief is maar inactief blijft, tenzij je naast de kostengegevens ook de gebruiksstatistieken bekijkt.

Een derde factor is van organisatorische aard: in veel bedrijven zijn de technische teams die resources toewijzen niet dezelfde teams die de rekening ontvangen. De factuur komt bij IT of de financiële afdeling terecht, maar de beslissingen over de uitgaven zijn genomen door de applicatieteams. Door deze kloof beschikken de mensen die bevoegd zijn om een resource te verwijderen vaak niet over de nodige context, terwijl de mensen die wel over die context beschikken, de motivatie ontbreekt.

Tot slot kunnen tools voor inzicht in cloudkosten je laten zien wat je uitgeeft, maar die gegevens zorgen niet automatisch voor een besluitvormingsritme. Zonder regelmatige evaluatiecycli en duidelijk toegewezen verantwoordelijkheden leidt inzicht niet tot actie. Dit is een van de kernproblemen die FinOps als werkwijze is bedoeld om op te lossen.

Hoe vind je ongebruikte cloudresources in je omgeving?

Je kunt ongebruikte cloudresources opsporen door de standaardtools van de cloudprovider te combineren met gebruiksgegevens en taggingbeleid. Dit proces omvat het opvragen van kosten- en gebruiksrapporten, het filteren op resources met een consistent laag of nulgebruik, en het vergelijken van die bevindingen met tags die aangeven wie de eigenaar van de resources is.

Hier volgt een praktische aanpak die je kunt volgen:

1. Rapportage over kosten en gebruik inschakelen: Zorg ervoor dat de standaard facturatie-exportfuncties van je cloudprovider actief zijn en dat de gegevens hieruit worden doorgesluisd naar een centrale gegevensopslag. AWS Cost Explorer, Azure Cost Management en de facturatierapporten van GCP bieden allemaal een goed uitgangspunt.
2. Filter voor onderbenutte middelen: Gebruik cloud-native tools of een FinOps-platform om VM’s te identificeren waarvan het CPU-gebruik onder een relevante drempelwaarde ligt (bijvoorbeeld minder dan 5% over een periode van 30 dagen), opslagvolumes zonder lees- of schrijfactiviteit en netwerkcomponenten zonder gegevensoverdracht.
3. Controleer de bronlabels: Door bronnen te voorzien van metadata over de eigenaar, de toepassing en de omgeving, kunnen bevindingen naar het juiste team worden doorgestuurd. Zonder tags ben je veel tijd kwijt aan het handmatig achterhalen van de eigenaar.
4. Oude bronnen doornemen: Sorteer resources op aanmaakdatum en markeer alles wat ouder is dan een vastgestelde drempel (bijvoorbeeld 90 dagen) en waar nog niet mee is gewerkt. Resources die langdurig in niet-productieomgevingen actief blijven, vormen een veelvoorkomende bron van verspilling.
5. Waarschuwingen voor inactieve resources automatiseren: Stel beleidsregels in die meldingen activeren wanneer een resource gedurende een bepaalde periode inactief is geweest. Hierdoor wordt detectie niet langer een periodieke handmatige taak, maar een continu proces.

Het doel is niet een eenmalige controle, maar een herhaalbaar proces dat verspilling aan het licht brengt voordat deze zich in de loop van factureringscycli opstapelt.

Welke indicatoren wijzen erop dat een cloudresource niet meer in gebruik is?

Een cloudresource is waarschijnlijk niet meer in gebruik wanneer deze een aanhoudende CPU-bezetting van bijna nul vertoont, er geen inkomend of uitgaand netwerkverkeer is, er geen lees- of schrijfactiviteit plaatsvindt op de gekoppelde opslag en er geen recente API-aanroepen of toegangsgebeurtenissen zijn. Deze statistieken, bekeken als geheel over een relevant tijdsbestek, zijn sterke aanwijzingen dat een resource veilig buiten gebruik kan worden gesteld.

Meer specifiek zijn de signalen waarop je moet letten onder meer:

• CPU-bezetting blijft constant onder 2-5%: Een actieve server met verwaarloosbare rekenactiviteit staat vrijwel altijd stil.
• Geen netwerkbytes in of uit gedurende 30 dagen: Een dienst zonder verkeer bedient geen gebruikers of downstream-systemen.
• IOPS voor lezen en schrijven op schijf bij nul: Opslagruimte waaruit niet wordt gelezen of waarin niet wordt geschreven, is in feite verweesd, ook al blijft deze aangesloten.
• Geen authenticatie- of toegangslogboeken: Bij diensten zoals databases of opslagbuckets wijst het ontbreken van recente toegangsgebeurtenissen erop dat geen enkele applicatie of gebruiker de bron actief gebruikt.
• Status ‘Losgekoppeld’ in de cloudconsole: Volumes, IP-adressen en netwerkinterfaces die als ‘niet gekoppeld’ worden weergegeven, zijn per definitie ongebruikt.

Een belangrijke kanttekening: een hulpbron met een lage bezettingsgraad is niet altijd ongebruikt. Sommige systemen draaien per definitie op een lage bezettingsgraad, zoals stand-by-instanties voor noodherstel of geplande batchtaken. Overleg altijd eerst met het verantwoordelijke team voordat je iets verwijdert.

Moet je een te weinig gebruikte cloudresource verwijderen of de capaciteit ervan aanpassen?

Je moet een resource verwijderen wanneer deze geen gebruik maakt en geen legitieme stand-byfunctie heeft. Je moet de omvang ervan aanpassen wanneer er wel sprake is van daadwerkelijk, maar laag gebruik, waardoor de huidige omvang of configuratie niet gerechtvaardigd is. De beslissing hangt af van de vraag of de resource een actieve functie vervult, zelfs als dat slechts af en toe is.

Verwijdering is de juiste keuze wanneer een resource daadwerkelijk verweesd is: geen enkele applicatie is ervan afhankelijk, geen enkel team claimt het eigendom ervan en er is gedurende een aanzienlijke periode geen activiteit waargenomen. Door de resource te verwijderen, worden de kosten volledig weggenomen en wordt de complexiteit van de omgeving verminderd.

Rightsizing is de juiste keuze wanneer een resource actief is maar te groot is. Een virtuele machine die bijvoorbeeld is ingedeeld met 16 vCPU’s en die constant op 10% CPU draait, wordt weliswaar gebruikt, maar dit is verspilling. Door deze te verkleinen naar een kleiner instancetype worden de kosten verlaagd terwijl de dienstverlening op peil blijft. Dezelfde logica geldt voor opslagniveaus, database-instancetypes en gereserveerde capaciteitsverplichtingen.

Een praktische manier om deze beslissing te benaderen, is door twee vragen te stellen. Ten eerste: maakt een team of applicatie gebruik van deze resource? Zo niet, verwijder deze dan. Ten tweede: is de huidige omvang van de resource gerechtvaardigd gezien de daadwerkelijke werklast? Zo niet, pas de omvang dan aan. Beide maatregelen dragen bij aan de optimalisatie van de cloudkosten, maar vereisen verschillende gesprekken met verschillende belanghebbenden.

Hoe voorkom je dat er zich opnieuw ongebruikte cloudresources opstapelen?

Je voorkomt dat ongebruikte cloudresources zich opstapelen door governance in het toewijzingsproces zelf in te bouwen: verplichte tagging, geautomatiseerde waarschuwingen bij inactiviteit, regelmatige evaluaties en duidelijke beleidsregels inzake verantwoordelijkheid. Preventie is effectiever dan periodieke opschoning, omdat hiermee de oorzaak wordt aangepakt in plaats van het symptoom.

De meest doeltreffende preventieve maatregelen zijn:

• Verplichte tagging van middelen bij de toewijzing: Stel als voorwaarde dat elke resource wordt voorzien van een eigenaar, een kostenplaats en een omgeving voordat deze kan worden aangemaakt. Hierdoor kunnen bevindingen met betrekking tot verspilling direct worden doorgestuurd naar het verantwoordelijke team.
• Geautomatiseerde beleidsregels voor ongebruikte resources: Stel je cloudprovider of FinOps-tools zo in dat resources die langer dan een bepaalde drempelwaarde inactief zijn geweest, automatisch worden gemarkeerd of uitgeschakeld. Sommige organisaties automatiseren het uitschakelen in niet-productieomgevingen en vereisen handmatige goedkeuring om de resources opnieuw te starten.
• Regelmatige FinOps-evaluatiecycli: Zorg voor een vast ritme, wekelijks of tweewekelijks, waarin de technische en financiële teams samen de clouduitgaven doornemen. Een consistent besluitvormingsritme zorgt ervoor dat inzicht wordt omgezet in actie, in plaats van dat optimalisatie een ad-hocactiviteit blijft.
• Checklists voor ontmanteling: Voeg bij elke projectafsluiting of sprintretrospectieve een stap toe voor het opruimen van cloudresources. Wanneer een project afloopt, moet er iemand expliciet verantwoordelijk zijn voor het controleren en vrijgeven van de bijbehorende cloudresources.
• Showback- of chargeback-modellen: Wanneer teams inzicht krijgen in de kosten van de middelen die ze in bezit hebben, hebben ze een directe prikkel om op te ruimen wat ze niet langer nodig hebben.

Het uitgangspunt is verantwoordelijkheid. Er ontstaat cloudverspilling wanneer niemand daarvoor verantwoordelijk is. Bestuursstructuren die duidelijke verantwoordelijkheden toewijzen en zorgen voor regelmatige evaluatiemomenten, voorkomen dat het probleem na een opruimactie weer de kop opsteekt.

Hoe wij u helpen om verspilling in de cloud tegen te gaan

Bij It’s Value helpen we organisaties om verder te gaan dan eenmalige opruimacties en over te stappen op een gestructureerde, duurzame aanpak van het beheer van cloudresources. Onze FinOps-diensten zijn opgezet om juist de uitdagingen aan te pakken die in dit artikel worden beschreven: een gebrek aan verantwoordelijkheid, onderling niet op elkaar afgestemde teams en inzicht dat niet tot beslissingen leidt.

Concreet ondersteunen wij u met:

• Beoordeling van de FinOps-rijpheid: Een gestructureerde evaluatie van uw huidige mogelijkheden op het gebied van financieel beheer in de cloud, waarbij wordt vastgesteld waar ongebruikte middelen zich waarschijnlijk het meest ophopen en welke tekortkomingen in het beheer verspilling in de hand werken.
• Volledige kostentoewijzing en optimalisatie van de personeelsbezetting: We implementeren toewijzingsmodellen binnen AWS, Azure en GCP die elke resource koppelen aan een team, een applicatie of een bedrijfsdienst, waardoor de verantwoordelijkheid zichtbaar en bruikbaar wordt.
• Ontwerp van het bestuursmodel en het bedrijfsmodel: Wij helpen u bij het vaststellen van de rollen, beslissingsbevoegdheden en evaluatiefrequenties waarmee u op basis van cloudkostengegevens regelmatige, verantwoorde beslissingen kunt nemen in plaats van af en toe brandjes te blussen.
• FinOps as a Service: Voor organisaties die doorlopende ondersteuning nodig hebben, bieden wij een volledig beheerd FinOps-model aan tegen een vast maandelijks tarief, waarbij governance, optimalisatie en tooling zijn inbegrepen.

Als ongebruikte cloudbronnen uw organisatie geld kosten en u niet goed weet waar u moet beginnen, neem contact met ons op om te bespreken hoe wij u kunnen helpen de zichtbaarheid en verantwoording te creëren die nodig zijn om verspilling in de cloud onder controle te houden.

Deze inhoud is gegenereerd met behulp van AI en kan fouten bevatten.