Hvordan bygge en sikker og pålitelig AWS-skyarkitektur uten å miste forstanden

Intro

Hvis du noen gang har prøvd å designe en skyarkitektur i AWS fra bunnen av, vet du det sikkert allerede: Det er like deler frihet og kaos. Det finnes tusen måter å bygge noe på, og like mange måter å ødelegge det på.

En kort titt på AWS-manualen kan få deg til å tenke: "Kult, vi skal bare følge førsteklasses praksis." Men i virkelige internasjonale miljøer lever ikke førsteklasses praksis ofte ved første berøring med reelle kommersielle bedriftsbehov, prisklassebegrensninger eller menneskelige feil. Derfor kan det å samarbeide med fagpersoner som perfsys på et tidlig tidspunkt forhindre at man spiller whack-a-mole med beskyttelseshull og skaleringskomplikasjoner senere.

Målet er ikke bare å få noe som kjører. Det er å bygge et system som ikke faller sammen når trafikken øker eller en region forsvinner - og som ikke lar inngangsdøren stå vidåpen for internett.

La oss begynne med det åpenbare: AWS er et beist

Du kan bygge praktisk talt hva som helst med AWS. Alt fra oppstartsbedrifter med to personer til omfattende bedriftsplattformer - alle byggesteinene er der - EC2, Lambda, RDS, S3, IAM, VPC-er, og listen fortsetter. Haken? Jo flere alternativer du har, desto lettere er det å skape et uoversiktlig rot.

Det er ikke det at AWS er dårlig designet. Det er bare det at du må utforme det på riktig måte. Ellers ender du opp med det noen team kaller "skyspagetti": tjenester som er avhengige av hverandre, hardkodede hemmeligheter, ingen merking, ingen logging og absolutt ingen anelse om hva som koster hvor mye.

Pålitelighet og sikkerhet er ikke noe som er fint å ha

Det er fristende å se på sikkerhet og pålitelighet som et fremtidig problem. "Vi skal sikre det etter at vi går live." "Vi legger til overvåking i neste sprint." Men spør alle som har opplevd et datainnbrudd eller et flere timer langt strømbrudd - det er ved å hoppe over disse stegene at du ender opp med å jobbe hele natten.

Hva pålitelighet egentlig betyr

Dette handler ikke om oppetidsgarantier på en lysbildeserie. Det handler om å planlegge for feil. Tjenester går ned. Disker svikter. API-er får timeout. Det som betyr noe, er om systemet ditt fortsetter å fungere når ting går i stykker.

Har du redundans på tvers av tilgjengelighetssoner? Tåler systemet en mislykket databasenode uten å miste data eller gi feilmeldinger? Kjører du kritiske arbeidsbelastninger i én enkelt region fordi "det var det som var enklest å distribuere"? Dette er spørsmålene som skiller fungerende systemer fra robuste systemer.

Og sikkerhet? Det handler ikke bare om IAM

Ja, Identity and Access Management (IAM) er den første muren. Men sikkerhet er mye mer enn det. Offentlig tilgjengelige S3-bøtter. Roller med for mange rettigheter. Hemmeligheter hardkodet inn i Lambda-funksjoner. Logging er slått av "for å spare kostnader". Alt dette er tidsinnstilte bomber.

Ved å bruke aws well architected-rammeverket kan du identifisere disse problemene før de eksploderer. Rammeverket deler arkitekturen inn i fem nøkkelområder - sikkerhet, pålitelighet, driftseffektivitet, ytelseseffektivitet og kostnadsoptimalisering - og tvinger teamene til å evaluere hvert enkelt område på en ærlig måte. Det er ingen patentløsning, men det tvinger deg til å stille vanskelige spørsmål.

Byggesteinene som faktisk betyr noe

La oss gå til saken. Her er det som betyr noe når du skal bygge en sikker og pålitelig arkitektur på AWS - og hvor teamene oftest gjør feil.

Bruk IAM-roller på riktig måte (ja, virkelig)

IAM-roller er mektige. Noen ganger for mektige. Det er altfor enkelt å gi administratortilgang fordi noe ikke fungerer, love å fikse det senere ... og så aldri fikse det.

Du må låse dette ned tidlig. Prinsippet om minste privilegium er ikke bare en beste praksis - det er den eneste fornuftige måten å operere på. Det betyr at det er den eneste fornuftige måten å jobbe på:

• Avgrensede roller per tjeneste

• Unngå jokertegn i tillatelser

• Kortvarig legitimasjon

• Obligatorisk MFA for menneskelige brukere

Høres det vanskelig ut? Det er det også. Men det er det også å forklare sjefen din hvorfor noen har exfiltrert kundedata fra en feilkonfigurert Lambda.

Separer nettverket ditt som om du mener det

Dette er et annet område der snarveier slår tilbake. Du trenger ikke et superkomplekst nettverksoppsett, men du kommer langt med noen grunnleggende ting:

• Offentlige undernett kun for ting som må vende ut mot internett (f.eks. ALB-er)

• Private undernett for alt annet

• NAT-gatewayer for kontrollert utgående tilgang

• VPC-endepunkter for AWS-tjenestetrafikk uten å treffe det offentlige Internett

En flat VPC med alt på samme subnett kan føles enkelt. Helt til noe går i stykker og tar alt med seg.

Logging og overvåking: Du kan ikke fikse det du ikke kan se

Dette burde ikke engang være oppe til debatt lenger. Logging er ikke valgfritt. Hvis du ikke registrerer CloudTrail, CloudWatch-beregninger og VPC-strømningslogger, flyr du i blinde.

Men her er haken - logging alene er ikke nok. Du må faktisk se på loggene. Opprett varsler for det som betyr noe. Filtrer bort støyen. Og sørg for at loggene er sentralisert på tvers av kontoer og regioner. Fragmentert innsyn er ikke innsyn.

Krypter alt (uten unntak)

Bruk KMS for data i hvile. Bruk TLS for data i transitt. Roter nøkler. Overvåk tilgangen. Dette er et av de områdene der det å være lat nå blir veldig dyrt senere.

Og ikke glem ting som RDS-kryptering, EBS-voluminnstillinger og API Gateway TLS-håndhevelse. Disse små detaljene utgjør en stor sum.

Infrastruktur som kode eller ikke

Distribuerer du fortsatt ved å klikke deg rundt i AWS-konsollen? Det er greit for dev, men farlig for prod.

Bruk Terraform, CloudFormation eller CDK. Uansett hva teamet ditt foretrekker - bare velg en og hold deg til den. Versjonsstyr malene dine. Bruk CI/CD til å distribuere. Automatiser tilbakeføringer. Manuelle distribusjoner er en åpen invitasjon til feil.

Og: merk alt. Ressurser uten tagger er som kabler uten merkelapper - ingen vet hva de er til, og alle er redde for å røre dem.

Skalering uten å synke

La oss gjøre det klart: AWS elsker når du overprovisionerer. Du får "ytelse", og de får pengene dine. Effektiv skalering handler om å kjenne mønstrene dine - og planlegge for dem.

Bruk grupper for automatisk skalering, spot-instanser (med omhu) og caching-lag. Men enda viktigere: test under belastning. Det siste du ønsker, er å oppdage at RDS-instansen din smelter under reell trafikk to dager etter lansering.

Reserver også kapasitet når det er fornuftig. Det sparer penger og forhindrer overraskende feil i klargjøringen.

Planer for katastrofegjenoppretting er ikke valgfritt

Hva skjer hvis en region går ned? Hva om den primære databasen blir ødelagt? Hvis svaret er "eh ... da er vi i trøbbel", er det på tide å omarbeide DR-strategien.

Dette betyr ikke at du må bygge en identisk kopi av infrastrukturen i en annen region. Det betyr å vite:

• Hva du vil gjenopprette

• Hvor lang tid det vil ta

• Hvilke data vil gå tapt (hvis noen)

• Hvem er ansvarlig for hva under en failover

Og ja - du bør teste gjenopprettingsplanen din. Ellers er den bare oppdiktet.

Vanlige antimønstre du bør unngå

La oss raskt ta for oss noen av de vanligste feilene som dukker opp altfor ofte:

• Én stor konto for alt: Bruk AWS Organizations. Separat prod, dev, staging osv.

• La standard VPC-er og sikkerhetsgrupper være urørt: lås dem ned.

• Overdreven bruk av t2.micro-instanser "for testing" - de vil ende opp i prod til slutt.

• Ikke budsjettere for CloudWatch-kostnader: Ja, logging koster penger. Å ikke logge koster mer.

• Gir tilgang til "bare fiks det raskt": fiks prosessen din i stedet.

Sluttord? Vær fleksibel, hold hodet kaldt

Skyarkitektur handler ikke om å finne det perfekte oppsettet. Det handler om å bygge noe som er fleksibelt, robust og forståelig for flere enn bare den som har skrevet det.

Du blir aldri helt "ferdig" - og det er helt greit. Det som betyr noe, er å være bevisst. Stille vanskelige spørsmål tidlig. Gjennomføre hyppige revisjoner. Automatisere der det teller. Og å vite når du skal tilkalle hjelp.

For la oss være ærlige - AWS er mektig, men det er også lett å gå seg vill i det. Å samarbeide med erfarne ingeniører som lever og ånder for skyarkitektur, kan utgjøre forskjellen mellom "det fungerer stort sett" og "vi sover om natten".

Og det er verdt å bygge for.