Choosing a platform
A side-by-side of the two stacks, and the questions that actually decide it.
Both platforms can build every system on this site. The choice is almost never about model quality, because the same frontier models are available on both and the gap closes within weeks of any release. It is about what your organisation already runs, where your data is allowed to live, and who has to operate the thing at 2am.
What actually decides it
| Question | Leans Azure | Leans AWS |
|---|---|---|
| What does the organisation already run? | Microsoft 365, Entra ID, .NET, existing Azure footprint. | Existing AWS estate, Linux and Python teams, data already in S3. |
| Who operates it? | A team that wants a portal, and prebuilt task services that work without ML depth. | A team comfortable with IAM, infrastructure as code and composing primitives. |
| Where must data live? | Check Foundry model availability in your required region. | Check Bedrock model availability in your required region. |
| How custom is the model? | Custom Vision and Document Intelligence cover a lot without ML work. | SageMaker if you are genuinely training and hosting your own. |
| How fast must the first version ship? | Portal-first flows get to a working demo quickly. | Knowledge Bases get a RAG system running quickly. |
Region availability beats every other criterion
Where they genuinely differ
Prebuilt task services
Azure is ahead here in breadth and in how far you get without ML expertise. Custom Vision will take a tagged image set to a published classifier from a portal, and Content Understanding applies one schema across documents, images, audio and video. On AWS the equivalent capability usually means composing several services yourself.
Composability
AWS is ahead here. Its services assume you are wiring primitives together with IAM, Lambda, Step Functions and EventBridge, which suits teams that want to own the pipeline rather than accept a managed shape.
Identity
If the organisation already runs Entra ID, Azure's managed identity story removes a whole class of key handling: the same credential works locally and in production with no code change. On AWS, IAM roles do the same job well but assume more familiarity.
Retrieval
Bedrock Knowledge Bases is the faster path to a working RAG system. AI Search is the more capable retrieval engine once you need faceting, filtering and hybrid ranking over a large corpus.
What we do in practice
- Follow the existing estate. The platform the client already runs wins unless something concrete disqualifies it. A team fluent in one platform ships better systems on it than a nominally better one they have never operated.
- Prototype on both when the choice is genuinely open. A week costs less than a year on the wrong platform.
- Keep the model call behind your own interface. One module that takes a prompt and returns text. Both our published APIs work this way, and it is why the underlying provider is an implementation detail rather than an architecture.
- Do not build for portability you will never use. An abstraction layer designed to support both platforms costs real complexity to serve a migration that usually never happens. One thin interface, not a framework.
When to use both
Deliberate multi-cloud is worth it in two situations, and neither is “avoiding lock-in” in the abstract:
- A specific capability exists on one platform only, and it is central to the product.
- Residency requires different regions for different markets, and one provider does not serve them all.
Otherwise the second platform is a second set of credentials, a second billing surface, a second on-call runbook and a second thing to keep current. Pick one and know it well.
We can run this assessment with you