Spring til indhold
FlareTech

AWS

AWS-arkitektur og cloud-drift

Vi designer og driver AWS-platforme der kan stå alene: rette services, IaC, mindst-privilegium IAM, monitorering og forbrugsstyring sat op fra start.

Book en samtaleFå en AWS-audit
3D isometrisk illustration af cloud-arkitektur — kuber for compute, database, kø og storage forbundet af glødende orange data-linjer.

Sådan vi tænker AWS

Den enkleste arkitektur der løser opgaven

Hele infrastrukturen som kode
Terraform
Production, staging og dev adskilt
Multi-account
Frankfurt og Stockholm som default
EU-region
Forbrug pr. team, miljø og service
Tagged

Sådan vi navigerer AWS

Den enkleste arkitektur slår den smarte.

AWS er voldsomt: 200+ services, en regning der er svær at forstå, og 17 måder at gøre det samme på. Vi navigerer det ved at vælge den enkleste arkitektur der løser opgaven — ikke den der ligner mest et AWS-marketing-diagram. Det betyder typisk en håndfuld kerne-services (ECS Fargate eller Lambda, RDS, S3, ALB, Route 53) sat sammen med IaC, IAM-rolle-disciplin og observability fra dag ét.

Vi har designet AWS-platforme for SaaS-produkter, dataplatforme og B2B-portaler. Vi ved hvor det går galt: utætte IAM-policies, tunge cross-region trafik-flows, RDS-instanser der bliver til et single-point-of-failure, og en regning der vokser fordi ingen rydder op. Vi designer for at undgå dem fra start — og auditerer dem ud hvis de allerede er der.

Vi bruger Terraform (eller Pulumi når det giver mening) for hele infrastrukturen, så hver ændring kan reviewes som kode, rulles tilbage og bygges op igen i et nyt environment. Det er forskellen på en platform jeres team kan vedligeholde og en platform der kun én senior konsulent forstår.

Hvad I får leveret

Kerne-services sat op rigtigt fra start.

ECS, Lambda, RDS, S3, VPC og IAM — som kode, ikke i konsollen.

  • Arkitektur og service-valg

    Vi designer den enkleste arkitektur der dækker jeres krav: ECS Fargate til containere, Lambda til hændelses-baserede workloads, RDS Aurora til primær database, S3 til objektlagring, CloudFront til distribution. Ingen unødvendige services.

  • Multi-account og organisation

    AWS Organizations med separate accounts for production, staging og udvikling. Service Control Policies, fælles logging-account og en sikker setup af AWS SSO via Microsoft Entra eller Okta.

  • Networking og sikkerhed

    VPC-design med private subnets, NAT, korrekt brug af security groups og NACLs. Interne services taler via Service Connect eller PrivateLink. WAF foran public endpoints, GuardDuty og Security Hub aktivt.

  • Databaser og data-layer

    RDS Aurora Postgres eller MySQL med backups, point-in-time restore, read-replicas og cross-region failover hvor det giver mening. Til serverless workloads vurderer vi Aurora Serverless v2 eller eksterne valg som Neon.

  • Observability og alerting

    CloudWatch logs og metrics, X-Ray tracing eller OpenTelemetry til Datadog/Honeycomb, SLO-baserede alarmer der pinger på sympotmer (latens, fejlrate) — ikke på CPU og RAM.

  • Forbrugsstyring og budget-alarmer

    AWS Budgets, Cost Anomaly Detection og Compute Optimizer slået til. Tagging-strategi der lader jer dele forbrug op pr. team, miljø og service. Reserved Instances og Savings Plans hvor det giver mening — ikke som en sælger-pakke.

Det her bør I vide

Skarpe kanter ved AWS.

  • Lambda vs. ECS vs. EC2

    Lambda er fantastisk til hændelses-baserede workloads og lette API-endpoints — men cold starts, 15-minutters timeout og memory-limits gør det forkert valg for langvarige jobs eller tunge afhængigheder. ECS Fargate giver containere uden at administrere servers; EC2 er sjældent det rigtige svar i 2026 medmindre I har et meget specifikt krav. Vi vælger pr. workload.

  • Multi-region: hvornår det er værd det

    Multi-region failover lyder altid godt og er sjældent nødvendigt. For de fleste produkter er en single-region setup med daglige cross-region backups, et godt monitorerings-setup og en testet recovery-procedure tilstrækkelig — og dramatisk billigere. Vi gennemgår faktiske RTO/RPO-krav og dimensionerer derefter.

  • IAM er produktionskode

    De fleste AWS-sikkerhedshændelser handler om for brede IAM-policies, ikke ondsindede angreb. Vi skriver alle policies i Terraform, reviewer dem som kode, bruger IAM Access Analyzer til at finde unødigt brede roller, og rotterer adgangsnøgler systematisk.

  • Lock-in og portabilitet

    Nogle AWS-services (DynamoDB, Step Functions, CloudWatch) skaber bevidst lock-in. Vi bruger dem hvor de giver klart størst værdi, og holder kerne-forretningslogikken på en stack der er portabel — Postgres, S3-kompatibel storage, OpenTelemetry til monitorering. Så I kan flytte hvis noget grundlæggende ændrer sig.

FAQ

Det folk plejer at spørge om.

  • Hvornår er AWS det rette valg over Vercel eller Cloudflare?

    AWS giver mening når I har tunge baggrundsjobs, store data-pipelines, behov for specialiseret compute (GPU, ARM), strikse compliance-krav der kræver ejet infrastruktur, eller kompleks netværk (VPN, Direct Connect, multi-cloud). For en almindelig Next.js-app uden de behov, er Vercel typisk hurtigere og billigere. Vi rådgiver ærligt — vi vælger ikke AWS bare fordi det er AWS.

  • Kan I migrere os fra on-prem eller anden cloud?

    Ja. Vi har migreret applikationer fra on-prem datacenters, Azure, GCP og hosted setups til AWS. Vi starter med en discovery-fase hvor vi gennemgår nuværende arkitektur, identificerer hvad der bør lift-and-shift'es, hvad der bør re-platformes og hvad der bør droppes. Vi flytter i etaper med parallel-drift, så I aldrig står med en stor-bang-cutover.

  • Hvordan undgår vi at AWS-regningen eksploderer?

    Forbrugsstyring designes ind fra start: tagging-strategi, AWS Budgets med alarmer, Cost Anomaly Detection slået til, og månedlige reviews. De fleste "overraskelses-regninger" kommer fra glemte ressourcer (test-RDS-instanser der kører 24/7), uoptimerede data-transfer-flows og over-provisionerede services. Vi bygger en cost-disciplin og dokumenterer hvad hver tag betyder.

  • Skal I have AWS-certificeringer for at bygge på AWS for os?

    Vi har Solutions Architect-certificeringer på teamet, men vi vælger ikke arkitektur ud fra hvad eksamen siger — vi vælger ud fra hvad der virker. Vi designer pragmatisk, dokumenterer beslutninger og kan defendere hver enkelt. Hvis jeres team selv vil tage AWS-certificeringer for at overtage drift, hjælper vi gerne med oplæring.

  • Kan I drifte AWS for os løbende?

    Ja. Vi tilbyder en månedlig drifts-aftale med monitorering, opdateringer (managed services patching, AMI-rotation), forbrugsstyring, sikkerhedsgennemgang og on-call rotation. Mange kunder vælger en blanding hvor jeres team kører applikationen og vi står for platformen.

Relaterede ydelser

Klar til at starte?

Lad os tage en uforpligtende snak.

Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.

Book en samtaleSkriv en mail