Så granskar du AWS Well-Architected Framework: En snabbguide

Många företag dras med i ivern och rusar mot molnet, ivriga att ta del av alla de uppenbara fördelar som utlovas. Det är en guldrush, men många företag går miste om guldet.

Som erfaren ”guldgrävare” vill jag dela med mig av vad du behöver veta om Well-Architected Framework och hur du använder det. När det används rätt är det ett fantastiskt sätt att säkerställa att du får ut mesta möjliga av AWS.

Här är först tre hårda sanningar:

Det är svårt att upprätthålla god säkerhet och samtidigt ge utvecklare och administratörer enkel åtkomst till molnresurser.
Saker går sönder, och om du saknar en väl genomtänkt strategi för säkerhetskopiering av data eller planer för katastrofåterställning kommer hela verksamheten att påverkas när fel oundvikligen uppstår.
Även med en välfungerande teknisk implementation – där tillgänglighet, prestanda och övervakning håller hög nivå – kan månadskostnaden fortfarande vara onödigt hög (häpnadsväckande hög).

Företag av alla slag och storlekar kommer förr eller senare till en punkt där de frågar sig: ”Gör vi verkligen det här på rätt sätt? Finns det ett enklare, bättre eller billigare sätt att driva verksamheten effektivt i molnet?”

För att besvara de här frågorna har AWS sedan 2015 kontinuerligt publicerat och vidareutvecklat sitt ”Well-Architected Framework” – en aktuell och lättöverskådlig sammanställning av beprövade metoder som är kostnadsfritt tillgänglig för alla.

Läs vidare och få veta mer om:

Vad detta ramverk för beprövade metoder är
Varför det är relevant och hur det kan hjälpa dig
Hur du bedömer och genomför de mest relevanta förändringarna för att följa beprövade metoder

Vad detta ramverk för beprövade metoder är

Varför det är relevant och hur det kan hjälpa dig

Hur du bedömer och genomför de mest relevanta förändringarna för att följa beprövade metoder

Låt oss börja med en enkel introduktion till AWS Well-Architected Framework.

Well-Architected Framework

År 2015 publicerade AWS en vitbok med titeln ”AWS Well-Architected Framework”. Syftet var att sammanfatta alla beprövade metoder och arkitekturutmaningar samt besvara de viktigaste frågor som uppstod i takt med att användningen av molntjänster ökade.

De samlade erfarenheterna presenterades i fem pelare (numera sex), med målet att täcka alla arkitekturbeslut och säkerställa bästa möjliga resultat för att köra workloads i molnet.

De sex pelarna definierar en omfattande uppsättning frågor och överväganden med lika stort fokus på den tekniska sidan som på verksamheten.

De sex pelarna är:

Operativ excellens
Säkerhet
Tillförlitlighet
Prestandaeffektivitet
Kostnadsoptimering
Hållbarhet

Operativ excellens

Säkerhet

Tillförlitlighet

Prestandaeffektivitet

Kostnadsoptimering

Hållbarhet

Varje pelare innehåller definitioner, designprinciper och beprövade metoder som hjälper dig att:

Synliggöra de områden där förbättringar skulle ge störst nytta
Driva verksamheten och ta hänsyn till olika delar av din affärsstrategi i förhållande till den tekniska designen och implementeringen

Därför bör du genomföra Well-Architected Reviews

När företag först migrerar till eller driftsätter nya workloads i molnet vill de vanligtvis uppnå flexibilitet och helt enkelt ”komma i gång”.

Tiden då företag behövde investera i hårdvara och infrastruktur i förväg är förbi. Det kunde vara ett stort hinder, särskilt för startups med osäkra framtidsutsikter.

Med molnet kan du enkelt driftsätta och skala infrastrukturen efter behov och betala för det du använder. Och om du behöver pausa verksamheten kan du helt enkelt stänga ner all användning i molnet och sluta betala.

Men för många företag har denna flexibilitet ett pris:

Problemet som ofta uppstår när du väl är i molnet

Det här är vad som ofta händer:

Med molnets flexibilitet kan företag skynda på för att korta tiden till marknaden. Därför genar de ofta i säkerhetsarbetet, driften och andra viktiga områden. Med tiden förvärras problemen. När efterfrågan ökar växer de tekniska lösningarna i både omfattning och komplexitet.

Så löser du problemet bäst med en Well-Architected Review

När dina tekniska lösningar blir allt mer komplexa är det viktigt att så snart som möjligt bygga eller förbättra en stabil grund med beprövade metoder – genom design och styrning. Det gäller särskilt kritiska workloads och operativa rutiner som playbooks och runbooks.

Men tänk på att detta inte är en engångsaktivitet.

Med tiden uppstår konfigurations- och driftsavvikelser. När din Well-Architected Review är klar är det därför viktigt att återkomma till den regelbundet.

AWS rekommenderar också att du genomför en granskning i samband med viktiga milstolpar i utvecklingscykeln och sedan följer goda rutiner för att förhindra att workload-designen försämras. Som tumregel kan detta vara var 12:e till 18:e månad.

Tre främsta skälen att genomföra en Well-Architected Review

Håll dina workloads säkra, tillförlitliga och motståndskraftiga mot fel och driftstopp
Minska kostnaderna, ibland avsevärt, med smarta kostnadsbesparingsplaner eller genom att stänga av resurser under inaktiva timmar
Identifiera förbättringsområden i din drift och dina resursers livscykler för högre prestandaeffektivitet

Håll dina workloads säkra, tillförlitliga och motståndskraftiga mot fel och driftstopp

Minska kostnaderna, ibland avsevärt, med smarta kostnadsbesparingsplaner eller genom att stänga av resurser under inaktiva timmar

Identifiera förbättringsområden i din drift och dina resursers livscykler för högre prestandaeffektivitet

För att få ut full nytta av AWS behöver du ta hänsyn till Well-Architected Framework när du utformar din arkitektur. I nästa avsnitt får du lära dig hur du enkelt tillämpar beprövade metoder med hjälp av ett enkelt verktyg.

Well-Architected Tool

AWS:s ”Well-Architected Tool” är kostnadsfritt tillgängligt via AWS-konsolen och hjälper dig att tillämpa beprövade metoder i Well-Architected Framework.

Verktyget samlar inte in data från de faktiska workloads, utan ger alla involverade parter – arkitekter och kunder/intressenter – en gemensam checklista med beprövade metoder samt anteckningar som sedan kan delas mellan kundens och tjänsteleverantörens AWS-konton, till exempel Eficodes.

Med hjälp av verktyget granskar arkitekten och workloadens ägare workloaden utifrån de sex perspektiven.

Varje perspektiv belyser olika delar av workloaden, ställer frågor ur ett tekniskt perspektiv och undersöker hur den tekniska lösningen stämmer överens med ägarens unika affärsmål och nyckelresultat. Frågorna varierar i komplexitet och alla är inte relevanta. Om en fråga bedöms som irrelevant utesluts den från de sammanställda resultaten och den övergripande poängen i slutet av granskningen.

Slutresultatet lyfter fram problem som klassas från medel- till högrisk. Problem med hög risk bör åtgärdas så snart som möjligt, medan problem med medelrisk kanske inte alls behöver hanteras.

Det här granskar du i en Well-Architected Review: de sex perspektiven

De sex perspektiven utgör grunden för hela granskningen. Du analyserar och diskuterar dem noggrant, ett i taget. Nedan följer en kort introduktion och sammanfattning av perspektiven och de nyckelbegrepp som definierar dem.

1. Operativ excellens

Det krävs alltid någon form av drift, oavsett hur liten workloaden är. Någon måste finnas till hands när något går fel, behöver ändras eller tas bort i slutet av en resurs livscykel. Nyckelordet här är excellens – att driva workloads som en väloljad maskin för att spara tid, frustration och pengar på sikt.

I grunden handlar detta perspektiv om hur du kan utforma ditt operativa arbete för att uppnå bästa möjliga resultat på ett så effektivt sätt som möjligt. Det består av fyra områden med beprövade metoder:

Organisation: Förstå organisationens prioriteringar och struktur, samtidigt som du synliggör hur organisationen stöttar sina teammedlemmar.
Förbered: Förstå dina nuvarande workloads och deras förväntade beteende. Du får insikt i deras status och de processer som stöder dem.
Driv: Synliggör statusen för din workload och din drift. Upptäck också var en specifik workload kan vara utsatt för risk och hur du bör agera.
Utveckla: Se var du kan förbättra och definiera lärdomar från tidigare operativa aktiviteter och deras framgångsgrad för framtida stegvisa förändringar.

Organisation: Förstå organisationens prioriteringar och struktur, samtidigt som du synliggör hur organisationen stöttar sina teammedlemmar.

Förbered: Förstå dina nuvarande workloads och deras förväntade beteende. Du får insikt i deras status och de processer som stöder dem.

Driv: Synliggör statusen för din workload och din drift. Upptäck också var en specifik workload kan vara utsatt för risk och hur du bör agera.

Utveckla: Se var du kan förbättra och definiera tidigare lärdomar från operativa aktiviteter och deras framgångsgrad, för framtida stegvisa förändringar.

Ett exempel på hur din sammanfattning av pelaren Operational Excellence kan se ut

Använd automatisering där det är möjligt.
Gör frekventa, små och reversibla förändringar.
Förfina operativa rutiner ofta.
Lär av alla operativa fel.
Förutse fel.
Lär av alla operativa fel.

2. Säkerhet

Den här pelaren fokuserar på hur du kan dra nytta av den senaste molntekniken för att göra dina workloads säkrare. Säkerhet har historiskt setts som något lite tråkigt, men i dagens läge har den blivit desto viktigare. Pelaren bygger på sätt och vis vidare på operational excellence och handlar om hur du uppnår god operativ hygien och en robust teknisk arkitektur på ett tryggt och säkert sätt.

Säkerhet omfattar sex områden med beprövade metoder:

Grund: Lär dig hur en grund bör byggas för att fungera med dina resurser på säkrast möjliga sätt.
Identitets- och åtkomsthantering: Upptäck hur du skapar ett robust och säkert sätt för användare att få åtkomst till resurser i dina workloads. Den består av:
Upptäckt: Visualisera var potentiella hot, felkonfigurationer och/eller oväntade beteenden kan störa dina workloads.
Infrastrukturskydd: Använd olika metoder enligt beprövad praxis för att hålla din infrastruktur så säker som möjligt. Skydda dina resurser mot säkerhetshot, både oavsiktliga och obehörig åtkomst, och hitta potentiella sårbarheter.
Dataskydd: Visualisera hur du bör kryptera och kategorisera dina data, till exempel med kryptering både i vila och under överföring, samt hur de ska klassificeras.
Incidenthantering: Implementera olika mekanismer för att hantera och begränsa framtida säkerhetsincidenter.

Grund: Lär dig hur en grund bör byggas för att fungera med dina resurser på säkrast möjliga sätt.

Identitets- och åtkomsthantering: Upptäck hur du skapar ett robust och säkert sätt för användare att få åtkomst till resurser i dina workloads. Den består av:

Identitetshantering: Hur du hanterar identiteter för personal och workloads, såsom applikationer, operativa verktyg och komponenter som behöver göra förfrågningar till dina AWS-resurser.
Behörighetshantering: Hur du hanterar säkerhet med policyer, gränser, attributbaserad åtkomstkontroll (ABAC) och Service Control Policies (SCP).

Identitetshantering: Hur du hanterar identiteter för personal och workloads, såsom applikationer, operativa verktyg och komponenter som behöver göra förfrågningar till dina AWS-resurser.

Behörighetshantering: Hur du hanterar säkerhet med policyer, gränser, attributbaserad åtkomstkontroll (ABAC) och Service Control Policies (SCP).

Upptäckt: Visualisera var potentiella hot, felkonfigurationer och/eller oväntade beteenden kan störa dina workloads.

Infrastrukturskydd: Använd olika metoder enligt beprövad praxis för att hålla din infrastruktur så säker som möjligt. Skydda dina resurser mot säkerhetshot, både oavsiktliga och obehörig åtkomst, och hitta potentiella sårbarheter.

Dataskydd: Visualisera hur du bör kryptera och kategorisera dina data (till exempel med kryptering både i vila och under överföring) och hur de ska klassificeras.

Incidenthantering: Implementera olika mekanismer för att hantera och begränsa framtida säkerhetsincidenter.

Ett exempel på hur sammanfattningen av din säkerhetspelare kan se ut

Separera olika arbetsbelastningar efter konto utifrån deras funktion samt krav på regelefterlevnad eller datakänslighet.
Användaråtkomst bör beviljas enligt principen om minsta privilegium och beprövade metoder, inklusive krav på lösenord och obligatorisk MFA.
Det är avgörande att analysera loggar och agera utifrån dem så att du kan identifiera potentiella säkerhetsincidenter. Gränsskydd, övervakning av in- och utgående trafik samt omfattande loggning, övervakning och larm är alla viktiga delar av en effektiv informationssäkerhetsplan.
Se till att du snabbt kan ge ditt säkerhetsteam åtkomst och automatisera isoleringen av instanser samt insamlingen av data och tillstånd för forensisk analys.

3. Tillförlitlighet

Här går du på djupet i arbetsbelastningarna och bedömer om deras avsedda funktioner fungerar som du vill. Är arbetsbelastningen självläkande? Kör du kontinuerligt tester under hela dess livscykel? Uppfyller arbetsbelastningen och data kraven på tillgänglighet och redundans?

Tillförlitlighet fokuserar på fyra områden med beprövade metoder:

Grunder: Se hur du kan bygga en stabil grund som sträcker sig bortom en enskild arbetsbelastning.
Arbetsbelastningsarkitektur: En tillförlitlig arbetsbelastning börjar med tidiga designbeslut för både mjukvara och infrastruktur. Dina arkitekturval påverkar hur arbetsbelastningen fungerar inom alla Well-Architected-pelare. För tillförlitlighet finns det specifika mönster som du måste följa.
Ändringshantering: Beskriv hur du övervakar dina resurser, genomför ändringar och utformar dina arbetsbelastningar så att de är så öppna för förändring som möjligt.
Felhantering: Ta till exempel reda på vad du behöver göra för att göra din arbetsbelastning motståndskraftig, hur du hanterar säkerhetskopiering och testning samt hur du planerar för katastrofåterställning.

Grunder: Se hur du kan bygga en stabil grund som sträcker sig bortom en enskild arbetsbelastning.

Arbetsbelastningsarkitektur: En tillförlitlig arbetsbelastning börjar med tidiga designbeslut för både mjukvara och infrastruktur. Dina arkitekturval påverkar hur arbetsbelastningen fungerar inom alla Well-Architected-pelare. För tillförlitlighet finns det specifika mönster som du måste följa.

Ändringshantering: Beskriv hur du övervakar dina resurser, genomför ändringar och utformar dina arbetsbelastningar så att de är så öppna för förändring som möjligt.

Felhantering: Ta till exempel reda på vad du behöver göra för att göra din arbetsbelastning motståndskraftig, hur du hanterar säkerhetskopiering och testning samt hur du planerar för katastrofåterställning.

Ett exempel på hur sammanfattningen av din tillförlitlighetspelare kan se ut

Utforma en arbetsbelastning så att den automatiskt lägger till och tar bort resurser utifrån efterfrågan. Det ökar inte bara tillförlitligheten, utan säkerställer också att affärsframgång inte blir en belastning.
Med övervakning på plats får ditt team automatiskt varningar när KPI:er avviker från förväntade nivåer.
Automatisk loggning av ändringar i din miljö gör att du kan granska och snabbt identifiera åtgärder som kan ha påverkat tillförlitligheten.
Kontroller för ändringshantering säkerställer att du kan tillämpa de regler som ger dig den tillförlitlighet du behöver.
Säkerhetskopiera dina data regelbundet och testa dina säkerhetskopior för att säkerställa att du kan återhämta dig från både logiska och fysiska fel.
En viktig del av felhantering är att ofta och automatiserat testa arbetsbelastningar genom att orsaka fel och sedan observera hur de återhämtar sig.

Utforma en workload som automatiskt lägger till och tar bort resurser utifrån efterfrågan. Det ökar inte bara tillförlitligheten, utan säkerställer också att affärsframgång inte blir en belastning.

Med övervakning på plats får ditt team automatiskt varningar när KPI:er avviker från förväntade nivåer.

Automatisk loggning av förändringar i din miljö gör att du kan granska och snabbt identifiera åtgärder som kan ha påverkat tillförlitligheten.

Kontroller för förändringshantering säkerställer att du kan tillämpa de regler som ger den tillförlitlighet du behöver.

Säkerhetskopiera dina data regelbundet och testa dina säkerhetskopior för att säkerställa att du kan återhämta dig från både logiska och fysiska fel.

En nyckel till att hantera fel är att ofta och automatiskt testa workloads genom att orsaka fel och sedan observera hur de återhämtar sig.

4. Prestandaeffektivitet

I pelaren för prestandaeffektivitet tittar du på hur AWS-resurser och -tjänster kan användas effektivt, men också på hur effektiviteten kan bibehållas över tid när kraven på workloaden ökar och nya tekniska lösningar utvecklas.

Prestandaeffektivitet omfattar fyra områden med beprövad praxis:

Val: Säkerställ att du har valt rätt lösning för dina affärsbehov. Det gör du genom att utvärdera de befintliga resurser du har valt för din workload utifrån:
Granskning: Ställ ett antal viktiga frågor om hur processen för att granska prestanda fungerar. Till exempel: Använder du fortfarande föråldrade resurser och tjänster? Har du en process för att förbättra workloadens prestanda?
Övervakning: Avgör hur du bäst använder och konfigurerar övervakning och larm.
Avvägningar: Fundera på vilka avvägningar du är beredd att göra för att förbättra workloadens prestanda, till exempel att byta konsekvens mot kortare tid och lägre latens.

Val: Säkerställ att du har valt rätt lösning för dina affärsbehov. Det gör du genom att utvärdera de befintliga resurser du har valt för din workload utifrån:

Prestandaarkitektur
Beräkningsarkitektur
Lagringsarkitektur
Databasarkitektur
Nätverksarkitektur

Prestandaarkitektur

Beräkningsarkitektur

Lagringsarkitektur

Databasarkitektur

Nätverksarkitektur

Granskning: Ställ ett antal viktiga frågor om hur processen för att granska prestanda fungerar. Till exempel: Använder du fortfarande föråldrade resurser och tjänster? Har du en process för att förbättra workloadens prestanda?

Övervakning: Avgör hur du bäst använder och konfigurerar övervakning och larm.

Avvägningar: Fundera över vilka avvägningar du är beredd att göra för att förbättra en arbetslasts prestanda, till exempel att byta konsekvens mot tid och latens.

Ett exempel på hur din sammanfattning av pelaren för prestandaeffektivitet kan se ut

När du utformar en arkitektur för prestanda bör du utnyttja tillgängliga mekanismer för elasticitet för att säkerställa tillräcklig kapacitet och bibehålla prestandan när efterfrågan förändras.
När du väljer en lagringslösning är det avgörande att den passar dina åtkomstmönster för att uppnå den prestanda du vill ha.
Databaser väljs ofta utifrån organisationens standardval i stället för genom ett datadrivet tillvägagångssätt. Precis som för lagring är det avgörande att ta hänsyn till arbetslastens åtkomstmönster och överväga om andra lösningar än databaser kan lösa problemet mer effektivt, till exempel grafdatabaser, tidsseriedatabaser eller databaser för lagring i minnet.
Genom att utnyttja Regions, placement groups och edge services kan du förbättra nätverksprestandan avsevärt. Nätverk i molnet kan enkelt förbättras över tid eftersom de snabbt kan byggas om eller ändras.
För att få en effektiv övervakningslösning är det viktigt att undvika falska positiva resultat. Automatiska utlösare minskar risken för mänskliga fel och kan förkorta tiden det tar att lösa problem.
Använd ett systematiskt tillvägagångssätt, till exempel lasttestning, för att undersöka om dina avvägningar förbättrar prestandan.

När du utformar en arkitektur för prestanda bör du utnyttja tillgängliga mekanismer för elasticitet för att säkerställa tillräcklig kapacitet och bibehålla prestandan när efterfrågan förändras.

När du väljer en lagringslösning är det avgörande att den passar dina åtkomstmönster för att uppnå den prestanda du vill ha.

Databaser väljs ofta utifrån organisationens standardval i stället för genom ett datadrivet tillvägagångssätt. Precis som för lagring är det avgörande att ta hänsyn till arbetslastens åtkomstmönster och överväga om andra lösningar än databaser kan lösa problemet mer effektivt, till exempel grafdatabaser, tidsseriedatabaser eller databaser för lagring i minnet.

Genom att utnyttja Regions, placement groups och edge services kan du förbättra nätverksprestandan avsevärt. Nätverk i molnet kan enkelt förbättras över tid eftersom de snabbt kan byggas om eller ändras.

För att få en effektiv övervakningslösning är det viktigt att undvika falska positiva resultat. Automatiska utlösare minskar risken för mänskliga fel och kan förkorta tiden det tar att lösa problem.

Använd ett systematiskt tillvägagångssätt, till exempel lasttestning, för att undersöka om dina avvägningar förbättrar prestandan.

5. Kostnadsoptimering

Kostnad är ofta en drivkraft för migrering till molnet. Att kunna få tillgång till beräkningsresurser vid behov och bara betala för det du använder kan vara en avgörande faktor för verksamhetens framgång. När tiden går och arbetslasterna ökar i takt med efterfrågan kommer även kostnaderna oundvikligen att öka. Därför är det viktigt att ha en grundlig förståelse för dagens utgifter och identifiera förbättringsområden, som ofta är enkla att åtgärda.

Kostnadspelaren omfattar fem olika områden med beprövade metoder:

Tillämpa cloud financial management (CFM): Identifiera var ditt affärsvärde finns och hur du kan förbättra ekonomin genom att optimera kostnaderna.
Insikt om utgifter och användning: Förstå hur du hanterar dina kostnader och din användning så effektivt som möjligt.
Kostnadseffektiva resurser: Utvärdera vilka resurser, tjänster och konfigurationer du ska använda för att sänka kostnaderna.
Hantera resurser för efterfrågan och tillgång: Analysera arbetslastens behov, till exempel om du kan tillhandahålla resurser dynamiskt i stället för statiskt.
Optimera över tid: Utveckla en process för att granska arbetslaster och införa nya, kostnadsbesparande AWS-tjänster i dina befintliga arbetslaster.

Tillämpa cloud financial management (CFM): Identifiera var ditt affärsvärde finns och hur du kan förbättra ekonomin genom att optimera kostnaderna.

Insikt om utgifter och användning: Förstå hur du hanterar dina kostnader och din användning så effektivt som möjligt.

Kostnadseffektiva resurser: Utvärdera vilka resurser, tjänster och konfigurationer du ska använda för att sänka kostnaderna.

Hantera resurser för efterfrågan och tillgång: Analysera behoven i dina arbetsbelastningar, till exempel om du kan tillhandahålla resurser dynamiskt i stället för statiskt.

Optimera över tid: Ta fram en process för att granska arbetsbelastningar och utvärdera nya kostnadsbesparande AWS-tjänster för dina befintliga arbetsbelastningar.

Ett exempel på hur sammanfattningen för pelaren Kostnadsoptimering kan se ut

Precis som för de andra pelarna finns det avvägningar att ta hänsyn till. Till exempel om du ska optimera för snabbare time-to-market eller för kostnad. I vissa fall är det bäst att optimera för snabbhet – att snabbt nå marknaden, leverera nya funktioner eller helt enkelt hålla en deadline – i stället för att investera i kostnadsoptimering i förväg.
Designbeslut styrs ibland av brådska snarare än data, och det finns alltid en frestelse att överkompensera ”för säkerhets skull” i stället för att lägga tid på benchmarking för att hitta den mest kostnadsoptimala driftsättningen. Det kan leda till överdimensionerade och underoptimerade driftsättningar.
Genom att lägga rätt mängd arbete på en strategi för kostnadsoptimering från början kan du lättare ta del av molnets ekonomiska fördelar. Det säkerställer att ni konsekvent följer beprövad praxis och undviker onödig överdimensionering.

Precis som för de andra pelarna finns det avvägningar att ta hänsyn till. Till exempel om du ska optimera för snabbare time-to-market eller för kostnad. I vissa fall är det bäst att optimera för snabbhet – att snabbt nå marknaden, leverera nya funktioner eller helt enkelt hålla en deadline – i stället för att investera i kostnadsoptimering i förväg.

Designbeslut styrs ibland av brådska snarare än data, och det finns alltid en frestelse att överkompensera ”för säkerhets skull” i stället för att lägga tid på benchmarking för att hitta den mest kostnadsoptimala driftsättningen. Det kan leda till överdimensionerade och underoptimerade driftsättningar.

Genom att lägga rätt mängd arbete på en strategi för kostnadsoptimering från början kan du lättare ta del av molnets ekonomiska fördelar. Det säkerställer att ni konsekvent följer beprövad praxis och undviker onödig överdimensionering.

6. Hållbarhet

Det här nyligen tillagda området (2021) belyser hur din verksamhet påverkar vår miljö, ekonomi och vårt samhälle. Det beskriver också vilka molnprocesser och beprövade metoder som kan minska ditt miljöavtryck. Hållbarhetspelaren kan delas in i tre huvudområden.

Hållbarhet i molnet: Förstå modellen för delat ansvar, där AWS ansvarar för att optimera molnets hållbarhet medan du som kund ansvarar för att optimera dina arbetsbelastningar och resursutnyttjandet i molnet.
Förbättringsprocesser: Utvärdera hur du kan minska ditt miljöavtryck genom att omarbeta lösningarnas arkitektur. Eliminera slöseri, hantera resurser med låg användning och få ut så mycket värde som möjligt av dina befintliga molnresurser.
Beprövade metoder för hållbarhet i molnet: Förstå beprövade metoder för att öka energieffektiviteten och maximera resursutnyttjandet.

Hållbarhet i molnet: Förstå modellen för delat ansvar, där AWS ansvarar för att optimera molnets hållbarhet medan du som kund ansvarar för att optimera dina arbetsbelastningar och resursutnyttjandet i molnet.

Förbättringsprocesser: Utvärdera hur du kan minska ditt miljöavtryck genom att omarbeta lösningarnas arkitektur. Eliminera slöseri, hantera resurser med låg användning och få ut så mycket värde som möjligt av dina befintliga molnresurser.

Beprövade metoder för hållbarhet i molnet: Förstå beprövade metoder för att öka energieffektiviteten och maximera resursutnyttjandet.

Ett exempel på hur sammanfattningen för hållbarhetspelaren kan se ut

Hållbarhet i molnet är ett kontinuerligt arbete som främst fokuserar på att minska energianvändningen och öka effektiviteten i alla delar av en arbetsbelastning. Det handlar om att få största möjliga nytta av de resurser som tillhandahålls och minimera det totala resursbehovet. Arbetet kan omfatta allt från att tidigt välja ett effektivt programmeringsspråk, använda moderna algoritmer och effektiva metoder för datalagring, till att driftsätta i rätt dimensionerad och effektiv beräkningsinfrastruktur samt minimera behovet av kraftfull slutanvändarhårdvara.

Så genomför du en Well-Architected Review

Nu när du känner till de sex pelarna kan vi gå vidare och titta på hur du praktiskt genomför själva granskningen.

Alla organisationer är olika, och det som fungerar, fungerar. Men vi på Eficode gör detta hela tiden för våra kunder, och vår process fungerar riktigt bra. Därför delar jag den med dig nu som inspiration.

Processen är ganska enkel.

Steg 1: Förberedelser

Vi behöver följande från dem som ansvarar för workloaden:

Workloaden som ska granskas. Det måste vara en produktions-workload för att vara berättigad till AWS Credits i slutet (mer om detta senare).
Ett arkitekturdiagram över den nuvarande arkitekturen (om det finns något)
AWS-konto-ID:t där workloaden finns
AWS-konto-ID:t där granskningen ska delas (det kan vara vilket konto som helst, men om det finns ett Audit-konto i en Control Tower-struktur kan det vara ett bra val)
Regionen där workloaden körs

Steg 2: Uppstart

Vi bokar ett uppstartsmöte där vi går igenom hela processen och planerar tider för alla workshoppar.

Steg 3: Workshoppar

Varje pelare får en egen granskning på två timmar. Det kan låta lite väl långt, men ofta visar det sig vara precis lagom. Vissa pelare kan ta längre tid än andra, medan andra tar kortare tid.

Efter pelarna behövs ytterligare två workshoppar för att slutföra granskningen. När alla pelare har granskats och en rapport har genererats från W-A-verktyget ber vi dig att gå igenom granskningen inför de kommande workshopparna.

I en prioriteringsworkshop bedömer vi varje HRI (high-risk issue) i ett diagram som visar hur lätt ett problem är att åtgärda i förhållande till vilken påverkan det skulle ha. I slutet placerar vi varje problem, tillsammans med föreslagen åtgärd, i en överenskommen tidsplan.

Följande upplägg fungerar bra för workshopparna:

Uppstartsmöte: Boka alla workshoppar och hitta tider som passar alla.
Pelare 1–6. (totalt 12 h)
Prioriteringsworkshop: Prioritera HRI:er utifrån deras påverkan och hur enkla de är att genomföra. (2 h)
Workshop för åtgärder och roadmap: Placera alla HRI:er och deras föreslagna åtgärder i en avgränsad tidsplan. (2 h)

Uppstartsmöte: Boka alla workshoppar och hitta tider som passar alla.

Pelare 1–6. (totalt 12 h)

Prioriteringsworkshop: Prioritera HRI:er utifrån deras påverkan och hur enkla de är att genomföra. (2 h)

Workshop för åtgärder och roadmap: Placera alla HRI:er och deras föreslagna åtgärder i en avgränsad tidsplan. (2 h)

Total tid för workshoppar: 16 h

Steg 4: Åtgärdande och finansiering

Efter workshopparna har den som ansvarar för workloaden en konkret lista över problem som behöver åtgärdas, en lista med föreslagna åtgärder för att lösa problemen samt en tidsplan med den bästa ordningen för att genomföra åtgärderna. Kort sagt, en plan för allt som behöver göras, inklusive ordning och tidsram.

Om du arbetar med en partner, som Eficode, är de nu väl förberedda för att genomföra dessa åtgärder.

Om vi tillsammans lyckas åtgärda 45 % av alla HRI:er (utan att räkna med problem med medelhög risk) kan arbetsinsatsen kvalificera sig för ett AWS-kreditbelopp på 5 000 USD att använda. Det skulle sannolikt täcka hela kostnaden för granskningen, och kanske mer därtill.

Sammanfattningsvis

Nu har du fått mer kontext kring komplexiteten i molnet, men du vet också hur du kan hantera de främsta utmaningarna. AWS har varit proaktiva med att ta fram verktyg för att identifiera svagheter och beprövade metoder för att åtgärda dem.

Men precis som din verksamhet i stort förändras molnet och din arkitektur i det ständigt. Det innebär att du behöver använda din kunskap och de verktyg du har till hands för att säkerställa att du fortsätter vara tillförlitlig, säker, kostnadseffektiv och effektiv. Oavsett om du väljer att göra det på egen hand eller samarbeta med en erfaren partner känner du nu till grunderna i Well-Architected Framework och har en handlingsplan i form av Well-Architected Review.

Nu är det upp till dig.

Så granskar du ditt AWS Well-Architected Framework: en snabbguide

Butrint Ferole