Ask any engineering team which AWS services they use and you will get a list. Ask them to prove it and the list changes. Some entries were decommissioned two years ago. Some were never wired up — someone granted the IAM permission during a spike and the code never followed. And several services the platform genuinely depends on will be missing entirely, because nobody thinks of Parameter Store or STS as a service; they think of them as plumbing.
This page is the corrected version of that list for a four-system production estate: three serverless platforms built on Lambda and SAM, and one container platform on ECS Fargate. Forty-five services, each linked to its official developer guide, grouped by the job it does rather than by the order AWS announced them.
It is worth saying up front how it was built, because the method matters more than the list. Nothing here came from memory or from an architecture diagram. Every entry is backed by something a machine can find in the repository.
MethodInventory from evidence, not recall
An accurate service inventory is a search problem, and the trick is knowing that a service leaves several independent kinds of fingerprint. Grep for only one and you will miss a third of the estate. Six signals, run across every repository:
# 1 — declared infrastructure (SAM / CloudFormation)
rg 'Type: AWS::(\w+)::' -o --no-filename | sort -u
# 2 — declared infrastructure (Terraform)
rg 'resource "aws_(\w+)"' -o --no-filename | sort -u
# 3 — runtime SDK calls (Python)
rg 'boto3\.(client|resource)\(' -o --no-filename | sort -u
# 4 — runtime SDK calls (JavaScript / TypeScript)
rg '@aws-sdk/client-[\w-]+' -o --no-filename | sort -u
# 5 — IAM policy statements (catches the aspirational ones)
rg '"?(s3|ssm|sqs|events|bedrock):[A-Z]\w+' -o --no-filename | sort -u
# 6 — CI/CD steps (deploy targets never appear in app code)
rg 'aws-actions/' .github/workflows/Each signal catches something the others miss. Declared infrastructure finds what exists but not what the code actually calls. SDK calls find the reverse — plenty of services are used without ever being declared, because they belong to a shared platform account and the application only holds a permission to reach them. IAM statements are the most interesting signal of all, because they catch intent: a permission is granted at the moment someone plans to use a service, which is rarely the moment the code ships.
The gap between "we have an IAM grant for it" and "we call it in production" is where every stale architecture diagram is born.
Run all six and you get two lists rather than one: services in use, and services merely referenced. Both are worth writing down. The second is shorter, more embarrassing, and considerably more useful.
01 · Five servicesCompute & containers
The premise: most of the estate is serverless, and the one exception exists for a specific, defensible reason.
Lambda is the default compute everywhere. The single container platform runs a long-lived Node service that holds WebSocket connections open — a workload functions handle badly, and the clearest signal you will get for when to reach for a container instead. That one decision pulls in ECS, Fargate and a load balancer, none of which the serverless systems need at all.
02 · Five servicesApplication integration & eventing
The premise: services announce facts; they do not call each other.
This group is the architecture. EventBridge carries every domain event, SQS gives each consumer a buffer and a dead-letter queue, and Firehose forwards the same stream into search so the events that drive the system double as its audit trail. If you read one group as a description of how the platform is put together, read this one.
03 · Six servicesStorage & databases
The premise: "the database" is rarely one thing, and the interesting entry is the connection pool.
Relational Postgres is the system of record. The entry worth dwelling on is RDS Proxy: Lambda's concurrency model and Postgres's connection limit are fundamentally incompatible, and a proxy is how you reconcile them without rewriting the application. Discovering you need it at two in the morning, under load, is a rite of passage best skipped.
04 · Seven servicesNetworking & content delivery
The premise: the network is the part nobody documents and everybody debugs.
Two different front doors live here, and the difference is the clearest architectural fault line in the estate: serverless traffic arrives through API Gateway and CloudFront, container traffic through an Application Load Balancer. Everything else — DNS, certificates, the VPC, cross-account routing — is shared underneath both.
05 · Seven servicesSecurity, identity & configuration
The premise: this is the group people leave off the list, and the group that runs everything.
Parameter Store deserves special mention. It is not glamorous, but it is the mechanism by which stacks discover each other: shared infrastructure publishes every identifier it creates to a well-known parameter path, and each service template resolves those at deploy time instead of hardcoding an ARN. That one convention is what makes it safe to delete a service stack without taking a database down with it.
06 · Seven servicesObservability & operations
The premise: in a multi-account estate the hard problem is not collecting telemetry — it is looking at all of it in one place.
Metrics, logs and traces are per-account by default, which means an incident spanning two accounts means two browser tabs and a lot of clock arithmetic. CloudWatch's cross-account observability links solve this properly: workload accounts share telemetry into one monitoring account, and you investigate without account boundaries. It is the least-known service on this list and the one that changes an on-call shift the most.
07 · Two servicesAI & document processing
The premise: two very different shapes of AI workload, and the boring one earns more.
Textract is the unglamorous, high-value one: structured extraction from documents, running as an ordinary step in an ordinary pipeline. Bedrock covers the two cases Textract cannot — reasoning over extracted content, and a low-latency bidirectional speech model behind a voice interface. Notably, both are called as plain SDK operations from services that already existed. Neither required a new architecture.
08 · Six servicesDelivery, email & governance
The premise: how code reaches production, how the platform reaches people, and who is allowed to do either.
The split between Terraform and CloudFormation is deliberate, and covered at length in the infrastructure part of the workshop series: shared and stateful belongs to Terraform; per-service compute belongs to SAM. SES sits here rather than under integration because in practice it is a delivery concern — and because it does inbound as well as outbound, receiving mail into an ingestion pipeline through receipt rules.
09 · The honest sectionReferenced but not in use
This is the part most inventories omit, and the part most worth writing. Several entries turned up with a fingerprint but no pulse — an SDK dependency with no call site, an IAM grant with no code behind it, a resource declared and then orphaned when the design moved on.
Why this matters more than the main list. Every one
of these reads, to the next engineer, as a deliberate decision. A
permission implies a plan. A dependency in
package.json implies a call site. Someone
will eventually build on the assumption and be wrong.
They cost something real, too: a standing grant nobody uses is access to a service nobody monitors.
The patterns are worth recognising, because yours will look the same:
- The grant that outlived the spike. Permissions added while prototyping and kept when the prototype was reverted. The call sites are commented out; the policy is not.
- The SDK client with no caller. A dependency installed for a scheduling feature that was designed, specced, and never built.
- The placeholder that shipped. A template with an un-substituted identifier that deployed cleanly, because nothing ever invoked the path that would have used it.
- The library mistaken for the platform. A client-side auth SDK in the frontend that shares a brand name with a hosting product the team does not use and never has.
- The resource the design outgrew. A private link provisioned for an API that ended up behind a load balancer instead. Harmless, confusing, still billed.
The fix is not to delete them in a panic. It is to write them down, in the same document as the real inventory, so the ambiguity stops costing the next person an afternoon.
The Through-Lines
Read the list as a shape rather than as forty-five entries and a few things stand out:
- The plumbing outnumbers the product. Seven services in security and configuration, seven in observability, six in delivery — twenty of forty-five before a single line of business logic runs. Budget for this.
- One workload decided an entire group. A single long-lived socket server is why ECS, Fargate, a load balancer and Redis appear at all. Service groups follow workloads, not preferences.
- Managed glue beats custom glue. Parameter Store as a service registry, EventBridge as the integration layer, OIDC instead of stored keys. Each replaces something a team would otherwise hand-roll and then own forever.
- Boring services carry the most risk. Nobody draws Parameter Store or STS on the architecture diagram. Either one takes the whole estate down.
- An inventory needs a date and a method. Without both it is folklore. With them, the next person re-runs six searches and sees precisely what changed.
If a service on this page is new to you, the link next to it goes to the official developer guide — the one AWS maintains, not a blog post about it. That is the entire point of the format.