paint-brush
Så här tjänar du 1 miljon dollar med AWS på ett årförbi@gianpicolonna
65,371 avläsningar
65,371 avläsningar

Så här tjänar du 1 miljon dollar med AWS på ett år

förbi Gianpi Colonna5m2024/04/28
Read on Terminal Reader
Read this story w/o Javascript

För länge; Att läsa

Sänk dina AWS-molnkostnader med 90 %! Lär dig fyra steg för att optimera utgifterna: utmana antaganden, justera resurser, använd Graviton-instanser och övervaka användningen.

Company Mentioned

Mention Thumbnail
featured image - Så här tjänar du 1 miljon dollar med AWS på ett år
Gianpi Colonna HackerNoon profile picture
0-item
1-item


Om du stötte på den här sidan och trodde att du kommer att bli rik med något bli rik-snabbt-schema, är jag ledsen att besviken. Den här artikeln kommer snarare att prata om hur du kan minska dina molnkostnader med 1 miljon dollar. Genom att göra det kommer du i princip ha genererat en extra miljon dollar i intäkter — som du kan spendera på att köpa min onlinekurs om hur du blir rik med AWS ( länk till kursen här ).



Molnkostnaden förbises ofta och inte redovisas i början av företags projekt. HashiCorps undersökning från 2021 visade att nästan 40 % av företagen spenderade för mycket på molnkostnader 2021 [ 1 ]. År 2023 medgav nästan alla företag (94 %) att de slösade bort pengar på molnet [ 1 ] och minst 30 % av molnets kostnad var bortkastade [ 2 ]. Molnutgifterna var nästan 500 miljarder dollar 2022 — därför talar vi om 150 miljarder dollar som slösas bort per år!!


Detta är inte bara ett problem för uteblivna intäkter utan också dåliga hållbarhetsmetoder. 150 miljarder dollar av bortkastad energi!


Dessa fynd involverar stora företag såväl som mindre, från hög molnmognad till låg molnmognad. Det hänvisar till AWS, men samma principer kan tillämpas på vilken annan molnleverantör som helst. Så om någon del av ditt jobb är i molnet, då är den här artikeln för dig.


Jag talar ur ett dataingenjörsperspektiv, men samma lärdomar kan tillämpas på andra programvarutekniker.

Låt oss dyka in.


Vad krävs för att spendera 1 miljon dollar i molnkostnader på ett år?

Denna typ av molnräkning är vanligtvis begränsad till mycket stora företag som verkar globalt med miljontals kunder.


För att ge dig en idé kan en molnnota på 1 miljon dollar resultera från ett Spark ETL-jobb som bearbetar ~1,5 Tb per timme 24x7 under 365 dagar om året. Ett annat exempel kan vara en applikation som tar emot miljarder förfrågningar om dagen från flera platser i världen.


I ett stort företag finns det hundratals applikationer i den här storleken – vilket resulterar i miljardkontrakt med molnleverantörer. Till exempel hade Airbnb ett åtagande att spendera 1,2 miljarder dollar på molnresurser under fem år i slutet av 2019 [3 ].


På Expedia sänkte vi kostnaderna för en databehandlings-ETL som kostar 1,1 miljoner dollar per år till bara 100 000 dollar per år genom att implementera optimeringsmetoder. Det är en kostnadsminskning på 91 %!!


Alla företag har inte applikationer av så stor storlek, men tänk dig att sänka dina molnkostnader med 90 % bara för en enskild applikation eller för hela ditt företag.



Hur börjar vi spara?

STEG 1: Utmana dina designantaganden

Gå och få en lista över dina dyraste applikationer och utmana dina designantaganden .

  • Bygger du en applikation som har en tillgänglighet på 99,999 % och en fördröjning på under millisekunder, men realistiskt sett skulle användare vara tillräckligt bra med en tillgänglighet på 99 % och hundratals millisekunders latens?
  • Skapar du datauppsättningar med miljarder rader men användare skulle bara använda aggregering av vissa av måtten?
  • Landar du data i realtid men data analyseras bara en gång om dagen?
  • Uppdaterar du cachen var tionde sekund, men den ändras bara på riktigt över dagar?


Alla dessa frågor går tillbaka till den viktigaste frågan: hur kommer applikationen att användas? Vad är affärsvärdet för att det ska finnas? Hur hjälper applikationen oss att uppnå ett givet mål?


Naturligtvis är alla dessa svar väldigt ofta oklara i början av ett projekt; men det är därför design alltid ska vara en iterativ process – så att förändringar kan ske så sömlöst som möjligt. Ingenjörer bör omfamna evolution och förändring, anpassa applikationsutveckling med effekt.


STEG 2: Finjustera dina infrastrukturresurser efter dina behov

Det andra steget består av att förse applikationen med rätt resurser och ställa in den till rätt infrastruktur.


Som ingenjör, var medveten om hur molnkostnaderna beräknas. Till exempel tillhandahåller AWS spot-instanser där du kan bjuda på klusterpriset – detta är särskilt användbart om du har feltoleranta och flexibla applikationer. Använd dem om du kan — AWS hävdar att kostnaderna minskar med upp till 90 % [ 4 ].


Några andra överväganden du kanske vill ta upp är:

  • Betjänar du kunder globalt eller bara i ett geografiskt område? Behöver du verkligen din infrastruktur för att leva över hela världen eller kan du sätta upp den närmare din kundbas?
  • Överprovisionerar du dina klusterinstanser? Försök att säkerställa att det finns tillräckligt med kapacitet för att hantera toppbelastningar utan onödiga kostnader. Använd automatisk skalning för att dynamiskt justera resurser baserat på faktisk efterfrågan, vilket förhindrar överbetalning för lediga resurser.
  • Om du arbetar med data och Spark, se till att du förstår Spark-koncept och inställning! Om du inte gör det, ta en titt på följande resurser [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

STEG 3: Använd AWS Graviton-instanser

Det finns små eller inga nackdelar med att använda AWS Graviton-instanser. AWS har investerat mycket i att skapa de mest kostnadseffektiva processorerna. Du kan få upp till 40 % minskning av molnutgifterna bara genom att byta från en Intel-baserad processor till en ARM-baserad processor [ 10 ].


Den enda förbehållet till detta är att din applikation måste vara kompatibel med de ARM-baserade processorer som Graviton körs på. Om du har att göra med en hanterad tjänst som RDS eller OpenSearch så finns det ingen komplikation alls med att byta – AWS hanterar det underliggande operativsystemet och applikationskompatibiliteten. Om du bygger din egen applikation kan du behöva kompilera om paketet beroende på vilket språk du använder - Java och andra språk kräver ingen förändring medan Python kräver lite uppmärksamhet.


STEG 4: Övervaka dina kostnadsutgifter och utbilda dig om kostnadsmedvetenhet

Slutligen, glöm inte att fortsätta övervaka dina kostnader för oväntade toppar och överraskningar. Kostnaden dag 0 av din ansökan kommer att skilja sig från kostnaden dag 170. Se till att du håller reda på ändringarna, och du förstår varför förändringen sker: staplar det s3-lagringskostnader eller är det bara en engångsföreteelse spika?


Ställ in nödvändiga varningar och driftguider !


Viktigt, implementera kostnadsfördelningstaggar för att spåra utgifter per avdelning, projekt eller miljö. Undvik risken att skapa ett dataträsk där kostnaden inte går att spåra eller kräver en lång resa över olika loggsystem. Det ska vara snabbt och enkelt att gå tillbaka till en given applikationskostnad.


Sista tankar

Var du än arbetar är det svårt att balansera leveransen av nya funktioner med optimeringen av nuvarande. Vem har inte blivit pressad att leverera nya knäppa funktioner i ljusets hastighet.


Det är dock viktigt för både ingenjörer och chefer att fatta medvetna och proaktiva beslut om sina nuvarande projekt, hantera risker och möjligheter effektivt.