AWS.
Serverless and managed services on AWS, set up so releases are repeatable and costs are visible.
Talk to us about AWS
Key features
What AWS does well.
Breadth of managed services
Compute, databases, queues, storage and AI models are all available as managed services in one account.
Fine-grained IAM
IAM policies can limit each person and service to the exact actions and resources it needs.
Regions near your users
Regions include London, Bahrain and the UAE, each split into separate Availability Zones.
Multi-account structure
AWS Organizations groups accounts and applies guardrails, so production can sit apart from testing.
What we build with it
Managed services, assembled with care.
AWS offers managed building blocks for most of what a product needs to run. We favour serverless and managed services where they fit, so there is less to patch, and define the setup in code so every environment matches.
Serverless back ends
Lambda functions behind API Gateway, scaling with demand and charged by use.
Authentication
User sign-in and access with Cognito, connected to the product’s own permissions.
Managed data
Databases, storage and messaging run as managed services with backups and access rules.
When it’s the right choice
AWS is a strong fit when you want a wide choice of managed services, or your organisation already runs workloads there.
When we’d pick something else
If your organisation is standardised on Microsoft or Google tools, Azure or Google Cloud may make identity, billing and support simpler.
Our AWS services
How we can help.
Architecture design
We choose services, regions and account structure to match your workload, budget and data rules.
Access review
We check IAM roles, keys and network rules, then tighten the ones that give more access than needed.
Cost review
We break down where the bill goes and suggest changes, with the trade-off of each one explained.
Migration to managed services
We move workloads off servers you maintain and onto managed services, in stages you can roll back.
How we work
Starting a AWS project.
Review what exists
Code, data, hosting and the people who maintain it, before any AWS decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
In our own products
SoulCare.
SoulCare runs Go services on AWS Lambda behind API Gateway, with Cognito for sign-in and AppSync for live updates.
Read the case study ↗
Where AI fits
AI in cloud & infrastructure work.
Models inside your cloud account
Amazon Bedrock, Azure and Google’s Gemini Enterprise Agent Platform give model access under your own account’s access, logging and billing controls.
AI workflow automation ↗Region and residency checks
Model availability differs by region, so we check where prompts and documents will be processed before choosing a service.
Cloud architecture ↗
Where it stops: Turning on a model service does not make a use compliant. Data protection and sector rules still apply to every prompt and output.
What’s changing
Shifts to plan for.
Dates that affect AWS projects, checked against the official sources.
June 2026
Amazon Linux 2 reaches end of life
Amazon Linux 2 reached end of life on 30 June 2026. Lambda runtimes built on it get limited patches until their own deprecation dates.
April 2026
Lambda deprecates Node.js 20
Lambda stopped patching nodejs20.x on 30 April 2026. Creating functions on it is blocked from 29 July 2027 and updating them from 31 August 2027.
Where it fits
Related expertise.
- Cloud architecture Choose and structure cloud services around your product’s data, access and operating needs.
- Infrastructure as code Define environments in version-controlled code, so changes are reviewed and drift is easy to spot.
- CI/CD pipelines Automated builds, tests and deployments, so every release follows the same checked path.
- Monitoring & support Logs, metrics and alerts that show problems early, with agreed support for after launch.
Common questions
AWS questions.
Can you review our existing AWS setup?
Yes. We look at the architecture, access, costs, deployment and monitoring, then agree which changes matter most and in what order.
Which AWS region should we use?
That depends on where your users are and any data residency requirements. We confirm those requirements before choosing regions.
Further reading
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- MySQL 8.0 has reached end of life: planning the move to 8.4 What MySQL 8.0’s end of life means, and how to plan, test and roll back an upgrade to MySQL 8.4 LTS.
- One database per tenant: isolating customer data in SaaS When each customer gets its own PostgreSQL database, and what that means for migrations, connections and running costs.