Hur optimerar jag dina Amazon S3-kostnader?

Du betalar i S3 S3 dataöverföringskostnader.

Amazons webbtjänster (AWS), och i synnerhet Simple Storage Service (S3) används ofta av många individer och företag för att hantera sina data, webbplatser och backend. Dessa sträcker sig från isolerade individer och små startups till värderingsföretag på flera miljarder dollar som Pinterest och (tidigare) Dropbox. Denna sida är inte avsedd som en guide till ombordstigning av S3; du kan hitta många andra sådana guider online. Snarare riktar det sig till individer och företag vars förväntade S3-kostnader ligger mellan 7,50€ per månad och 7460€ per månad. Andra liknande listor med tips finns tillgängliga online.

Denna sida går inte heller in på andra typer av S3-optimeringar, som att optimera skop, mapp- och filnamn och driftsordning, fokuserad på att maximera genomströmningen eller minimera latens. De flesta av dessa optimeringar påverkar inte kostnaderna direkt (varken positivt eller negativt). Dessutom blir de vanligtvis bara relevanta i en väsentligt större skala än den skala som målgruppen för denna sida sannolikt kommer att vara i. Du kan läsa mer om sådana optimeringar i den officiella S3-guiden och på andra håll.

Del 1 av 6: Få en bred förståelse för s3

1
Förstå ditt s3-användarfall. S3 kan användas för många mål.
- Som en plats att lagra filer för live-servering på webbplatser, inklusive bildfiler eller en hel statisk webbplats (vanligtvis bakom ett CDN som Amazon CloudFront eller CloudFlare).
- Som en "datasjö", en plats för data som du konsumerar från eller genererar i dina applikationer: I huvudsak blir S3 det långvariga lagringsutrymmet för dina data, med din första genererade data loggas till S3 och olika applikationer läser från S3, omvandla data och skriva tillbaka till S3.
- Som ett "datalager", en plats att lagra långvariga säkerhetskopior av strukturerad och ostrukturerad data som inte är avsedda för ytterligare aktiv konsumtion.
- Som en plats för att lagra körbara filer, skript och konfigurationer som är nödvändiga för att starta nya EC2-instanser med dina applikationer (eller uppdatera dina applikationer i befintliga instanser).
2
Förstå hur s3 påverkar kostnaderna. Siffrorna nedan är för standardlagring, förbehåll associerade med andra former av lagring diskuteras senare. Alla kostnader tillämpas och rapporteras separat för varje skopa och varje timme. med andra ord, om du laddar ner din detaljerade faktureringsrapport ser du en rad vardera för varje kombination av hink, timme och kostnadstyp.
- Lagringskostnader: Kostnaden mäts i lagringsutrymmet multiplicerat med tiden. Du betalar inte i förskott för en tilldelad mängd lagringsutrymme. Snarare, varje gång du använder mer lagringsutrymme, betalar du extra för det extra lagringsutrymmet för den tid du använder det. Kostnader kan därför fluktuera över tid när mängden data du har lagrat ändras. Lagringskostnader rapporteras separat för varje skopa varje timme. Prissättningen varierar beroende på region men är fast inom varje region. Från och med mars 2020 varierar kostnaden från 2,3 cent per GB-månad i US Standard (North Virginia) till 4,05 cent per GB-månad i Sao Paulo.
- Begärande prissättning: För standardlagring varierar kostnaden för PUT, COPY, POST- eller LIST-förfrågningar från 0€ per 1000 förfrågningar i amerikanska regioner till 0€ per 1000 förfrågningar i Sao Paulo. Kostnaden för GET och alla andra förfrågningar är mindre än 0€ per 10000 förfrågningar i alla amerikanska regioner till 0€ per 10000 förfrågningar i Sao Paulo. Observera dock att de flesta kostnader som är förknippade med en GET-förfrågan tas med i dataöverföringskostnaderna (om begäran görs utanför regionen). Observera också att för data som lagras i andra typer av lagring är begäran om prissättning lite högre. En annan typ av begäran som blir relevant när man diskuterar livscykelpolicyer är begäran om livscykelövergång (t.ex. övergång från standardlagring till IA eller Glacier).
- Dataöverföringskostnader: Kostnaderna är noll inom samma AWS-region (både S3 -> S3 och S3 -> EC2-instanser), cirka 2 cent per GB för dataöverföring över regioner och cirka 9 cent per GB för dataöverföring till AWS utanför.
- Prissättning för hämtning: Detta gäller inte standardlagring, utan snarare gäller två av de andra lagringsklasserna, nämligen IA och Glacier. Denna prissättning tillämpas per GB för data som hämtats.
3
Förstå den centrala roll som hinkar spelar för att organisera dina s3-filer och användningen av "objekt" för s3-filer.
- Du kan skapa hinkar under ditt konto. En hink identifieras med en sträng (skopnamnet). Det kan bara finnas en hink med ett visst hinknamn över hela S3, över kunder; därför kanske du inte kan använda ett skopnamn om någon annan redan använder det.
- Varje hink är associerad med en AWS-region och replikeras över flera tillgänglighetszoner inom den regionen. Informationen om tillgänglighetszon är inte tillgänglig för slutanvändaren, men är en intern implementeringsdetalj som hjälper S3 att upprätthålla hög hållbarhet och tillgänglighet av data.
- Inom varje hink kan du lagra dina filer antingen direkt under hinken eller i mappar. Mappar behöver inte skapas eller tas bort. Om du sparar en fil kommer den automatiskt att skapa "mappar" för att filvägen ska vara meningsfull, om de inte redan finns. När det inte finns några filer under den upphör mappen automatiskt att existera.
- Sättet som S3 lagrar informationen är som ett nyckel-värdelager: för varje prefix som inte är ett filnamn lagras det uppsättningen filer och mappar med det prefixet. För varje filnamn mappas det till den faktiska filen. I synnerhet kan olika filer i en hink lagras i mycket olika delar av datacentret.
- S3 kallar sina filer "objekt", och du kan stöta på den här termen när du läser upp S3 någon annanstans.
4
Förstå de olika sätten du kan interagera med s3-filer på.
- Du kan ladda upp och ladda ner filer online genom att logga in via en webbläsare.
- Kommandoradsverktyg baserade på Python inkluderar AWS Command Line Interface, den föråldrade s3cmd och senare s4cmd.
- Om du använder Java eller ett annat språk som är baserat på JVM (som Scala) kan du komma åt S3-objekt med AWS Java SDK.
- Distributionsverktyg som Ansible och Chef erbjuder moduler för att hantera S3-resurser.
5
Förstå fördelarna och nackdelarna med att hantera s3 och dess skillnader från ett traditionellt filsystem.
- Med S3 kräver det lite mer gymnastik (och körtid) för att få en global bild av mängden data som används i en hink eller i undermappar för den hinken. Det beror på att dessa data inte spelas in någonstans direkt utan snarare måste beräknas genom rekursiva nyckel-värde-sökningar.
- Att hitta alla filer som matchar en regex kan vara en mycket dyr operation, särskilt när regexen innehåller jokertecken mitt i uttrycket snarare än i slutet.
- Det är inte möjligt att utföra åtgärder som att lägga till data i en fil: du måste hämta filen, ändra den och sedan lägga upp hela den modifierade filen (se punkten senare om synkroniseringsfunktionerna).
- Att flytta eller byta namn på filer innebär faktiskt att du tar bort objekt och skapar nya. Att flytta en mapp innebär att alla objekt under den raderas och återskapas. Varje filflyttning innebär ett GET- och ett PUT-samtal, vilket leder till ökad prissättning av begäran. Dessutom kan rörliga objekt vara dyra om objekten lagras i lagringsklasser (Standard-IA och Glacier) där hämtning kostar pengar.
- S3 kan stödja filstorlekar upp till 5 TB, men dataöverföring mellan regioner kan börja trassla för filstorlekar på mer än några hundra megabyte. CLI använder uppladdning i flera delar för stora filer. Se till att om dina program hanterar stora filer fungerar de genom uppladdning i flera delar, eller delar utdata i mindre filer.
- S3 ger inte fullt stöd för rsync. Det finns dock ett synk-kommando (aws s3 sync i AWS CLI och s3cmd sync i s3cmd) som synkroniserar allt innehåll mellan en lokal mapp och en S3-mapp eller mellan två S3-mappar. För filer som finns i både källan och målmappen kan den upptäcka identiska filer och undvika dataöverföring om filerna är identiska. det är dock inte så effektivt som rsync genom att det kan behöva utföra en fullständig överföring om filer skiljer sig lite, medan rsync bara skickar en liten diff för mycket liknande filer. Den andra skillnaden med rsync är att den gäller en hel mapp och att filnamn inte kan ändras.

Om du replikerar skopan i USA öst betalar du bara en gång för dataöverföringskostnaderna.

Del 2 av 6: zippa / komprimera data

1
Se till att du komprimerar data där det tillåts av kraven i din applikation innan du börjar.
- Utforska vilka former av zippning och komprimering som är kompatibla med de processer du använder för att generera data och de processer du använder för att läsa och bearbeta data.
- Se till att du använder blixtlås och komprimering för dina största dumpningar av data i den mån det inte stör din applikation. I synnerhet är råa användarloggar och strukturerad data baserad på användaraktivitet de främsta kandidaterna för komprimering.
- Som en allmän regel kommer komprimering att spara inte bara lagringskostnader utan också överföringskostnader (när du läser / skriver data) och kan till och med sluta göra din applikation snabbare om uppladdning / nedladdningstid är en större flaskhals än lokal komprimering / dekompressionstid. Detta är ofta fallet.
- För att ta ett exempel på att konvertera stora strukturerade datafiler till BZ2-formatet kan lagringsutrymmet minska med en faktor som varierar från 3 till 10; BZ2 är dock datorintensiv för att zip och packa upp. Andra komprimeringsalgoritmer att tänka på är gzip, lz4 och zstd.
- Andra möjliga sätt att minska utrymmet inkluderar att använda kolumnbaserad lagring snarare än radbaserad lagring och att använda binära format (som AVRO) snarare än mänskligt läsbara format (som JSON) för långvarig datalagring.
2

Om det inte är möjligt att komprimera data vid den tidpunkt då du först skriver ut det, överväg att köra en alternativ process för att återintaga och komprimera data. Detta är i allmänhet en suboptimal lösning och mycket sällan nödvändig, men det kan finnas fall där det är relevant. Om du tittar på en sådan lösning måste du köra beräkningarna noggrant baserat på kostnaden för att testa om och komprimera data och den totala tid du tänker behålla informationen.

Del 3 av 6: Optimering av lagringskostnader

1
Förstå skillnaderna mellan de fyra typerna av s3-lagring.
- Standardlagring är det dyraste för lagring, men är billigast och snabbast för ändringar av data. Den är utformad för 99,999999999% hållbarhet (över ett år, dvs detta är den förväntade fraktionen av S3-objekt som kommer att överleva under ett år) och 99,99% tillgänglighet (tillgänglighet med hänvisning till sannolikheten för att ett givet S3-objekt är tillgängligt vid en given tidpunkt). Observera att i praktiken är det mycket sällsynt att förlora data i S3, och det finns större riskfaktorer för dataförlust än data som faktiskt försvinner från S3 (dessa större faktorer inkluderar oavsiktlig radering av data och någon skadligt hackar in på ditt konto för att radera innehåll, eller även Amazon tvingas ta bort dina uppgifter på grund av press från regeringar).
- Reducerad redundanslagring (RRS) var tidigare 20% billigare än standardlagring och erbjuder lite mindre redundans. Du kanske vill använda den för mycket av dina data som inte är mycket kritiska (till exempel fullständiga användarloggar). Detta är utformat för 99,99% hållbarhet och 99,99% tillgänglighet. Från och med december 2016 åtföljdes dock inte prissänkningar för standardlagring av motsvarande prissänkningar till RRS, så RRS är för närvarande lika eller dyrare.
- Standardlagring - Sällsynt åtkomst (kallad S3 - IA) är ett alternativ som Amazon introducerade i september 2015, som kombinerar S3s höga hållbarhet med en låg tillgänglighet på endast 99%. Det är ett alternativ för att lagra långsiktiga arkiv som inte behöver nås ofta men som måste nås snabbt när de behöver nås. S3 - IA debiteras i minst 30 dagar (även om objekt raderas innan det) och en minsta objektstorlek på 128 KB. Det är ungefär hälften så dyrt som S3, även om den exakta rabatten varierar beroende på region.
- Glaciären är den billigaste formen av lagring. Glacier kostar emellertid pengar för att arkivera och göra tillgängligt igen för läsning och skrivning, med det belopp du behöver betala beroende på antalet hämtningsförfrågningar, den hastighet med vilken du vill att data ska hämtas och storleken på data som hämtas. Glaciärfiler har också en lagringsperiod på minst 90 dagar: filer som raderas innan dess debiteras för de återstående 90 dagarna efter borttagning.
2
Få en känsla av hur dina kostnader växer.
- I ett användningsfall där du har en fast uppsättning filer som du regelbundet uppdaterar (effektivt tar bort äldre versioner) är dina månatliga lagringskostnader ungefär konstanta, med en ganska snäv övre gräns. Dina kumulativa lagringsutgifter växer linjärt. Detta är ett typiskt scenario för en uppsättning körbara filer och skript.
- I ett användningsfall där du kontinuerligt genererar ny data i konstant takt växer dina månatliga lagringskostnader linjärt. Din kumulativa lagringskostnad växer kvadratiskt.
- I ett användningsfall där datagenereringshastigheten växer linjärt växer dina månatliga lagringskostnader kvadratiskt och dina kumulativa lagringskostnader växer stadigt.
- I ett användningsfall där datagenereringshastigheten växer exponentiellt växer både din månatliga datalagringskostnad och din kumulativa datalagringskostnad exponentiellt också.
3
Utforska om objektversionering är vettigt för dina mål.
- Objektversionering låter dig behålla äldre versioner av en fil. En fördel är att du kan besöka en äldre version.
- När du använder versionversionering av objekt kan du kombinera den med livscykelprinciper för att återställa versioner som är äldre än en viss ålder (om inte den aktuella versionen).
- Om du använder objektversionering, kom ihåg att bara listning av filer (med aws s3 ls eller online-gränssnittet) kommer att göra att du underskattar det totala lagringsutrymmet som används, eftersom du debiteras för äldre versioner som inte ingår i listan.
4
Utforska livscykelpolicyer för dina data.
- Du kan ställa in policyer för att automatiskt radera data i vissa hinkar, eller till och med med vissa prefix i hinkar, som är mer än ett visst antal dagar gamla. Detta kan hjälpa dig att bättre kontrollera dina S3-kostnader och också hjälpa dig att följa olika sekretess- och datapolicyer. Observera att vissa lagar och policyer för datalagring kan kräva att du behåller data under en minimal tid; dessa sätter en lägre gräns för tiden efter vilken du kan ta bort data i din livscykelpolicy. Andra policyer eller lagar kan kräva att du raderar data inom en viss tidsperiod; dessa sätter en övre gräns för tiden efter vilken du behöver ta bort data i din livscykelpolicy.
- Med en livscykelpolicy för radering förändras hur dina kostnader växer mycket. Nu, med en konstant ström av inkommande data, förblir dina månatliga lagringskostnader konstanta snarare än att växa linjärt, eftersom du bara lagrar ett rörligt datafönster i stället för all data hittills. Även om storleken på inkommande data växer linjärt växer dina månatliga lagringskostnader bara linjärt snarare än kvadratiskt. Detta kan hjälpa dig att knyta dina infrastrukturkostnader till din intäktsmodell: om din månatliga intäkt är ungefär proportionell mot den hastighet med vilken du får data är din lagringsmodell skalbar.
- En teknisk begränsning: du kan inte ställa in två principer med samma hink där ett prefix är en delmängd av det andra. Tänk på detta när du funderar på hur du lagrar dina S3-data.
- Förutom livscykelpolicyer för radering kan du också ställa in policyer för att arkivera data (dvs. konvertera den från standardlagring till Glacier), vilket minskar lagringskostnaderna. Glacier har dock en minsta kvarhållningsperiod på 90 dagar: du debiteras för 90 dagars lagring i Glacier, även om du väljer att ta bort den innan dess. Därför, om du tänker radera inom kort, är det förmodligen inte en bra idé att flytta till Glacier.
- Du kan också ha en livscykelpolicy för att konvertera data i S3 (standardlagring) till S3 - IA. Denna policy är idealisk för data som du förväntar dig att du kommer åt ofta i omedelbar efterdyning av dess skapande men sällan efteråt. Filer i IA har en minsta objektstorlek (du debiteras för 128 KB filstorlek för mindre filer än den) och en lagringstid på minst 30 dagar.
- Observera att livscykelövergångar själva kostar pengar, och det är ofta bättre att skapa objekt direkt i önskad lagringsklass snarare än att överföra dem. Du måste göra beräkningarna för ditt användningsfall för att veta om och när livscykelövergång är vettigt.
5
Använd följande heuristik för att bestämma den bästa lagringsklassen baserat på ditt användningsfall. Medan vi pratar som om vi har att göra med en enda fil, tänker vi verkligen på en inställning där detta sker separat och oberoende för ett stort antal filer.
- Det första steget för att bestämma rätt lagringsklass är att få en uppskattning av din filstorlek, lagringsperiod, förväntat antal åtkomster (samt hur detta antal varierar över tiden baserat på ålder) och den maximala tid du kan vänta när du behöver komma åt något. Du kan använda alla dessa som parametrar i en formel som beräknar den förväntade kostnaden för att använda varje lagringsklass. Formeln blir ganska komplicerad.
- Observera att exakta trösklar för dessa kan variera beroende på de aktuella priserna i din region. Priserna varierar beroende på region och ändras med tiden. I synnerhet är följande: lagringsprissättning för varje lagringsklass, begäran om prissättning för varje lagringsklass, prissättning för hämtning för varje lagringsklass och krav på minimistorlek och minsta lagringstid. Med dessa försiktighetsåtgärder är heuristiken nedan.
- Om du tänker behålla data i två veckor eller mindre är standardlagring att föredra både framför IA och för Glacier-lagring. Anledningen är att de minsta kvarhållningsperioderna (30 dagar för IA, 90 dagar för glaciären) upphäver kostnadsfördelarna (högst dubbelt för IA, cirka sex gånger för Glacier) vid två veckor eller mindre.
- Om din filstorlek är 64 kB eller mindre, slår standardlagring alltid ut IA-lagring. Det beror på att minimikravet på IA (128 kB) upphäver kostnadsfördelen (högst dubbelt).
- Om du tänker komma åt varje fil en gång i månaden eller oftare, vinner standardlagring relativt både IA och Glacier. Det beror på att den extra kostnaden för till och med en datahämtning förstör den månatliga lagringsbesparingen.
- Låt oss säga att du har data som du först måste förvara i standardlagring i en månad, varefter du är okej med att flytta den till IA i en månad eller mer, eftersom du förväntar dig att inte behöva komma åt den alls efter det. Det är vettigt att flytta den till IA endast om det totala antalet megabyte-månader i IA-tillstånd per fil är minst 1. Det beror på att livscykelövergångskostnaden för att flytta till IA måste övervinnas av kostnadsbesparingen. Om du till exempel vill behålla informationen i ytterligare en månad bör filstorleken vara minst 1 MB för att det ska vara en lönsam kostnad. Observera den minsta 30-dagarsperioden gör övergångar för kortare tider ännu mindre värda.
- På samma sätt, för migrering till Glacier, är breakeven cirka 2,5 megabyte-månader för varje fil. Observera dock att den minimala 90-dagars kvarhållningsperioden i Glacier komplicerar saker; om du tänker dra nytta av att flytta data till Glacier under en månad bör filstorleken vara 7,5 MB eller högre.
- Om du förväntar dig att du inte behöver komma åt innehållet efter att ha skrivit det till S3 är den optimala strategin vanligtvis antingen standard eller Glacier, med avvägningen beroende på lagringsperioden. Det finns emellertid en mellanmål där IA är det bästa alternativet (till exempel lagring av 128 kB i en månad). För att illustrera detta nedan är en bild för det enkla fallet där du behöver behålla en enda fil av en fast storlek under en viss tid, med noll förväntade åtkomst efter att den har lagrats. Tiden i månader är på den horisontella axeln och filstorleken i GB är på y-axeln. En punkt är färgad blå, röd eller gul beroende på om den optimala lagringsklassen ur ett kostnadsperspektiv är standard, IA eller Glacier. Vi använder kostnader som i den amerikanska standardregionen i december 2016.
- När du ökar det förväntade antalet åtkomst till data blir standard optimal för allt fler användningsfall (dvs. för större datastorlekar och för längre lagringsperioder). IA börjar också bli optimal i fall där Glacier tidigare skulle ha varit optimal. Med andra ord tar standard över från IA och IA tar över från Glacier.
6
Använd följande riktmärken för sunt förnuft baserat på ditt användningsfall för lagring. Detta hjälper dig att få en känsla av hur mycket du kan förvänta dig i lagringskostnader.
- Om du levererar en statisk webbplats eller bilder live: Lagringskostnaderna är sannolikt några cent, med detaljer beroende på storleken på din webbplats. Huvudkostnaderna för att betjäna en levande webbplats är begäran om prissättning och överföringskostnader.
- Om du lagrar en datasjö där den huvudsakliga användargenererade strömmen är webb- eller appaktivitet (dvs webbförfrågningsloggar): En enskild webbförfrågan kan variera i maximal storlek från 1 kB (om du behåller alla standardrubriker och fält) till 10 kB (om du också inkluderar perifer information om användaren och sammanhanget). Om du får en miljon webbförfrågningar i månaden och håller gamla webbförfrågningsloggar i en månad, det översätter sig till någonstans mellan 1 GB och 10 GB lagring, vilket är mellan 2,3 cent och 40,5 cent i månatlig lagringskostnad. Kostnaden skalas linjärt både med din trafik och med ditt beslut om hur länge du ska lagra. Till exempel, med en miljard webbförfrågningar per månad och lagring av data i ett år, skjuts din månatliga datalagringskostnad upp till någonstans mellan 210€ och 3630€ Att använda binära format och zippa / komprimera kan sänka kostnaderna ytterligare.
- Om du lagrar arkiv med bilder och videofilmer: Till exempel om du är ett TV-nätverk som tar bilder regelbundet och vill ha arkiv med gamla bilder tillgängliga om det blir relevant senare. Detta är ett användningsfall där det totala lagringsutrymmet kan vara ganska betydande. Till exempel, med 10 timmars videofilmer dagligen, kan du lägga till något i intervallet 100 GB (okomprimerat) varje dag. Om du lägger detta material i standardlagring för det första året och sedan arkiverar till Glacier i ytterligare nio år, kommer dina totala data att uppgå till 365 TB (36,5 TB i standardlagring) och dina månatliga S3-lagringskostnader (före komprimering) skulle vara cirka 1640€ (två tredjedelar för Glacier, en tredjedel för standardlagring). Komprimering av olika slag kan minska lagringskostnaderna med en faktor som varierar från 2 till 10.
- Det är lärorikt att titta på räkningarna för vissa kraftiga S3-användare för att få en känsla för hur mycket en räkning kan variera.
  - Dropbox rapporterades ha 500 petabyte data i S3 innan den flyttades till sina egna servrar. Till de nuvarande priserna online, skulle det kosta cirka 7,80 miljoner euro per månad. Även om Dropbox sannolikt fick en betydande rabatt och uppnådde fördelar med dataduplicering och komprimering, var dess räkning troligtvis fortfarande minst hundratusentals dollar i månaden.
  - Ett annat extremt exempel på en stor användare är DigitalGlobe, som flyttar 100 PB högupplösta satellitbilder till S3.
  - Pinterest rapporterade att den lägger till 20 terabyte data om dagen, vilket i standardlagring innebär att deras månadsräkning skulle öka med 450€ / månad varje dag. Om denna datahastighet fortsätter i tio år skulle de ha en total lagring på cirka 75 PB och en månadsräkning i storleksordningen hundratusentals dollar.
  - Utöver dessa extrema användningsfall har dock även några av världens största företag ganska låga S3-räkningar. I slutet av 2013 rapporterade till exempel Airbnb att ha 50 TB högupplösta hemfotodata, ett belopp som skulle kosta cirka 860€ per månad till dagens priser.

Förstå den centrala roll som hinkar spelar för att organisera dina s3-filer och användningen av "objekt" för s3-filer.

Del 4 av 6: Optimering av dataöverföringskostnader

1
Om du använder s3 för live-serveringsinnehåll, placera det bakom en CDN som amazon cloudfront, cloudflare eller maxcdn.
- CDN har ett stort antal kantplatser i olika delar av världen, vanligtvis från dussintals till hundratals.
- Användarens begäran om sidan dirigeras till närmaste CDN-kantplats. Denna kantplats kontrollerar sedan om den har en uppdaterad kopia av resursen. Om inte, hämtar den den från S3. Annars serverar den den kopia den har.
- Resultatet: slutanvändare ser högre tillgänglighet och lägre latens (eftersom resurserna serveras från en plats fysiskt nära dem) och antalet förfrågningar och mängden dataöverföring från S3 hålls lågt. Explicit uttrycks begränsas antalet förfrågningar av (antal kantplatser) X (antal filer) om du aldrig uppdaterar filer; om du uppdaterar filer måste du också multiplicera med antalet filuppdateringar.
2
Förstå den centrala samplaceringsfördelen med ec2 / s3. Om din primära användning för S3 är att läsa och skriva data till EC2-instanser (dvs. något av andra användningsfall än live-serveringsinstansen), så utnyttjas denna fördel bäst om din S3-hink ligger i samma AWS-region som EC2-instanser som läser eller skriver till den. Detta kommer att ha flera fördelar:
- Låg latens (mindre än en sekund)
- Hög bandbredd (över 100 Mbit / sekund): Observera att bandbredd faktiskt är ganska bra mellan de olika USA-regionerna, så det här är inte en viktig fråga om alla dina regioner finns i USA, men det kan vara betydande mellan USA och EU, EU och Asien-Stillahavsområdet, eller USA och Asien-Stillahavsområdet.
- Inga dataöverföringskostnader (dock betalar du fortfarande begäran om prissättning)
3
Bestäm platsen (AWS-regionen) för din s3-skopa.
- Om du kör EC2-instanser som läser från eller skriver till S3-hinkarna: Som nämnts i steg 1 hjälper samlokalisering av S3 och EC2, i den mån det är möjligt, med bandbredd, latens och dataöverföringskostnader. Därför är ett viktigt övervägande för att hitta din S3-hink: var förväntar du dig att ha EC2-instanser som kommer att interagera med denna S3-hink? Om EC2-instanser oftast är backend-instanser bör du överväga kostnaderna för dessa instanser. Om de är frontend-instanser, överväg vilka regioner du förväntar dig att få mest av din trafik från. I stort sett bör du förvänta dig att EC2-instansöverväganden är viktigare än S3-överväganden när du bestämmer regionen. Så det är i allmänhet vettigt att först bestämma var du förväntar dig att din EC2-instanskapacitet ska vara och sedan ha dina S3-hinkar där. I allmänhet,S3-kostnaderna är lägre i samma regioner som EC2-förekomster, så det skapar lyckligtvis ingen konflikt.
- Om det finns andra AWS-tjänster som du måste ha, men som inte är tillgängliga i alla regioner, kan detta också begränsa ditt val av region.
- Om du ofta laddar upp filer från din hemdator till S3 kan du överväga att få en hink i en region närmare ditt hem för att förbättra uppladdningsfördröjningen. Detta bör dock vara en mindre övervägande i förhållande till de andra.
- Om du förväntar dig att använda S3 för live-servering statiska bilder, bestämma platsen baserat på var du förväntar dig att få din trafik från.
- I vissa fall begränsar de policyer du är skyldiga att följa baserat på lag eller avtal ditt val av region för S3-datalagring. Tänk också på att den fysiska platsen för din S3-hink kan påverka vilka regeringar som lagligt kan tvinga Amazon att släppa dina data (även om sådana händelser är ganska sällsynta).
4
Undersök om replikering över regioner är meningsfull för din hink. Cross-region replikering mellan hinkar i olika regioner synkroniserar automatiskt uppdateringar till data i en hink med data i andra hinkar. Ändringen kanske inte sker omedelbart och särskilt stora filändringar begränsas av bandbreddsbegränsningar mellan regioner. Tänk på följande fördelar och nackdelar med replikering över regioner.
- Du betalar mer i S3-lagringskostnader, eftersom samma data speglas i flera regioner.
- Du betalar i S3 <-> S3 dataöverföringskostnader. Om data läses eller skrivs av EC2-instanser i flera regioner kan detta dock kompenseras av besparingar i S3 -> EC2-dataöverföringskostnaderna. Det främsta sättet detta kan hjälpa till är om du laddar samma S3-data till EC2-instanser i många olika regioner. Antag till exempel att du har 100 instanser vardera i USA: s öst och USA väst där du måste ladda samma data från en S3-hink i USA-väst. Om du inte replikerar den här skopan i USA-öst betalar du för överföringskostnaden för de 100 dataöverföringarna från S3-skopan till USA-östmaskinerna. Om du replikerar skopan i USA öst betalar du bara en gång för dataöverföringskostnaderna.
- Cross-region replikering är således mycket meningsfullt för körbara filer, skript och relativt statisk data, där du värdesätter gränsöverskridande redundans, där uppdateringar av data är sällsynta och där det mesta av dataöverföringen sker i S3 -> EC2 riktning. En annan fördel är att om dessa data replikeras över regioner är det mycket snabbare att snurra upp nya instanser, vilket möjliggör mer flexibla EC2-instansarkitekturer.
- För loggningsapplikationer (där data läses av många frontendinstanser och måste loggas på en central plats i S3) är det bättre att använda en tjänst som Kinesis för att samla dataströmmar över regioner istället för att använda replikerade S3-hinkar över regioner.
- Om du använder S3 för live-servering av statiska bilder på en webbplats, kan replikering över regioner vara vettigt om din webbtrafik är global och snabb laddning av bilder är viktigt.
5
Om du synkroniserar regelbundna uppdateringar till redan befintliga filer, välj en mappstruktur som tillåter användning av AWS clis synkroniseringsfunktion.
- Kommandot "aws s3 sync" beter sig som rsync, men kan bara köras på en mappsnivå. Håll därför din mappstruktur så att du kan använda det här kommandot.
6
Tänk på följande heuristik för att uppskatta överföringskostnader.
- För en statisk webbplats som levererar live är månatlig dataöverföring, utan CDN, lika med den totala trafiktidstorleken för varje besökt sida (inklusive bilder och andra resurser som laddas på sidan). Till exempel, för en miljon sidvisningar och en genomsnittlig sidstorlek på 100 kB, är den totala datan ut 100 GB och kostar 6,70€ per månad.
- För en live-serverande statisk webbplats bakom en CDN, inför CDN en övre gräns för den totala dataöverföringen. Specifikt, om du inte uppdaterar data alls så att CDN serverar sin egen cache, begränsas den totala dataöverföringen ut av produkten av din webbplats totala storlek och antalet kantplatser för CDN, oavsett trafik volym. Om din webbplats till exempel har totalt 1000 sidor om 100 kB vardera, är den totala storleken 100 MB. Om det finns 100 kantplatser ger det en total dataöverföringsgräns på 10 GB per månad eller en kostnadsgräns på 90 cent per månad. Men om du uppdaterar några av filerna måste du räkna varje fil igen efter varje uppdatering.
- I vilken utsträckning CDN-filer sparar i förhållande till att du inte har något CDN beror på mångfalden av tillgång till ditt innehåll och även på den geografiska spridningen av åtkomst. Om ditt innehåll nås i en geografisk region sparar du mer. Om människor får åtkomst till ett litet antal sidor på din webbplats kommer du att spara mer. Om människor inom varje region har åtkomst till ett litet antal sidor på din webbplats (även om sidorna skiljer sig åt efter region) kommer du att spara mer. CDN-besparingar kan variera från 50% till 99%.

Läs också: Hur säljer jag spel på Amazon?

Del 5 av 6: Optimering av kostnad på grund av begäran om prissättning

1

Om prissättning av begäran är ett viktigt problem, förvara dina data i standardlagring. Se del 3, steg 5 för mer information.
2

Om du live-serverar en statisk webbplats eller statiska bilder eller video via s3, placera den bakom en CDN. Detta beror på samma skäl som de som diskuteras i del 4, steg 1.
3
Om du använder s3 som ett datalager för nyckelvärdesuppslag måste du byta ut PUT-begärandeprissättning mot dataöverföringsprissättning när du bestämmer storleken på de filer du behöver dela dina data i.
- Om du delar upp data i ett stort antal små filer, måste du ett stort antal PUT för att infoga data, men varje sökning är snabbare och använder mindre dataöverföring eftersom du måste läsa en mindre fil från S3.
- Å andra sidan, om du delar upp data i ett litet antal stora filer, behöver du ett litet antal PUT: er, men varje åtkomst kostar mycket i dataöverföringskostnader (eftersom du behöver läsa en stor fil).
- Avvägningen sker vanligtvis någonstans i mitten. Matematiskt är antalet filer du ska använda kvadratroten av förhållandet mellan en kostnadsterm för dataöverföring och en PUT-kostnad.
4

I allmänhet är det bättre att använda ett mindre antal medelstora filer för en datasjö.
5
Om du delar upp data över filer, använd ett litet antal medelstora filer (någonstans mellan 1 MB och 100 MB) för att minimera begäran om prissättning och överbelastning.
- Ett mindre antal större filer minskar antalet förfrågningar som behövs för att hämta och läsa in data samt för att skriva data.
- Eftersom det finns en liten fördröjning associerad med varje fil som läses kommer distribuerade dataprocesser (som Hadoop-baserade eller Apache Spark-baserade processer) som läser filer i allmänhet att gå snabbare med ett litet antal medelstora filer än med en stor antal små filer.
- Ju färre ditt totala antal filer, desto billigare är det att köra frågor som försöker matcha godtyckliga reguljära uttryck.
- En viktig varning är att den naturliga utgångstypen i många fall är ett stort antal små filer. Detta gäller för utdata från distribuerade databehandlingsbelastningar, där varje nod i klustret beräknar och matar ut en liten fil. Det är också sant om data skrivs ut i realtid och vi vill skriva ut data inom ett kort tidsintervall. Om du förväntar dig att läsa och bearbeta dessa data upprepade gånger kan du överväga att sammanföra data till större filer. För data som kommer in i realtid, överväg också att använda streamingtjänster som Kinesis för att samla in data innan du skriver ut det till S3.
6

Om du ser stora oväntade förfrågningskostnader, leta efter oseriösa processer som gör regex-matchning. Se till att någon regex-matchning använder jokertecken så nära slutet av filen som möjligt.
7
Tänk på följande heuristik för förfrågningskostnader.
- Begäran kostar bör vara mellan 0% och 20% av lagringskostnaderna. Om de är högre, överväga om du använder rätt lagringsklass, skärpa data i rätt storlekar eller göra onödiga eller ineffektiva åtgärder. Kontrollera också om onödiga livscykelövergångar liksom oseriösa regex-matchningsprocesser.
- Begäran kostar bör vara lägre än överföringskostnaderna om dina data primärt skickas till utanför AWS (om dina data skickas inom samma AWS-region bör det inte finnas några dataöverföringskostnader, så detta gäller inte, eftersom begäran kostar positiva medan överföringskostnaderna blir noll).

På hög nivå kanske du vill rapportera en fördelning av dina kostnader mellan lagring, överföring och begäran om prissättning.

Del 6 av 6: övervakning och felsökning

1
Ställ in övervakning för dina s3-kostnader.
- Ditt AWS-konto har tillgång till faktureringsuppgifterna som ger en fullständig fördelning av kostnaderna. Ställ in en faktureringsvarning så att data börjar skickas till Amazon CloudWatch. Du kan sedan ställa in fler varningar med CloudWatch. CloudWatch-data kommer in som datapunkter varannan timme, men inkluderar inte en detaljerad uppdelning över alla dimensioner av intresse.
- När som helst kan du ladda ner detaljerad uppdelning per timme och servicetyp från ditt root-konto. Dessa data är vanligtvis 24-48 timmar försenade, dvs. du kommer inte att se information för de senaste 24-48 timmarna. För S3 kan du ladda ner data i ett kalkylblad eller CSV-format med uppdelning per timme, hink, region och operationstyp (GET, POST, LIST, PUT, DELETE, HEADOBJECT eller vad du än gör)
2
Skriv skript för att ge lättlästa dagliga rapporter om dina kostnader fördelade på olika sätt.
- På hög nivå kanske du vill rapportera en fördelning av dina kostnader mellan lagring, överföring och begäran om prissättning.
- Inom vart och ett av dessa kanske du vill fördela kostnaderna ytterligare baserat på lagringsklassen (Standard, RRS, IA och Glacier).
- Inom begäran om prissättning kanske du vill fördela kostnaderna efter operationstyp (GET, POST, LIST, PUT, DELETE, HEADOBJECT eller vad din verksamhet är)
- Du kan också ge en uppdelning per hink.
- Som en allmän regel måste du bestämma antalet dimensioner du borrar ner genom att byta ut lätt förståelse mot tillräcklig granularitet. En generellt bra kompromiss är att inkludera drilldowns längs en dimension åt gången (t.ex. en drilldown per bucket, en drilldown efter lagring kontra överföring vs begäran prissättning, en drilldown efter lagringsklass) i din dagliga rapport, och bara gå ner ytterligare om något verkar ovanligt.
3
Bygg en förväntad kostnadsmodell och använd ditt skript för att identifiera avvikelser mellan faktiska kostnader och din modell.
- Utan en modell av vad kostnaderna ska vara är det svårt att ta en titt på kostnaderna och veta om de är fel.
- Processen med att bygga en kostnadsmodell är en bra övning för att tydligt formulera din arkitektur och eventuellt tänka på förbättringar även utan att titta på mönstret för de faktiska kostnaderna.
4
Felsöka höga kostnader.
- Om den skyldige är lagringskostnader, se del 3.
- Om den skyldige är enorma dataöverföringskostnader, se del 4.
- Om den skyldige är begäran om prissättning, se del 5.

De huvudsakliga kostnaderna för att betjäna en levande webbplats är begäran om prissättning och överföringskostnader.

Tips

Håll koll på dina Amazon S3-kostnader. Du kan inte optimera det du inte mäter. En av de största fördelarna med S3 är att du inte behöver tänka för hårt på fillagring: du har effektivt obegränsat fillagring som inte är knuten till en viss instans. Detta erbjuder mycket flexibilitet, men å andra sidan betyder det också att du kan tappa koll på hur mycket data du använder och hur mycket det kostar dig. Du bör regelbundet granska dina S3-kostnader och också ställa in AWS-faktureringsvarningar i Amazon CloudWatch för att varna dig när S3-kostnader för en viss månad överskrider en tröskel.
Använd inte Amazon S3 för operationer som kräver latenser på under en sekund. Du kan använda S3 för att initiera instanser som kör sådana operationer eller för periodisk uppdatering av data och konfigurationer på dessa instanser, men lita inte på S3-fil-GET för operationer där du behöver svara inom millisekunder. Om du använder S3 för loggning, buffra aktiviteterna lokalt på din frontend-instans (eller skriv dem till en ström som Kinesis) och logga dem sedan regelbundet till S3.
Använd inte S3 för applikationer som involverar frekvent läsning och skrivning av data. Amazon S3 passar mer för dataloggning på medellång och lång sikt än som en plats att lagra och snabbt uppdatera och slå upp data. Överväg att använda databaser (och andra datalagrar) för att snabbt uppdatera data. En viktig sak att komma ihåg med S3 är att omedelbar läs- / skrivkonsistens inte garanteras: det kan ta några sekunder efter en skrivning innan läsningen hämtar den nyskrivna filen. Dessutom kommer du också att se en enorm räkning om du försöker använda den på det här sättet, eftersom priset på begäran blir ganska högt om du använder S3 på det här sättet.