Lesson 1 — What you are actually renting
Each major cloud provider lists dozens of AI services. The names overlap, the boundaries are unclear, and the documentation assumes you already know which one you want.
There are four categories. Identify yours and the catalogue shrinks to a handful of options.
Category 1 — Raw compute
A machine with accelerators, and nothing else. You install what you like and manage it yourself.
Use it when you want control, have your own tooling, or need a specific hardware configuration. Also when you are simply training something for a few hours and want no platform between you and the hardware.
What you handle: drivers, environments, data movement, scheduling, everything.
What it costs: per hour, per machine, whether or not you are using it. That last clause is where most surprise bills originate.
This category also includes the specialist GPU providers outside the three major clouds, which are frequently cheaper for pure training work and offer less around it.
Category 2 — Managed AI APIs
A trained model behind an endpoint. You send data, you get a result. No training, no data, no infrastructure.
| Service type | What it does |
|---|---|
| Speech to text | Transcription, usually with speaker separation |
| Text to speech | Synthetic voices |
| Translation | Between dozens of languages |
| Document extraction | Text, tables and fields from scans and PDFs |
| Image labels and moderation | Standard object and content categories |
| Face detection | Detection and matching, with real restrictions in some jurisdictions |
| Text analysis | Sentiment, entities, key phrases |
Use these unless you have a reason not to. For general tasks they outperform what a small team would build, they need no training data, and they cost per request rather than per hour.
Where they disappoint is anything specific to your domain: your defect categories, your document layouts, your industry vocabulary. A general document extractor reads an invoice well and does not know which of your fields matter.
What to check before adopting one: whether your data is retained, whether it is used to improve the service, which region processes it, and what happens when the provider changes the model underneath you — because they will, and your output will shift without any change on your side.
Category 3 — Machine learning platforms
The environment for building your own models: managed notebooks, training job orchestration, experiment tracking, a model registry, deployment endpoints, monitoring, pipelines. SageMaker, Azure Machine Learning and Vertex AI are the three.
Use one when you are training custom models with a team and want the MLOps machinery from the previous course without building it.
What you gain: much of lesson 2 to 4 of the MLOps course as configuration rather than code. Managed training that shuts itself down, a registry with staging, endpoints with traffic splitting, monitoring with drift detection.
What you pay: a premium over raw compute, some rigidity, and a real amount of platform-specific knowledge.
The trap worth naming: these platforms are large, and adopting one wholesale for a single model means learning a great deal of surface for benefit you will not use. Most of them can be adopted piecemeal — managed training jobs alone, or endpoints alone — and that is usually the right way in.
Category 4 — Hosted foundation models
Access to large pretrained models you could not practically run yourself, priced per token or per image.
This covers the language model APIs, the image generators, and the provider-neutral gateways — AWS Bedrock, Azure AI Foundry, Google's model APIs — which offer several model families through one interface. The gateways are worth knowing about because they reduce switching cost between model providers to a configuration change, which is genuinely valuable in a market where the best model changes every few months.
Use these for anything in the generative AI or LLM territory, unless data residency forbids it or volume makes self-hosting cheaper.
Choosing the category
The order in that diagram is deliberate. Each step down means more work and more control, and teams routinely start at the bottom when the top would have done.
The question underneath all of this
Build or buy applies per capability rather than per project, and the answer usually differs across the pieces of one system.
| Use a managed service when | Build your own when |
|---|---|
| The task is general and well served | The task is specific to your domain |
| You have no labelled data | You have labelled data and it encodes real advantage |
| Volume is low or unpredictable | Volume is high and steady, making per-request pricing painful |
| Speed to a working system matters most | Cost per prediction at scale matters most |
| You lack the expertise to maintain a model | You have it, and a plan for who maintains it in a year |
| The capability is not your differentiator | It is |
The last row decides more than the others. A logistics company should not be building a speech transcription model. It probably should be building its own delivery-time prediction, because that is where its data and its advantage are.
Building a custom model for a task a managed API already handles. It happens because building is more interesting than integrating, and because "we need control" sounds like a reason. Test the managed API on fifty of your real examples first — it takes an hour, and it either saves you a quarter of work or gives you a concrete reason to build.
In three sentences
Cloud AI offerings reduce to four categories: raw compute you manage entirely, managed APIs that solve general tasks with no data or training, machine learning platforms that supply MLOps machinery as configuration, and hosted foundation models priced per token. Work down that list rather than up, because each step means more work and more control, and teams routinely build custom models for tasks a managed API already handles — which is the most common expensive mistake in this area. The build-or-buy question applies per capability rather than per project, and the deciding row is whether the capability is your differentiator: use a service for anything general, build where your own data encodes real advantage and you have a plan for who maintains it next year.