# AWS ## Hva det er AWS, kort for Amazon Web Services, er Amazons virksomhet med å leie ut datakraft per time og per gigabyte: virtuelle servere, fillagring, administrerte databaser, private nettverk, køer og en lang katalog med andre tjenester, alt slått på gjennom ett API og fakturert til én konto. Amazon har solgt det siden 2006. To av de best kjente tjenestene forklarer mye av resten. Amazon EC2 leier ut virtuelle maskiner, som AWS kaller instanser, og Amazon S3 lagrer filer som objekter i beholdere som kalles bøtter (buckets). Med ordene i NISTs definisjon er AWS en offentlig sky: alle med et betalingskort kan åpne en konto, ressursene er på plass i løpet av minutter, og hvert sekund eller hver gigabyte som brukes, blir målt. Den veies som regel opp mot Microsofts Azure og Google Cloud, som selger omtrent de samme byggeklossene under andre navn. Det AWS kaller en EC2-instans, er en virtuell maskin i Azure eller en Compute Engine-instans i Google Cloud. Hver ressurs i AWS befinner seg et bestemt sted. Tjenesten er delt inn i regioner, som hver er laget for å være isolert fra de andre, og hver region har flere tilgjengelighetssoner (Availability Zones). En sone er ett eller flere separate datasentre med redundant strøm, nettverk og tilkobling, fysisk atskilt fra de andre sonene i regionen. En ressurs opprettes i én region, ofte i én enkelt sone, og et team velger stedet ut fra latens, lovverk og pris. All tilgang går gjennom AWS Identity and Access Management, eller IAM. En konto starter med en rotbruker som kan gjøre alt, og IAM legger til brukere, grupper, roller og policyer som sier hvilket API-kall som er tillatt på hvilken ressurs og under hvilke betingelser. De fleste spørsmål om sikkerhet i AWS viser seg å være spørsmål om de policyene. ## Hvorfor det er viktig Team velger AWS for bredden. Et produkt som trenger en administrert PostgreSQL, en kø, et CDN, objektlagring og et sted å kjøre containere, kan få alt dette på én regning og i ett identitetssystem, dokumentert etter et felles mønster. Bredden er også prisen. Hver tjeneste har sine egne prisdimensjoner, sine egne grenser og sitt eget hjørne av policyspråket i IAM, og et team som tar i bruk ti tjenester, vedlikeholder nå ti små integrasjoner mot Amazons grensesnitt. Å gå ut senere betyr å erstatte hver av dem. Den andre beslutningen er hva som blir liggende hos kunden. AWS publiserer en modell for delt ansvar og trekker grensen med to uttrykk: AWS har ansvaret for sikkerheten «av» skyen, altså maskinvaren, programvaren, nettverket og anleggene som kjører tjenestene, og kunden for sikkerheten «i» skyen. Hvor grensen går, avhenger av tjenesten. På en EC2-instans oppdaterer kunden gjesteoperativsystemet, tar seg av hvert program som er installert på det, og konfigurerer sikkerhetsgruppen, brannmuren foran instansen. På S3 eller DynamoDB driver AWS operativsystemet og plattformen, og kunden sitter igjen med dataene, valgene for kryptering og tillatelsene som avgjør hvem som kan lese dem. Den tredje er kostnad, som i AWS er en egenskap ved designet mer enn en faktura som kommer senere. Amazons Well-Architected Framework nevner seks søyler en arbeidslast skal vurderes etter: operasjonell fortreffelighet, sikkerhet, pålitelighet, ytelseseffektivitet, kostnadsoptimalisering og bærekraft. Kostnad fortjener plassen på den listen fordi det samme systemet kan bygges billig eller dyrt gjennom valg som tas den første uka: størrelsen på instansene, hvor mange soner, hvor mye data som forlater regionen, og hvilke administrerte tjenester som tar over for en prosess på en vanlig server. ## Slik ser det ut i praksis På [siden om teknologiene](/nb/tech-stack/) står AWS ved siden av Google Cloud som én av de to skyene selskapet jobber i som standard, med Azure lagt til der en kunde allerede holder til. Ett oppdrag brukte begge de skyene samtidig: [tjue Docker-applikasjoner kjørte på tvers av Google Cloud og AWS](/nb/portfolio/deployed-and-maintained-20-docker-containerized-applications-troubleshooting-19/), noen av dem R-baserte analyseapper. De ble satt i produksjon og vedlikeholdt med den samme konfigurasjonen og overvåkingen i hver sky, slik at ingen app ble et eget spesialtilfelle. Når noe gikk galt, gikk feilsøkingen gjennom Podman og feilsøkingen av orkestreringen gjennom Kubernetes, og analyseappene ble holdt stabile og reproduserbare i produksjon på begge sider. Et annet oppdrag gikk motsatt vei. For en internasjonal kunde [var et AWS-oppsett blitt overdimensjonert og hadde samlet opp tjenester ingen brukte](/nb/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/), og månedsregningen hadde glidd langt ut av proporsjon med det virksomheten trengte. Arbeidet begynte med en kartlegging av hva som faktisk kjørte, for det er der de dupliserte og unødvendige tjenestene viser seg, og de ble kuttet. Det som var igjen, ble dimensjonert etter den reelle etterspørselen i stedet for anslagene for verste fall som oppsettet var bygd på. Deretter ble arbeidslastene flyttet helt bort fra AWS, over til en mer kostnadseffektiv hostingløsning, i etapper slik at virksomheten gikk som normalt hele veien. Kostnadene falt til omtrent en tidel, uten noe tap i produktivitet. Begge tilfellene koker ned til den samme vanen. En tjeneste med betaling etter bruk fakturerer for alt som er slått på, så et AWS-miljø holder seg sunt når noen fortsetter å sammenligne det som kjører, med det virksomheten faktisk bruker. ## Hvor det går galt AWS mister sjelden data eller blir liggende nede lenge. De dyre hendelsene starter som regel inne i kundens egen konto. **Rotbrukeren gjør dagens arbeid.** Hver konto begynner med en rotbruker, e-postadressen og passordet som åpnet den, med ubegrenset tilgang til hver ressurs og innstilling, også til å stenge kontoen. Å logge inn som rot for rutineoppgaver betyr at ett lekket passord når alt. AWS anbefaler å sikre rotbrukerens påloggingsinformasjon, legge flerfaktorautentisering på den og spare den til den lille håndfullen oppgaver som krever den, mens det daglige arbeidet skjer gjennom føderert pålogging og roller. **Langvarige tilgangsnøkler lekker.** Et nøkkelpar for tilgang virker til noen sletter det, og det reiser godt: inn i dotfilene på en bærbar maskin, en CI-variabel, et containerbilde, en commit. Listen over beste praksis for IAM starter fra den andre enden. Folk logger inn gjennom en identitetsleverandør og får midlertidig påloggingsinformasjon, og arbeidslaster henter midlertidig påloggingsinformasjon fra en IAM-rolle knyttet til maskinene de kjører på. Der en langvarig nøkkel virkelig trengs, bør den roteres, og nøkler, brukere og roller som ikke har vært i bruk, bør fjernes. **Et budsjettvarsel blir tatt for en brems.** AWS Budgets sender et varsel når faktisk eller anslått forbruk krysser en terskel, og tallene oppdateres opptil tre ganger i døgnet, så et varsel melder om penger som allerede er brukt. Ressursene fortsetter å kjøre og fortsetter å koste. Budgets kan også utføre en handling, f.eks. å legge på en IAM-policy eller en service control policy som hindrer at nye ressurser opprettes, eller å gjøre noe med bestemte EC2- eller RDS-instanser. Det skjer bare når handlingen er satt opp på forhånd, med en rolle å handle gjennom. **Alt ligger i én tilgjengelighetssone.** Én instans med én disk i én sone er det billigste oppsettet, og det deler skjebne med det ene stedet. Soner finnes for at en feil i strøm eller nettverk i én skal la de andre kjøre videre, og dokumentasjonen fra AWS anbefaler å spre en applikasjon over flere. En database som betyr noe, får en reserve i en annen sone, og et webnivå får instanser i minst to, bak en lastbalanserer som spenner over begge. **En bøtte som ble åpnet for en demo, blir stående åpen.** Nye S3-bøtter blokkerer offentlig tilgang som standard, men en bøttepolicy eller en tillatelse på et objekt kan endre det på et minutt, og en lenke som ble delt med en kunde for én ettermiddag, er fortsatt offentlig et år senere. S3 Block Public Access, satt for hele kontoen eller organisasjonen, overstyrer de policyene. Slå det på overalt der en konto ikke har noen grunn til å publisere filer, og server offentlige filer fra en bøtte som er laget for akkurat det. ## Les mer - [AWS Documentation](https://docs.aws.amazon.com/) — oversikten over brukerveiledninger, API-referanser og opplæring for hver tjeneste i AWS. - [Shared responsibility](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html) — sikkerhetssøylen i Well-Architected om hvilke lag AWS sikrer, og hvilke kunden sikrer. - [The pillars of the framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html) — de seks områdene AWS vil at en arbeidslast skal vurderes etter, med kostnad og pålitelighet blant dem. - [AWS Regions and Availability Zones](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html) — hvordan regioner og soner er isolert fra hverandre, og hvorfor en applikasjon bør spenne over flere soner. - [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) — føderering, roller, flerfaktorautentisering, rotbrukeren og minste privilegium, i én liste. - [Managing your costs with AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) — budsjetter for faktisk og anslått forbruk, varslene de sender, og handlingene de kan utføre.