AWS Services Cheat Sheet

AWS has grown so large that the useful way to understand it is by capability, not by memorising product names. Most teams are really choosing among a few recurring concerns: where code runs, where data lives, how traffic enters, how identity is enforced, and how the platform is observed and automated.

Compute: choose the level of control you want to own

The first split is compute. Virtual machines give the most operating system control but also make you responsible for patching, scaling, and capacity planning. Containers reduce packaging drift and improve deployment consistency, but you still need orchestration. Serverless functions remove most host management, which is attractive for event-driven or bursty work, though the model introduces cold starts, execution limits, and more fragmented debugging.

Managed application platforms sit between those extremes. They trade some flexibility for faster delivery. The right choice depends on workload shape and how much platform engineering capacity the team has.

Storage and databases: match data to access patterns

Object storage is ideal for blobs, backups, logs, and static assets. Block storage suits persistent volumes attached to compute instances. File storage helps when applications need shared POSIX-like semantics.

On the database side, relational engines are usually the default when transactions, joins, and strong consistency matter. Key-value or document stores fit workloads that need simpler access paths and horizontal scaling. Analytical warehouses are built for large scans and reporting, not hot transactional writes. Choosing correctly here matters more than any later optimisation because data model mistakes are expensive to unwind.

Networking and edge services

AWS networking services exist to isolate, route, and inspect traffic. Virtual networks define the private address space and security boundaries. Load balancers distribute requests and often terminate TLS. DNS and edge delivery services control how users reach the system globally.

The important operational question is where trust changes. Public entry points, service-to-service traffic, and private data paths often need different controls. AWS gives you many knobs, but that flexibility means teams must be explicit about exposure, egress, and cross-account access.

Identity, security, and operations

Identity is foundational in AWS because nearly every service call depends on it. Roles, policies, and short-lived credentials are safer than static keys. Encryption, secret storage, audit trails, and configuration policy complete the security picture.

Observability and automation matter just as much. Logs, metrics, traces, infrastructure definitions, and deployment pipelines turn cloud resources from a set of consoles into an operable platform.

A practical way to navigate AWS

Instead of asking "Which AWS service should I learn next?", ask which system capability you are solving: compute, storage, data, messaging, networking, security, or operations. Then pick the most boring service that satisfies the real constraint. AWS rewards clear workload thinking far more than raw catalogue memorisation.