AWS Explained: Core Services, Regions, and How the Platform Is Organized
A practical overview of how AWS is organised: accounts and Organizations, IAM identity, regions and availability zones, core services by category, billing, budgets, and the service quotas that shape every account.
Amazon Web Services is the largest public cloud by service count, and its size is the first thing that confuses new users. This guide explains how an AWS account is structured, how identity and access work, what regions and availability zones mean in practice, how billing and quotas behave, and which core services matter for most teams.
How AWS is organised: accounts, Organizations, and the root user
The basic unit in AWS is the account. An account is a hard boundary: it has its own resources, its own bill, its own service quotas, and its own identity store. Every resource you create, from a virtual machine to a DNS record, lives inside exactly one account.
Each account has a single root user, identified by the email address used at sign-up. The root user has unrestricted power, including the ability to close the account and change payment details. AWS recommends securing it with multi-factor authentication and then leaving it alone. Day-to-day work should happen through IAM users or federated identities, not through root.
Larger setups group accounts with AWS Organizations. An organization has a management account and any number of member accounts arranged into organizational units. Service control policies set the maximum permissions available in member accounts, and consolidated billing rolls all charges into one invoice. Many teams run one account per environment or one account per client for exactly this isolation.
- Account
- Boundary for resources, billing, quotas, and identity
- Root user
- Sign-up identity with full control; protect with MFA and avoid daily use
- AWS Organizations
- Groups accounts under a management account with shared policies and one bill
Identity and access with IAM
AWS Identity and Access Management (IAM) controls who can do what. Its building blocks are users, groups, roles, and policies. A policy is a JSON document that allows or denies specific actions (for example s3:GetObject) on specific resources, optionally under conditions. Policies attach to users, groups, or roles.
Roles are how AWS avoids long-lived credentials. An EC2 instance, a Lambda function, or a container task assumes a role and receives temporary credentials automatically. A person in another account can also assume a role, which is the standard way to grant cross-account access without sharing keys.
For human sign-in across several accounts, AWS IAM Identity Center provides single sign-on and permission sets. Every API call is recorded by AWS CloudTrail for auditing and incident review.
Regions, availability zones, and edge locations
AWS divides its infrastructure into regions, each a separate geographic area with its own set of services and pricing. Inside a region are multiple availability zones (AZs): physically separate data center groups with independent power and networking, connected by low-latency links. Placing copies of an application in two or more AZs is the standard way to survive a single facility failure.
Most services are regional. An S3 bucket, an EC2 instance, or an RDS database belongs to one region, chosen when you create it. A few services, such as IAM, Route 53, and CloudFront, are global. CloudFront also uses edge locations, a much larger set of points of presence for caching content close to end users.
Region choice affects latency, data residency, and which services and instance types are available, since new capabilities usually launch in the largest regions first.
Core services grouped by job
AWS lists well over two hundred services, but most workloads use a small set.
| Category | Key services | What they do |
|---|---|---|
| Compute | EC2, Lambda, ECS, EKS, Fargate | Virtual machines, event-driven functions, and container orchestration with or without managed hosts |
| Storage | S3, EBS, EFS, S3 Glacier | Object storage, block volumes for EC2, shared file systems, and archival tiers |
| Databases | RDS, Aurora, DynamoDB, ElastiCache | Managed relational engines, a cloud-native SQL engine, a key-value store, and in-memory caching |
| Networking | VPC, Route 53, CloudFront, Elastic Load Balancing | Private networks, DNS, content delivery, and traffic distribution |
| Messaging and email | SQS, SNS, EventBridge, Amazon SES | Queues, notifications, event routing, and application email sending |
| Security and operations | IAM, KMS, CloudTrail, CloudWatch, Secrets Manager | Access control, encryption keys, audit logs, metrics and alarms, and secret storage |
| AI and machine learning | Amazon Bedrock, SageMaker | Access to foundation models through an API, and a platform for training and hosting custom models |
EC2 is where most people start. Instances come in families (general purpose, compute optimised, memory optimised, accelerated) and sizes. Amazon SES behaves like a product of its own, with a sandbox mode and separate sending quotas. Amazon Bedrock exposes third-party and Amazon models through one API and carries per-model, per-region request limits.
Billing, budgets, and service quotas
AWS bills pay-as-you-go by default, with no upfront commitment. Savings Plans and Reserved Instances discount steady workloads, and Spot Instances offer spare capacity at lower prices in exchange for possible interruption. The AWS Free Tier gives new accounts limited free usage of certain services; its terms are set by AWS and change over time, so check the current page before you rely on it.
Billing tools live in the Billing and Cost Management console. AWS Budgets sets spend or usage thresholds and sends alerts. Cost Explorer breaks down historical spend by service, region, or tag, which is why consistent tagging matters.
Service quotas are per-account, per-region limits on how much of a service you can use. The best-known example is the vCPU quota for running On-Demand EC2 instances, which is why account listings are often described by vCPU tier. New accounts start with conservative quotas, and increases are requested through the Service Quotas console and reviewed by AWS. Full details are in the AWS service quotas reference.
Typical workloads and practical considerations
AWS fits almost any workload, but a few patterns dominate. Web applications run on EC2 or containers behind a load balancer with RDS or DynamoDB for data. Serverless APIs combine API Gateway, Lambda, and DynamoDB. Data pipelines land files in S3 and process them with Glue, Athena, or EMR. AI teams call Bedrock for inference and use SageMaker for training. Transactional email goes through SES.
Before you build, settle a few practical points:
- Turn on MFA for root and all users, and create an administrator IAM identity so root is never used for routine tasks.
- Create a budget with an alert on day one. Forgotten instances and data transfer are the most common surprises.
- Check quotas for the instance families you plan to use in your target region, and request increases early, since reviews take time.
- Read the AWS Acceptable Use Policy. Unsolicited email, network scanning, and abusive workloads lead to account action, and buyers are expected to follow provider rules exactly as written.
- Enable CloudTrail in all regions and keep the logs in a protected S3 bucket.
Where to go next
If you need an account with a specific vCPU tier, credit balance, or Bedrock access, the variants are listed on the Buy AWS Accounts product page. For application email on AWS, see the Buy Amazon SES Accounts page.
Related reading in the Cloud Library:
- What is a cloud account? Organizations, projects, billing, and access
- Cloud regions and availability zones: how to choose a location
- Cloud service quotas and limits explained
- Amazon SES explained: sandbox, production access, and sending quotas
- Getting started with Amazon Bedrock: models, regions, and quotas
Browse every guide in the Cloud Library, or compare AWS with other platforms on the AWS vs Google Cloud page.