AWS
En stabil grund för moderna webbplatser
Att drifta webbplatser och webbapplikationer i molnet kan göras på många sätt. Vissa lösningar är snabba att komma igång med, andra är billiga på kort sikt, men i längden krävs erfarenhet och genomtänkta val för att få en plattform som är snabb, stabil, säker och kostnadseffektiv.
Vi väljer alltid driftlösning utifrån varje kunds individuella behov, men vi arbetar mycket med Amazon Web Services (AWS) eftersom det ger oss en välbeprövad teknisk grund och möjligheten att automatisera mycket av det som annars blir manuellt, sårbart och svårt att skala. För oss handlar det i slutändan om att tekniken ska kännas trygg: webbplatsen ska prestera bra, uppdateringar ska kunna göras utan oro och driften ska vara förutsägbar även när behoven förändras.
Våra byggstenar på AWS
Vi föredrar att använda ett fåtal stabila, hanterade AWS-tjänster som tillsammans ger en robust helhet. Det minskar komplexiteten och gör lösningen lättare att underhålla, vidareutveckla och felsöka.
- AWS ECS Fargate används för att köra själva applikationen i containrar. Det gör miljön förutsägbar och lätt att skala vid behov.
- Amazon Aurora (MySQL) används som databas. Det är en hanterad databaslösning som är byggd för hög tillgänglighet och bra prestanda.
- Amazon S3 används för uppladdade filer och media. Lagringen är hållbar och passar bra för allt från bilder till dokument.
- Amazon CloudFront används som CDN (innehållsnätverk) för att leverera statiskt innehåll snabbt till användare oavsett var de befinner sig.
- AWS ElastiCache (Redis) används för cache, vilket avlastar databasen och kan ge markant snabbare svarstider.
- AWS Web Application Firewall (WAF) används som ett extra skyddslager mot skadlig trafik och automatiserade attacker.
Det här upplägget gör att vi kan fokusera på funktion och användarupplevelse, samtidigt som driften bygger på tjänster som är designade för att vara robusta från början.
Prestanda
Snabba webbplatser är inte bara “nice to have”. De påverkar användarupplevelsen, konvertering och ofta även synlighet i sökmotorer. Därför bygger vi vår drift med prestanda som en grundprincip, inte som en eftertanke.
Innehåll levereras nära besökaren via CDN och cache, så att allt inte behöver hämtas från ursprungsservern varje gång. Tunga beräkningar cachas så att applikationen slipper räkna ut samma sak om och om igen. Och inför lanseringar eller större förändringar belastningstestar vi när det behövs, så att vi vet hur sajten beter sig under press i stället för att hoppas på det bästa.
Skalbarhet
En stor fördel med AWS är att plattformen kan anpassa sig efter belastning. När trafiken ökar kan fler instanser startas automatiskt. När trafiken minskar skalar resurserna ned igen.
Det här gör stor skillnad i praktiken. I stället för att “gissa” en serverstorlek som ska klara allt året runt, kan vi bygga för en normalnivå och låta systemet hantera toppar när de faktiskt händer. Vid kampanjer, nyhetsflöden, biljettsläpp eller andra händelser som skapar tillfälliga trafikökningar innebär det att webbplatsen kan fortsätta vara snabb och stabil utan panikåtgärder.
Vid större behov går det också att skala databasen genom att separera läsning från skrivning, så att enklare förfrågningar inte belastar den del som hanterar uppdateringar och transaktioner.
Stabilitet
Stabil drift handlar inte om att slippa problem helt. Det handlar om att problemen inte når besökaren.
Faller en applikationsinstans ersätts den automatiskt. Stiger lasten för mycket finns regler som ökar kapaciteten i tid. Databasen, som oftast är den mest kritiska biten, kör vi med hög tillgänglighet och tät övervakning.
Uppdateringar och driftsättningar med låg risk
En vanlig orsak till driftproblem är mänskliga misstag vid uppdateringar. Därför bygger vi mycket av vårt arbetssätt runt en trygg och repeterbar process.
Vår grundprincip är att förändringar ska vara:
- förberedda (utvecklas lokalt och granskas),
- testade (i en separat testmiljö),
- spårbara (det ska gå att se vad som ändrats och när),
- enkla att backa (om något inte beter sig som tänkt).
Ändringar utvecklas lokalt och granskas, testas i en separat miljö, och deployas automatiskt på samma sätt varje gång. Ser något fel ut kan vi rulla tillbaka till förra fungerande versionen på direkten. Det gör att uppdateringar blir mindre dramatiska – och att förbättringar kan levereras oftare utan att risknivån ökar.
Övervakning och proaktiv drift
En bra arkitektur räcker inte om ingen tittar på den. Vi bevakar svarstider, felkoder, last och avvikelser i trafiken löpande, och får larm när något drar iväg. Oftast hinner vi agera innan någon användare märker något. Som bonus ser vi vad som faktiskt händer i verkligheten, vilket gör det lättare att optimera på riktigt i stället för på känsla.
Säkerhet som standard
Säkerhet är inbyggt i hela plattformen. Vi arbetar med flera lager av skydd, så att en enskild åtgärd aldrig blir den enda barriären.
Isolering och tydliga gränser. Miljöer byggs så att resurser inte blandas mellan olika projekt. Nätverk, rättigheter och åtkomst hålls tydligt avgränsade.
Minimerad åtkomst. Åtkomst till AWS kräver multifaktorautentisering och behörigheter är begränsade utifrån roll och behov. Alla viktiga ändringar loggas så att det går att se vad som hänt och av vem.
Kryptering och säkra anslutningar. Data skyddas både när den lagras och när den skickas mellan systemets delar. Hemligheter och nycklar hanteras separat och lagras inte i källkod.
Skydd mot attacker. Vi använder brandväggar, säkerhetsregler och WAF för att filtrera skadlig trafik, bottar och vanliga angreppsmönster. Genom att applikationer körs i hanterade, låsta miljöer minskar också risken för sårbarheter som kommer från “klassiska serverupplägg”.
Dessutom arbetar vi proaktivt i utvecklingen med etablerade säkerhetsprinciper (som till exempel OWASP) i kodgranskning och tester.
Backup och återställning när det verkligen gäller
Förr eller senare behöver något återskapas – en uppdatering som blev fel, innehåll som råkade skrivas över, eller en oväntad incident. Då är det återställningen som räknas, inte att man råkar ha en backup liggande någonstans.
Databasen säkerhetskopieras löpande och kan rullas tillbaka till en specifik tidpunkt. Filer i S3 versionshanteras, så att en överskriven bild går att få tillbaka. Och vi ser till att processen faktiskt går att genomföra i skarpt läge, inte bara på pappret.
Kostnadseffektiv drift över tid
Kostnadseffektivitet handlar sällan om att välja den billigaste lösningen på pappret. Det handlar om att få rätt nivå av prestanda, stabilitet och säkerhet – utan att betala för överkapacitet eller lägga tid på onödig manuellt underhåll.
Med autoskalning, cache och hanterade tjänster håller vi resursförbrukningen rimlig utan att tumma på kvaliteten. Och eftersom miljöerna är standardiserade går utveckling och uppdateringar snabbare med färre fel, ofta en större kostnadspost än själva infrastrukturen.
En plattform byggd för långsiktighet
Vår AWS-plattform är byggd för att fungera konsekvent över tid. Samma typ av miljö används i utveckling, test och produktion, vilket minskar risken för överraskningar och gör det enklare att arbeta i team.
Det ger också en praktisk fördel: nya utvecklare kan komma in snabbare, projekt blir lättare att ta över, och förbättringar kan levereras mer förutsägbart.
Kort sagt använder vi AWS för att kunna leverera webbplatser och applikationer som är snabba, stabila och säkra.