Infrastruktur
Var plattformen körs, hur den är satt ihop, och hur vi märker när något är fel.
På arkitekturnivå. Specifika värdar, adresser och resursidentifierare delas i en genomgång under sekretessavtal snarare än publiceras.
Ert system körs nära er
Digital Plattform driftsätts i vilken AWS-region som helst. Vilken ert system får avgörs av var ni finns: regionen närmast era användare, satt utifrån er plats när systemet sätts upp.
Skälet är svarstider. En tur och retur till en avlägsen region är en kostnad varje enskild förfrågan betalar, och ingen mängd applikationstrimning tar igen den. Att köra systemet bredvid människorna som använder det är den enda åtgärd som fungerar.
Var uppgifterna finns följer av samma beslut. Ert systems beräkning, databas, fillagring och säkerhetskopior ligger alla i den enda regionen tillsammans.
| Del | Leverantör | Region |
|---|---|---|
| Applikationsservrar | AWS EC2 | Ert systems region |
| Plattformsdatabasen | I egen drift på AWS EC2 | Ert systems region |
| Fillagring | AWS S3 | Ert systems region |
| Säkerhetskopior och maskinavbilder | AWS S3 / AWS Backup | Ert systems region |
| Transaktionsmejl | AWS SES | Ert systems region |
| AI-funktioner, där de är påslagna | Modellleverantörer | Leverantörens region |
Beräkning och lagring
Vad körs plattformen på?
Amazon EC2-instanser i ert systems region, i AWS-konton vi äger direkt snarare än genom en återförsäljare. Maskinparken kör på ARM-baserade instanser, vilket är ett kostnads- och effektivitetsval snarare än ett säkerhetsval.
Applikationsservrar, databasen och stödtjänster kör på skilda instanser. Lagringen är AWS gp3-volymer för instans- och databaslagring, och S3 för uppladdade filer, säkerhetskopior och arkiv.
Vilken databas använder plattformen?
Plattformsdatabasen är MongoDB, i egen drift som en replikuppsättning på våra egna instanser. Den flyttades från MongoDB Atlas till egen infrastruktur i mars 2026, vilket lade uppgifterna och deras säkerhetskopior inne i våra egna konton och vår egen region.
Plattformens datalager stöder också PostgreSQL, ScyllaDB, Cassandra och CockroachDB, så ett system med en last som kräver någon av dem tvingas inte in på standardvalet.
Hur skalar plattformen?
Vertikalt först — instanser storleksändras efter lasten, och maskinparken har ändrats på plats när behovet ändrats. Lagringsvolymer utökas utan ombyggnad.
Databasen skalar genom att fler medlemmar läggs till i replikuppsättningen, vilket också ökar redundansen i stället för att byta bort den.
Planerat: horisontell autoskalning av applikationsservrar bakom en lastbalanserare. Kapaciteten sätts i dag medvetet snarare än automatiskt.
Vilken redundans finns?
Databasen kör som en replikuppsättning, så att förlusten av en enskild nod varken förlorar uppgifterna eller stoppar tjänsten.
Varje server har en maskinavbild från dagen innan, så en förlorad värd byggs om från en avbild i stället för att installeras om från grunden.
Planerat: driftsättning över flera tillgänglighetszoner för applikationsservrarna, och automatisk omkoppling för applikationslagret. I dag återställs ett bortfall på en applikationsvärd av en operatör snarare än automatiskt.
Vad som är exponerat
Vad går att nå från internet?
Webbapplikationen och dess API, endast över HTTPS. TLS avslutas i nginx, certifikaten utfärdas av Let's Encrypt och förnyas automatiskt, och vanlig HTTP omdirigeras i stället för att besvaras.
Plattformsdatabasen går inte att nå från det publika internet och tar emot anslutningar bara på det interna nätverket.
Hur styrs administrativ åtkomst till servrarna?
SSH med nyckelbaserad autentisering på en icke-standardport. Lösenordsautentisering är avstängd, så ett gissat eller läckt lösenord är ingen väg in.
Administrativ åtkomst går till namngivna konton snarare än till en delad inloggning, vilket är det som gör en åtgärd på en server möjlig att härleda till en person.
Använder ni WAF eller DDoS-skydd?
Planerat. Det står ingen brandvägg för webbapplikationer framför plattformen i dag, och skyddet mot volymattacker är begränsat till det AWS ger på nätverksnivå som standard.
Vi säger hellre det rakt ut än beskriver plattformen som skyddad av något som inte är driftsatt.
Övervakning och loggning
Vad vi bevakar, vad vi sparar, och — den del de flesta leverantörssidor utelämnar — vad vi ännu inte samlat på ett ställe.
Hur övervakas plattformen?
Larm i Amazon CloudWatch över hela maskinparken täcker värdarnas och tjänsternas hälsa, och larmen går till de personer som driver plattformen. Ett larm går till en människa, inte till en instrumentpanel ingen tittar på.
Säkerhetskopieringsjobben rapporterar sitt utfall, så en kopiering som tyst slutat köra är ett upptäckbart tillstånd i stället för något man får veta under en återläsning.
Vad loggas?
Tre skilda spår. Applikationsloggar på servrarna, infrastrukturmått och larmhistorik i CloudWatch, och plattformens egen granskningslogg över användar- och administratörsaktivitet i databasen — den sista beskrivs i sin helhet på säkerhetssidan.
Planerat: samlad hopsamling av alla tre i en enda sökbar lagring med bestämd bevarandetid. I dag frågas de där de ligger.
Finns det en publik statussida?
Det finns en statussida i det här Trust Center, som sköts för hand. Automatisk statusrapportering driven av löpande hälsokontroller är planerad snarare än i drift, och sidan säger det i stället för att antyda att ett direktflöde finns.
Kunder som påverkas av en incident kontaktas direkt. Vi förlitar oss inte på en statussida som aviseringsväg.
Behöver ni driftdetaljerna?
Arkitekturskisser, specifika resursförteckningar och konfigurationsdetaljer finns att få i en teknisk genomgång under sekretessavtal.