Amazon Web Services (AWS) is a public cloud computing platform operated by Amazon that provides on-demand infrastructure and managed services, including virtual servers, storage, databases, networking, analytics and machine learning, billed according to actual usage. In cloud fundamentals, AWS is the reference example of a hyperscale provider and the platform on which much of today’s IaaS and PaaS vocabulary was established.
AWS began offering its first broadly available services, Amazon S3 and Amazon EC2, in 2006. It now delivers hundreds of services from a global network of regions and availability zones, alongside other major platforms such as Microsoft Azure and Google Cloud.
How AWS is organized globally
AWS infrastructure is structured in nested layers of isolation, and understanding them is essential for designing reliable systems. Customers choose where resources run, and that choice affects latency, resilience, data residency and price.
| Layer | What it is | Design relevance |
|---|---|---|
| Region | Geographic area with several separate data center groups | Data residency, latency, service availability |
| Availability zone | One or more data centers with independent power and networking | High availability within a region |
| Local Zone | Smaller extension of a region near a large city | Single-digit millisecond latency for nearby users |
| Edge location | Point of presence for CDN and DNS | Content delivery and fast DNS responses |
Most AWS services are regional: resources created in one region do not appear in another unless they are explicitly replicated. Some services, such as identity management and the DNS service, are global. A common design rule is to spread production workloads across at least two availability zones, so the failure of one zone does not stop the service.
Core AWS service categories
AWS services range from raw infrastructure that the customer manages to fully managed platforms where AWS operates servers, patching and scaling. The same workload can often be built at several of these levels.
| Category | Example services | Model |
|---|---|---|
| Compute | EC2 virtual machines, Lambda functions | IaaS and serverless |
| Storage | S3 object storage, EBS block volumes, EFS files | Managed storage |
| Databases | RDS, Aurora, DynamoDB | Managed PaaS |
| Networking | VPC, Route 53, CloudFront, Elastic Load Balancing | Virtual networking and delivery |
| Containers | ECS, EKS, Fargate | Managed orchestration |
| Security and identity | IAM, KMS, CloudTrail | Access control and audit |
Everything in AWS is controlled through APIs. The web console, the command line interface, software development kits and infrastructure as code tools such as CloudFormation or Terraform all call the same APIs, which makes automation the normal way to operate rather than an add-on.
Choosing the level of management is a trade-off between control and operational effort. Running a database on EC2 gives full control over versions and tuning, while Amazon RDS takes over backups, patching and failover at a higher price per hour and with fewer configuration options. For small teams, managed services usually lower total cost once staff time is counted.
AWS compared with other cloud models and providers
AWS is a public cloud: shared physical infrastructure, logically isolated per customer, consumed over the internet or private links. Organizations combine it with on-premises systems in hybrid cloud setups or with other providers in multi-cloud strategies.
| Option | Who runs the hardware | Typical reason to choose |
|---|---|---|
| AWS public cloud | AWS | Broad service catalog, global reach, elasticity |
| Microsoft Azure | Microsoft | Close integration with Microsoft enterprise software |
| Google Cloud | Data analytics and Kubernetes heritage | |
| Private cloud | The organization or a host | Full control, regulatory or cost constraints |
| AWS Outposts | AWS hardware in the customer site | AWS APIs with on-premises data and latency |
The major providers offer broadly comparable core services, so the decision usually rests on existing skills, licensing, specific managed services, regional presence and contract terms rather than on raw capability.
Pricing and the shared responsibility model
AWS pricing is pay as you go, but the price of the same capacity varies widely by purchasing model. Long-running stable workloads benefit from commitments, while interruptible jobs can use spare capacity at a steep discount.
| Option | Commitment | Best fit |
|---|---|---|
| On-Demand | None, billed per second or hour | Unpredictable or short workloads |
| Savings Plans | One or three years of spend per hour | Steady baseline usage |
| Reserved Instances | One or three years for specific capacity | Stable databases and servers |
| Spot Instances | None, but can be reclaimed at short notice | Batch jobs, CI runners, fault-tolerant tasks |
Security follows the shared responsibility model. AWS is responsible for security of the cloud, meaning physical facilities, hardware and the virtualization layer, while the customer is responsible for security in the cloud: identity and access policies, operating system patching on EC2, network rules and data encryption settings.
Common mistakes when adopting AWS
Most problems in AWS environments come from configuration rather than platform failures. The flexibility that makes AWS powerful also makes it easy to create expensive or insecure setups.
- Publicly readable S3 buckets created by mistake expose sensitive data.
- Using the root account for daily work instead of IAM roles with least privilege.
- Running everything in one availability zone, which removes the main resilience benefit.
- Ignoring data transfer charges, which can exceed compute costs for traffic-heavy applications.
- Lifting and shifting servers unchanged and paying on-demand prices for idle capacity.
Mature teams use multiple accounts separated by environment, central logging with CloudTrail, budgets and cost alerts, and infrastructure as code so that every change is reviewed and repeatable.
The simple explanation
Amazon Web Services is a way to rent computing power instead of buying it. A company does not buy servers or build a server room. It asks AWS for what it needs and pays only for the time it uses.
Think of it like electricity from the grid. You do not build your own power plant. You plug in and pay for what you consume. The main benefit is that capacity can grow or shrink within minutes, matching what the business actually needs.
How it is used in practice
A ticket sales company sees traffic jump many times above normal whenever popular concerts go on sale. Its own data center had to be sized for these rare peaks, so most servers sat idle for most of the year.
The company moves its web tier to EC2 instances in an Auto Scaling group across three availability zones, puts static content in S3 behind CloudFront and moves its database to Amazon Aurora. Baseline capacity is covered by a Savings Plan, while extra instances are started on demand during sales events.
On a major sale day the platform scales out automatically within minutes and scales back down in the evening. The company pays for peak capacity only during the peak, and the loss of a single availability zone during the year causes no customer-visible outage.