DEV Community

Cover image for Cloud foundations & IAM
Rajesh
Rajesh

Posted on

Cloud foundations & IAM

#aws #iam #devops #cloud

Why do we go for AWS?

Setting up your own physical servers means spending lakhs up front on hardware, electricity, cooling, and guessing how many servers you need.

AWS lets you rent computers and storage over the internet in seconds and pay only for the exact minutes or hours you use.

1. Cloud computing

Instead of buying and keeping bulky computers in your office room, you rent virtual machines and storage from huge data centres run by Amazon.

It works just like electricity at home: you don't build your own power station to turn on a fan, you just plug in and pay the monthly bill for the units you used.

2. Service models: IaaS, PaaS, SaaS

Think of how you eat dinner to understand how much you manage versus how much AWS manages:

  • IaaS (Infrastructure as a Service): Renting an empty kitchen. AWS gives you the physical server and network; you install the OS, setup Python/Node, and run your code.
    • Example: Amazon EC2, Amazon VPC, Amazon EBS.
  • PaaS (Platform as a Service): Getting a meal kit with pre-chopped ingredients. You just write your app code and hand it over; AWS handles the OS, patching, and scaling.
    • Example: AWS App Runner, AWS Elastic Beanstalk, Amazon RDS.
  • SaaS (Software as a Service): Sitting at a restaurant and eating food. Everything is fully built and managed; you just log in and use it.
    • Example: Amazon QuickSight, Amazon Connect (or Gmail and Slack outside AWS).
  • Serverless (FaaS): Buying a snack from a vending machine. You write a single function and pay only when that function runs.
    • Example: AWS Lambda.

3. Regions

A Region is a specific physical geographic location in the world where AWS operates a cluster of data centres (like Mumbai ap-south-1 or Singapore ap-southeast-1).

Each Region is completely independent. Your data stays in that Region and never leaves unless you intentionally copy or replicate it out.

How to choose a Region:

  1. Compliance / Data laws: If your government rules say customer data must stay in India, pick Mumbai or Hyderabad.
  2. Latency: Choose the location closest to your users so the site opens fast.
  3. Available services: Brand new AWS services often arrive in us-east-1 (N. Virginia) first.
  4. Price: Resource prices differ slightly across countries based on local taxes and power costs.

4. Availability Zones (AZs)

Inside every Region, AWS builds separate data centre clusters called Availability Zones (AZs) (for example: ap-south-1a, ap-south-1b, and ap-south-1c in Mumbai).

An AZ is made of one or more physical data centres with redundant power, backup generators, and cooling. They sit miles apart from each other so a flood or local power cut in one building doesn't hurt the other, but they are linked by super-fast private fibre cables.

Region: ap-south-1 (Mumbai)
 ├── ap-south-1a [Data Centre 1 + Data Centre 2]
 ├── ap-south-1b [Data Centre 3 + Data Centre 4]
 └── ap-south-1c [Data Centre 5 + Data Centre 6]
Enter fullscreen mode Exit fullscreen mode

The 3 Core AZ Rules & Limitations:

  1. Minimum 3 AZs per Region: Every standard AWS Region gives you at least 3 AZs for high availability.
  2. AZ-Scoped Services: Certain resources live strictly inside one single AZ. An EC2 instance, an EBS volume, and a VPC Subnet can only exist in one AZ at a time. If that AZ goes dark and you don't have a backup in another AZ, your app goes down.
  3. AZ Names are Random per Account: The name ap-south-1a in your account might actually map to a different physical building than your friend's ap-south-1a (to balance traffic across AWS buildings). The permanent true ID is the Zone ID (like aps1-az1).

5. Edge locations & Caching

Edge locations are hundreds of smaller branch offices in major cities (like Chennai, Bengaluru, Delhi, Frankfurt, New York) sitting right next to end-users.

They don't run heavy virtual servers. Instead, they run Amazon CloudFront (Content Delivery Network) and Amazon Route 53 (DNS).

When a user in Chennai asks for an image stored in a server in Ireland, CloudFront fetches it once and saves a local copy in Chennai's cache. The next user in Chennai gets the image in 10ms instead of waiting 250ms across the ocean.

6. IAM: Authentication, Authorisation, Root User, Users & Groups

AWS Identity and Access Management (IAM) is the free global security guard for your entire cloud account.

       [ Human / Developer ]
                 │
                 ▼ (Member of)
             [ Group ]
                 │
                 ▼ (Has Attached)
          [ JSON Policies ] ◄──── Sets rules (Effect, Action, Resource)
Enter fullscreen mode Exit fullscreen mode

Authentication vs. Authorisation

  • Authentication (Who are you?): Checking your credentials. At a building gate, this is the security guard looking at your photo ID card or checking your password and MFA code.
  • Authorisation (What can you do?): Checking the rulebook. Can your badge open the server room door? Or are you only allowed in the lobby? In AWS, IAM checks if you have permission to run s3:GetObject or ec2:StartInstances.

The Root User

  • The root user is the primary email address used to create the AWS account.
  • It has absolute god-mode access and can delete everything. You cannot restrict root using normal IAM policies.
  • Best practice: Lock root with Multi-Factor Authentication (MFA), delete any root access keys, and never use root for daily work.

IAM Users

  • A unique personal login created for one specific person or application.
  • Each user gets their own password for the AWS console or access keys (AKIA...) for the CLI.
  • If a team member leaves, you disable only their IAM user without breaking anyone else's access.

IAM Groups

  • A collection of IAM users (like a developers or finance department).
  • Instead of adding policies to 20 users one by one, attach the policy to the group. Anyone added to the group automatically gets those rights.
  • Note: Groups cannot be nested inside other groups.

7. Policies (JSON)

An IAM Policy is a simple JSON document that writes down permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadCompanyReports",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-reports",
        "arn:aws:s3:::company-reports/*"
      ],
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

The Anatomy of a Policy:

  • Version: Always use "2012-10-17" (the current policy language version).
  • Effect: Either "Allow" or "Deny".
  • Action: The exact API call you are allowing or blocking (e.g. s3:GetObject, ec2:RunInstances).
  • Resource: The ARN (Amazon Resource Name) of the target. Notice the S3 difference:
    • arn:aws:s3:::company-reports = the bucket itself (needed to list bucket contents).
    • arn:aws:s3:::company-reports/* = the files inside the bucket (needed to download files).
  • Condition: Extra safety checks (e.g., only allow if MFA is turned on, or only from office IP).

8. How AWS evaluates a request: Deny always wins!

When you click a button or type a CLI command, IAM checks all policies attached to you using a strict order:

AWS Policy Evaluation
(Reference: Official AWS IAM Evaluation Guide)

       Incoming Request (e.g. s3:DeleteObject)
                         │
                         ▼
             Is there an Explicit DENY?
                   /           \
                 YES            NO
                 /                \
          [ DENY Access ]     Is there an Explicit ALLOW?
                                 /           \
                               YES            NO
                               /                \
                       [ ALLOW Access ]    [ DENY Access ]
                                           (Default Deny)
Enter fullscreen mode Exit fullscreen mode
  1. Default is Deny: Everything starts completely locked. If no policy mentions your action, you are blocked.
  2. Explicit Allow: If a policy says "Allow", you get access.
  3. Explicit Deny ALWAYS Trumps: If any policy anywhere says "Deny", that request is instantly blocked. An explicit Deny kills any Allow, every single time.

9. Roles and STS: Temporary logins

Why do we need Roles if we already have IAM users?

Because storing permanent access keys (AKIA...) on EC2 servers or in .env files is dangerous. If code leaks to GitHub, bots grab those keys in seconds and run up huge bills.

[ EC2 Server / Lambda / GitHub Actions ]
                   │
                   ▼ (Calls sts:AssumeRole)
        [ AWS STS (Token Service) ]
                   │
                   ▼ (Generates)
    [ Temporary Access Keys (ASIA...) ]
      • Valid for 15 mins to 12 hours
      • Rotates automatically
Enter fullscreen mode Exit fullscreen mode

How Roles Work:

  • A Role is an identity that has no password and no permanent secret key.
  • When an EC2 server or Lambda function needs to read an S3 bucket, it asks AWS STS (Security Token Service) to assume the role.
  • STS hands back temporary credentials (starts with ASIA...) that expire automatically in minutes or hours.
  • The AWS SDK rotates them automatically behind the scenes. No permanent keys ever sit on your server disk.

The Two Sides of Every Role:

  1. Trust Policy (Who can wear the badge?): Specifies which service or account is allowed to assume the role (e.g., ec2.amazonaws.com).
  2. Permissions Policy (What can you do while wearing it?): The normal JSON policy specifying allowed actions (e.g., read files from S3).

Hands-On Practice & Console Walkthrough

Here is the exact hands-on practice I did today inside my AWS account, along with the console setups and CLI steps.

Step 1: Setting up an IAM User, Group & Policy (Console)

First, I went to the IAM console so I don't work as root anymore.

  1. Created an IAM User: Gave it console access with a custom password and required password reset.
  2. Created an IAM Group: Named it developers and attached the ReadOnlyAccess policy to it.
  3. Added User to Group: Put my new user into the developers group.

Creating my new IAM user inside the AWS Console
Fig 1: Creating a dedicated IAM user with console access and custom password.

Adding user to the developers group with ReadOnly policy
Fig 2: Adding the user to the developers user group with ReadOnlyAccess policy attached.

Step 2: Creating an IAM Role for Testing

Next, I created an IAM Role named lab-s3-reader to test temporary access:

  1. Chose AWS account as the trusted entity so my current user can assume it.
  2. Attached AmazonS3ReadOnlyAccess to the role.
  3. Verified the trust relationship policy.

Role trust policy and attached permissions
Fig 3: Setting up the IAM role trust policy and testing permissions.

Step 3: Terminal POC (Testing with AWS CLI)

Before running commands from your local computer's terminal, you need credentials for the CLI:

1. Generating Your Access Key

  1. In the IAM Console, go to Users → click your user name → open the Security credentials tab.
  2. Scroll down to Access keys and click Create access key.
  3. Choose Command Line Interface (CLI), acknowledge the recommendation, and click next.
  4. AWS will give you two values:
    • Access key ID: A public identifier starting with AKIA...
    • Secret access key: A private string.

Important Warning from AWS:

If you lose or forget your secret access key, you cannot retrieve it again. Instead, you must delete or deactivate the old key and create a new one. Download the .csv file or keep it safe.

Access keys section in IAM Security Credentials tab
Fig 4: Generating and managing Access Keys inside the Security Credentials tab.

2. Configure AWS CLI

In your local terminal, run:

aws configure
Enter fullscreen mode Exit fullscreen mode

Paste your Access Key ID, Secret Access Key, default region (e.g., ap-south-1), and default output format (json).

3. Test your connection

Check who you are logged in as:

aws sts get-caller-identity
Enter fullscreen mode Exit fullscreen mode

This prints your Account ID, User ID, and user ARN so you know your keys are active.

4. Create a test S3 bucket in Mumbai and upload a file 

# S3 bucket names must be globally unique, so we add a random number
aws s3 mb s3://my-test-bucket-$RANDOM --region ap-south-1

# Make a small test text file and copy it to your bucket
echo "Session 1 complete" > test.txt
aws s3 cp test.txt s3://<your-bucket-name>/

# List the files inside your bucket
aws s3 ls s3://<your-bucket-name>/
Enter fullscreen mode Exit fullscreen mode

5. Clean up before closing

Always delete test buckets right after you finish so your account stays tidy and free:

aws s3 rb s3://<your-bucket-name>/ --force
Enter fullscreen mode Exit fullscreen mode

Session 1 Key Takeaways

Things I made sure to check off today:

  • Locked my root account with an MFA app right away and stopped using it for daily work.
  • Created a $5 budget alert in AWS Budgets so I get an email before any surprise bill hits.
  • Remembered the golden IAM rule: if even one policy has an explicit Deny, it immediately blocks the request no matter what else says Allow.
  • Stopped putting secret access keys into code or server folders—using IAM Roles with STS temporary tokens instead.

Top comments (0)