Core AWS Services to Learn

If you are learning AWS, the goal is not to memorise hundreds of product names. It is to understand the small set of services that define how workloads are secured, connected, deployed, observed, and paid for. Once those foundations are clear, the rest of the platform becomes much easier to reason about.

Start with IAM. Identity and Access Management controls who can do what in an AWS account. Nearly every real system depends on IAM roles, policies, and temporary credentials. The important mechanism is that AWS services usually call each other using assumed roles rather than long-lived secrets. If you do not understand IAM, you can build something that works in development but fails in production or exposes far more access than intended.

Next learn VPC, subnets, security groups, and route tables. These are the networking primitives that decide whether resources can talk to each other and how traffic enters or leaves a workload. Many AWS outages at the application level are really configuration mistakes at the network layer: a missing route, the wrong security group rule, or a private subnet without the egress path a service needs.

For compute, EC2 is still worth learning even if you prefer containers or serverless. EC2 teaches the baseline model: you are responsible for the instance, operating system, patching, scaling, and capacity planning. From there, the tradeoffs of managed compute become clearer. Lambda removes server management and scales quickly for event-driven work, but it comes with cold starts, execution time limits, and tighter packaging constraints. ECS and EKS matter when you need container scheduling, but many teams should learn them after EC2 and Lambda, not before.

For storage, S3 is essential. It is durable object storage, not a general-purpose filesystem. That distinction matters operationally. You store objects by key, not by mutating files in place. S3 is excellent for assets, logs, backups, and data lakes, but less suitable when an application expects POSIX semantics. Learn bucket policies, lifecycle rules, versioning, and presigned URLs because those features show up in real architectures constantly.

For databases, understand at least RDS and DynamoDB. RDS represents the managed relational path: SQL, transactions, indexes, and familiar engines such as PostgreSQL or MySQL. DynamoDB represents the key-value and document path with a very different design model centred on access patterns, partition keys, and throughput behaviour. Knowing when not to force one model into the other is more valuable than deep feature trivia.

Two more services deserve early attention: Route 53 and CloudFront. Route 53 handles DNS and health-aware routing. CloudFront places content and cached responses closer to users. Together they explain how AWS serves traffic globally and how latency, caching, and failover fit together.

Finally, learn CloudWatch and CloudTrail. Systems are not operable if you cannot see metrics, logs, alarms, and API activity. CloudWatch tells you what the system is doing. CloudTrail tells you who changed it. That distinction matters during incidents.

A practical AWS learning path is therefore: IAM, networking, EC2, S3, RDS, DynamoDB, Lambda, Route 53, CloudFront, and observability. After that, pick specialised services based on workload, such as SQS and SNS for messaging or EKS for platform teams. The important thing is to understand the operating model each service imposes, because in AWS the biggest mistakes are usually not syntax errors. They are architectural mismatches.