devuplabs.cloud
Free previewConcept guide45 min read45 min setup

Getting Started

This page is your entry point. Before opening any lab in this course, read this page end to end. Every lab assumes the mental models and setup steps covered here.

Don't skip this unless you already have an AWS account with the $200 credit claimed and know the bare minimum basics.

What is the Cloud?

The problem cloud solves

Before cloud computing, if you wanted to run a web application, you had to:

  1. 1Buy physical servers (weeks of procurement, thousands of dollars upfront)
  2. 2Rent space in a data centre and pay for power and cooling
  3. 3Set up networking, security, operating systems yourself
  4. 4Overprovision, buy enough hardware for your peak load, which sits idle 90% of the time
  5. 5Wait months before your app could serve a single user

This worked for large companies. It was impossible for a student or a startup.

Cloud computing flips this model. Instead of buying infrastructure, you rent it by the hour (or the second). You pay only for what you use. You can go from zero to a globally available application in minutes. You return resources when you're done and stop paying immediately.

The three core properties that define cloud computing:

  • On-demand self-service: you provision resources yourself through a console or API, no human approval needed
  • Elasticity: scale up when traffic spikes, scale down when it drops, automatically
  • Pay-as-you-go: no upfront commitment, billed for actual usage, usually per second or per request

The three service models

Mental model: the pizza analogy

Think of making pizza. You can make everything from scratch at home (traditional IT), buy a frozen pizza and just bake it (IaaS), call for delivery but bring your own toppings (PaaS), or just order from a restaurant (SaaS). Each model offloads more responsibility to someone else.

ModelYou manageProvider managesAWS Example
IaaS: Infrastructure as a ServiceOS, runtime, app, dataHardware, networking, data centreEC2 (virtual machines)
PaaS: Platform as a ServiceApp code and dataOS, runtime, scaling, patchingLambda, RDS, Elastic Beanstalk
SaaS: Software as a ServiceYour data and configurationEverything elseAmazon WorkMail, Chime

This course focuses on IaaS and PaaS: the layers where engineers build.


AWS Fundamentals

What is AWS?

Amazon Web Services (AWS) is the world's largest cloud platform. Launched in 2006, it offers over 200 services, from virtual machines and databases to machine learning, IoT, and satellite ground stations.

You don't need to know all 200. This course covers the core services every backend engineer uses daily: compute (EC2, Lambda), storage (S3), databases (RDS, DynamoDB), messaging (SQS, SNS, EventBridge), and observability (CloudWatch).

Regions and Availability Zones

Mental model: think of it like this

A Region is a city. An Availability Zone is a different building in that city. The buildings are close enough to talk to each other quickly (low latency), but far enough apart that a flood, fire, or power outage in one building doesn't affect the others. AWS runs your app across multiple buildings so it stays up even when one fails.

Region:

a physical geographic location where AWS has data centres. Examples: ap-south-1 (Mumbai), us-east-1 (N. Virginia), eu-west-1 (Ireland). Each region is completely independent, data in Mumbai does not automatically replicate to Ireland.

Availability Zone (AZ):

one or more discrete data centres within a Region, each with independent power, cooling, and networking. Every Region has at least 3 AZs. They're identified as ap-south-1a, ap-south-1b, ap-south-1c.

Why this matters for you

When you create a resource like an EC2 instance or RDS database, you choose which Region and AZ it lives in. If you put everything in one AZ and that AZ has a power outage, your app goes down. Production systems spread across multiple AZs to survive single failures.

For this course:

We use ap-south-1 (Mumbai) throughout. It's the closest region for most students and has the full set of services the labs need.

bash
# Set your region once -- paste this into every new terminal session
export AWS_REGION=ap-south-1

# Verify AWS CLI knows your region
aws configure get region

# List all available regions
aws ec2 describe-regions --query 'Regions[*].RegionName' --output table

The Global Infrastructure map

Rendering diagram…

Click to interact · then scroll to zoom, drag to pan

Service categories you'll encounter

CategoryWhat it doesKey servicesCovered in
ComputeRun code / applicationsEC2, Lambda, ECS, EKSLambda, ECS labs
StorageStore files, objects, blocksS3, EBS, EFSS3 lab
DatabaseStructured and NoSQL dataRDS, DynamoDB, ElastiCacheRDS lab
NetworkingConnect and isolate resourcesVPC, Subnets, Route Tables, Security GroupsNetworking labs
MessagingAsync communication between servicesSQS, SNS, EventBridge, KinesisSQS, SNS, EventBridge labs
ObservabilityMonitor, log, and alertCloudWatch, X-RayCloudWatch labs
Security & IdentityControl who can do whatIAM, KMS, Secrets ManagerAll labs (IAM sessions)
Developer ToolsBuild and deploy pipelinesCodePipeline, ECR, CodeBuildCI/CD lab

Account Setup

Create your AWS account

You need a personal AWS account for every lab in this course

Do not use a company or shared account, labs create and delete real resources, and you need full admin access. The Free Tier and $200 in credits cover everything in this course if you clean up after each lab.

  1. 1Go to https://aws.amazon.com and click Create an AWS Account
  2. 2Enter your email address and choose an account name (e.g. yourname-aws-learning)
  3. 3Choose Root user and verify your email
  4. 4Enter your contact information, use your real address
  5. 5Enter a payment method. AWS requires this even for Free Tier accounts to verify identity.

For Indian accounts, prefer using UPI at signup. AWS sends a ₹2 collect request to your UPI app (GPay, PhonePe, Amazon Pay) for identity verification (refunded within a few business days). You can also set up UPI AutoPay for automated recurring monthly billing.

How AWS billing actually works, read this before you worry

AWS does not auto-deduct charges in real time. Instead:

  1. AWS meters your usage throughout the month
  2. At the end of the month, AWS generates an invoice
  3. You receive the invoice by email and it appears in the Billing Dashboard
  4. Payment is collected from your saved payment method a few days after invoice generation

This means: if you accidentally leave a resource running and exceed Free Tier, you will not be immediately charged. You get an invoice first. If the charges are due to a genuine mistake, you can contact AWS Support, explain the situation, and request a waiver. AWS routinely does this for learners encountering their first accidental charge. You can also dispute the charge through the Billing console with a valid reason.

That said, do not rely on this. The cleanup habit at the end of every lab is non-negotiable. Repeated overages won't be waived.

  1. 1Verify your phone number via SMS or voice call
  2. 2Choose the Basic (Free) support plan
  3. 3At account plan selection, choose Free Plan: this gives you the full $200 in credits (see Part 4)
  4. 4Sign in to the AWS Console at https://console.aws.amazon.com

Checkpoint: you can log in to the AWS Console and see the main dashboard.

Secure your root account immediately

The root account has unlimited power

The root account has unlimited power over your AWS account, it can delete everything, change billing, and cannot be restricted by any policy. Never use it for day-to-day work. Secure it now and put it away.

Enable MFA on root:

  1. 1Click your account name (top right) → Security credentials
  2. 2Under Multi-factor authentication (MFA)Assign MFA device
  3. 3Choose Authenticator app → scan the QR code with Google Authenticator or Authy
  4. 4Enter two consecutive OTP codes to confirm
  5. 5Sign out

Never use root again after this step. All lab work happens through an IAM user (created in Step 3).

Create an IAM admin user

What's happening here

IAM (Identity and Access Management) is AWS's permission system. Every API call you make (from the console or CLI) is made by an *identity* (a user or role). That identity has policies attached that say what it can and cannot do.

You'll create one IAM user with AdministratorAccess for this course. In a real company you'd use more restricted permissions, but for learning, admin access lets you follow every lab without hitting permission errors.

  1. 1In the AWS Console, search for IAM and open it
  2. 2Left sidebar → UsersCreate user
  3. 3Username: aws-learning-admin
  4. 4Check Provide user access to the AWS Management Console
  5. 5Choose I want to create an IAM user
  6. 6Set a password and uncheck "User must create a new password"
  7. 7Click NextAttach policies directly → search for and select AdministratorAccess
  8. 8Click NextCreate user
  9. 9Download the CSV with the console sign-in URL, username, and password. Save it.
  10. 10Sign out from root → sign in as aws-learning-admin using the console sign-in URL from the CSV

Checkpoint: you're logged in as aws-learning-admin: not root. Check the top-right corner, it should show aws-learning-admin @ your-account-id.

Install and configure the AWS CLI

What's happening here

Every lab in this course uses the AWS CLI (Command Line Interface), a terminal tool that lets you create, query, and delete AWS resources by running commands. It's faster and more reproducible than clicking through the console, and it's how engineers work in the real world.

The CLI uses Access Keys: a key ID and secret that authenticate your commands. These are like a username and password for the API.

Install the CLI:

bash
# macOS (Homebrew)
brew install awscli

# Linux (apt)
sudo apt install awscli

# Verify installation
aws --version
# Expected: aws-cli/2.x.x Python/3.x.x ...

Create Access Keys for your IAM user:

  1. 1In the Console, go to IAM → Users → aws-learning-admin
  2. 2Tab: Security credentialsCreate access key
  3. 3Use case: Command Line Interface (CLI)
  4. 4Check the confirmation box → NextCreate access key
  5. 5Copy both the Access Key ID and Secret Access Key now. You cannot retrieve the secret again.

Configure the CLI:

bash
aws configure
# AWS Access Key ID: paste your key ID
# AWS Secret Access Key: paste your secret key
# Default region name: ap-south-1
# Default output format: json

# Verify it works
aws sts get-caller-identity

Checkpoint: aws sts get-caller-identity returns your Account ID, UserId, and Arn containing aws-learning-admin. If you see an error, re-check the key ID and secret.

Useful CLI patterns you'll see in every lab:

bash
# Export variables so you don't retype them
export AWS_REGION=ap-south-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# --query filters the JSON response (JMESPath syntax)
aws ec2 describe-instances --query 'Reservations[*].Instances[*].InstanceId'

# --output controls the format: json (default), text, table
aws s3 ls --output table

# --region overrides your configured region for one command
aws s3 ls --region us-east-1

Cost Management

The Free Tier & $200 in Credits

What's happening here

AWS overhauled its Free Tier in July 2025. New accounts now get real credits, not just usage limits. Here's what you actually get:

  • $100 in credits at signup: automatically applied to your account, works across all 200+ AWS services
  • Up to $100 more: earn by completing 5 quick onboarding activities in the AWS Console (launch an EC2 instance, create an RDS database, create a Lambda function, try Bedrock, set up a Budget). Takes about 30 minutes total.
  • 30+ Always Free services: Lambda, DynamoDB, SQS, SNS, and others have monthly free usage limits that never expire, regardless of credits
  • Free Plan duration: 6 months from signup, or until credits run out, whichever comes first. You can upgrade to a Paid Plan anytime; unused credits remain valid for 12 months from your signup date.

This course is designed to stay well within the Always Free limits. The $200 in credits is a safety net for the EC2 and RDS labs, which use t3.micro instances that cost fractions of a cent per hour. If you clean up after every lab, your credits will still be nearly intact after finishing the entire course.

Key Always Free limits relevant to this course:

ServiceAlways Free LimitWhat uses it in this course
Lambda1 million invocations/month, 400,000 GB-seconds computeLambda, EventBridge Scheduler, CloudWatch Alarms labs
DynamoDB25 GB storage, 25 RCU + 25 WCU (always free)DynamoDB usage in labs
SQS1 million requests/monthSQS, EventBridge Scheduler labs
SNS1 million publishes/month, 1,000 email deliveriesSNS, CloudWatch Alarms labs
EventBridge Scheduler14 million invocations/monthEventBridge Scheduler lab
CloudWatch10 custom metrics, 5 GB log ingestion, 3 dashboards/monthCloudWatch labs (stay within 10 custom metrics)
EC2750 hours/month of t2.micro or t3.micro (draws from $200 credits)CloudWatch Agent lab (1 instance × lab duration)
S35 GB storage, 20,000 GET, 2,000 PUT requests (draws from credits)S3 lab
RDS750 hours/month of db.t3.micro (draws from credits)RDS lab

Services that cost money immediately (not covered by Always Free or credits efficiently)

  • NAT Gateway: ~$0.045/hour + data transfer. Avoid unless the lab explicitly requires it.
  • Elastic IP: free while attached to a running instance, $0.005/hour when unattached. Release them immediately after labs.
  • RDS Multi-AZ: uses 2× the instance hours. Only use Single-AZ for labs.
  • CloudWatch custom metrics beyond 10: $0.30/metric/month. Labs in this course stay within 10.

Earn your extra $100 in credits

Do this immediately after account setup, it takes 30 minutes and doubles your credit balance:

  1. 1Sign in to the AWS Console
  2. 2On the Console Home page, find the Explore AWS widget
  3. 3Complete all 5 activities: EC2, RDS, Lambda, Bedrock, Budgets (these will be covered in the labs)
  4. 4Credits are applied within a few minutes of completing each activity

Checkpoint: Go to Billing DashboardCredits: you should see $200 total once all activities are complete.

Set up a billing alert (Mandatory)

What's happening here

A billing alert emails you when your AWS charges exceed a threshold. This is your safety net, if you forget to clean up a resource, you'll know before the bill gets large.

Set this up before running any lab. Use $5 as the threshold, any real charge (above Free Tier) should be investigated immediately.

Step 1: Enable billing alerts (one-time, must be done as root)

  1. 1Sign in as root
  2. 2Top-right → your account name → Billing and Cost Management
  3. 3Left sidebar → Billing Preferences
  4. 4Under Alert preferences → check Receive CloudWatch billing alerts
  5. 5Save preferences
  6. 6Sign out from root, sign back in as aws-learning-admin

Step 2: Create the billing alarm via CLI

bash
# Billing metrics are always in us-east-1 regardless of your working region
aws cloudwatch put-metric-alarm \
  --alarm-name billing-alert-5usd \
  --alarm-description "Alert when AWS charges exceed USD 5" \
  --namespace AWS/Billing \
  --metric-name EstimatedCharges \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --region us-east-1

# Create SNS topic for the alert (also in us-east-1)
BILLING_SNS=$(aws sns create-topic \
  --name billing-alerts \
  --region us-east-1 \
  --query 'TopicArn' --output text)

# Subscribe your email
aws sns subscribe \
  --topic-arn $BILLING_SNS \
  --protocol email \
  --notification-endpoint your-email@example.com \
  --region us-east-1

# Attach SNS to the alarm
aws cloudwatch put-metric-alarm \
  --alarm-name billing-alert-5usd \
  --alarm-description "Alert when AWS charges exceed USD 5" \
  --namespace AWS/Billing \
  --metric-name EstimatedCharges \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions $BILLING_SNS \
  --region us-east-1

echo "Billing alert set. Confirm the subscription in your email."

Checkpoint: billing alarm created in us-east-1. Email confirmation received from SNS. Open the email and click Confirm subscription.

Set up an AWS Budget

What's happening here

A Budget gives you a monthly spending cap with proactive alerts, it notifies you at 50%, 80%, and 100% of your budget threshold. This is different from a billing alarm: the alarm triggers on the current estimated charge, while a Budget forecasts whether you'll exceed your limit by month-end.

Set a $10/month budget. If you hit $5 (50%), investigate immediately.

bash
cat > /tmp/budget.json << 'EOF'
{
  "BudgetName": "aws-learning-monthly",
  "BudgetLimit": {
    "Amount": "10",
    "Unit": "USD"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}
EOF

cat > /tmp/notifications.json << 'EOF'
[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 50,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      {"SubscriptionType": "EMAIL", "Address": "your-email@example.com"}
    ]
  },
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      {"SubscriptionType": "EMAIL", "Address": "your-email@example.com"}
    ]
  }
]
EOF

aws budgets create-budget \
  --account-id $ACCOUNT_ID \
  --budget file:///tmp/budget.json \
  --notifications-with-subscribers file:///tmp/notifications.json

echo "Budget created: USD 10/month with alerts at 50% and 80%"

Checkpoint: aws budgets describe-budgets --account-id $ACCOUNT_ID returns your aws-learning-monthly budget.

The cleanup habit

Every lab in this course ends with a cleanup section. Run it before closing your terminal. Always.

The most common source of unexpected AWS charges for students:

  • EC2 instances left running (costs by the hour)
  • RDS instances left running (costs by the hour, even when idle)
  • Elastic IPs not released
  • NAT Gateways not deleted
  • S3 buckets with data not emptied and deleted

Quick check, run this after any lab session to catch leftover resources:

bash
export AWS_REGION=ap-south-1

echo "=== Running EC2 Instances ==="
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,Type:InstanceType,Name:Tags[?Key==`Name`].Value|[0]}' \
  --region $AWS_REGION --output table

echo "=== RDS Instances ==="
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,Class:DBInstanceClass,Status:DBInstanceStatus}' \
  --region $AWS_REGION --output table

echo "=== Elastic IPs ==="
aws ec2 describe-addresses \
  --query 'Addresses[*].{IP:PublicIp,AssociatedInstance:InstanceId}' \
  --region $AWS_REGION --output table

echo "=== NAT Gateways ==="
aws ec2 describe-nat-gateways \
  --filter Name=state,Values=available \
  --query 'NatGateways[*].{ID:NatGatewayId,State:State}' \
  --region $AWS_REGION --output table

echo "=== S3 Buckets ==="
aws s3 ls

If you see anything you don't recognise, terminate, delete, or release it.


IAM in 5 Minutes

Why IAM matters for every single lab

Every action in AWS (creating an S3 bucket, invoking a Lambda function, reading from SQS) is an API call made by an *identity*. IAM decides whether that identity is allowed to make that call. Get IAM wrong and nothing works. Understand IAM and debugging becomes systematic.

The four IAM concepts you need immediately

1. Users:

a person or application with long-lived credentials (username/password + access keys). You created aws-learning-admin in Step 3. In production, humans use users.

2. Roles:

an identity that AWS services assume temporarily. A Lambda function assumes a role to call S3. An EC2 instance assumes a role to write logs. Roles have no long-lived credentials, they get temporary tokens that expire. This is how service-to-service authentication works in AWS.

3. Policies:

JSON documents that list allowed or denied actions. Attached to users or roles. Example: AWSLambdaBasicExecutionRole allows Lambda to write CloudWatch logs.

4. Trust Policy:

a special policy on a role that says *who is allowed to assume this role*. A Lambda role has lambda.amazonaws.com in its trust policy. An EC2 role has ec2.amazonaws.com. If the trust policy is wrong, the service can't assume the role and nothing works.

bash
# See your current identity
aws sts get-caller-identity

# List policies attached to your IAM user
aws iam list-attached-user-policies --user-name aws-learning-admin

# See what a policy allows (example: AWSLambdaBasicExecutionRole)
aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole \
  --version-id v1 \
  --query 'PolicyVersion.Document'

The IAM mental model for every lab

Every time a lab creates an IAM role, ask yourself two questions:

  1. 1Trust policy: which AWS service is allowed to assume this role? (lambda.amazonaws.com, ec2.amazonaws.com, scheduler.amazonaws.com)
  2. 2Permission policy: what is this role allowed to do once assumed? (logs:PutLogEvents, s3:GetObject, sqs:SendMessage)

If a resource can't do something (Lambda can't write logs, EC2 can't publish metrics), the answer is almost always: wrong trust policy OR missing permission policy.


Tools Setup

Required tools

bash
# 1. AWS CLI (already installed in Part 3)
aws --version

# 2. jq -- JSON processor, used in every lab to parse CLI output
brew install jq          # macOS
sudo apt install jq      # Ubuntu/Debian

jq --version

# 3. Python 3 -- used in a few labs for quick calculations
python3 --version

# 4. zip -- needed for packaging Lambda functions
zip --version
bash
# Add this block to your ~/.bashrc or ~/.zshrc
# So these are set automatically in every new terminal

export AWS_REGION=ap-south-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text 2>/dev/null)

# Handy alias to check your current AWS identity
alias whoami-aws='aws sts get-caller-identity'

# Alias for the region you use most
alias aws-region='echo $AWS_REGION'

AWS Console orientation

The labs are CLI-first, but the console is useful for visually verifying what you've built. Key navigation:

  • Search bar (top): fastest way to find any service. Type Lambda, S3, CloudWatch: etc.
  • Region selector (top right): always check this before doing anything in the console. If your CLI is set to ap-south-1 but the console is showing us-east-1: you won't see your resources.
  • CloudShell (top right, terminal icon): a browser-based terminal with AWS CLI pre-installed. Useful if you're on a restricted machine. All lab commands work in CloudShell.
  • Billing (account menu, top right): check your current month's charges here anytime.

Before Your First Lab

Setup verification checklist

Run through this list top to bottom. All must be complete before opening any lab.

0 of 12 checked

How each lab is structured

Every lab in this course follows the same format:

  • Sessions: each lab has 3–6 sessions, each with a clear goal and estimated time
  • Callouts: read these *before* running the commands. They explain what's about to happen and why. Predict the outcome, then run the command and compare.
  • Checkpoints: verify your work before moving to the next step. If a checkpoint fails, debug before continuing.
  • Break It: intentionally cause failures to see what real error messages look like. These sections are not optional. Production debugging requires knowing what failures look like.
  • 🧹 Cleanup: run this at the end of every lab, every time.
  • Resume Script: if you close your terminal mid-lab, source this script to restore all environment variables and see where you left off.

Mental models to carry into every lab

Everything is an API call. Clicking a button in the AWS Console is just the console making an API call on your behalf. Every CLI command is an API call. Understanding this means you can always find the equivalent CLI command for any console action, and automate it.

IAM is the first thing to check when something doesn't work. 80% of "why isn't this working" errors in AWS are IAM errors. Before debugging the service itself, ask: does the identity making this call have permission? Does the role have the right trust policy?

Resources cost money while they exist, not just while they're being used. An EC2 instance that's stopped still has an attached EBS volume that costs money. An RDS instance that's stopped resumes billing after 7 days. A NAT Gateway costs $0.045/hour whether or not any traffic flows through it. Always clean up.

The region selector in the console is a trap. If your resources aren't showing up, check the region first. Your CLI region and console region must match.


You're ready

Your account is set up, your billing safety nets are in place, and you have the mental models to make sense of every lab.

Next:

read AWS Overview, it explains why networking comes before every other service. Then start the networking labs (N1 → N10) before moving to compute, serverless, or database labs.

Unlock all 24 AWS services & 291+ lab sessions (~180 hours)

Pricing