What do Netflix, a two-person startup, and a government agency have in common? They all rent computing power from the same place. Amazon Web Services started in 2006 with two products, Amazon S3 for storage and Amazon SQS for messaging, and grew into a catalog of more than 200 services. That size is the problem. Most teams do not need 200 services. They need six or seven, chosen well.
This guide walks through what AWS services are, how the major families fit together, and where newcomers usually go wrong. It stays practical: what each service does, when to pick it, and when a simpler option wins.
What AWS services are, in plain terms
AWS is a collection of on-demand cloud products. Instead of buying servers, teams rent virtual machines, storage, databases, and networking by the hour or by the gigabyte. The official AWS overview documentation groups the portfolio into categories such as compute, storage, databases, networking, security, analytics, and machine learning.
The mental model that helps most: AWS sells building blocks, not finished solutions. A database service gives you a running database engine. It does not design your tables, tune your queries, or decide when to back up. That remains your job.
The compute layer: where code runs
Compute is the part people picture first. Amazon EC2 provides resizable virtual servers called instances. You pick an operating system, a size, and a network, and you get a machine you fully control. It is the closest thing to renting a traditional server.
AWS Lambda takes a different path. It is a serverless service that runs code in response to events, with no servers to provision. Upload a function, connect it to a trigger such as a file upload or an HTTP request, and it runs when needed. The official Lambda Developer Guide explains the model in detail. Lambda suits short, event-driven tasks. It fits poorly with long-running processes or workloads that need persistent local state.
A rough decision rule:
| Workload | Better fit | Why |
|---|---|---|
| Legacy app needing full OS control | EC2 | You manage the machine end to end |
| Short event-driven function | Lambda | No servers, scales automatically |
| Steady containerized app | Container services | Balance of control and portability |
| Batch processing on a schedule | EC2 or managed batch tooling | Predictable, long-running jobs |
Storage: objects, blocks, and files
Storage confuses newcomers because AWS offers three shapes of it, and they are not interchangeable.
Amazon S3 is object storage. You store files as objects inside buckets, addressed by key. The S3 User Guide documents a durability design of 99.999999999 percent, often called eleven nines. That number describes the design target for object durability, not a promise that you will never delete something by accident.
Amazon EBS provides block storage volumes attached to EC2 instances. Think of it as the virtual hard drive for a server.
Amazon EFS is managed file storage that multiple machines can mount at once.
The common mistake is treating S3 like a file system. It is not one. Renaming a “folder” in S3 is really a copy-and-delete operation, and listing millions of objects has costs and quirks. Design keys with that in mind from day one.
Databases: relational, NoSQL, and Aurora
Amazon RDS is a managed relational database service supporting engines including MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. AWS handles patching, backups, and failover. You still own schema design, indexing, and query performance. The RDS User Guide is the place to start for engine-specific behavior.
Amazon DynamoDB is a managed NoSQL key-value and document database built for predictable latency at scale. It rewards teams that design access patterns before writing code. It punishes teams that treat it like a relational database and expect flexible ad-hoc queries.
Amazon Aurora is a MySQL- and PostgreSQL-compatible database built by AWS, aimed at higher performance and availability than standard engines.
Practical advice: pick the database that matches your access patterns, not the one with the most exciting marketing. A relational database handles most business applications fine. Reach for DynamoDB when you genuinely need single-digit-millisecond reads at high volume and can model your queries up front.
Networking and content delivery
Amazon VPC lets you define isolated virtual networks with your own IP ranges, subnets, and routing. Nearly everything else lives inside a VPC, so it is worth learning early. The VPC User Guide covers the concepts.
Amazon CloudFront is a content delivery network that caches content at edge locations close to users. Route 53 is a DNS service that also handles health checks and routing policies.
The classic beginner error is putting a database in a public subnet because it was easier. Fix network layout before workloads multiply. Retrofitting private subnets later is possible, but it is tedious and risky.
Identity and security: the part that decides everything
AWS Identity and Access Management, or IAM, controls who can do what. Users, groups, roles, and policies define access. The IAM User Guide explains the model, including the principle of least privilege.
AWS also publishes the shared responsibility model, which splits duties: AWS secures the cloud itself, while customers secure what they put in it. Misreading that line causes real incidents. An unsecured S3 bucket is a customer problem, not an AWS one.
Two habits pay off immediately:
- Never use the root account for daily work. Create an administrative identity and enable multi-factor authentication.
- Grant permissions through roles and groups, not by attaching broad policies to individuals.
Related decisions about ownership and accountability matter as much as the technical setup. A useful read on that front is the piece on who owns an AI service after the pilot, which applies the same logic to AI workloads.
Management, governance, and observability
AWS CloudTrail records API activity for auditing, answering the question of who did what and when. The CloudTrail User Guide covers trails and event history.
Amazon CloudWatch handles monitoring: metrics, logs, alarms, and dashboards. Most teams underuse it at first and then scramble when something breaks at 2 a.m.
AWS Organizations manages multiple accounts, which is how mature teams separate environments and business units.
A pattern that works: one account per environment, centralized logging, and budget alarms from week one. Surprise bills are the most common complaint from new cloud teams, and they are usually caused by forgotten resources, not by pricing tricks. Planning capacity sensibly before launch helps; the guide to planning capacity for a new cloud service walks through the sizing questions worth answering early. (Cloud computing)
Analytics and machine learning
Amazon Athena queries data sitting in S3 using standard SQL, with no cluster to manage. It suits occasional analysis of logs and data lakes. The Athena documentation explains how it works.
Amazon SageMaker is a platform for building, training, and deploying machine learning models. It covers the whole workflow, which is helpful for teams with data scientists and overkill for teams without them.
The practical caution: analytics and ML services are where curiosity meets cost. A single unpartitioned Athena query over a large dataset can scan enormous amounts of data. Partition your tables and test on small samples first.
Global infrastructure: Regions and Availability Zones
AWS organizes its infrastructure into Regions, which are geographic areas, and Availability Zones, which are isolated data-center clusters within a Region. The AWS global infrastructure documentation describes the model. Region and zone counts change often, so treat any specific number as dated the moment you read it.
The design lesson is simple: spread critical workloads across multiple Availability Zones, and choose a Region close to your users and consistent with your legal obligations. Data residency rules in some jurisdictions restrict where certain data can live.
Common mistakes that cost real money and time
Experience across many cloud migrations surfaces the same errors repeatedly.
Skipping the account structure. Teams build everything in one account, then discover they cannot separate billing, permissions, or blast radius. Set up multiple accounts early.
Ignoring the shared responsibility line. Assuming AWS handles patching, backups, or access control for your application leads to gaps. Read the split carefully.
Over-engineering on day one. A startup with ten users does not need a multi-region, multi-account architecture. Start simple, then add complexity where real pressure exists.
Forgetting to tag resources. Tags enable cost allocation, automation, and cleanup. Untagged resources become invisible spending.
Treating serverless as free. Lambda charges per request and per compute duration. A runaway loop can generate a surprising bill. Alarms exist for a reason.
Not reading the service quotas. Every AWS service has limits. Hitting one during a launch is avoidable with a five-minute check.
How to choose your first set of services
A sensible starting stack for most web applications looks like this:
- A VPC with public and private subnets across at least two Availability Zones.
- EC2 instances or a container service for the application tier.
- RDS for the primary relational database.
- S3 for file storage and static assets.
- CloudFront in front of public content.
- IAM roles with least privilege, plus CloudTrail and CloudWatch from day one.
Add Lambda for glue tasks, DynamoDB when access patterns demand it, and analytics services when data volume justifies them. Keeping an eye on news and announcements helps teams spot relevant changes without chasing every launch. (News)
Conclusion
AWS services reward a clear head. The catalog is enormous, but the working set for most teams is small: compute, storage, a database, networking, identity, and monitoring. Get those six right, structure your accounts sensibly, and resist the urge to adopt every new service the moment it appears. The teams that do well in the cloud are rarely the ones using the most services. They are the ones who understand the handful they use, and who know exactly where their responsibility ends and Amazon’s begins.
Frequently asked questions
What are AWS services?
AWS services are on-demand cloud products covering compute, storage, databases, networking, security, analytics, and machine learning. Teams rent them instead of buying hardware, paying for what they use. The portfolio has grown past 200 services since launching in 2006 with S3 and SQS.
How many AWS services are there?
AWS has cited a figure of more than 200 services for several years. The exact count shifts as new services launch and older ones are renamed or retired. Treat any specific number as a snapshot rather than a fixed fact.
What is the difference between EC2 and Lambda?
EC2 gives you a virtual server you manage, including the operating system. Lambda runs your code in response to events with no servers to provision. EC2 suits long-running or highly customized workloads; Lambda suits short, event-driven tasks.
Do I need to use all AWS services?
No. Most applications need a small core: compute, storage, a database, networking, identity management, and monitoring. Adding more services increases cost and complexity, so adopt them only when a real requirement appears.
Is AWS secure?
AWS secures the underlying infrastructure, but customers secure what they build on top of it. That split is called the shared responsibility model. Misconfigured storage buckets and overly broad permissions remain common causes of incidents, and both are customer-side responsibilities.
Which AWS database should a beginner choose?
Amazon RDS is usually the safest starting point because it supports familiar relational engines such as MySQL and PostgreSQL. DynamoDB makes sense when you need very fast key-based access at scale and can design your queries in advance.
