Hoe u in één jaar $ 1 miljoen verdient met AWS

Als u op deze pagina bent beland met het idee dat u rijk gaat worden met een get-rich-quick-plan, dan moet ik u helaas teleurstellen. Dit artikel gaat eerder over hoe u uw cloudkostenrekeningen met $ 1 miljoen kunt verlagen. Door dat te doen, genereert u in feite een extra miljoen dollar aan inkomsten — die u kunt besteden aan het kopen van mijn online cursus over hoe u rijk kunt worden met AWS ( link naar cursus hier ).

Cloudkosten worden vaak over het hoofd gezien en niet meegenomen in de beginfase van projecten van bedrijven. Uit het onderzoek van HashiCorp uit 2021 bleek dat bijna 40% van de bedrijven in 2021 te veel geld uitgaf aan cloudkosten [ 1 ]. In 2023 gaven bijna alle bedrijven (94%) toe dat ze geld verspilden aan de cloud [ 1 ] en dat minstens 30% van de cloudkosten verspild werd [ 2 ]. In 2022 bedroegen de clouduitgaven bijna $ 500 miljard — dus we hebben het over $ 150 miljard verspild per jaar!!

Dit is niet alleen een zorg vanwege gemiste inkomsten, maar ook vanwege slechte duurzaamheidspraktijken. Er gaat 150 miljard dollar aan energie verloren!

Deze bevindingen hebben betrekking op zowel grote als kleinere ondernemingen, van high-cloud maturity tot low-cloud maturity. Het verwijst naar AWS, maar dezelfde principes kunnen worden toegepast op elke andere cloudprovider. Dus als een deel van uw werk zich in de cloud afspeelt, dan is dit artikel voor u.

Ik spreek vanuit het perspectief van een data engineer, maar dezelfde lessen kunnen ook worden toegepast op andere software engineering-praktijken.

Laten we beginnen.

Wat is er nodig om in een jaar 1 miljoen dollar uit te geven aan cloudkosten?

Dit soort cloudrekeningen zijn doorgaans beperkt tot zeer grote ondernemingen die wereldwijd actief zijn en miljoenen klanten hebben.

Om u een idee te geven, een cloudrekening van $ 1 miljoen kan het resultaat zijn van een Spark ETL-job die ~1,5 TB per uur 24x7 gedurende 365 dagen per jaar verwerkt. Een ander voorbeeld is een applicatie die miljarden verzoeken per dag ontvangt van meerdere locaties in de wereld.

In een groot bedrijf zijn er honderden applicaties van deze omvang, wat resulteert in miljardencontracten met cloudproviders. Airbnb had bijvoorbeeld een toezegging om eind 2019 $ 1,2 miljard te besteden aan cloudbronnen over vijf jaar [3 ].

Bij Expedia hebben we de kosten voor een dataverwerkings-ETL van $ 1,1 miljoen dollar per jaar teruggebracht tot slechts $ 100.000 per jaar door optimalisatiepraktijken te implementeren. Dat is een kostenreductie van 91%!!

Niet alle bedrijven hebben applicaties van zo'n grote omvang, maar stel je eens voor dat je je cloudkosten met 90% kunt verlagen voor slechts één applicatie of voor je hele bedrijf.

Hoe beginnen we met sparen?

STAP 1: Daag uw ontwerpveronderstellingen uit

Maak een lijst van uw duurste toepassingen en stel uw ontwerpveronderstellingen ter discussie .

• Bouwt u een applicatie met een beschikbaarheid van 99,999% en een latentie van minder dan een milliseconde, maar zouden gebruikers realistisch gezien ook genoeg hebben aan een beschikbaarheid van 99% en een latentie van honderden milliseconden?
• Maakt u datasets met miljarden rijen, maar gebruiken gebruikers slechts aggregaties van een deel van de metingen?
• Krijgt u uw gegevens in realtime binnen, maar worden ze slechts één keer per dag geanalyseerd?
• Ververst u de cache elke 10 seconden, maar verandert de informatie eigenlijk alleen na een dag?

Al deze vragen komen terug op de belangrijkste vraag: hoe gaat de applicatie gebruikt worden? Wat is de zakelijke waarde ervan om te bestaan? Hoe helpt de applicatie ons om een bepaald doel te bereiken?

Natuurlijk zijn al deze antwoorden vaak onduidelijk aan het begin van een project; maar daarom moet design altijd een iteratief proces zijn — waarbij veranderingen zo naadloos mogelijk plaatsvinden. Engineers moeten evolutie en verandering omarmen en applicatieontwikkeling afstemmen op impact.

STAP 2: Stem uw infrastructuurbronnen af op uw behoeften

De tweede stap bestaat uit het voorzien van de applicatie van de juiste middelen en het afstemmen ervan op de juiste infrastructuur.

Wees als ingenieur op de hoogte van hoe cloudkosten worden berekend. AWS biedt bijvoorbeeld spotinstances, waar u kunt bieden op de clusterprijs — dit is vooral handig als u fouttolerante en flexibele applicaties hebt. Gebruik ze als u kunt — AWS claimt tot 90% kostenreductie [ 4 ].

Andere overwegingen die u wellicht wilt maken, zijn:

• Bedient u klanten wereldwijd of alleen in één geografisch gebied? Moet uw infrastructuur echt over de hele wereld draaien of kunt u deze dichter bij uw klantenbestand opzetten?
• Overprovisioneert u uw clusterinstances? Zorg ervoor dat er voldoende capaciteit is om piekbelastingen te verwerken zonder onnodige kosten. Gebruik autoscaling om resources dynamisch aan te passen op basis van de werkelijke vraag, zodat u niet te veel betaalt voor inactieve resources.
• Als u met data en Spark werkt, zorg er dan voor dat u de concepten en tuning van Spark begrijpt! Als u dat niet doet, bekijk dan de volgende bronnen [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

STAP 3: Gebruik AWS Graviton-instanties

Er zijn weinig tot geen nadelen aan het gebruik van AWS Graviton-instanties. AWS heeft zwaar geïnvesteerd in het creëren van de meest kosteneffectieve processors. U kunt tot 40% reductie in clouduitgaven krijgen door gewoon over te stappen van een Intel-gebaseerde processor naar een ARM-gebaseerde processor [ 10 ].

De enige kanttekening hierbij is dat uw applicatie compatibel moet zijn met de ARM-gebaseerde processors waarop Graviton draait. Als u te maken hebt met een beheerde service zoals RDS of OpenSearch, dan is er helemaal geen complicatie bij het overschakelen — AWS regelt de onderliggende OS- en applicatiecompatibiliteit. Als u uw eigen applicatie bouwt, dan moet u het pakket mogelijk opnieuw compileren, afhankelijk van de taal die u gebruikt — Java en andere talen vereisen geen wijziging, terwijl Python enige aandacht vereist.

STAP 4: Houd uw kosten in de gaten en zorg voor kostenbewustzijn

Vergeet ten slotte niet om uw kosten in de gaten te houden voor onverwachte pieken en verrassingen. De kosten op dag 0 van uw applicatie zullen verschillen van de kosten op dag 170. Zorg ervoor dat u de wijzigingen bijhoudt en dat u begrijpt waarom de wijziging plaatsvindt: stapelt u s3-opslagkosten op of is het slechts een eenmalige piek?

Stel de nodige waarschuwingen en operationele handleidingen in !

Belangrijk is dat u kostenallocatietags implementeert om uitgaven per afdeling, project of omgeving bij te houden. Vermijd het risico dat u een datamoeras creëert waarbij kosten niet te traceren zijn of waarbij een lange reis door verschillende logsystemen nodig is. Het moet snel en eenvoudig zijn om terug te gaan naar de kosten van een bepaalde applicatie.

Laatste gedachten

Waar u ook werkt, het is lastig om de levering van nieuwe functies in evenwicht te brengen met de optimalisatie van de huidige. Wie is er niet onder druk gezet om nieuwe, eigenzinnige functies met de snelheid van het licht te leveren?

Het is echter essentieel dat zowel ingenieurs als managers weloverwogen en proactieve beslissingen nemen over hun huidige projecten en risico's en kansen effectief beheren.