What is AWS?
Amazon Web Services (AWS) is a cloud computing platform that provides infrastructure and managed services for running applications, storing data, processing events, building networks, operating databases, and many other computing workloads.
Instead of purchasing physical servers and building a data center, applications can provision computing resources through AWS APIs, consoles, command-line tools, and infrastructure-as-code systems. Resources can often be created or removed within minutes and scaled as application requirements change.
Table of Contents
- Why AWS Exists
- How AWS Works
- AWS Regions and Availability Zones
- Core AWS Services
- EC2 vs Containers vs Serverless
- Scaling on AWS
- High Availability on AWS
- AWS Shared Responsibility Model
- How AWS Pricing Works
- Production Design Example
- Common AWS Mistakes
- Conclusion
Why AWS Exists
Running an application traditionally required purchasing servers, installing them in a data center, configuring networking, planning capacity, replacing failed hardware, and maintaining enough spare infrastructure for future growth.
That model creates significant upfront cost and long provisioning cycles.
Cloud computing changes the model:
Traditional Infrastructure
Buy Hardware
↓
Install Servers
↓
Configure Network
↓
Deploy Application
↓
Maintain Hardware
AWS
Request Resources
↓
Deploy Application
↓
Scale as NeededA server can be created through an API instead of physically installed. Storage can expand without purchasing disks. Managed databases can handle backups and replication. Load balancers can distribute traffic without operating dedicated load-balancing hardware.
This does not eliminate infrastructure engineering. It moves much of the work from managing physical hardware toward designing, configuring, automating, securing, and operating cloud resources.
How AWS Works
AWS provides many independent services that can be combined to build an application architecture.
A simple web application might use:
Users
↓
CloudFront
↓
Load Balancer
↓
Application
↓
DatabaseEach layer can correspond to one or more AWS services.
For example:
CDN → Amazon CloudFront
Load Balancer → Application Load Balancer
Compute → Amazon EC2 / ECS / Lambda
Database → Amazon RDS
Object Storage → Amazon S3
Cache → Amazon ElastiCache
Monitoring → Amazon CloudWatchAWS is therefore better understood as a collection of infrastructure building blocks rather than a single hosting product.
Applications select the services that match their architecture instead of using every AWS service available.
AWS Regions and Availability Zones
AWS infrastructure is geographically distributed.
A Region represents a geographic area where AWS operates infrastructure. Applications choose one or more Regions in which to deploy resources.
Inside a Region are multiple Availability Zones. Availability Zones provide physically separated infrastructure designed so applications can avoid depending on one data-center location.
AWS Region
┌─────────────────────────────────────┐
│ │
│ Availability Availability │
│ Zone A Zone B │
│ │
│ App Servers App Servers │
│ │ │ │
│ └──────┬─────────┘ │
│ ↓ │
│ Database │
│ │
└─────────────────────────────────────┘A production application can distribute instances across Availability Zones so failure of one zone does not necessarily make the entire application unavailable.
Regions solve a different problem. Multiple Regions can support disaster recovery, geographic latency requirements, regulatory requirements, or global applications.
Multi-region architectures are substantially more complex because databases, traffic routing, failover, and data consistency must work across geographic boundaries. Multi-Region Architecture and Disaster Recovery covers these trade-offs in more detail.
Core AWS Services
AWS contains a large catalog of services, but most application architectures are built from a smaller set of fundamental capabilities: compute, storage, databases, networking, messaging, monitoring, and security.
Compute
Compute services run application code.
Amazon EC2 provides virtual machines. Applications choose an instance type, operating system, storage, networking configuration, and other infrastructure settings.
EC2 Instance
↓
Linux
↓
Application Runtime
↓
ApplicationEC2 provides significant control but also requires responsibility for operating the instance, including operating-system configuration and application deployment.
Amazon ECS runs containerized applications. Instead of treating the virtual machine as the primary deployment unit, applications are packaged as containers and executed as ECS tasks.
Container Image
↓
ECS Task Definition
↓
ECS Service
↓
Running TasksFor a detailed introduction, see Amazon ECS Explained: A Beginner-Friendly Introduction.
AWS Lambda provides serverless compute. Application code runs in response to requests or events without requiring the application team to manage persistent servers.
Event
↓
Lambda Function
↓
Application Code
↓
ResultLambda is particularly useful for event-driven processing, APIs, scheduled jobs, automation, and workloads where request volume changes significantly.
AWS Lambda Explained: A Beginner-Friendly Introduction covers the Lambda execution model in more depth.
Storage
AWS provides different storage models because applications have different access patterns.
Amazon S3 provides object storage. It is commonly used for images, videos, backups, documents, logs, static website assets, data lakes, and other files represented as objects.
S3 Bucket
│
├── images/product-1.jpg
├── documents/report.pdf
└── backups/database.sql.gzObject storage behaves differently from a normal local filesystem. Applications interact with objects through APIs and object keys rather than modifying arbitrary bytes in files through a traditional filesystem interface.
AWS also provides block and file storage services for workloads that require those models. The differences are explained in Object Storage vs File Storage vs Block Storage.
Databases
AWS provides both managed relational and NoSQL database services.
Amazon RDS manages relational database engines and automates significant portions of database infrastructure operations such as provisioning, backups, patching, and certain high-availability configurations.
A typical architecture might use:
Application
↓
Amazon RDS
↓
PostgreSQLAmazon DynamoDB is a managed NoSQL key-value and document database designed for predictable access patterns and large-scale workloads.
DynamoDB applications usually model data around known query patterns rather than treating the database like a relational system. Amazon DynamoDB: Pros, Cons, and Use Cases explains where that model works well and where it does not.
Choosing between relational and NoSQL databases should depend on workload characteristics, consistency requirements, access patterns, transactions, and scaling needs rather than whether a service is considered more cloud-native.
Networking
Amazon VPC provides logically isolated networking for AWS resources.
A simplified VPC might contain public and private subnets:
Internet
↓
Load Balancer
↓
Public Subnets
↓
Application
↓
Private Subnets
↓
DatabaseSecurity groups control allowed network traffic to resources. Route tables determine where network traffic is sent. Internet gateways and NAT-related infrastructure connect selected resources to external networks.
A common design keeps application databases inaccessible directly from the public internet and allows connections only from authorized application resources.
Elastic Load Balancing distributes incoming requests across application instances or containers.
┌→ App 1
Users → ALB ──────┼→ App 2
└→ App 3Amazon Route 53 provides DNS capabilities, while Amazon CloudFront provides content delivery through globally distributed edge locations.
The relationship between DNS, load balancers, and reverse proxies is covered in DNS, Load Balancers, and Reverse Proxies.
Messaging and Events
Distributed applications frequently need asynchronous communication.
Amazon SQS provides managed message queues:
API
↓
SQS Queue
↓
Worker
↓
DatabaseThe API can enqueue work without waiting for the worker to finish processing it. This helps absorb traffic spikes and separates request processing from slower background operations.
Amazon SNS provides publish-subscribe messaging, while Amazon EventBridge routes events between applications and AWS services based on event rules.
These services support different messaging patterns rather than being interchangeable names for the same mechanism.
The underlying architecture is described in Event-Driven Architecture in Distributed Systems.
Monitoring and Security
Amazon CloudWatch collects metrics, logs, and operational signals from AWS resources and applications.
Examples include:
EC2 CPU utilization
Lambda invocation count
Lambda errors
ALB request count
Application logs
Database metricsAWS Identity and Access Management (IAM) controls identities and permissions.
Instead of embedding long-lived credentials into application code, AWS workloads can often receive permissions through IAM roles.
For example:
ECS Task
↓
IAM Role
↓
Permission:
Read specific S3 bucketThe application receives only the permissions required for its workload.
This follows the principle of least privilege: grant the minimum access necessary rather than broad administrative permissions.
EC2 vs Containers vs Serverless
AWS provides several levels of abstraction for running applications.
| Model | Typical AWS Service | Application Team Manages |
|---|---|---|
| Virtual machines | EC2 | OS, runtime, application, scaling configuration |
| Containers | ECS | Container image, application, service configuration |
| Serverless functions | Lambda | Function code, runtime configuration, integrations |
More abstraction generally means less infrastructure to operate directly, but it can also introduce service-specific constraints.
EC2 offers significant control. Containers provide standardized packaging and deployment. Lambda removes server management from the application model but introduces constraints around execution lifecycle, runtime behavior, and service integration.
There is no universally correct compute model. Many production systems use several simultaneously.
For example:
REST API → ECS
Image Processing → Lambda
Legacy Application → EC2
Scheduled Job → Lambda
Long-Running Worker→ ECSThe broader trade-offs are covered in Virtual Machines vs Containers vs Serverless.
Scaling on AWS
One major benefit of cloud infrastructure is the ability to change capacity without physically installing new servers.
An application might initially run:
Load Balancer
↓
2 Application InstancesAs traffic increases:
Load Balancer
↓
8 Application InstancesAuto Scaling can adjust compute capacity based on metrics or configured policies.
For example:
CPU > threshold
↓
Add instances
↓
Traffic distributed across more capacityScaling down when demand falls can reduce infrastructure cost.
However, adding application instances works best when application servers are stateless. If important user state exists only on one instance, requests cannot freely move between instances.
Scaling Stateless Applications explains why stateless architecture simplifies horizontal scaling.
The database, cache, queues, external APIs, and other dependencies must also support increased throughput. Auto Scaling the application tier does not automatically scale every downstream component.
High Availability on AWS
Running an application in AWS does not automatically make it highly available.
Consider an application with one EC2 instance:
Internet
↓
EC2 InstanceIf that instance fails, the application becomes unavailable.
A more resilient architecture can distribute resources across Availability Zones:
┌→ App A → Availability Zone A
Load Balancer ┤
└→ App B → Availability Zone BThe database also needs an appropriate availability strategy.
A production architecture might therefore look like:
Internet
↓
Load Balancer
↙ ↘
App A App B
AZ-A AZ-B
\ /
\ /
Database
Multi-AZ SetupIf one application instance or Availability Zone becomes unavailable, traffic can continue through healthy infrastructure.
High availability requires removing single points of failure across the complete request path, not simply creating multiple application instances. Designing Highly Available Cloud Systems explores these patterns in more depth.
AWS Shared Responsibility Model
Using AWS does not transfer every operational and security responsibility to the cloud provider.
AWS manages the underlying cloud infrastructure, while customers remain responsible for areas that depend on how their workloads are configured and operated.
The exact boundary changes depending on the service.
With EC2, the application team manages much more of the software stack:
Application → Customer
Runtime → Customer
Operating System → Customer
Virtualization → AWS
Physical Servers → AWS
Data Center → AWSWith a more managed service, AWS operates more layers.
This distinction matters for security. AWS can operate secure physical infrastructure while an application remains vulnerable because of an overly permissive IAM policy, public storage bucket, exposed database, weak application authentication, or leaked credential.
Cloud security therefore requires understanding both the provider's responsibilities and the application's responsibilities.
How AWS Pricing Works
AWS primarily uses consumption-based pricing, although the exact pricing model differs between services.
Costs can be based on factors such as:
- compute duration;
- instance type and running time;
- stored data;
- database capacity;
- number of requests;
- network data transfer;
- provisioned throughput;
- serverless execution duration;
- reserved or committed capacity.
This allows infrastructure to start small, but cloud resources are not automatically inexpensive.
For example, an architecture may scale application instances efficiently while generating unexpectedly high costs from cross-region traffic, NAT processing, logging volume, oversized databases, unused storage, or permanently overprovisioned resources.
Cost should therefore be treated as another production metric alongside reliability, latency, and throughput.
Production Design Example
Consider a web application that serves an API, stores uploaded images, processes background jobs, and uses PostgreSQL.
A production AWS architecture could use:
Users
↓
Route 53
↓
CloudFront
↓
ALB
↙ ↘
ECS Task ECS Task
AZ-A AZ-B
\ /
\ /
RDS
PostgreSQL
Uploads ───────────────→ S3
API
↓
SQS
↓
ECS Background Workers
Metrics + Logs ────────→ CloudWatchEach component has a specific responsibility.
Route 53 resolves the application's domain. CloudFront can serve cached content close to users and forward dynamic requests. The Application Load Balancer distributes API requests across healthy ECS tasks.
The ECS service runs multiple copies of the application across Availability Zones. This prevents a single container or one application host from becoming the only request-serving resource.
Amazon RDS for PostgreSQL stores transactional data. Database backups and an appropriate high-availability configuration protect against infrastructure failures according to the application's recovery requirements.
Uploaded files go to Amazon S3 instead of being stored on container filesystems:
POST /uploads
↓
Application
↓
S3Long-running work is moved outside the synchronous API path:
POST /reports
↓
API
↓
SQS
↓
Worker
↓
Generate ReportIf request traffic increases, the API service can add ECS tasks. If queue depth grows, the worker service can scale separately.
IAM roles give each workload only the permissions it needs. API tasks might receive permission to write specific S3 objects and SQS messages, while workers receive permission to consume from the queue.
CloudWatch collects application and infrastructure signals such as request latency, HTTP errors, task health, queue depth, database load, and logs.
This architecture illustrates an important AWS design principle: use independent managed components with clear responsibilities and scale them according to their own workload.
For a broader view of these architectural decisions, see Cloud Architecture Explained: Building Modern Applications.
Common AWS Mistakes
- Assuming AWS automatically provides high availability. A single EC2 instance in one Availability Zone is still a single point of failure.
- Giving workloads excessive IAM permissions. Permissions should be limited to the resources and operations actually required.
- Exposing databases publicly without a real requirement. Internal databases should normally be reachable only from authorized network paths.
- Keeping application state on individual instances. Local state makes horizontal scaling and instance replacement harder.
- Ignoring network architecture. Subnets, routes, security groups, internet access, and service connectivity should be intentionally designed.
- Using the same compute model for every workload. APIs, background workers, batch jobs, and event handlers can have different runtime requirements.
- Assuming managed means maintenance-free. Applications still need capacity planning, monitoring, security configuration, schema management, and operational procedures.
- Ignoring failure behavior. Every architecture should define what happens when an instance, Availability Zone, database, queue consumer, or dependency fails.
- Ignoring cost until after launch. Data transfer, logging, idle capacity, and poorly selected resource sizes can become significant expenses.
- Using services because they exist rather than because they solve a requirement. More AWS services can increase architecture complexity without improving the system.
A good AWS architecture is not the architecture containing the largest number of managed services. It is the architecture that meets availability, scalability, security, performance, operational, and cost requirements with reasonable complexity.
Conclusion
AWS is a cloud computing platform that provides building blocks for compute, storage, databases, networking, messaging, security, monitoring, and many other infrastructure requirements.
Its main architectural advantage is not simply that servers run somewhere else. Infrastructure becomes programmable: resources can be provisioned through APIs, distributed across Availability Zones, scaled with workload changes, replaced automatically, and combined with managed services.
The core principle is: AWS provides infrastructure capabilities, but reliable cloud systems still require deliberate decisions about architecture, security, scalability, failure handling, observability, and cost.
Comments (0)