Wat is een drempelwaarde voor het opsporen van afwijkingen in cloudkosten en hoe stel je die in?

Een drempelwaarde voor het detecteren van afwijkingen in cloudkosten is de grens die bepaalt wanneer een verandering in de clouduitgaven significant genoeg is om een waarschuwing te activeren. U stelt deze in door een referentiepunt voor normaal uitgavenpatroon vast te leggen en vervolgens een tolerantiebereik te definiëren – hetzij als een vast bedrag in dollars, een procentuele afwijking of een statistisch afgeleide bandbreedte – waarboven het systeem ongebruikelijke activiteit signaleert. De juiste drempelwaarde zorgt voor een evenwicht tussen gevoeligheid en ruis: is deze te streng, dan wordt u overspoeld door valse positieven; is deze te ruim, dan blijven echte kostenpieken onopgemerkt. In de onderstaande paragrafen wordt uitgelegd hoe afwijkingsdetectie werkt, wat ermee wordt opgespoord en hoe u drempelwaarden kunt configureren die daadwerkelijk van nut zijn voor uw team.

Hoe werkt het opsporen van afwijkingen in cloudkosten eigenlijk?

Het opsporen van afwijkingen in cloudkosten werkt door de huidige uitgavenpatronen voortdurend te vergelijken met een aangeleerde referentie en afwijkingen te signaleren die een vastgestelde drempel overschrijden. Het systeem verwerkt factuurgegevens van uw cloudproviders, stelt een model op van wat normale uitgaven zijn voor een bepaalde dienst, account of tag, en geeft vervolgens een waarschuwing wanneer de werkelijke kosten meer dan de geconfigureerde tolerantie afwijken van dat model.

De meeste moderne tools voor het opsporen van afwijkingen, waaronder die welke zijn ingebouwd in AWS Cost Anomaly Detection, Azure Cost Management en tools van derden FinOps-platforms, werken in een continue lus. Ze halen gedetailleerde factureringsgegevens op, vaak met een resolutie per uur of per dag, werken hun basismodel bij zodra er nieuwe gegevens binnenkomen en toetsen elk nieuw gegevenspunt aan de huidige drempelwaarde. Wanneer een gegevenspunt buiten het verwachte bereik valt, genereert het systeem een waarschuwing en stuurt deze door naar het verantwoordelijke team of de kostenverantwoordelijke.

De kwaliteit van anomaliedetectie hangt in hoge mate af van twee factoren: de rijkdom van de tagging- en toewijzingsgegevens die in het model worden ingevoerd, en de geavanceerdheid van de baseline zelf. Een systeem dat werkt met goed getagde bronnen en een lange geschiedenis van schone factureringsgegevens zal veel meer bruikbare waarschuwingen opleveren dan een systeem dat werkt met niet-toegewezen, slecht gelabelde uitgaven.

Welke soorten afwijkingen in de cloudkosten kunnen met een drempelwaarde worden opgespoord?

Een drempelwaarde voor het opsporen van afwijkingen in cloudkosten kan elk uitgavenpatroon signaleren dat aanzienlijk afwijkt van de gangbare normen, waaronder plotselinge pieken, onverwachte geleidelijke stijgingen en ongebruikelijke dalingen die kunnen duiden op een verkeerde toewijzing van middelen of een storing in de dienstverlening. De meest voorkomende soorten afwijkingen vallen onder vier categorieën.

• Plotselinge pieken: Een dienst of hulpbron leidt tot een scherpe, kortstondige kostenstijging, vaak veroorzaakt door een verkeerd geconfigureerd beleid voor automatische schaalbaarheid, een uit de hand gelopen taak of een onbedoelde inzet van te grote instances.
• Aanhoudende afwijking: De kosten op een bepaalde rekening of voor een bepaalde dienst stijgen geleidelijk in de loop van dagen of weken zonder dat daar een zakelijke reden voor is; dit is vaak het gevolg van een opeenstapeling van ongebruikte middelen of van het inzetten van nieuwe werkzaamheden zonder dat daarvoor budgettaire goedkeuring is verleend.
• Onverwachte nieuwe uitgaven: Er verschijnen kosten voor een dienst of regio die nog nooit eerder is gebruikt, wat kan duiden op een beveiligingslek, ‘schaduw-IT’-activiteiten of een ontwikkelaar die buiten de goedgekeurde omgevingen experimenteert.
• Ongewone dalingen: De uitgaven liggen aanzienlijk onder het verwachte niveau, wat erop kan wijzen dat een cruciale dienst is uitgevallen, dat datapijplijnen niet meer werken of dat er factureringsgegevens ontbreken in de rapportagefeed.

Om alle vier de soorten afwijkingen te detecteren, moet uw drempelwaarde voor elke uitgavencategorie afzonderlijk worden gekalibreerd. Als u één algemene drempelwaarde toepast op de totale clouduitgaven, zullen afwijkingen in afzonderlijke diensten over het hoofd worden gezien, omdat deze worden gemaskeerd door compenserende mutaties elders op de factuur.

Welke factoren bepalen de juiste drempelwaarde voor anomaliedetectie?

De juiste drempelwaarde voor het detecteren van afwijkingen hangt af van de volatiliteit van uw cloud-workloads, de gedetailleerdheid waarmee u de uitgaven monitort, het financiële belang van de betrokken diensten en het vermogen van uw team om op waarschuwingen te reageren. Er is geen algemeen geldende juiste waarde.

Er zijn verschillende factoren die de beslissing rechtstreeks beïnvloeden:

• Schommelingen in de werkbelasting: Zeer wisselende werklasten, zoals batchverwerkingsopdrachten of gebeurtenisgestuurde functies, leiden van nature tot grote schommelingen in de dagelijkse kosten. Een strakke procentuele drempelwaarde zorgt bij deze diensten voor voortdurende ruis. Een ruimere bandbreedte of een dynamische drempelwaarde op basis van historische variatie is geschikter.
• Financiële materialiteit: Een piek van 20% bij een dienst die 50 euro per maand kost, zal waarschijnlijk niet dezelfde urgentie vereisen als een piek van 10% bij een dienst die 50.000 euro per maand kost. Door drempels op basis van zowel percentages als absolute waarden te combineren, zodat er alleen een waarschuwing wordt geactiveerd wanneer aan beide voorwaarden is voldaan, wordt ongewenste ruis bij lage waarden verminderd.
• Kennisgeving aan de eigenaar: Als meldingen worden doorgestuurd naar een team dat er niet binnen enkele uren op kan reageren, leidt een te strenge gevoeligheidsdrempel tot achterstanden in plaats van reacties. Stem de gevoeligheid af op de daadwerkelijke reactiecapaciteit van uw team.
• Actualiteit van de gegevens: Drempelwaarden die zijn ingesteld op basis van dagelijkse factuurgegevens gedragen zich anders dan drempelwaarden die zijn ingesteld op basis van uurgegevens. Een fijnere granulariteit maakt een vroegere detectie mogelijk, maar versterkt ook kortstondige schommelingen.
• Seizoensgebondenheid van de bedrijfsactiviteiten: Met voorspelbare periodes waarin veel wordt uitgegeven, zoals rapportagecycli aan het einde van het kwartaal of seizoensgebonden pieken in het verkeer, moet in de basislijn rekening worden gehouden, zodat verwachte stijgingen geen valse waarschuwingen veroorzaken.

Hoe stel je stap voor stap een drempelwaarde in voor het opsporen van afwijkingen in cloudkosten?

Je stelt een drempelwaarde voor het detecteren van afwijkingen in cloudkosten in door historische uitgaven te analyseren om een referentiepunt vast te stellen, een drempelwaardetype te kiezen, tolerantiewaarden te definiëren, de drempelwaarde te toetsen aan historische gegevens en vervolgens het proces te herhalen op basis van de kwaliteit van de waarschuwingen. Dit proces vergt in het begin weliswaar wat extra inspanning, maar zorgt er op termijn voor dat het aantal valse alarmen drastisch afneemt.

1. Deel je uitgaven in segmenten in: Verdeel de totale cloudkosten in zinvolle monitoringeenheden, per dienst, account, teamtag of omgeving. Het opsporen van afwijkingen werkt het beste wanneer dit wordt toegepast op homogene uitgavenstromen in plaats van op samengevoegde totalen.
2. Stel een uitgangssituatie vast: Gebruik ten minste 30 dagen aan historische factuurgegevens, bij voorkeur 60 tot 90 dagen, om de gemiddelde dagelijkse of wekelijkse uitgaven per segment te berekenen. Neem variatiemaatstaven zoals de standaardafwijking mee om inzicht te krijgen in de mate van natuurlijke schommelingen.
3. Kies een drempeltype: Bepaal of u een vast bedrag wilt gebruiken (waarschuwing wanneer de uitgaven X euro boven de basislijn uitkomen), een procentuele afwijking (waarschuwing wanneer de uitgaven meer dan Y% boven de basislijn liggen) of een statistische bandbreedte (waarschuwing wanneer de uitgaven buiten N standaardafwijkingen van het gemiddelde vallen). Statistische bandbreedtes presteren doorgaans het beste bij volatiele workloads.
4. Stel de beginwaarden in: Begin voorzichtig, bijvoorbeeld met twee standaardafwijkingen of een 20%-afwijking in combinatie met een minimaal absoluut bedrag van 100 euro. Zo worden meldingen van geringe waarde uitgefilterd, terwijl belangrijke gebeurtenissen wel worden opgemerkt.
5. Backtest op basis van historische gegevens: Pas uw drempelwaarde toe op de afgelopen 30 tot 60 dagen en tel hoeveel waarschuwingen er dan zouden zijn afgegeven. Beoordeel of elke waarschuwing aanleiding zou hebben gegeven tot actie. Pas de tolerantiewaarden aan totdat de verhouding tussen actiegerichte waarschuwingen en valse alarmen acceptabel is.
6. Eigenaar en route toewijzen: Elke melding moet worden doorgestuurd naar een met naam genoemde verantwoordelijke die zowel de nodige context als de bevoegdheid heeft om de zaak te onderzoeken en maatregelen te nemen. Meldingen zonder verantwoordelijke zijn de belangrijkste reden waarom programma’s voor het opsporen van afwijkingen mislukken.
7. Controleer en kalibreer regelmatig: Naarmate de werklast verandert, verschuiven de referentiewaarden. Plan een maandelijkse evaluatie van de prestatiedrempels en pas de referentiewaarden aan, zodat ze aansluiten bij de huidige bestedingspatronen.

Wat is het verschil tussen statische en dynamische drempelwaarden voor anomaliedetectie?

Een statische drempelwaarde voor het detecteren van afwijkingen is een vaste waarde die niet verandert, ongeacht het bestedingspatroon, terwijl een dynamische drempelwaarde zich automatisch aanpast aan historisch gedrag, seizoensinvloeden en variatie. Statische drempelwaarden zijn eenvoudiger in te stellen, maar minder nauwkeurig; dynamische drempelwaarden vereisen meer gegevens en instellingen, maar leiden tot aanzienlijk minder valse positieven bij variabele werkbelastingen.

Statische drempelwaarden

Statische drempels leggen een vaste grens vast; zo wordt er bijvoorbeeld een waarschuwing gegeven wanneer de dagelijkse uitgaven voor een dienst de 500 euro overschrijden of met meer dan 25% stijgen ten opzichte van de vorige dag. Ze zijn eenvoudig te begrijpen, gemakkelijk uit te leggen aan belanghebbenden en snel te configureren. Het nadeel is dat ze alle dagen als gelijkwaardig beschouwen. Een dienst die op de laatste dag van elke maand legitiem 800 euro kost, zal elke maand een statische drempel van 500 euro activeren, ongeacht of de piek een echt probleem weerspiegelt.

Dynamische drempelwaarden

Dynamische drempels berekenen de verwachte uitgavenbandbreedte voor elke periode op basis van historische patronen. Ze houden rekening met effecten van de dag van de week, maandelijkse cycli en groeitrends op de lange termijn, zodat de drempel op een vrijdag met hoge uitgaven automatisch ruimer is dan de drempel op een zondag met weinig verkeer. Anomaliedetectie op basis van machine learning, zoals aangeboden door tools als Apptio Cloudability, maakt gebruik van dynamische referentiewaarden om het aantal valse positieven te verminderen en tegelijkertijd de gevoeligheid voor echte anomalieën te behouden. Het nadeel is dat dynamische drempels voldoende historische gegevens vereisen om betrouwbaar te zijn en dat ze moeilijker uit te leggen zijn aan niet-technische belanghebbenden die willen weten waarom er op een bepaalde dag een waarschuwing is afgegeven.

Voor de meeste organisaties met bestaande cloud-workloads levert een dynamische drempelwaarde, die per dienst en per account wordt afgestemd, betere resultaten op dan een statische drempelwaarde. Voor nieuwe omgevingen met een beperkte factureringsgeschiedenis is een statische drempelwaarde een praktisch uitgangspunt, totdat er voldoende gegevens beschikbaar zijn om een betrouwbaar dynamisch model op te stellen.

Waarom geven waarschuwingen over afwijkingen in cloudkosten steeds vals-positieve resultaten?

Waarschuwingen over afwijkingen in cloudkosten leiden vooral tot valse positieven omdat de drempelwaarde te streng is gezien de natuurlijke schommelingen van de werklast, de basislijn geen rekening houdt met bekende seizoenspatronen, of de gedetailleerdheid van de monitoring niet is afgestemd op het uitgavenpatroon van de dienst. Om het aantal valse positieven te verminderen, is afstemming nodig, niet alleen strengere regels.

De meest voorkomende onderliggende oorzaken zijn:

• Te krappe drempels: Een procentuele afwijking van 5% of 10% zal voortdurend worden geactiveerd bij werklasten met een natuurlijke dagelijkse variatie van 15% of meer. Door de bandbreedte te vergroten of over te schakelen naar een statistische drempelwaarde op basis van de werkelijke variatie, wordt het grootste deel van deze ruis geëlimineerd.
• Geen seizoenscorrectie: Voorspelbare gebeurtenissen die hoge kosten met zich meebrengen, zoals batchtaken aan het einde van de maand, wekelijkse rapportagecycli of bekende verkeerspieken, moeten worden uitgesloten van de basisberekeningen of worden gemodelleerd als verwachte variatie. Als dit niet gebeurt, beschouwt het systeem normale pieken als afwijkingen.
• Monitoring met een te fijne granulariteit: Gegevens over de kosten per uur bevatten meer ruis dan dagelijkse gegevens. Als je team de waarschuwingen één keer per dag bekijkt, leidt monitoring op uurbasis tot een toename van het aantal valse positieven, zonder dat de reactietijd daardoor verbetert.
• Algemene drempelwaarden in plaats van drempelwaarden per dienst: Door voor alle diensten één enkele drempel toe te passen, wordt voorbijgegaan aan het feit dat verschillende diensten fundamenteel verschillende kostenprofielen en volatiliteitsniveaus hebben.
• Verouderde referentiepunten: Als de referentiewaarde maanden geleden is vastgesteld en de werkbelasting is toegenomen of veranderd, geeft het model niet langer het huidige normale gedrag weer. Het regelmatig opnieuw kalibreren van de referentiewaarde is geen optie; het maakt deel uit van het doorlopende beheer van cloudkosten hygiëne.

Het aanpakken van valse positieven is een iteratief proces. Houd elke waarschuwing bij, bestempel deze als ‘actie vereist’ of ‘ruis’, en gebruik die gegevens om je drempelwaarden systematisch aan te scherpen. Teams die dit consequent doen, slagen er doorgaans in om het aantal ruiswaarschuwingen binnen twee of drie evaluatiecycli met meer dan de helft te verminderen.

Hoe wij helpen bij het opsporen van afwijkingen in de cloudkosten

Wij helpen organisaties om de stap te zetten van reactieve waarschuwingen naar een gestructureerde FinOps-aanpak, waarbij het opsporen van afwijkingen deel uitmaakt van een breder model voor kostenbeheer. Als u met ons samenwerkt, profiteert u van:

• Standaardconfiguratie en drempelwaardebepaling: We analyseren uw historische factuurgegevens en stellen drempels voor afwijkingsdetectie in die aansluiten bij de daadwerkelijke volatiliteit en materialiteit van uw workloads, waardoor ruis vanaf dag één wordt beperkt.
• Instellingen voor tagging en toewijzing: Een effectieve detectie van afwijkingen is afhankelijk van een nauwkeurige en consistente toewijzing van kosten. Wij helpen u bij het opzetten van de tagging-structuur en toewijzingsregels die ervoor zorgen dat de monitoring per dienst en per team betrouwbaar verloopt.
• Implementatie van gereedschappen: Als Apptio-partner implementeren en configureren wij Apptio Cloudability voor het opsporen van afwijkingen in het kader van FinOps, waardoor uw teams beschikken over dynamische, op machine learning gebaseerde drempelwaarden en een systeem voor het doorsturen van bruikbare waarschuwingen binnen AWS, Azure en GCP.
• Eigendom en bestuursstructuur: We leggen vast wie verantwoordelijk is voor elke waarschuwingscategorie, hoe het reactieproces eruitziet en hoe bevindingen over afwijkingen worden meegenomen in uw bredere cyclus voor het beoordelen van uw clouduitgaven.
• Beoordeling van de FinOps-rijpheid: Als u niet precies weet hoe uw huidige capaciteit op het gebied van anomaliedetectie ervoor staat, geeft onze beoordeling u een duidelijk beeld van de tekortkomingen en een op prioriteit gerangschikt stappenplan voor verbetering.

Als je niet langer wilt verdrinken in een zee van geluid en de belangrijke gebeurtenissen wilt gaan opmerken die er echt toe doen, neem contact met ons op om te bespreken hoe wij u kunnen helpen bij het opzetten van een systeem voor afwijkingsdetectie dat geschikt is voor de omvang en complexiteit van uw cloudomgeving.