Cloud job descriptions read like alphabet soup until you notice the pattern: they're organized around the same handful of infrastructure concerns, just wearing each provider's brand names. Learn the categories, and you can map your real experience onto any posting's vocabulary — even for a provider you've used less.
The categories that recur
Almost every cloud posting touches these areas. Here's the concept and how each of the big three names it:
- Compute — where code runs. AWS: EC2, Lambda, ECS/Fargate. Azure: Virtual Machines, Functions, App Service. GCP: Compute Engine, Cloud Functions, Cloud Run.
- Storage — object and block stores. AWS: S3, EBS. Azure: Blob Storage, Managed Disks. GCP: Cloud Storage, Persistent Disk.
- Networking — the private network layer. AWS: VPC, Route 53, ELB. Azure: VNet, Azure DNS, Load Balancer. GCP: VPC, Cloud DNS, Cloud Load Balancing.
- Infrastructure as Code (IaC) — defining infra in version-controlled files. Terraform is cross-provider and shows up everywhere; provider-native tools are CloudFormation (AWS), ARM/Bicep (Azure), and Deployment Manager (GCP).
- Containers and orchestration — Kubernetes is the common tongue: EKS (AWS), AKS (Azure), GKE (GCP). Docker underlies all of them.
- Observability — monitoring, logging, tracing. AWS: CloudWatch, X-Ray. Azure: Monitor, Application Insights. GCP: Cloud Monitoring and Logging (formerly Stackdriver).
- Security and identity — access control and secrets. AWS: IAM, KMS, Secrets Manager. Azure: Entra ID (formerly Azure AD), Key Vault. GCP: IAM, Cloud KMS, Secret Manager.
When you read a posting, tag each requirement to one of these buckets. Suddenly a wall of acronyms becomes seven familiar problems, and you can see which ones your background actually covers.
Mapping your experience to their language
The mistake is describing your work in your own shorthand and hoping a reader translates. If your resume says "set up servers and load balancing on AWS" and the posting asks for "VPC design and ELB configuration," those are the same work — so use their words. Match the concept first, then adopt the specific service name you genuinely worked with.
Be precise about depth. "Deployed to EKS" and "operated and upgraded production EKS clusters" describe very different levels of ownership. Use the verb that's true. A reviewer who runs Kubernetes daily will read the difference immediately, and claiming the bigger scope only sets up a hard interview.
Handling multi-cloud honestly
Plenty of postings list two or three providers, and plenty of engineers are deep in one and lighter in the others. Say that plainly. "Primary experience in AWS; delivered one production workload on GCP" is a credible, useful statement — far better than implying equal fluency across all three. The transferable concepts are real: someone who understands VPCs, IAM, and Terraform on one platform picks up the equivalents faster, and it's fair to say so.
Where your evidence is thin for a provider a role centers on, name it as a gap rather than papering over it — in a cover letter, "ramping on Azure to complement my AWS background" is honest and often enough. Keeping your actual projects, the services you touched, and the scope you owned in one place — a Memory Board of real cloud work — makes this mapping fast: you're matching a posting against a record, not straining to recall which project used which service. Match the category, name the service you truly used, and be straight about the rest.