AWS: Services & Architecture

Welcome

A practical guide to 58 core AWS services — what they do, how they work, when to use them, and when not to.

10 chapters 58 services covered 5 case studies Knowledge check on every service 6 hours audio

About This Guide

AWS has over two hundred services and a documentation library that grows faster than anyone can read it. Most engineers work with a few dozen and need solid familiarity with perhaps fifty. This guide covers fifty-eight — the ones that appear most often in production, form the backbone of real architectures, and cause the most trouble when chosen wrong.

Official documentation is comprehensive and current, but it does not tell you when not to use a service, how to navigate overlapping options, or what the practical failure modes look like. AWS services often arrive wrapped in language that makes them sound more magical than they are. This guide uses plain engineering language to make the trade-offs visible.

Each service is covered with consistent structure: what it is, how it works, when to use it, when not to, common mistakes, and best practices. Where services overlap — and on AWS they overlap constantly — the guide gives direct decision guidance rather than leaving that work to you.

Who This Is For

Software engineers, DevOps and platform engineers, and cloud architects working with AWS or preparing to. The material assumes you can read code, understand how web applications are built, and are comfortable with the basics of Linux, networking, and relational databases. No prior AWS experience is required. Engineers with Google Cloud or Azure background will find the comparable-services sections a useful translation layer.

Prerequisites

  • Basic Linux operations — files, processes, permissions, SSH, reading a stack trace
  • Any modern programming language well enough to read short Python or JSON examples
  • HTTP and TLS fundamentals — the shape of a web request, transit encryption
  • Networking basics — IP addresses, ports, subnets, public vs private networks
  • No prior AWS experience required

The AWS Landscape

AWS launched in 2006 with S3 and EC2 and effectively created the public cloud market. That head start shows in the surface area: AWS almost always has more than one service for a given job, the older service sitting next to its newer replacement, and the naming is inconsistent because services were built by independent teams over two decades. The cost of being first is a catalog that rewards knowing the map.

AWS Global Infrastructure — Regions and Availability Zones
Region · example: us-east-1
us-east-1aisolated data center(s)
us-east-1bisolated data center(s)
us-east-1cisolated data center(s)
A Region is a geographic area; each holds multiple Availability Zones with independent power and networking. Spreading across AZs survives a single-facility failure; spreading across Regions survives a Region-wide outage.

The upside is depth and maturity. The Global Infrastructure spans dozens of Regions, each with multiple isolated Availability Zones, and the core primitives — EC2, S3, VPC, IAM — are battle-tested at a scale nothing else matches. Engineers who know Google Cloud or Azure will find the patterns familiar; the differences are naming, specific features, and the sheer number of overlapping options.

Architecture Philosophy

One theme runs through every chapter: the best architecture is the simplest one that meets the requirements. This runs against the instinct to reach for sophisticated services because they feel safer or more impressive. Complexity is a real cost, and operational burden — patching, upgrades, incident response, capacity planning — is as real as the compute bill even when it does not appear on the invoice.

Start simple
Operational complexity is a cost. A managed service that requires less maintenance earns its place even when it is less configurable than the alternative.
Match tool to workload
AWS has many services that look similar. Each has a specific performance envelope. Using the wrong one does not just cost more — it creates problems that are hard to undo.
Anticipate sensibly
Design for ten times current load — that is prudent. Designing for ten thousand times is premature optimization that costs real money today.
Operational burden is cost
Every self-managed component carries maintenance cost. Managed services delegate that work. Treat the trade-off explicitly, not as a default.

Chapter Map

Chapter 1
Compute
EC2, Lambda, containers on ECS/EKS/Fargate, Elastic Beanstalk, Batch, and Lightsail — eight services across the full control spectrum.
Chapter 2
Storage
Object, block, and file storage — S3, EBS, EFS, FSx, Glacier — plus Storage Gateway and Backup. Models that are not interchangeable.
Chapter 3
Databases
Eight databases spanning relational, document, key-value, in-memory, analytical, graph, and time-series models.
Chapter 4
Networking & Content Delivery
VPC, Route 53, CloudFront, API Gateway, load balancers, Direct Connect, Transit Gateway, and PrivateLink — eight services for connectivity, traffic, and edge delivery.
Chapter 5
Security & Identity
IAM, KMS, Secrets Manager, WAF & Shield, GuardDuty, Macie, Security Hub, and Certificate Manager — eight services forming an AWS account's security posture.
Chapter 6
Monitoring & Management
CloudWatch, CloudTrail, Config, Systems Manager, Trusted Advisor, and Cost Explorer & Budgets — six services for visibility, governance, and cost control.
Chapter 7
Developer Tools & Integration
CloudFormation, CDK, the Code* pipeline, EventBridge, SQS, SNS, and Step Functions — seven services for infrastructure-as-code and decoupled, event-driven systems.
Chapter 8
AI & Machine Learning
SageMaker, Bedrock, and the pre-trained AI APIs — Rekognition, Comprehend, Textract, Polly, Transcribe, Translate — six entries covering the AI surface of AWS.
Chapter 9
Architecting on AWS
The Well-Architected Framework, architectural patterns, networking deep-dive, and the cross-cutting best practices for security, cost, and reliability.
Chapter 10
Case Studies
Five workload shapes — e-commerce, fintech, analytics, microservices migration, and serverless SaaS — and the architectures they produce from the same service catalog.

Disclaimer

This course is an independent educational project created and maintained by Sergey Okinchuk. It is provided for learning and reference purposes only.

No affiliation with Amazon. This course is not affiliated with, sponsored by, endorsed by, commissioned by, or in any way officially connected to Amazon Web Services, Inc., Amazon.com, Inc., or any of their subsidiaries or affiliates. All opinions, interpretations, and recommendations expressed are those of the author.

Trademarks. "AWS", "Amazon Web Services", "Amazon", and all AWS service names and logos are trademarks of Amazon.com, Inc. or its affiliates. All other product names, service names, and logos referenced throughout this course are trademarks or registered trademarks of their respective owners. Use of these names and marks is for identification and educational purposes only and does not imply any endorsement, sponsorship, or partnership.

Logo and icon attribution. The AWS logo and the per-service product icons used throughout this course are reproduced from the official AWS Architecture Icons set under nominative fair use for educational and editorial purposes. No modifications have been made to the official marks beyond resizing and standard rendering.

Accuracy and currency. Cloud platforms evolve rapidly. Features, pricing, regional availability, quotas, default behavior, and best practices described in this course reflect the author's understanding at the time of writing and may not be current. Always consult the official AWS documentation as the authoritative source before making architectural, operational, or financial decisions.

No warranty. This material is provided "as is" without warranty of any kind, express or implied, including but not limited to warranties of accuracy, completeness, merchantability, or fitness for a particular purpose. The author makes no representations regarding the suitability of this material for any specific use, and accepts no liability for any loss, damage, cost, or claim arising from reliance on the content in production systems or otherwise.

Third-party content. Where this course references documentation, blog posts, conference talks, or other external sources, attribution is provided to the original authors. All quoted material remains the property of its respective rights-holders.