Cloud for DevOps 2026 - AWS vs Azure vs GCP, Cloud Networking & IAM Basics

DevOps runs on the cloud. This guide helps you pick a platform to start with, then covers the two cloud fundamentals every DevOps engineer is expected to know: networking and identity/access.

Which cloud is best for DevOps jobs in India?

AWS dominates DevOps job demand in India and globally - it is the safest first choice.

Is Azure useful?

Yes. Azure is strong in enterprises built on Microsoft and .NET, and in many GCCs.

What about GCP?

GCP is popular with data, analytics and AI-focused companies, and for Kubernetes (it created the technology behind it).

Beginner recommendation

Start deep on AWS, learn the concepts well, then expand to a second cloud later - the fundamentals transfer across all three.

The same service, three names

Most of what looks like three separate skill sets is one skill set with three vocabularies. Once you know what a service does, learning its name on another cloud takes an afternoon. This table is the translation layer - it is also the fastest way to make sense of a job description written for a cloud you have not used.

What it does	AWS	Azure	GCP
Virtual machines	EC2	Virtual Machines	Compute Engine
Managed Kubernetes	EKS	AKS	GKE
Object storage	S3	Blob Storage	Cloud Storage
Private network	VPC	Virtual Network (VNet)	VPC
Serverless functions	Lambda	Azure Functions	Cloud Functions
Managed SQL database	RDS	Azure SQL Database	Cloud SQL
Container registry	ECR	ACR	Artifact Registry
Identity & permissions	IAM	Microsoft Entra ID + Azure RBAC	Cloud IAM
Secrets storage	Secrets Manager	Key Vault	Secret Manager
Native IaC	CloudFormation	ARM templates / Bicep	Mostly Terraform in practice

One naming note worth knowing, because it dates a CV: Azure Active Directory was renamed Microsoft Entra ID in 2023. Job listings and older tutorials still say Azure AD, and both refer to the same service.

Cloud networking basics

Every cloud gives you a private network (a VPC on AWS) divided into subnets (public and private). Security groups and firewall rules control which traffic is allowed in and out, route tables decide where traffic goes, and load balancers spread traffic across servers. Understanding this is what lets you deploy applications that are both reachable and secure.

The mental model that makes the rest click: a subnet is public because its route table sends outbound traffic to an internet gateway, not because of anything about the subnet itself. A private subnet routes outbound traffic through a NAT gateway instead, so instances can reach the internet to fetch packages but nothing on the internet can open a connection to them. Databases belong in private subnets; load balancers belong in public ones.

On AWS, the distinction people get wrong in interviews is security groups versus network ACLs. A security group is attached to an instance, is stateful (allow traffic in and the reply is automatically allowed out), and only has allow rules. A network ACL sits at the subnet boundary, is stateless (you must allow both directions explicitly), and supports deny rules. If traffic is being blocked and the security group looks correct, the NACL is the next place to look.

IAM and access control

Identity and Access Management (IAM) controls who can do what in your cloud account. The golden rule is least privilege - grant only the permissions a user or service actually needs. Key building blocks are users, groups, roles (assumed by services), and policies (the JSON that defines permissions). Mishandled IAM is one of the biggest causes of cloud breaches, so DevOps engineers are expected to get this right.

An IAM policy is just JSON with an effect, a set of actions, and the resources they apply to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

Note the /* on the end of the resource. That grants access to objects inside the bucket, not to the bucket itself - listing the bucket needs s3:ListBucket on the bucket ARN without the wildcard. Getting those two confused is the single most common IAM support ticket a junior engineer raises.

The habit that matters more than the syntax: use roles, not access keys. An EC2 instance or a CI runner should assume a role and receive short-lived credentials automatically. A long-lived access key pasted into a config file is the thing that ends up in a public repository and then in someone else's crypto miner.

How much cloud do you need before applying?

Less than most people assume, and in a narrower shape. Being able to explain how you would put a containerised application behind a load balancer, with the database in a private subnet and permissions granted by a role, covers most junior interview ground. Breadth across forty services does not - nobody is impressed that you know what Amazon Braket is.

Build one thing end to end on your own account instead. The free tier is enough, and remember to tear it down afterwards.

Bottom line

Pick AWS first, master networking and IAM early, and the rest of the cloud becomes far easier to learn.