· Part 6/6 · Choosing AWS services under constraint
The AI service catalogue is a build-or-buy decision with a residency catch
AWS's ML guide lists twenty-four services. Choosing between them is not a modelling question — it is a question about where inputs travel, what record survives the call, and which of these still exists in three years.
AWS’s machine learning decision guide covers twenty-four services, and it is the one in this series with the shortest shelf life. Some of what it lists is general-purpose infrastructure that will outlive all of us. Some is a narrow managed model for one task, and that category turns over faster than any document about it can.
That is not a criticism of the guide. It is the first thing to understand about the category, and it has a direct design consequence: put every narrow managed model behind an interface you own. Not because any particular one will be withdrawn, but because the replaceable layer should be replaceable in your codebase too. If a call to a document-understanding API is scattered through forty files, the vendor’s roadmap is now your roadmap.
Before you build on any service in this class, open its service page and check its current status. This applies to every dated document, including this one.
The three questions that decide it
Choosing here is a build-or-buy decision, and the axes are not accuracy.
Where do the inputs go, and what is kept? A managed model is an API call, and that call carries your data across a boundary. The questions that matter are: which region processes it, whether anything is retained, and whether that retention is a contractual commitment or a configuration setting somebody could change. For a customer’s identity documents or a patient record, this is not a procurement detail — it is the design.
What record survives the call? A managed service returns an answer and often a confidence score. That is not a decision record. Reconstructing why a system did what it did needs the inputs, the retrieved context, the model and version, the prompt if there was one, and the human who approved the outcome. None of that assembles itself, and none of it can be added retrospectively. If you do not build it on day one, the answer to the question in month twenty is that there is no answer.
Who evaluates it? This is the one that gets skipped. Buying a managed model removes the training problem and leaves the harder one: knowing whether it is good enough on your data, and whether last week’s prompt change helped or merely changed things. That requires an evaluation set built from your own historical cases, and somebody who owns it. A team with no ML engineers can absolutely buy a managed model. They still need that person, and the role is usually unfilled because the service looked like it removed the need.
Run the sieve
Which of these are true for you?
Still standing7 of 7
Amazon Bedrock
Foundation models behind one API, without hosting any of them.
Amazon SageMaker
The full lifecycle — training, tuning, hosting, monitoring — for teams that own their models.
Amazon Textract
Structure out of documents: forms, tables, key-value pairs.
Amazon Comprehend
Entities, sentiment and classification over text, without a model to own.
Amazon Kendra
Managed enterprise search with connectors and document-level access control.
Self-hosted models on EC2 or EKS
Weights you hold, on machines you name. The option that answers a residency question outright.
Amazon Augmented AI (A2I)
A human review step wired into an automated pipeline, with the reviewer’s decision recorded.
Our reading, not a specification. Service behaviour changes — check any elimination that decides something against the service page before you design around it.
Turn on inputs must not leave a jurisdiction we name and nobody here trains or evaluates models together. That pair is extremely common — it is close to the default position of a mid-sized European company — and it is close to contradictory. Residency pushes towards holding the weights yourself; no ML capability pushes hard the other way.
There is no service that resolves it. What resolves it is narrowing the problem until the residency constraint applies to less of it: keeping the sensitive fields out of the call entirely, or doing the sensitive part deterministically and letting the model work on what is left. That is engineering, and it is the work the catalogue cannot do for you.
The pattern that survives all of this
Across every project in this class, one shape keeps being the right one:
- The model gets judgement. Code gets the facts. Anything that must be exact — a total, a date, an identifier, an entitlement — is computed and placed into a fixed slot. The model writes the prose around it. A paraphrased number is a liability, and the paraphrasing is not a bug you can prompt away.
- Retrieval respects the asker. If the store enforces nothing, the index built from it enforces nothing, and a summary that crossed a permission boundary is a leak that leaves no trace in any log.
- Every call is attributable and bounded. Which model, which version, on whose behalf, and what the ceiling was.
Those three do not depend on which service you picked, which is the point. They are what makes the thing defensible, and they are the part no decision guide has a column for.
Closing the series
Six guides, six categories, one recurring shape. In every case the vendor’s document was accurate and the decision was made somewhere else — by placement, by who is on call, by whether a read is attributable, by what happens when a consumer dies mid-batch, by who may see which rows.
None of those are features. All of them are questions about the organisation around the system, and the reason they are not in the comparison table is that the vendor cannot know the answers. You can. Ask them first, and the service selection tends to make itself.