# AWS ## Vad det är AWS, förkortning för Amazon Web Services, är Amazons verksamhet med att hyra ut datorkraft per timme och per gigabyte: virtuella servrar, lagring av filer, hanterade databaser, privata nätverk, köer och en lång katalog med ytterligare tjänster, som alla slås på via ett och samma API och faktureras till ett och samma konto. Amazon har sålt det sedan 2006. Två av de mest kända tjänsterna förklarar mycket av resten. Amazon EC2 hyr ut virtuella maskiner, som AWS kallar instanser, och Amazon S3 lagrar filer som objekt i behållare som kallas buckets. Med ordförrådet i NIST:s definition är AWS ett publikt moln: vem som helst med ett betalkort kan öppna ett konto, resurser dyker upp inom några minuter, och varje sekund eller gigabyte som används mäts. Det vägs oftast mot Microsofts Azure och Google Cloud, som säljer ungefär samma byggstenar under andra namn. Det som AWS kallar en EC2-instans är en virtuell maskin i Azure eller en Compute Engine-instans i Google Cloud. Varje resurs i AWS finns på en bestämd plats. Tjänsten är indelad i regioner (Regions), var och en utformad för att vara isolerad från de andra, och varje region rymmer flera tillgänglighetszoner (Availability Zones). En zon är ett eller flera separata datacenter med redundant strömförsörjning, nätverk och anslutningar, fysiskt åtskilda från de andra zonerna i samma region. En resurs skapas i en region, ofta i en enda zon, och ett team väljer plats med latens, lagstiftning och pris i åtanke. Åtkomsten till allt detta går genom AWS Identity and Access Management, eller IAM. Ett konto börjar med en rotanvändare som kan göra vad som helst, och IAM lägger till användare, grupper, roller och policyer som anger vilket API-anrop som är tillåtet på vilken resurs och under vilka villkor. De flesta frågor om säkerheten i AWS visar sig vara frågor om de policyerna. ## Varför det spelar roll Team väljer AWS för bredden. En produkt som behöver en hanterad PostgreSQL, en kö, ett CDN, objektlagring och någonstans att köra containrar kan få allt detta på en faktura och i ett identitetssystem, dokumenterat efter ett gemensamt mönster. Bredden är också priset. Varje tjänst har sina egna prisdimensioner, sina egna gränser och sitt eget hörn av IAM:s policyspråk, och ett team som tar tio tjänster i bruk underhåller därmed tio små integrationer med Amazons gränssnitt. Att lämna senare innebär att ersätta var och en av dem. Det andra beslutet gäller vad som stannar hos kunden. AWS publicerar en modell för delat ansvar och drar gränsen med två uttryck: AWS ansvarar för säkerheten ”för” molnet, alltså den hårdvara, mjukvara, de nätverk och de anläggningar som kör tjänsterna, och kunden för säkerheten ”i” molnet. Var gränsen hamnar beror på tjänsten. På en EC2-instans patchar kunden gästens operativsystem, sköter varje program som är installerat på den och konfigurerar säkerhetsgruppen, den brandvägg som står framför instansen. På S3 eller DynamoDB kör AWS operativsystemet och plattformen, och kunden blir kvar med datan, dess alternativ för kryptering och de behörigheter som avgör vem som får läsa den. Det tredje är kostnaden, som i AWS är en egenskap hos designen mer än en faktura som kommer senare. Amazons Well-Architected Framework namnger sex pelare som en arbetslast granskas mot: operativ förträfflighet, säkerhet, tillförlitlighet, prestandaeffektivitet, kostnadsoptimering och hållbarhet. Kostnaden förtjänar sin plats på listan eftersom samma system kan byggas billigt eller dyrt genom val som görs den första veckan: instansstorlekar, hur många zoner, hur mycket data som lämnar regionen och vilka hanterade tjänster som ersätter en process på en vanlig server. ## Så ser det ut i praktiken På [sidan om teknikstacken](/sv/tech-stack/) står AWS bredvid Google Cloud som ett av de två moln som företaget arbetar i som standard, med Azure där kunden redan finns. Ett uppdrag använde båda de molnen samtidigt: [tjugo Docker-applikationer kördes i Google Cloud och AWS](/sv/portfolio/deployed-and-maintained-20-docker-containerized-applications-troubleshooting-19/), några av dem R-baserade analysappar. I rollen som DevOps-ingenjör mellan 2022 och 2024 driftsattes och underhölls de med samma konfiguration och övervakning i båda molnen, så att ingen app blev ett specialfall för sig. När något gick fel skedde felsökningen med Podman och felsökningen av orkestreringen med Kubernetes, och analysapparna hölls stabila och reproducerbara i produktion på båda sidor. Ett annat uppdrag gick åt motsatt håll. För en internationell kund hade [en AWS-miljö överdimensionerats och samlat på sig tjänster som ingen använde](/sv/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/), och den månatliga fakturan hade glidit långt ur proportion till vad verksamheten behövde. Arbetet började med en granskning av vad som faktiskt kördes, vilket är där dubblerade och onödiga tjänster visar sig, och de togs bort. Det som var kvar dimensionerades efter verklig efterfrågan i stället för efter de gissningar på värsta tänkbara fall som miljön hade byggts på. Sedan flyttades arbetslasterna bort från AWS helt och hållet, till en mer kostnadseffektiv hostinglösning, i etapper så att verksamheten fortsatte att fungera hela tiden. Kostnaderna sjönk ungefär tiofalt, utan någon förlust i produktivitet. Båda fallen kokar ned till samma vana. En tjänst som tar betalt per användning fakturerar allt som har slagits på, så en AWS-miljö förblir frisk när någon fortsätter att jämföra det som körs med det som verksamheten faktiskt använder. ## Var det går fel AWS förlorar sällan data eller ligger nere länge. De dyra incidenterna brukar börja inne i kundens eget konto. **Rotanvändaren gör det dagliga arbetet.** Varje konto börjar med en rotanvändare, den e-postadress och det lösenord som öppnade kontot, med obegränsad åtkomst till varje resurs och inställning, inklusive möjligheten att stänga kontot. Att logga in som root för rutinuppgifter innebär att ett enda läckt lösenord når allt. AWS:s råd är att skydda rotanvändarens inloggningsuppgifter, sätta multifaktorautentisering på dem och spara dem till de få uppgifter som kräver dem, medan det dagliga arbetet sker via federerad inloggning och roller. **Långlivade åtkomstnycklar läcker.** Ett nyckelpar för åtkomst fungerar tills någon raderar det, och det färdas lätt: in i dotfilerna på en bärbar dator, en CI-variabel, en containeravbildning, en commit. IAM:s lista över bästa praxis börjar från andra hållet. Människor loggar in via en identitetsleverantör och får tillfälliga inloggningsuppgifter, och arbetslaster tar tillfälliga inloggningsuppgifter från en IAM-roll som är kopplad till den beräkningsresurs de körs på. Där en långlivad nyckel verkligen behövs, rotera den, och ta bort nycklar, användare och roller som inte längre används. **Ett budgetlarm tas för en broms.** AWS Budgets skickar en avisering när faktiska eller prognostiserade kostnader passerar ett tröskelvärde, och dess siffror uppdateras upp till tre gånger per dag, så ett larm rapporterar pengar som redan är spenderade. Resurserna fortsätter att köras och att faktureras. Budgets kan också utföra en åtgärd, t.ex. tillämpa en IAM-policy eller en service control policy som hindrar att nya resurser skapas, eller agera på specifika EC2- eller RDS-instanser. Det sker bara när åtgärden har konfigurerats i förväg, med en roll att agera genom. **Allt ligger i en enda tillgänglighetszon.** En enda instans med en enda disk i en zon är den billigaste uppställningen, och den delar öde med just den platsen. Zoner finns för att ett fel i ström eller nätverk i en zon ska lämna de andra igång, och AWS:s dokumentation rekommenderar att en applikation sprids över flera. En databas som spelar roll får en standby i en andra zon, och ett webblager får instanser i minst två, bakom en lastbalanserare som spänner över båda. **En bucket som öppnades för en demo förblir öppen.** Nya S3-buckets blockerar publik åtkomst som standard, men en bucket-policy eller en behörighet på ett objekt kan ändra det på en minut, och en länk som delades med en kund för en eftermiddag är fortfarande publik ett år senare. S3 Block Public Access, inställt för hela kontot eller organisationen, går före de policyerna. Slå på det överallt där ett konto inte har något skäl att publicera filer, och servera publika filer från en bucket som är byggd för just det. ## Läs mer - [AWS Documentation](https://docs.aws.amazon.com/) — registret över användarguider, API-referenser och handledningar för varje tjänst i AWS. - [Shared responsibility](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html) — säkerhetspelaren i Well-Architected och dess redogörelse för vilka lager AWS säkrar och vilka kunden säkrar. - [The pillars of the framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html) — de sex områden som AWS vill att en arbetslast granskas mot, bl.a. kostnad och tillförlitlighet. - [AWS Regions and Availability Zones](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html) — hur regioner och zoner hålls isolerade, och varför en applikation bör spänna över flera zoner. - [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) — federering, roller, multifaktorautentisering, rotanvändaren och minsta privilegium, i en och samma lista. - [Managing your costs with AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) — budgetar för faktiska och prognostiserade kostnader, deras aviseringar och de åtgärder de kan köra.