AWS cloud engineering
Most AWS conversations start in one of three places: a migration that has stalled, a bill nobody can explain, or a platform that works but cannot be operated by the team that owns it.
01Capabilities
The four jobs people actually hire us for on AWS
AWS is the cloud we have the most delivered work on, across logistics, healthcare and SaaS products. Almost every engagement is one of four shapes, and knowing which one you are in changes the plan more than the architecture does.
- Migration
Moving workloads without a long freeze
Applications and their data onto AWS while the business keeps running. The hard part is rarely the compute. It is the data cutover, the DNS, and the rollback path you hope not to use and must have anyway.
- Cost
Bringing a bill back under control
Bills grow through instance sizing, storage classes, data transfer and forgotten environments, not through one bad decision. We treat that as an engineering problem with a measurable target rather than a negotiation with your account manager.
- Platform
Accounts, networking and guardrails set up once
So a product team can ship without opening a ticket, and so your security people have something to audit. This is the part that is cheap to do early and expensive to unpick later, which is why it is card three and not card one.
- Operations
Making the thing survivable at 3am
Logging, metrics, alerting and the runbooks an on-call rotation actually needs. A platform your own team cannot operate is not finished, whatever the architecture diagram says. We build them under an ISO 27001:2022 certified information-security management system.
02Case studies
What we have already shipped on AWS
Six systems in production, across SaaS, logistics, healthcare, entertainment, knowledge work and document automation.
See all case studies- SaaSAWS costs down 30%+ for a US B2B SaaS platformunicrew became the programming team for a B2B SaaS platform that had run for over a decade, streamlined how it used AWS and Heroku, and sped up rollouts.30%+Lower AWS costs
HospitalityHighly Adjustable Platform for entertainment industriesunicrew developed a platform for Booked It that enhanced the customer experience for nightclub, entertainment center, and festival goers.600+Businesses using the platform- AutomationDoubling data-entry throughput with a custom recognition toolunicrew automated a manual data-entry bottleneck with a C# and AWS recognition tool, doubling the data sets the team got through each month.2xData sets processed per month
- LogisticsA freight-management platform and mobile apps for a US logistics startup (Mover Technologies)
- HealthcareStabilizing and Scaling a Home Health Monitoring PlatformA U.S. consumer health tech company needed system stability and an experienced partner. unicrew stabilized the platform, optimized infrastructure costs, and delivered new features, becoming a long-term technology partner.
Knowledge ManagementSaaS for Digital ResearchesA SaaS solution that helps knowledge workers streamline research work involving a substantial amount of information.
03Fit
When we would tell you not to use AWS
AWS is our default where a workload needs breadth of managed services, or where the team already has the skills to run it. It is not automatically the right answer, and four of the six rows below send you somewhere that is not us. We hold no reseller incentive in either direction, which is the only reason this table can say what it says.
| Your situation | What we recommend |
|---|---|
| Broad service needs, workloads that vary in shape, and a team that already has AWS skills | Use AWSThe service breadth is the genuine advantage, and the people who will operate it on Monday already know how. |
| A Microsoft estate: .NET, Active Directory, SQL Server, an enterprise agreement already signed | Different pageOur Azure page. Identity and licensing dominate the total cost here, and no per-service comparison will outweigh them. |
| The bill is the problem and the architecture is fine | We argue againstDo the cost work, not a migration. Changing provider to fix a bill trades a bill you understand for one you do not. |
| One predictable application, a small team, and no appetite for an on-call rotation | We argue againstA managed platform costs less to run and far less to operate. A full AWS build would give you capability you will pay for and never use. |
| Data residency or a regulator is what is actually driving the decision | Start elsewhereStart from the constraint and work back. Sometimes the answer is one specific region, and sometimes it is not public cloud at all. |
| A migration that already stalled halfway, with pressure to add scope and restart | Stop firstRe-plan the cutover before anything else. A stalled migration is almost always a data and rollback problem wearing a capacity costume. |
Scope
What we own on an AWS engagement is the architecture decision and everything downstream of it: the cost profile, the failure modes, the upgrade path, and whether your own team can still change the system after we stop. unicrew has been building this kind of platform since 2012, with 100+ senior in-house engineers across six countries. Where the honest answer is a smaller piece of work than the one you came for, you get that answer, including when the larger piece would have been ours.
The AWS bills that shock people are almost never one bad decision. They are four years of small ones: an instance sized for a launch that has been over for three years, storage nobody moved to a cheaper class, and traffic crossing a boundary it did not need to cross. We start by making the bill readable per team and per feature. Once somebody can see what their own service costs, most of the saving happens without us.
Oleksandr TrofimovChief Technology Officer, unicrew04Delivery
The order that decides whether a migration lands
Migrations fail at the discovery step, not the coding step. Steps one and two are where this is won or lost, and step two is where you find out whether you are buying a move or a rebuild.
- Map what runs and what talks to whatIncluding the things nobody documented. The integration everyone forgot is the one that breaks on cutover night, and it is always cheaper to find it now than at 2am with the business waiting.
- Decide the cutover per workload, not per programmeLift and shift, re-platform, or rebuild, chosen one workload at a time. Most estates need all three, and picking a single doctrine for the whole thing is the most common reason a timeline slips.
- Build the landing zone and the way backAccounts, networking, identity and guardrails first, then a tested rollback for every workload. A migration without a rehearsed way back is a bet rather than a plan.
- Move, prove it, then tuneMigrate, verify against real traffic, and only then optimise cost and performance. Tuning during the move makes it impossible to tell which change caused a regression. Each step is checked through the same QA and test automation practice we use on our own builds.
05Client voices
Two clients, in their own words
Artelogic has enabled us to develop and roll out products significantly faster than our previous service provider. The team has great knowledge of AWS and Heroku, which has helped us streamline and reduce costs. Artelogic has helped us reduce our AWS costs by 30% or more.
I’m consistently humbled by Artelogic’s performance. Projects of this caliber are hard to outsource. Teams come and go, and this type of work almost never gets done. They’ve kept their priorities straight as they’ve grown and always deliver.
06Stack
The rest of the stack these systems sit in
The technologies that turn up in the same estates, each with its own page if that is the decision you are actually making.
07Questions
The questions that come up on the first call
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on platform work it is often the right shape, because your people hold the operational context. What we will not do is supply engineers and leave the architecture unowned. An architect outside the delivery team reviews the design, the work goes through the same QA practice as our own projects, and the cost profile is our responsibility rather than something you discover later. Team extension is managed teams; handing over the outcome is cloud migration.
It comes down to what you already run, not a feature comparison. A Microsoft estate with Active Directory, SQL Server and an enterprise agreement is normally cheaper and simpler on Azure, because identity and licensing dominate total cost. Where the estate is mixed or the workloads vary, AWS service breadth tends to win. It is a real question, not a preference we are defending.
Usually yes, and it is where we would start. Most overspend comes from instance sizing, storage classes, data transfer and environments nobody switched off, none of which touches application architecture. We agree a measurable target first so the work can be judged. One published engagement cut a client's AWS spend by more than 30% against their previous setup.
Whatever your team can maintain, which in practice means Terraform on most engagements and CDK where the team already lives in TypeScript. We care far more that infrastructure is in version control and reproducible than which tool expresses it. Where you already have a standard, we work inside it rather than introducing a second one for you to maintain.
A scoping call with an engineer rather than a salesperson. For an existing estate we ask for read access to the account and the billing data first, because an hour inside the cost breakdown moves an estimate more than several hours of discussion. What comes back is written: the migration path or the cost profile, what we would do first, and what we would leave alone. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on an estate nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate inside any of them depends on the seniority mix the work needs, so it is quoted rather than listed.
Migrating to AWS, or trying to understand the bill?
Send us the account structure and the workloads. You will get an engineer's read on the migration path and the cost profile, including the parts we would leave alone.