Provider Guides 7 min read Updated

AWS Explained: Core Services and How the Platform Is Organized

A practical tour of AWS core services, from Regions and accounts to EC2, S3, RDS, VPC and IAM, with a sensible learning order for teams.

AWS core services illustration: stacked server units in front of a large circle on a dark background

Amazon Web Services offers hundreds of products, but most real workloads are built from a small set of AWS core services: compute, storage, databases, networking and identity. This guide explains what those building blocks do, how AWS organizes them geographically and administratively, and which ones a new team should learn first.

How the AWS platform is organized #

Before looking at individual services, it helps to understand the containers everything lives in. Almost every confusing moment for new AWS users (a missing resource, an unexpected bill, a permission error) traces back to one of three things: the wrong Region, the wrong account, or the wrong IAM permissions.

Regions, Availability Zones and edge locations

A Region is a separate geographic area, such as us-east-1 (N. Virginia) or eu-west-1 (Ireland). Most services are regional: an EC2 instance or RDS database you create in one Region does not appear in the console when another Region is selected. Choose Regions based on user latency, data residency requirements and whether the services you need are available there.

Each Region contains multiple Availability Zones (AZs), which are one or more physically separate data centers with independent power and networking. Spreading instances or database replicas across at least two AZs is the standard way to survive a data center level failure. AWS also runs edge locations for CloudFront and Route 53, plus Local Zones and Wavelength Zones for workloads that need to sit closer to specific cities or mobile networks.

Accounts and AWS Organizations

An AWS account is both a billing boundary and a security boundary. Resources in one account are isolated from another unless you explicitly grant cross-account access. Many teams use several accounts (for example production, staging and a sandbox) rather than one shared account, which limits the blast radius of mistakes.

AWS Organizations ties those accounts together under a management account. It provides consolidated billing, organizational units for grouping accounts, and service control policies (SCPs) that set maximum permissions for every account in a group. AWS Control Tower builds on Organizations to set up a multi-account landing zone with guardrails.

Global services versus regional services

A few services are global rather than regional. IAM, Route 53 and CloudFront are managed globally, while EC2, RDS, Lambda and most others are scoped to a Region. S3 bucket names are globally unique, but each bucket’s data is stored in the Region you choose when creating it.

The core service families #

The table below maps the most commonly used services to their job. It is not a complete catalog, but it covers the pieces that show up in most architectures.

Category Service What it does
Compute Amazon EC2 Virtual machines with a wide choice of instance types, operating systems and pricing options
Compute AWS Lambda Runs functions in response to events without managing servers; billed per request and duration
Containers Amazon ECS, Amazon EKS, AWS Fargate Container orchestration (AWS native or Kubernetes), with Fargate as a serverless way to run containers
Object storage Amazon S3 Durable object storage for files, backups, static assets and data lakes
Block and file storage Amazon EBS, Amazon EFS EBS provides disks for EC2 instances; EFS provides a shared NFS file system
Relational databases Amazon RDS, Amazon Aurora Managed MySQL, PostgreSQL, MariaDB, SQL Server, Oracle and Db2, plus AWS’s own Aurora engine
NoSQL Amazon DynamoDB Serverless key-value and document database with single-digit millisecond reads at scale
Networking Amazon VPC, Elastic Load Balancing Private networks, subnets, route tables and load balancers
DNS and CDN Amazon Route 53, Amazon CloudFront Domain registration and DNS, plus a content delivery network
Identity AWS IAM, IAM Identity Center Users, roles and policies, plus single sign-on for people across accounts
Observability Amazon CloudWatch, AWS CloudTrail Metrics, logs and alarms, plus an audit trail of API calls
Infrastructure as code AWS CloudFormation, AWS CDK Define infrastructure in templates or general-purpose code and deploy it repeatably

Compute: choosing between EC2, containers and Lambda #

EC2 gives you the most control. You pick an instance family (general purpose, compute optimized, memory optimized, storage optimized, accelerated), an Amazon Machine Image, and a size. You are responsible for patching the operating system and everything above it. EC2 suits lift-and-shift migrations, legacy applications and anything that needs specific OS-level configuration.

Containers are a middle ground. ECS is AWS’s own orchestrator and is simpler to operate; EKS runs upstream Kubernetes and makes sense if your team already uses Kubernetes tooling. Either can run on EC2 instances you manage or on Fargate, where AWS manages the underlying hosts.

Lambda removes servers from your view entirely. It fits event-driven work such as processing S3 uploads, handling API Gateway requests or running scheduled jobs. It has limits on execution time and package size, so long-running or stateful processes usually belong elsewhere.

If you are still deciding how much of the stack you want to manage, our explainer on IaaS, PaaS and SaaS with real cloud examples gives a useful frame.

Storage and databases #

S3, EBS and EFS

These three are often confused. S3 stores objects accessed over HTTPS by key; it is not a disk you mount. EBS volumes are block devices attached to a single EC2 instance in a single AZ (with limited multi-attach support for specific volume types). EFS is a managed NFS file system that many instances can mount at once.

S3 offers several storage classes (Standard, Intelligent-Tiering, Standard-IA, Glacier tiers and others) with different retrieval characteristics and costs. Lifecycle rules can move objects between classes automatically. By default, new buckets block public access, and it is worth leaving that setting on unless you have a specific reason.

RDS, Aurora and DynamoDB

RDS handles provisioning, backups, patching and optional Multi-AZ failover for common relational engines. Aurora is a MySQL and PostgreSQL compatible engine with a distributed storage layer, and it has a serverless option that scales capacity with demand. DynamoDB is a different model entirely: you design around access patterns and partition keys rather than joins, and in return you get predictable performance without managing servers.

Networking basics you cannot skip #

Every EC2 instance, RDS database and many other resources live inside a Virtual Private Cloud. Each Region gives new accounts a default VPC, which is convenient for experiments but usually replaced with a purpose-built VPC for production.

  • Subnets are ranges within a VPC tied to one AZ. Public subnets route to an internet gateway; private subnets do not.
  • Security groups are stateful firewalls attached to instances and other resources. Network ACLs are stateless and apply at the subnet level.
  • NAT gateways let private resources make outbound connections. They are billed per hour and per GB processed, which surprises many new users.
  • Load balancers come in Application (HTTP/HTTPS), Network (TCP/UDP) and Gateway flavors.

For a provider-neutral walkthrough of these concepts, see our guide to VPCs, subnets, firewalls and load balancers.

Identity and the shared responsibility model #

IAM decides who can do what. Principals (users, roles, and federated identities) receive permissions through JSON policies that allow or deny actions on resources. The general recommendation from AWS is to use IAM Identity Center or federation for people, IAM roles for workloads, and to avoid long-lived access keys wherever possible.

The root user, created with the account’s email address, has unrestricted access. Protect it with MFA, do not use it for daily work, and do not create access keys for it.

Our cloud account security checklist covers MFA, least privilege and audit logging in more depth.

A sensible learning order for new teams #

  1. Account hygiene first. Sign up through the official AWS website, secure the root user with MFA, create an administrative identity through IAM Identity Center, and turn on a billing budget.
  2. IAM and CloudTrail. Understand policies and roles, and confirm CloudTrail is recording API activity.
  3. VPC and EC2. Launch an instance in a public subnet, connect using Session Manager or SSH, then move it behind a load balancer.
  4. S3 and RDS. Store assets in S3 and connect an application to a managed database in a private subnet.
  5. CloudWatch. Add alarms on CPU, error rates and billing metrics.
  6. Infrastructure as code. Recreate what you built by hand in CloudFormation, the CDK or Terraform so it can be reviewed and repeated.

Costs are part of the learning curve too. Our explanation of how AWS billing, the Free Tier and Savings Plans work is a good companion to this article, and the AWS platform overview summarizes where AWS fits compared with other providers.

The official AWS documentation has a user guide and API reference for every service, and the AWS Well-Architected Framework describes design principles across security, reliability, performance, cost and sustainability.

AWS core services: frequently asked questions #

How many AWS services do I actually need to learn?

Most small and mid-sized applications run on a handful: IAM, VPC, EC2 or Lambda, S3, a database such as RDS or DynamoDB, CloudWatch and CloudTrail. Learn those well before exploring specialized services.

Why can’t I see resources I created earlier?

The console is usually set to a different Region. Most AWS services are regional, so check the Region selector in the top navigation bar before assuming anything was deleted.

Should I use one AWS account or several?

AWS recommends multiple accounts for separating environments and teams, managed through AWS Organizations. A single account can be fine for early experiments, but splitting production from development early makes permissions and billing much easier to reason about.

Is EC2 or Lambda cheaper?

It depends on the workload. Lambda is usually economical for spiky or low-volume event-driven work, while steady, high-utilization workloads often cost less on EC2 or containers, especially with Savings Plans. Model both using the official AWS Pricing Calculator.

Back to the Guide

Have a question about a platform or a guide?

Send a note and we will point you to the right overview, guide or official documentation.

Contact us