Takeaways från AWS Summit Online
AWS brukar varje år arrangera flera endagars-konferenser runt om i värden, AWS Summits. I Stockholm brukar AWS Summit Stockholm arrangeras i maj. Sedan tidigt i våras har samtliga av dessa ställts in pga Covid-19. Istället bjöd AWS den 17 juni in till AWS Summit Online. En halvdags-konferens med 11(!) spår där samtliga föreläsningar finns tillgängliga i efterhand online. Svårighetsgraden på föreläsningarna varierade från introduction (Level 100) till expert (400) men med en tydlig tyngdpunkt på intermediate (200) och advanced (300). Efter att under ett par år ha varit på ett par AWS-events fysiskt och digitalt har jag lärt mig att lärt mig att med hjälp av titeln och nivå får man en väldigt bra överblick av om det är värt att gå på föreläsningen. Handlar den om ett område man inte är bekant med eller bara doppat tårna i kommer man inte att lära sig mycket från 300- eller 400-nivå. På samma sätt får man inte ut något av 100- eller ens 200-nivå om man är en van användare.
Överlag tyckte jag att konferensen höll bra kvalitet. Med 11 parallella spår är det mer troligt att man måste välja bort en eller flera intressanta föreläsningar än att man inte hittar något intressant att titta på. Jag försöker här sammanfatta ett par av de saker jag tar med mig från dagen. Jag försökte fokusera mina val mot säkerhet och/eller arkitektur där det passade och det är framförallt från det tidigare jag tar med mig mest. En del tjänster och funktioner används naturligt, men det finns en del som man behöver lägga ner lite arbete på men som i längden kan ge väldigt mycket tillbaka.
AWS har många tjänster inom säkerhetsövervakning och skydd: AWS Security Hub, Amazon GuardDuty och AWS Shield för att nämna några. Jag har varit vid flertalet föreläsningar där flera av dessa tjänster beskrivs och där jag kännt att det är väldigt bra verktyg att att jag/vi borde börja använda mer. Som utvecklare kanske det inte alla gånger är så naturligt att ta steget att börja experimentera med Amazon GuardDuty direkt. Det kanske är svårt att motivera varför tid ska läggas på detta. Jag tror att det finns en naturlig väg att komma in på automatiserad säkerhetsövervakning via loggning. De flesta om inte alla utvecklare i en DevOps-organisation kommer att stöta på incidenter där det har blivit något fel i någon av de tjänster man ansvarar för. Efter ett par liknande incidenter börjar utvecklaren troligen och även (förhoppningsvis) produktägaren att fundera på vad som kan göras för att minimera tiden som läggs på att hantera incidenter. Här kanske man nu bygger stödsystem för att förbättra och centralisera loggning. Man kanske automatiserar så att varje gång en viss typ av fel uppträder i loggarna så skickar man ett mail till utvecklaren. Nästa steg blir att man kan automatisera även vilket åtgärd man tar på felet. När man väl kommit så här långt är steget att bygga vidare. Nu kan vi med en lite större arbetsinsats utöver det stöd vi behöver för att lösa våra incidenter, även mitigera en säkerhetsrisk. Steget till att använda alla de säkerhetsverktyg som finns i AWS behöver inte vara så långt.