AWS Cloud: What You Should Know
A field-guide breakdown of AWS cloud: what the platform actually is, its core service categories, the shared responsibility model, and how teams adopt it.
Track: Cloud Engineering. Era: the cloud-migration sessions that dominated conference schedules from the early 2010s onward. Modern lesson: AWS is less a product than a set of building blocks, and the hard part is choosing which ones a team actually needs.
AWS (Amazon Web Services) is a cloud platform that rents compute, storage, networking, databases, and higher-level managed services on demand, billed by usage. Instead of buying servers, a team provisions resources through an API or console, pays for what it runs, and offloads physical infrastructure to Amazon. As of 2026, verify current service details against official docs.
The recovered track
If you walked the infrastructure or cloud track at developer conferences across the 2010s, the arc was predictable. Early sessions explained why you would move off your own racks. Middle-era sessions were migration war stories. Later ones were about cost, governance, and the realization that “lift and shift” rarely delivered the savings the slide deck promised.
The talk titles aged. The underlying decisions did not. A team still has to answer: which workloads belong in the cloud, who owns the bill, and how do we avoid recreating our old data-center problems with new acronyms? AWS is the most common answer to “where,” but it never answers “how” on its own.
What is AWS cloud, really?
AWS is a collection of independently usable services that share an account, an identity system, and a billing model. You rarely adopt “AWS” as a monolith. You adopt EC2 for virtual machines, or S3 for object storage, or RDS for managed databases, and the platform stitches them together through networking and access control.
The service catalog is large, but the categories are stable. The AWS documentation home groups them roughly like this:
- Compute, EC2 virtual machines, Lambda functions, ECS and EKS for containers.
- Storage, S3 for objects, EBS for block volumes, EFS for shared file storage, Glacier for archival.
- Databases, RDS (managed relational), DynamoDB (managed NoSQL), Aurora, ElastiCache.
- Networking, VPC for isolated networks, Route 53 for DNS, CloudFront for content delivery, load balancers.
- Identity and security, IAM for permissions, KMS for key management, security and audit services.
- Operations, CloudWatch for metrics and logs, CloudFormation for declarative infrastructure.
A working team usually touches a dozen of these and ignores the rest. The skill is not memorizing the catalog. It is recognizing which category a problem belongs to before reaching for a service.
How does the shared responsibility model work?
This is the concept most worth understanding before any team commits to AWS, because it determines who is liable when something breaks or leaks.
AWS publishes a shared responsibility model that splits duties along one line: AWS secures the cloud itself (the data centers, hardware, hypervisor, and managed-service internals), and the customer secures what they put in the cloud (their data, their access policies, their patching of self-managed instances, their network rules).
The split shifts depending on the service. With EC2, you patch the operating system, so you own a lot. With a fully managed service like Lambda or DynamoDB, AWS handles more of the stack, and your responsibility narrows mostly to data and permissions. Many cloud incidents trace back to a team assuming AWS owned a layer that was actually theirs, a public S3 bucket, an over-broad IAM policy, an unpatched instance. The model is not trivia. It is the boundary that decides who gets paged.
| Layer | EC2 (IaaS) | Lambda (serverless) |
|---|---|---|
| Physical infrastructure | AWS | AWS |
| Runtime / OS patching | You | AWS |
| Application code | You | You |
| Data and access policy | You | You |
What does “good” AWS adoption look like?
Tool sprawl is easy. Disciplined adoption is harder. A few durable signals separate teams that benefit from AWS from teams that just relocated their problems:
- Infrastructure is declared, not clicked. Console-driven setups drift and resist review. Declarative infrastructure (CloudFormation, or a third-party tool) makes environments reproducible. This is the same principle behind reliable delivery that our CI/CD pipeline field guide covers for application code.
- Identity is scoped tightly. IAM policies grant the minimum needed, not blanket admin. Most cloud breaches are permission breaches.
- Cost is owned by someone. A monthly bill nobody reads is how cloud spend triples quietly. Tag resources, set budgets, and review usage.
- Workloads are placed deliberately. Not everything belongs in the cloud, and not every cloud workload belongs on EC2. Match the service tier to the actual need.
A practical decision rule: before adopting a new AWS service, write one sentence describing the problem it solves for your team and one sentence describing what you now own that you didn’t before. If you can’t write the second sentence, you don’t understand the service yet.
How do regions and availability zones fit in?
One structural concept underpins almost every reliability decision on AWS, and the old cloud tracks rarely explained it clearly: the platform is physically distributed, and that geography is something you design around, not something you ignore.
AWS divides the world into regions, isolated geographic areas like us-east-1 or eu-west-1, and each region contains multiple availability zones, which are distinct data centers with independent power and networking but low-latency links between them. The distinction matters for two reasons. First, latency: serving users from a nearby region is faster. Second, resilience: spreading a workload across availability zones means a single data-center failure doesn’t take the whole system down.
The recurring mistake is treating the region as an afterthought. Teams deploy everything into one zone, then discover that “highly available” on a slide doesn’t survive a real outage. A workload that needs resilience should span availability zones by design, and teams with compliance or latency constraints have to think about which region holds their data before they write a line of code. Geography is an architecture decision, not a deployment detail.
How does AWS pricing actually work?
Cost was the subject of more disillusioned conference talks than any other cloud topic, because the “pay only for what you use” pitch hid real complexity. Understanding the basic pricing shapes prevents most of the unpleasant surprises.
AWS bills along a few axes that recur across services: compute time, storage volume, data transfer (especially data leaving a region), and request counts. The pricing models layered on top are worth knowing conceptually:
- On-demand, pay the full rate for what you use, no commitment. Flexible, most expensive per unit.
- Reserved or committed-use, commit to a level of usage for a term in exchange for a lower rate. Good for steady baseline load.
- Spot, bid on spare capacity at a steep discount, accepting that AWS can reclaim it. Good for interruptible, fault-tolerant work.
The trap that caught so many early adopters was data-transfer cost, moving data between regions or out to the internet is billed in ways that don’t show up until the invoice arrives. A practical habit: tag resources by team or project, set billing alerts, and review the bill monthly. Cloud spend rarely spikes because of one bad decision. It creeps because nobody is watching.
What changed, and what didn’t
The early cloud talks treated AWS as a cheaper data center. That framing aged badly. The platform’s center of gravity moved toward managed and serverless services where you run less infrastructure yourself, and toward containers and Kubernetes-style orchestration for portable workloads. If your team is weighing certification paths alongside hands-on adoption, our Kubernetes certification overview maps the adjacent orchestration skill set.
What didn’t change is the core tension every conference cloud track circled: flexibility versus cost, and convenience versus control. AWS gives you enormous flexibility and hands you the bill and the responsibility boundary along with it. The platform is mature. The discipline to use it well is still the scarce resource.
Related reading
- CI/CD Pipeline: What It Is and How To Ship Reliably
- Kubernetes Certification: What You Should Know
- DevOps Lessons From Conference Tracks
Sources
- “AWS Documentation”, Official service catalog and reference documentation.
- “Shared Responsibility Model”, AWS, The security duty split between AWS and the customer.