Cloud Computing (AWS, Azure, Google Cloud)

The ideas every cloud job starts with: what "the cloud" really is, the NIST five characteristics, CapEx versus OpEx, the service models (IaaS, PaaS, SaaS, serverless), the deployment models (public, private, hybrid, multi-cloud), regions and availability zones, and the shared responsibility model. After this module you can explain the cloud clearly in an interview, pick a sensible region for an Indian app, and say who must secure what.

1. What the cloud is, and why companies use itCloud computing means renting computing power, storage and software over the internet from a provider, and paying only for what you use. You get a server in minutes instead of weeks, and you can grow or shrink with demand. The trade-off: bills can surprise you, you depend on the provider, and outages still happen.25 min
2. IaaS, PaaS, SaaS and serverlessService models say how much of the stack the provider runs for you. With IaaS you rent virtual machines and manage the operating system upwards. With PaaS you hand over your code and the platform runs it. With SaaS you simply use finished software. Serverless (FaaS) and containers as a service sit between IaaS and PaaS.25 min
3. Public, private, hybrid and multi-cloudDeployment models say WHERE the cloud runs and WHO shares it. A public cloud is shared by many customers; a private cloud serves one organisation; hybrid joins on-premises systems with a public cloud; multi-cloud uses two or more providers. In India, government work often uses MeitY-empanelled clouds.20 min
4. Regions, availability zones and edge locationsA region is a geographic area with several data centres, such as AWS Asia Pacific (Mumbai). Inside a region, availability zones are separate data centres with their own power and cooling, linked by fast private networks, so one fire or flood does not take your app down. Edge locations cache content close to users. You choose a region for latency, law, available services and price.25 min
5. The shared responsibility modelSecurity in the cloud is split. The provider secures the cloud itself: buildings, hardware, network and the virtualisation layer. You secure what you put in the cloud: your data, who can log in, your settings and, on IaaS, the operating system. The more managed the service, the less you do, but your data and access are always yours.25 min

Your first real steps on AWS: opening an account safely, locking down the root user, using the console, CLI, SDK and CloudShell, then IAM users, groups, roles and policies, how AWS decides allow or deny, and how the bill is calculated and kept under control. After this module you can set up an AWS account the way a careful company would, read and write least-privilege IAM policies, and estimate and watch your monthly cost.

1. Creating and securing an AWS accountAn AWS account is your container for resources and bills. The email you sign up with becomes the root user, which can do everything, so you protect it with MFA, never create access keys for it, and use it only for a few account tasks. You then create an admin identity for daily work, set a budget alert, and use AWS through the console, the CLI, an SDK or CloudShell.30 min
2. IAM: users, groups, roles and least privilegeIAM (Identity and Access Management) decides who can do what in your AWS account. Users and groups are for long-term identities, roles give temporary credentials to services and people, and policies list the allowed actions. Give each identity only the permissions it needs (least privilege), turn on MFA, and never put access keys in code.30 min
3. IAM policy JSON and how AWS decidesAn IAM policy is JSON with a Version and one or more Statements. Each statement has an Effect (Allow or Deny), the Actions (like s3:GetObject), the Resources as ARNs, and optional Conditions. AWS starts from deny, an explicit Allow grants access, and an explicit Deny always wins.35 min
4. Pricing, billing and cost controlAWS charges mainly for three things: compute time, stored data and data sent out to the internet (data coming in is usually free). You can pay On-Demand, commit for 1 or 3 years with Savings Plans or Reserved Instances for big discounts, or use Spot capacity at up to about 90% off if your work can be interrupted. Budgets, Cost Explorer and tags keep the bill under control.30 min

Run virtual servers on Amazon EC2 and keep data on EBS, EFS and Amazon S3. You learn how instance types are named, how to connect safely, how EC2 is billed, how block, file and object storage differ, how to organise and archive S3 data with storage classes and lifecycle rules, and how to keep buckets private with Block Public Access, bucket policies, encryption and pre-signed URLs. After this module you can launch and connect to an EC2 instance, choose the right storage for a workload, and run a private, cost-aware S3 bucket.

1. EC2: virtual servers in the cloudAmazon EC2 (Elastic Compute Cloud) rents you virtual servers, called instances, by the second. You pick an image (AMI) for the operating system, an instance type for the CPU and memory, a key pair or Session Manager to log in, and a security group as the firewall. You pay while the instance runs, so stop or terminate what you do not need.35 min
2. Block and file storage: EBS, instance store and EFSBlock storage (EBS) is a virtual hard disk for one instance in one Availability Zone. Instance store is a fast local disk that is wiped when the instance stops. File storage (EFS) is a shared network folder that many instances can use at once across zones. Object storage (S3) keeps files as objects you read over HTTPS.25 min
3. Amazon S3: buckets, objects and storage classesAmazon S3 stores files as objects inside buckets. A bucket has a globally unique name and lives in one region; each object has a key (its full name) and can be up to 5 TB. Storage classes let you pay less for data you read rarely, and lifecycle rules move or delete objects automatically as they age.35 min
4. Securing and sharing S3 dataNew S3 buckets are private by default: Block Public Access is on and ACLs are disabled. You grant access with IAM policies (for your own users and roles) and bucket policies (on the bucket itself), encrypt data with SSE-S3 or SSE-KMS, and share single files for a limited time with pre-signed URLs. Serve public websites through CloudFront rather than opening the bucket.30 min

Build your own private network in AWS and put the right database inside it. You plan a VPC and its subnets, understand public and private subnets, Internet and NAT gateways and route tables, protect traffic with security groups and network ACLs, connect VPCs to each other and to an office, run managed relational databases on RDS and Aurora, choose between relational, key-value, cache and warehouse databases, and put Route 53 and CloudFront in front of it all. After this module you can design a standard two-AZ VPC with private databases, choose Multi-AZ or read replicas, model a DynamoDB table, and serve a site globally with DNS and a CDN.

1. VPC basics: CIDR, subnets and gatewaysA VPC (Virtual Private Cloud) is your own private network inside an AWS region, with an IP range written in CIDR notation such as 10.0.0.0/16. You split it into subnets, each in one Availability Zone. A subnet is public when its route table sends internet traffic to an Internet Gateway; private subnets reach the internet only outward, through a NAT gateway.35 min
2. VPC security and connectivitySecurity groups are stateful allow-only firewalls on each instance; network ACLs are stateless subnet firewalls with numbered allow and deny rules. VPC endpoints let private subnets reach AWS services without the internet. Peering, Transit Gateway, Site-to-Site VPN and Direct Connect join VPCs and offices, and Flow Logs record who talked to whom.30 min
3. Managed relational databases: RDS and AuroraAmazon RDS runs MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2 for you, handling patching, backups and failover. Multi-AZ keeps a synchronous standby in another zone for high availability; read replicas are asynchronous copies for scaling reads. Aurora is AWS's own MySQL- and PostgreSQL-compatible engine. Keep databases in private subnets and let only the app's security group in.30 min
4. Choosing a database: DynamoDB, caches and warehousesNot every app needs a relational database. Key-value stores like DynamoDB give fast, predictable lookups at any scale when you know your access patterns; in-memory caches like ElastiCache make repeated reads very fast; warehouses like Redshift run big analytical queries. Pick the database by how the data is read and written, not by habit.30 min
5. DNS and CDN: Route 53 and CloudFrontRoute 53 is AWS's DNS service: it turns names like news.example.com into addresses, using records such as A, AAAA, CNAME and alias, and routing policies such as weighted, latency, failover and geolocation, with health checks. CloudFront is a CDN that caches your content at edge locations near users, so pages and videos load fast and your origin does less work.30 min

Run code without managing servers using AWS Lambda, connect parts of a system with API Gateway, SQS, SNS, EventBridge and Step Functions, watch everything with CloudWatch and CloudTrail, and keep the monthly bill under control with budgets, tags, schedules and clean-up habits. After this module you can build a small event-driven app on AWS, set alarms that wake the right person, explain who changed what, and estimate and cut what it costs.

1. Serverless with AWS LambdaServerless means AWS runs the servers for you: you upload a function, it runs only when an event arrives, it scales out on its own and scales to zero when idle. AWS Lambda charges per request and per GB-second of run time. It suits short, spiky jobs (up to 15 minutes) and is a poor fit for long jobs or a steady, heavy load.30 min
2. Event-driven design: API Gateway, SQS, SNS, EventBridge and Step FunctionsIn an event-driven system, parts talk by leaving messages instead of calling each other and waiting. API Gateway is the front door, SQS is a queue that holds work until a worker is ready, SNS copies one message to many subscribers, EventBridge routes events and runs schedules, and Step Functions runs multi-step workflows. Decoupling like this lets each part fail, retry and scale on its own.30 min
3. Monitoring with CloudWatch, CloudTrail and ConfigAmazon CloudWatch collects metrics (numbers over time), logs (text lines) and alarms that act when a metric crosses a line. CloudTrail records every API call, so you can see who did what and when. AWS Config records how each resource was configured over time. Together they tell you that something is wrong, why, and who changed it.30 min
4. Cost control in practiceIn the cloud nothing stops you spending, and the bill arrives at the end of the month. Control it in three steps: see it (budgets with alerts, Cost Explorer, anomaly detection and tags), cut waste (rightsize, schedule dev servers, delete forgotten volumes, IPs and NAT gateways, add S3 lifecycle rules), and pay less for what stays (Savings Plans and Spot). FinOps makes this a shared, regular habit.30 min

Learn Azure the way an AWS-trained engineer meets it at a new job: how tenants, management groups, subscriptions and resource groups fit together, how Microsoft Entra ID and Azure RBAC control who can do what, the main compute and storage services (VMs, scale sets, App Service, storage accounts and blob tiers), and networking, Azure Functions, databases and Azure Monitor. After this module you can find your way around an Azure subscription, create resources with the Azure CLI, grant least-privilege access, choose the right storage tier, write NSG rules, and map the AWS services you know to their Azure equivalents.

1. How Azure is organised: tenants, subscriptions and resource groupsAzure is organised as a tree: a Microsoft Entra tenant at the top, then management groups, subscriptions (each one a billing and access boundary), resource groups (containers that share a lifecycle), and finally resources such as VMs and storage accounts. Azure Resource Manager handles every request, whether it comes from the portal, the Azure CLI, PowerShell or a Bicep template. Resources live in regions, many of which have availability zones; India has Central India (Pune), South India (Chennai) and West India (Mumbai).25 min
2. Microsoft Entra ID and Azure RBACMicrosoft Entra ID (called Azure Active Directory until 2023) is the identity service behind Azure and Microsoft 365: it holds users, groups, service principals and managed identities, and handles sign-in with MFA, passwordless methods and Conditional Access. Azure RBAC then decides what an identity may do with Azure resources: a role assignment joins a security principal, a role definition and a scope, and it is inherited downward.30 min
3. Azure compute and storageAzure Virtual Machines come in families such as B (burstable), D (general purpose), E (memory) and F (compute); availability sets and availability zones keep them running through failures, and VM Scale Sets add and remove copies. App Service runs web apps without managing servers, and Container Apps runs containers. A storage account holds Blob, Files, Queue and Table data with redundancy from LRS to GZRS, and blobs can live in Hot, Cool, Cold or Archive tiers.30 min
4. Azure networking, Functions, databases and monitoringAn Azure VNet is your private network, split into subnets and protected by network security groups whose rules are checked by priority, lowest number first. Peering, VPN Gateway and ExpressRoute connect networks; Load Balancer, Application Gateway and Front Door spread traffic. Azure Functions is the serverless option, Azure SQL Database and Cosmos DB are the main managed databases, and Azure Monitor with Log Analytics (queried in KQL) watches it all.35 min

Learn how Google Cloud is organised (organisation, folders, projects, billing and IAM), tour its core services from Compute Engine and Cloud Storage to Cloud Run and BigQuery, map services between AWS, Azure and Google Cloud, and drive all three clouds safely from the command line. After this module you can set up a sensible Google Cloud project structure, pick the right Google service for a job, name the equivalent service on another cloud, and script the AWS, Azure and Google Cloud CLIs without leaking credentials.

1. Google Cloud structure: projects, billing and IAMIn Google Cloud every resource lives in a project, projects can be grouped into folders, and folders sit under one organisation. A billing account pays for projects, and budgets warn you before costs run away. IAM grants roles to principals (people, groups and service accounts), and a role granted higher up the tree is inherited by everything below it.30 min
2. Core Google Cloud servicesA dozen services cover most real projects on Google Cloud: Compute Engine for VMs, Cloud Storage for files, a global VPC and Cloud Load Balancing for networking, Cloud Run for containers that scale to zero, Cloud SQL and Firestore for databases, BigQuery for analytics, Pub/Sub for messaging and GKE for Kubernetes. Knowing what each one is for, and how it is billed, prevents most surprises.30 min
3. AWS vs Azure vs Google Cloud: the service mapThe three big clouds offer the same building blocks under different names: EC2, Azure Virtual Machines and Compute Engine are all VMs; S3, Blob Storage and Cloud Storage are all object storage. A service map lets you carry your skills from one cloud to another. Choose a cloud by team skills, existing licences, data and AI needs, credits, regions, price and compliance, and be honest that multi-cloud adds complexity.25 min
4. The command line on all three cloudsEvery cloud has a command-line tool: the AWS CLI (aws), the Azure CLI (az) and the Google Cloud CLI (gcloud). They let you script anything you can click, choose an account and region per command, and print JSON you can filter or feed into scripts. Keep credentials out of code and Git, prefer single sign-on and short-lived credentials, and turn on secret scanning.30 min

Package an app as a container image, push it to a cloud registry, and run it on the cloud: Amazon ECS with Fargate, managed Kubernetes (EKS, AKS and GKE) and serverless container platforms such as Cloud Run. You also learn how to choose between serverless containers, Kubernetes, plain VMs and PaaS. After this module you can build and push an image, read an ECS task definition and a Kubernetes Deployment, estimate Fargate and node costs, and recommend the right place to run a container for a given team.

1. Containers, images and registriesA container packages an app with everything it needs and runs it as an isolated process that shares the host's kernel, so it is lighter and starts faster than a virtual machine. You build an image from a Dockerfile, store it in a registry such as Amazon ECR, Azure Container Registry or Google Artifact Registry, and run it anywhere. Tags are movable labels; digests identify one exact image.30 min
2. Amazon ECS and AWS FargateAmazon ECS is AWS's own service for running containers. You describe a container in a task definition, run copies of it as tasks, and keep the right number running behind a load balancer with a service. With the Fargate launch type you never manage servers and pay per vCPU and GB of memory per second; with the EC2 launch type you run and pay for the instances yourself.30 min
3. Managed Kubernetes: EKS, AKS and GKEKubernetes is an open-source container orchestrator: a control plane decides where pods (groups of containers) run on worker nodes, and Deployments and Services describe what you want. Managed Kubernetes means the cloud runs and upgrades the control plane for you: Amazon EKS, Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE). GKE Autopilot and EKS with Fargate go further and manage the nodes too.30 min
4. Choosing where to run a containerYou can run a container on serverless container platforms (Cloud Run, Azure Container Apps, ECS on Fargate), on managed Kubernetes, on plain VMs, or on a PaaS such as Azure App Service or AWS Elastic Beanstalk. Start with the simplest option your team can run well, and move to Kubernetes when the number of services, the team's skills and the need for control justify it.25 min

Stop building cloud systems by clicking. This module explains why teams write infrastructure as code, how declarative tools, idempotency and drift work, and then shows the same versioned S3 bucket in AWS CloudFormation and in Terraform, with the commands to preview, apply and remove it. It ends with how a team works safely: pull request reviews of plans, CI pipelines, separate environments, no secrets in templates, policy checks and tagging rules. After this module you can read and write a small CloudFormation template and Terraform configuration, explain a plan before applying it, and set up a safe IaC workflow for a team.

1. Why infrastructure as codeInfrastructure as code (IaC) means you describe your servers, networks, buckets and databases in text files and let a tool create them. The files live in Git, so every change is reviewed, repeatable and easy to undo. Most IaC tools are declarative: you say what you want, and the tool works out the steps, again and again, with the same result.25 min
2. AWS CloudFormationCloudFormation is the IaC service built into AWS. You write a template in YAML or JSON that lists resources, and AWS creates them together as a stack. Change sets show what will change before it happens, and if something fails, CloudFormation rolls the stack back to the last working state.30 min
3. Terraform for the cloudTerraform is a declarative IaC tool that works with AWS, Azure, Google Cloud and hundreds of other services through plugins called providers. You write .tf files in HCL, run terraform plan to preview the changes and terraform apply to make them. Terraform remembers what it built in a state file, which teams keep in shared, locked remote storage.35 min
4. IaC in a team: reviews, pipelines and policyIn a team, infrastructure changes go through Git like application code: a pull request shows the plan, a teammate reviews it, and a CI pipeline applies it after merge. Environments come from the same code with different settings, secrets stay in a secrets manager, and automated policy checks stop risky changes, such as a public bucket, before they are applied.30 min

Design systems that stay up, grow with demand and come back after a disaster. This module covers availability and the "nines", single points of failure, multi-AZ and stateless design, and the maths of components in series and in parallel. It then explains load balancers and Auto Scaling groups with their scaling policies, backups, RPO and RTO and the four disaster recovery strategies, and finally the AWS Well-Architected Framework with its six pillars. After this module you can calculate the availability of a design, choose a scaling policy and a DR strategy that fit the business targets, and review an architecture against the six pillars.

1. Designing for high availabilityAvailability is the share of time a system works for its users, often written as "nines" such as 99.9%. You raise it by removing single points of failure: run stateless app servers in more than one Availability Zone, keep state in managed databases and caches, and let health checks send traffic only to healthy servers. Simple maths tells you what a design can achieve: parts in series multiply, redundant parts in parallel add up.30 min
2. Load balancing and auto scalingYou can scale up (a bigger server) or scale out (more servers). Scaling out needs a load balancer to share traffic and an Auto Scaling group to add and remove servers. Scaling policies decide when: keep average CPU near a target, step up on alarms, scale on a schedule before a known peak, or let AWS predict the load from history.35 min
3. Backups and disaster recoveryHigh availability survives a broken server or zone; backups and disaster recovery (DR) survive deleted data, ransomware and the loss of a whole region. Two numbers drive every DR plan: RPO, how much data you can afford to lose, and RTO, how long you can afford to be down. The four DR strategies, from backup and restore to multi-site active/active, trade cost against those two numbers.35 min
4. The Well-Architected FrameworkThe AWS Well-Architected Framework is a set of best practices and review questions organised into six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization and Sustainability. Teams use it, often with the free Well-Architected Tool, to find risks in a design and plan improvements. Azure and Google Cloud publish similar frameworks.30 min

How companies keep cloud accounts and data safe, and how they prove it to auditors and regulators: identity as the new perimeter, encryption and secrets management, logging and threat detection, and compliance frameworks with the Indian rules (DPDP Act, CERT-In directions, RBI data localisation, MeitY empanelment). After this module you can lock down an AWS organisation, protect data with KMS and Secrets Manager, set up the logs and detectors that catch an attack, and write a first compliance checklist for an Indian fintech.

1. Identity is the new perimeterIn the cloud there is no office wall around your servers: anyone with valid credentials can reach the API from anywhere. So identity becomes the perimeter. You lock away the root user, require MFA everywhere, sign people in through SSO, give machines roles with short-lived credentials, grant the least privilege needed, and use AWS Organizations with Service Control Policies to set guardrails no one can break.30 min
2. Encryption, keys and secretsEncrypt data at rest (on disks, in buckets and databases) and in transit (with TLS). Cloud key services such as AWS KMS hold the master keys and use envelope encryption, so your data keys are themselves encrypted. Passwords, API tokens and database credentials belong in a secrets manager, never in code. Classify data first, so the most sensitive data gets the strongest controls, and encrypt your backups too.30 min
3. Logging, threat detection and incident responseYou cannot protect what you cannot see. CloudTrail records every API call; GuardDuty spots threats in those logs; Security Hub gathers findings in one place; Inspector scans for vulnerabilities, Macie finds sensitive data in S3, and AWS Config checks settings against rules. WAF and Shield protect web apps at the edge. When something goes wrong, you isolate, preserve evidence, rotate credentials and trace what happened in CloudTrail.30 min
4. Compliance in the cloud, with Indian rulesCompliance means proving you follow the laws and standards that apply to your data. The cloud provider's audits cover its part; you must cover yours. Know the main frameworks (ISO/IEC 27001, SOC 2, PCI DSS, HIPAA, GDPR) and the Indian rules: the DPDP Act 2023, the CERT-In directions (6-hour incident reporting, 180 days of logs in India), RBI payment data localisation and MeitY empanelment for government work. Region choice gives you data residency; AWS Config and Azure Policy give you evidence.30 min

Turn what you learned into a job: the foundational exams (AWS Cloud Practitioner, Azure Fundamentals, Google Cloud Digital Leader), the associate exams (AWS Solutions Architect Associate, Azure Administrator, Google Associate Cloud Engineer) and how to answer scenario questions, portfolio projects that get interviews, and the cloud roles in India with honest salary ranges and model interview answers. After this module you can pick the right exam, follow a week-by-week study plan, build and document two or three portfolio projects, and prepare for a cloud job interview.

1. Foundational exams: CLF-C02, AZ-900 and Cloud Digital LeaderA foundational exam proves you understand cloud basics: what the cloud is, the main services, security, pricing and support. AWS Certified Cloud Practitioner (CLF-C02), Microsoft Azure Fundamentals (AZ-900) and Google Cloud Digital Leader are the common choices, and AWS Certified AI Practitioner is a newer option. They suit freshers, career changers and non-technical staff. With this course, free official training and a few weeks of steady study, most learners are ready.25 min
2. Associate exams and scenario questionsAssociate exams test whether you can design and run real systems. AWS Solutions Architect – Associate (SAA-C03) is the most requested in job adverts; Azure Administrator (AZ-104) and Google Associate Cloud Engineer are the equivalents on the other clouds. Their questions are scenarios with several plausible answers. Read the last line first, spot the keyword such as "most cost-effective" or "least operational overhead", and eliminate the wrong options.30 min
3. Portfolio projects that get interviewsA certificate says you studied; a project shows you can build. Four projects cover most of what interviewers ask: a static website on S3 and CloudFront with HTTPS, a serverless API with API Gateway, Lambda and DynamoDB, a three-tier app in a custom VPC built with Terraform, and a monitoring and cost dashboard. Document each one with an architecture diagram, a cost estimate, your security choices and teardown steps, and always set a budget and delete resources when you finish.35 min
4. Cloud roles, salaries and interviews in IndiaCloud jobs range from cloud support associate and cloud administrator to cloud engineer, DevOps engineer, solutions architect, cloud security engineer and FinOps analyst. All of them need Linux, networking, scripting and one cloud learned deeply. In India, freshers in support and associate roles commonly earn about ₹3.5–7 LPA, and cloud engineers with 2–4 years about ₹7–15 LPA, varying by city, company and skills. Jobs are in IT services companies, product companies, global capability centres, startups and cloud consulting partners.30 min