AWS Cloud Engineer: 48 Services to Know
AWS learning gets easier when candidates group services by workload domain: run, store, connect, secure, observe, automate, analyze, move, and serve users.
AWS can look like a wall of service names. That is the wrong way to learn it. A cloud engineer needs a mental map: what runs the workload, what stores data, what connects traffic, what secures access, what watches the system, and what automates change.
This map turns 48 common AWS services into domains a candidate can actually study and explain.
AWS learning should start with service domains and workload tradeoffs, because that is how cloud engineering work is evaluated.
Why this map matters
AWS publishes services across many categories, and the public overview describes more than 200 services. That scale is useful in production, but it can be confusing for candidates who are trying to decide what to study first.
Cloud roles usually test patterns before trivia. Teams want to know whether you can run workloads, protect access, move data, diagnose failures, automate delivery, and explain cost and reliability tradeoffs.
What the sources actually support
The official AWS overview groups the platform into service categories such as compute, storage, databases, networking, management, security, analytics, migration, and AI.
AWS services overviewThe Well-Architected compute guidance frames compute choices around instances, containers, and functions, which is the right mental model for EC2, ECS, EKS, and Lambda.
AWS Well-ArchitectedAWS security guidance keeps identity, access control, key management, secrets, threat detection, and auditing close to every workload decision.
AWS security servicesManagement and governance services such as CloudWatch, CloudTrail, Config, CloudFormation, and Systems Manager make deployed systems inspectable and controllable.
AWS management and governanceHow to read the service map
A useful AWS learning plan is not a bigger checklist. It is a domain map that shows what each service is for and how it connects to a workload.
Orientation before studying or applying to cloud roles.
Names alone do not prove the candidate understands architecture, tradeoffs, or operations.
A candidate can name EC2, S3, RDS, VPC, IAM, Lambda, and CloudWatch.
Learning how cloud systems are assembled.
The map still needs hands-on work; a diagram is only a starting point.
Services are grouped into compute, storage, database, networking, security, observability, automation, data, AI, and migration.
Portfolio and interview evidence.
A project without monitoring, rollback notes, or cost checks can look like a tutorial clone.
One deployed service shows IAM boundaries, VPC decisions, storage, database access, logs, alerts, and deployment history.
Senior cloud conversations.
A memorized answer breaks quickly when the workload constraints change.
The candidate can explain why Lambda versus ECS, RDS versus DynamoDB, CloudFront versus Global Accelerator, or DMS versus DataSync.
Turn the map into proof
Use the map to build one small workload instead of trying to master every service at once.
- Deploy one simple app with IAM boundaries, one compute option, S3, VPC networking, and a managed database.
- Add CloudWatch logs or metrics, CloudTrail awareness, and one Config or tagging rule so the system is inspectable.
- Automate deployment with CloudFormation or a pipeline, then write down the rollback and cost assumptions.
- Practice three tradeoff answers: Lambda versus ECS, RDS versus DynamoDB, and CloudFront versus Route 53.
Cloud engineering starts to feel manageable when AWS is grouped by job to be done: run, store, connect, secure, observe, automate, analyze, move, and serve users.
The career signal is not knowing every service by heart. It is being able to design a small workload, explain the boundaries, and choose the next service for a reason.
What to do next
- Start with seven core services: IAM, EC2 or Lambda, S3, VPC, RDS or DynamoDB, CloudWatch, and one deployment tool.
- Build one small AWS project that connects identity, compute, storage, networking, data, monitoring, and cost notes.
- Turn the service map into interview proof by explaining why you chose each service and what you would use instead.
- Practice service tradeoffs by comparing managed databases, containers, serverless, and migration paths for one realistic workload.
Choose the right surface
Compute choices
EC2 Lambda ECS EKS
Object, block, file
S3 EBS EFS FSx
Managed data layer
RDS Aurora DynamoDB ElastiCache
Private and public paths
VPC Route 53 CloudFront Global Accelerator
Identity, keys, secrets
IAM KMS GuardDuty Secrets Manager
Logs, traces, config
CloudWatch CloudTrail X-Ray Config
Infrastructure and release
CloudFormation CodePipeline CodeBuild CodeDeploy
APIs, workflows, events
API Gateway Step Functions EventBridge AppSync
Warehouse, query, ETL
Redshift Athena EMR Glue
Models and intelligence
Bedrock SageMaker AI Rekognition Comprehend
Modernize and transfer
Application Migration Service DMS Snow Family DataSync
Remote desktops and apps
WorkSpaces AppStream 2.0 Secure Browser Amazon DCV