AWS Services: What You Should Know

A field-guide breakdown of AWS services: the core categories, the handful most teams actually use, and how to choose without drowning in the catalog.

Track: Cloud Engineering. Era: the sessions where a presenter tried, and failed, to summarize the whole AWS catalog in fifty minutes. Modern lesson: the catalog is enormous, but the services a working team actually uses fit on one whiteboard.

AWS services are the individual building blocks of Amazon Web Services, compute, storage, databases, networking, security, and operations offerings you assemble into a system. There are hundreds, but they cluster into a small number of stable categories, and most teams run on a couple dozen. As of 2026, confirm current service names and capabilities against the official AWS documentation.

The recovered track

Every cloud conference had a version of the same doomed talk: someone attempting to cover “all of AWS” in one session. The slide count was absurd, the audience glazed over, and the useful part was never the list. It was the moment the presenter said “but honestly, you’ll only use these.” That sentence was worth the whole talk.

The catalog kept growing. The advice didn’t change. AWS adds services faster than any single team can track, and the durable skill is not knowing them all. It’s recognizing which category a problem belongs to, then picking the right service within it.

What are the core AWS service categories?

The catalog is large, but the AWS documentation organizes it into stable groups. These categories barely change even as new services appear inside them.

If you can place a new requirement into one of these buckets before reaching for a service, you’ve done the hard part. The mistake teams make is shopping the catalog by service name instead of by problem category.

Which AWS services do most teams actually use?

A small set carries most real workloads. These are the ones worth knowing well:

• EC2, virtual machines, the workhorse for anything that needs a long-running server.
• S3, object storage for files, backups, static assets, and data lakes.
• Lambda, event-driven serverless compute, covered in our AWS Lambda field guide.
• RDS / DynamoDB, managed relational and NoSQL databases, so you don’t run database servers by hand.
• VPC, the isolated network everything else lives inside.
• IAM, the permission system that decides who can do what.
• CloudWatch, metrics, logs, and alarms, the observability backbone.

That’s roughly the whiteboard. A team can build serious systems with just these, layering in specialized services only when a concrete need appears. The full set of building blocks and how they fit together is the subject of our AWS cloud overview.

How do you choose the right AWS service?

Naming the tradeoff beats declaring a favorite. A few decision rules keep teams out of trouble:

• Match the service tier to your ownership appetite. A self-managed EC2 instance gives control and hands you patching. A managed service like RDS or Lambda hands AWS more of the stack, and shifts the shared responsibility model boundary accordingly. Decide how much you want to own before you pick.
• Prefer the managed option until you have a reason not to. Running your own database on EC2 is sometimes right, but the default should be the managed service unless control or cost demands otherwise.
• Don’t adopt a service you can’t describe in one sentence. If you can’t say what problem it solves and what you now own, you’re not ready to use it.
• Treat infrastructure as reviewable code. Declarative tools like CloudFormation make service choices reproducible, the same discipline our CI/CD pipeline field guide applies to application delivery.

A practical decision rule: start from the category, pick the most managed service that meets the requirement, and only drop to a lower-level service when you hit a real constraint. Over-provisioning control you don’t need is how teams accumulate operational debt.

How do AWS services connect to each other?

The catalog talks rarely explained the part that actually matters: services are only useful when they compose, and a few connective services do most of that work.

Three categories act as the glue for almost every system:

• Networking (VPC). Nearly everything runs inside a virtual private cloud, an isolated network you define. Compute instances, databases, and load balancers live in it, and its subnets, routing, and security groups decide what can talk to what. Get the network wrong and nothing else works.
• Identity (IAM). Every interaction between services is governed by permissions. A Lambda function reading from S3, an EC2 instance writing to a database, each requires an explicit grant. IAM is the connective tissue of access, and over-broad grants are the most common security failure.
• Events and messaging. Queues, notifications, and event buses let services hand work to each other without tight coupling. This is how a file upload triggers processing, or a spike of requests gets buffered instead of dropped.

Understanding these three is what turns a pile of individual services into a system. A team that knows compute and storage but treats networking and identity as afterthoughts ends up with components that either can’t reach each other or can reach far too much.

What mistakes do teams make choosing services?

The recurring failure modes show up in nearly every real AWS account, and naming them prevents most of them:

• Catalog shopping. Picking services by browsing names instead of starting from the problem category. The result is a stack assembled from whatever looked interesting rather than what the workload needs.
• Reaching for the lowest level by default. Running databases and queues by hand on EC2 when a managed service would do the same job with less operational ownership. Control you don’t need is debt you do.
• Ignoring data-transfer cost. Wiring services across regions or pushing heavy traffic out to the internet without realizing the transfer charges, which surface only on the invoice.
• One person owns the architecture. When service choices live in a single engineer’s head, every change is risky. Declarative infrastructure and review make the choices legible to the whole team.

A practical habit: when adding a service, ask which existing service it connects to and what permission that connection requires. If you can’t answer, you’re not ready to wire it in. The same review discipline our AWS cloud overview recommends for the platform as a whole applies to every service you add to it.

What changed, and what didn’t

AWS has added entire service categories over the years, machine learning, analytics, edge computing, and renamed or re-scoped existing ones. Any specific capability you read about should be re-checked, because the catalog moves faster than documentation about it.

What didn’t change is the lesson buried in those overstuffed catalog talks: you will use a fraction of what exists. The skill that lasts is categorization and restraint, knowing which bucket a problem belongs to, choosing the most managed service that fits, and ignoring the rest of the catalog until you genuinely need it.

Related reading

• AWS Cloud: What You Should Know
• AWS Lambda: What You Should Know
• CI/CD Pipeline: What It Is and How To Ship Reliably

Sources

• “AWS Documentation”, Official service catalog organized by category.
• “Shared Responsibility Model”, AWS, How the responsibility boundary shifts between service tiers.