Why These 10 Services Come First
AWS lists over 200 services, which makes "where do I start?" a real question.
//
Search across all documentation pages
AWS lists over 200 services, which makes "where do I start?" a real question.
The answer is that a small core does most of the work. EC2, Lambda, S3, RDS/Aurora, DynamoDB, IAM, VPC, CloudWatch, SNS, and SQS are the services almost every project reaches for first.
This page explains why these ten, and how they group into a mental map you can carry into every other service.
Every application answers a few basic questions, and each of these ten services answers one of them.
Where does my code run? That is compute. EC2 gives you virtual machines you control end to end. Lambda runs functions on demand with no servers to manage. Most workloads sit somewhere on the line between those two.
Where does unstructured data live? That is S3, object storage for files, backups, images, logs, and static assets. It is often the first service a new account uses.
Where does structured data live? Two answers cover most cases. RDS and Aurora give you managed relational databases (PostgreSQL, MySQL, and more) when you need SQL, joins, and transactions. DynamoDB gives you a managed key-value and document store when you need single-digit-millisecond reads at any scale.
Who is allowed to do what? That is IAM, the identity and permission layer. Every SDK call is authorized by IAM, so it underpins all the others.
How do the pieces reach each other? That is VPC, your private network on AWS - subnets, routing, and security groups that decide what can talk to what.
How do I know it is working? That is CloudWatch, which collects metrics, logs, and alarms.
How do components talk without being wired directly together? That is messaging. SNS fans a message out to many subscribers; SQS buffers messages in a queue for a worker to process later.
The reason to learn these together is that they interlock on almost every request.
Picture an order-processing API. A client calls an endpoint. The request lands on compute - a Lambda function or an EC2-hosted service. That compute has an IAM role, so its SDK calls are authorized without stored keys.
The function validates the order and writes it to DynamoDB for fast lookups, or to RDS/Aurora if it needs relational integrity. It stores the customer's uploaded receipt in S3.
To avoid doing slow work inline, it drops a job on an SQS queue. A separate worker pulls the job later and processes it, which keeps the API fast and resilient to spikes.
When the order ships, the system publishes to an SNS topic, which fans the event out to email, a webhook, and another queue at once.
All of this runs inside a VPC, so the database is not exposed to the public internet, and security groups gate traffic. Throughout, CloudWatch records metrics and fires an alarm if the queue backs up or error rates climb.
That single flow touched eight of the ten services. This is why they come first: they are the pieces that show up over and over, in combination.
The SDK patterns are shared too. Every one of these services uses the same client-request-response shape, the same credential resolution, the same ARNs to reference resources, and the same waiters or paginators for long-running or large results. Learn the patterns here and they transfer everywhere.
A useful way to hold the ten in your head is by layer.
| Layer | Services | What it answers |
|---|---|---|
| Identity | IAM | Who can do what |
| Network | VPC | What can reach what |
| Compute | EC2, Lambda | Where code runs |
| Storage | S3 | Where files live |
| Database | RDS/Aurora, DynamoDB | Where structured state lives |
| Messaging | SNS, SQS | How components communicate |
| Observability | CloudWatch | How you see it working |
Two of these layers are foundational in a stricter sense. IAM and VPC rarely deliver business value on their own, but almost nothing else works correctly without them. An SDK call with no permissions fails at IAM; a database with no network path is unreachable no matter how it is configured. That is why they are worth learning early even though they feel like plumbing.
The compute choice between EC2 and Lambda shapes much of the rest. Lambda pushes you toward event-driven designs with SQS and SNS; EC2 gives you long-lived processes and finer control. Neither is universally right.
The database choice between RDS/Aurora and DynamoDB is the other big fork. Relational when relationships and ad-hoc queries matter; DynamoDB when predictable scale and access patterns dominate. Many systems use both.
Beyond these ten, specialized needs bring in more services - EventBridge for richer event routing, ElastiCache for caching, OpenSearch for search, and so on. But those extend the same mental model rather than replacing it, so this core is the right foundation to build from.
They map to the universal layers of an application - identity, network, compute, storage, database, messaging, and observability. Most projects touch several of them on day one, which makes them the highest-leverage starting set.
No. A small app might use only S3, Lambda, and IAM. The list is a menu of the most common first-touch services, not a mandatory checklist.
Because every other SDK call is authorized by IAM. It is invisible when it works and blocking when it does not, so understanding it early prevents a lot of confusing AccessDenied errors.
Lambda is the faster on-ramp for SDK-driven work because there are no servers to manage. Learn EC2 when you need long-running processes or full control of the machine.
Choose RDS/Aurora when you need SQL, joins, transactions, or ad-hoc queries. Choose DynamoDB when your access patterns are known and you want predictable performance at scale. Many systems use both.
Even serverless functions often need a VPC to reach a private database. And any EC2, RDS, or ElastiCache resource lives in a VPC, so the networking concepts apply broadly.
SNS pushes one message to many subscribers (fan-out); SQS holds messages in a queue for a worker to pull when ready (buffering). They complement each other.
Because you cannot operate the other nine safely without visibility. Metrics, logs, and alarms are how you learn that a queue is backing up or errors are rising before users do.
Yes. The client-request-response model, credential resolution, ARNs, waiters, and paginators you learn here work the same way across nearly every AWS service.
No. It is the set most projects assemble from first. Popularity and cost vary, but these are the primitives that recur across the widest range of applications.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Reviewed by Chris St. John·Last updated Jul 23, 2026