Een bruikbare kostenbespreking begint bij het verschil tussen de factuur van deze maand en de vorige. Zoek welke diensten de stijging veroorzaken en wie ze beheert. “Compute is duurder geworden” is te breed om iets mee te doen. Een oude testomgeving of een groeiend logarchief kun je wel onderzoeken.
Maak onderscheid tussen meer gebruik, een prijswijziging, een configuratieaanpassing en resources die zijn blijven draaien. Elk geval vraagt een andere aanpak.
Zoek resources zonder huidig doel
Bekijk losgekoppelde schijven, oude snapshots, verlaten ontwikkelomgevingen, dubbele monitoringdiensten en gereserveerde adressen. Laat de eigenaar bevestigen waarvoor een resource dient voordat je ze verwijdert. Een schijf die vandaag nergens aan hangt, kan nog deel uitmaken van een herstelprocedure.
Geef tijdelijke omgevingen een eigenaar en een einddatum. Voor ontwikkelsystemen die veilig kunnen worden gestopt, kun je draaien tijdens werkuren vergelijken met continu draaien. Controleer geplande taken, koppelingen en opstarttijd voordat je dat invoert.
Bekijk opslag apart. Welke bewaartermijnen zijn bewust gekozen, welke zijn standaardinstellingen en welke zijn nooit meer herbekeken? Bereken ook het ophalen en terugzetten van data voordat je naar een goedkoper opslagtype overstapt.
Dimensioneer op basis van de relevante pieken
Een lage gemiddelde CPU-belasting is reden voor onderzoek, maar onvoldoende bewijs om een machine te verkleinen. Een database kan haar geheugen nodig hebben voor cache. Een batchtaak kan het meeste werk in een kort nachtelijk venster uitvoeren. Sommige applicaties worden beperkt door schijflatentie of netwerkdoorvoer terwijl de CPU weinig doet.
Meet over een periode met de relevante pieken, zoals facturatie of maandafsluiting. Pas één resourcelimiet tegelijk aan en vergelijk responstijden, wachtrijen, fouten en geheugendruk. Zorg dat je de wijziging kunt terugdraaien.
Heeft de omgeving reservecapaciteit voor storingen, test de kleinere configuratie dan ook met een uitgevallen host. Capaciteit die je voor uitval aanhoudt, kan bij normaal gebruik overbodig lijken. De gids over herstel gaat daarop in.
Leg afnames pas vast na het opruimen
Een afnameverplichting kan een voorspelbare applicatie goedkoper maken. Ze kan er ook voor zorgen dat je blijft betalen voor een applicatie die is verhuisd of uitgezet. Controleer waarop de afspraak van toepassing is, hoe gebruik wordt verrekend en welke wijzigingen betaalde capaciteit ongebruikt zouden laten.
Baseer de keuze op de vraag die overblijft na verkleinen en opruimen. Vergelijk de totale verplichting met de verwachte kosten zonder vastlegging over dezelfde periode. Een groot kortingspercentage helpt weinig als je daardoor meer capaciteit afneemt dan nodig.
Reken het beheer van het alternatief mee
Neem bij een vergelijking van public en private cloud ook personeelstijd, ondersteuning, licenties, back-ups, reserve, netwerkverkeer en hardwarevervanging mee. Zet migratie en tijdelijk dubbel draaien in dezelfde berekening.
Eigen capaciteit kan passen bij stabiele applicaties die er een aanzienlijk deel van benutten. Ze heeft nog steeds grenzen en lopende kosten. Extra applicaties gebruiken stroom, opslag, beheertijd en groeiruimte, ook als de maandelijkse serverprijs gelijk blijft.
Public cloud kan beter passen bij kortstondige of moeilijk voorspelbare vraag, of wanneer een beheerde dienst werk overneemt dat je team anders zelf doet. Vergelijk de hostingmodellen op basis van het gemeten gebruik.
Houd per wijziging kort bij wie verantwoordelijk is, welke besparing je verwacht, welke controles nodig zijn en hoe de factuur er nadien uitziet. Daarmee heeft de volgende bespreking meer houvast dan een streefpercentage.