· Part 1/6 · Choosing AWS services under constraint
The compute decision is not about compute
AWS's compute guide compares twenty-one services on features. Two questions that appear in no comparison table eliminate most of them before you have opened it.
AWS publishes a decision guide for choosing compute services. It covers twenty-one of them, laid out on the axes you would expect: abstraction level, scaling model, pricing model, primary function. It is a good document. It is also, on its own, almost useless for making the decision, and the reason is worth being precise about.
A feature matrix answers what can each of these do. That is not the question. The question is which of these survive what I am actually constrained by — and the constraints that decide it are rarely columns in anybody’s table.
Two questions, asked before the guide
Who is awake at three in the morning? Not “do we have an ops team” — every team says yes to that. The question is whether there is a named person whose job includes being woken because a kernel CVE landed, an AMI needs rebuilding, or a node group stopped draining. If the honest answer is that the same four engineers who write the product also carry that pager, then every option on the list that hands you an operating system has a cost that does not appear in its price.
What does idle cost? A workload that is busy eight hours a day and asleep sixteen has a different economically correct answer than the same code serving a steady trickle. This is arithmetic, not preference, and almost nobody does it before arguing.
Here is the arithmetic. The default rates are placeholders — put your own in.
Move the workload
Per request6.44 / month
Always on × 258.4 / month
They meet at 28.7M requests a month. At the volume set above, the always-on pair is about 13% busy — which is the other half of the decision, and the half a cost comparison alone will not show you.
Use your own rates
two, if you want to survive an AZ
The four numbers above are placeholders chosen to make the arithmetic legible, not quoted rates. Published prices change and differ by region — take yours off your own bill. Costs are shown in whatever unit you enter.
Compute only. No data transfer, no storage, no load balancer, no NAT gateway, and no salary for whoever keeps the fleet patched — which on a real bill is usually the largest number of all.
The number that matters is not either monthly cost. It is the crossover, and the utilisation figure beside it. A crossover you reach at 4% utilisation and one you reach at 70% are two completely different conversations, and only one of them is about money.
The wrong turn we have watched more than once
A team picks a container platform because the workload is “obviously” a long-running service. Reasonable. Then the requirement arrives that the whole thing must run inside one named jurisdiction, on infrastructure a customer’s auditor can be shown — and it turns out that region selection was never the constraint. The constraint was placement, which is a different axis, and the services that satisfy it are a much shorter list that includes options nobody considered because they were filed under “hybrid” rather than “compute”.
The failure was not the platform choice. It was that placement never entered the decision, because it was not a column.
Run the sieve
Turn on what is true of your situation. Twenty-one becomes three quite fast, and the interesting part is not what survives — it is the sentence attached to each elimination.
Which of these are true for you?
Still standing8 of 8
AWS Lambda
Per-request compute with no machine to own. Scales to zero and back without asking.
AWS Fargate
Containers without nodes. You bring an image and a task definition; the host is somebody else’s problem.
Amazon ECS on EC2
Containers on machines you can see, with a scheduler that is one fewer thing to run.
Amazon EKS
Kubernetes with a managed control plane. The API everyone already knows.
Amazon EC2
A machine. Everything else on this list is a policy about how not to have one.
AWS Batch
Queue-driven jobs with a scheduler that understands "run this when capacity is cheap".
AWS Outposts
AWS hardware in your building, speaking the same APIs.
Amazon ECS Anywhere / EKS Anywhere
The control plane in AWS, the workload on hardware you already have.
Our reading, not a specification. Service behaviour changes — check any elimination that decides something against the service page before you design around it.
If everything is eliminated, that is a real finding and not a bug in the widget. It usually means one of the constraints is negotiable and nobody has admitted which, or that the work does not belong on a managed platform at all.
What an auditor asks
Eighteen months later, nobody will ask which compute service you chose. They will ask three things, and all three are decided by the choice:
- Where did this run, and how do you know? A region is an answer. A named facility is a different answer, and you cannot retrofit one into the other.
- Who could reach the machine? On a serverless runtime the honest answer is “nobody, there is no machine”. On an instance fleet it is a list of people, and that list is now something you maintain and evidence.
- What happened when it failed? Not whether it failed. What the system did next, whether that behaviour was designed, and where it is written down.
None of those are features. All of them are consequences of the abstraction level you picked, which is why the abstraction level is the decision and the service name is a detail that follows from it.
The order we actually use
- Establish the placement constraint, if there is one. It eliminates the most, fastest, and it is the one that cannot be worked around later.
- Establish who owns an operating system. If nobody does, say so out loud and let it remove options rather than discovering it in month four.
- Then do the cost arithmetic, on the two or three that are left.
Doing it in the other order — costing twenty-one options and then discovering that four were never eligible — is how a spreadsheet ends up justifying a decision that was already impossible.
Next in this series: storage, where the durability numbers are all effectively the same and the decision turns entirely on the shape of the access pattern.