AWS
AWS architecture and cloud operations
We design and operate AWS platforms that can stand on their own: the right services, IaC, least-privilege IAM, monitoring and spend control — set up from the start.
How we think about AWS
The simplest architecture that solves the job
- Entire infrastructure as code
- Terraform
- Production, staging and dev separated
- Multi-account
- Frankfurt and Stockholm as default
- EU region
- Spend per team, environment and service
- Tagged
How we navigate AWS
The simplest architecture beats the clever one.
AWS is enormous: 200+ services, a bill that's hard to parse, and 17 ways to do the same thing. We navigate it by choosing the simplest architecture that solves the job — not the one that looks most like an AWS marketing diagram. That typically means a handful of core services (ECS Fargate or Lambda, RDS, S3, ALB, Route 53) wired together with IaC, IAM-role discipline and observability from day one.
We've designed AWS platforms for SaaS products, data platforms and B2B portals. We know where it goes wrong: leaky IAM policies, heavy cross-region traffic, RDS instances that become single points of failure, and a bill that grows because no one cleans up. We design to avoid those from the start — and audit them out if they're already there.
We use Terraform (or Pulumi when it makes sense) for the entire infrastructure, so every change can be reviewed as code, rolled back, and rebuilt in a new environment. That's the difference between a platform your team can maintain and a platform only one senior consultant understands.
What we deliver
Core services, set up correctly from the start.
ECS, Lambda, RDS, S3, VPC and IAM — as code, not in the console.
Architecture and service choice
We design the simplest architecture that meets your requirements: ECS Fargate for containers, Lambda for event-driven workloads, RDS Aurora for the primary database, S3 for object storage, CloudFront for distribution. No unnecessary services.
Multi-account and organisation
AWS Organizations with separate accounts for production, staging and development. Service Control Policies, a shared logging account, and a secure setup of AWS SSO via Microsoft Entra or Okta.
Networking and security
VPC design with private subnets, NAT, correct use of security groups and NACLs. Internal services talk via Service Connect or PrivateLink. WAF in front of public endpoints, GuardDuty and Security Hub active.
Databases and data layer
RDS Aurora Postgres or MySQL with backups, point-in-time restore, read replicas and cross-region failover where it makes sense. For serverless workloads we evaluate Aurora Serverless v2 or external choices like Neon.
Observability and alerting
CloudWatch logs and metrics, X-Ray tracing or OpenTelemetry to Datadog/Honeycomb, SLO-based alerts that page on symptoms (latency, error rate) — not on CPU and RAM.
Spend control and budget alerts
AWS Budgets, Cost Anomaly Detection and Compute Optimizer enabled. Tagging strategy that lets you split spend per team, environment and service. Reserved Instances and Savings Plans where they make sense — not as a vendor bundle.
Things to know
Sharp edges of AWS.
Lambda vs. ECS vs. EC2
Lambda is great for event-driven workloads and lightweight API endpoints — but cold starts, 15-minute timeout and memory limits make it the wrong choice for long-running jobs or heavy dependencies. ECS Fargate gives you containers without managing servers; EC2 is rarely the right answer in 2026 unless you have a very specific requirement. We choose per workload.
Multi-region: when it's worth it
Multi-region failover always sounds good and is rarely necessary. For most products a single-region setup with daily cross-region backups, a good monitoring setup, and a tested recovery procedure is sufficient — and dramatically cheaper. We walk through actual RTO/RPO requirements and size accordingly.
IAM is production code
Most AWS security incidents are about overly broad IAM policies, not malicious attacks. We write all policies in Terraform, review them as code, use IAM Access Analyzer to find unnecessarily wide roles, and rotate access keys systematically.
Lock-in and portability
Some AWS services (DynamoDB, Step Functions, CloudWatch) deliberately create lock-in. We use them where they give clearly the most value, and keep the core business logic on a stack that's portable — Postgres, S3-compatible storage, OpenTelemetry for monitoring. So you can move if something fundamental changes.
FAQ
What people usually ask.
When is AWS the right choice over Vercel or Cloudflare?
AWS makes sense when you have heavy background jobs, large data pipelines, need for specialised compute (GPU, ARM), strict compliance requirements that demand owned infrastructure, or complex networking (VPN, Direct Connect, multi-cloud). For a typical Next.js app without those needs, Vercel is usually faster and cheaper. We advise honestly — we don't choose AWS just because it's AWS.
Can you migrate us from on-prem or another cloud?
Yes. We've migrated applications from on-prem datacenters, Azure, GCP and hosted setups to AWS. We start with a discovery phase reviewing the current architecture, identifying what should be lift-and-shifted, what should be re-platformed and what should be dropped. We move in stages with parallel operations, so you never face a big-bang cutover.
How do we avoid the AWS bill exploding?
Spend control is designed in from the start: tagging strategy, AWS Budgets with alerts, Cost Anomaly Detection enabled, and monthly reviews. Most 'surprise bills' come from forgotten resources (test RDS instances running 24/7), unoptimised data-transfer flows, and over-provisioned services. We build a cost discipline and document what each tag means.
Do you need AWS certifications to build on AWS for us?
We have Solutions Architect certifications on the team, but we don't choose architecture based on what the exam says — we choose based on what works. We design pragmatically, document decisions, and can defend each one. If your team wants to take AWS certifications themselves to take over operations, we're happy to help with the training.
Can you operate AWS for us continuously?
Yes. We offer a monthly operations agreement with monitoring, updates (managed services patching, AMI rotation), spend control, security review and on-call rotation. Many customers choose a mix where your team runs the application and we run the platform.
Related services
- CloudflareDNS, WAF, Workers, R2 and Pages — set up correctly from the start, so Cloudflare actually works for you.
- VercelHosting, preview deploys and edge functions set up so Next.js delivers what Vercel promises.
- Cloud migrationFrom on-prem, hosted servers or another cloud to a modern stack — without lost data and without long downtimes.
Ready to get started?
Let's have a no-pressure conversation.
We'll get back within one business day with concrete input — not a stock proposal.