🔐 AWS Security & Identity Deep Dive for Backend Engineers

IAM | KMS | GuardDuty — Access Control, Encryption & Threat Detection

🚀 Introduction

Security is not a layer you “add later” — it’s built into every AWS decision.
Whether you’re deploying an EC2 service, running an EKS pod, or encrypting S3 data, AWS gives you primitives to control access, encrypt data, and detect anomalies.

This post covers the three pillars every backend engineer must master:

IAM (Identity & Access Management) – Who can do what?
KMS (Key Management Service) – How is data encrypted and controlled?
GuardDuty – How are threats and anomalies detected?

🧱 1. AWS IAM — Identity and Access Management

🔹 What is IAM?

AWS IAM controls who can perform what actions on which resources under what conditions.
Everything in AWS — whether a human, service, or container — operates under an identity governed by IAM.

🧩 IAM Core Building Blocks

Concept	Description	Credential Type
User	Long-term identity for a human or external app	Password / Access key
Role	Temporary identity assumed by a trusted service or user	STS token
Policy	JSON document defining allowed or denied actions	n/a
Group	Collection of users sharing common policies	n/a
Trust Policy	Defines who can assume the role	n/a
Permission Policy	Defines what actions the identity can perform	n/a

🧠 Visual: How IAM Objects Relate


┌───────────────────────────────┐
│         AWS IAM               │
└───────────────────────────────┘
         │
         ▼
┌──────────────────────────┐
│ Identity (User / Role)   │  ← "Who"
└───────────┬──────────────┘
            │
    Attached Policy JSON    ← "What they can do"
            │
            ▼
┌──────────────────────────┐
│ AWS Resource (S3, EC2...)│  ← "On which resource"
└──────────────────────────┘

🧍‍♂️ IAM User — Permanent Identity (For People or Long-Lived Systems)

An IAM User is meant for humans or applications that require long-term credentials.
They log in to the AWS console or access APIs via access keys.

Example use case:

A developer (Vinod) logs in via the AWS CLI using his access key.
A CI/CD system like Jenkins deploys code using an IAM user.


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

✅ User can download files.
❌ Cannot delete or write unless policy allows.

🎭 IAM Role — Temporary Identity (For AWS Services or Federated Users)

Unlike users, roles don’t have permanent credentials.
They are assumed by trusted entities (AWS services like EC2, Lambda, or EKS pods) through the AWS STS (Security Token Service) which issues short-lived credentials.

🧩 The Role’s Two Parts

Type	Purpose	Example
Trust Policy	Defines who can assume the role	EC2, Lambda, EKS, or cross-account user
Permission Policy	Defines what actions the role can perform	s3:GetObject, dynamodb:PutItem

🧠 Role vs User Analogy

Concept	Analogy	Credentials	Lifetime
User	Employee with a permanent badge	Yes	Long-term
Role	Visitor pass valid for a few hours	No	Temporary

💡 Diagram: User vs Role


┌──────────────────────┐
│ IAM User (Human/App) │
│ - Has password/key   │
│ - Long-lived access  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ IAM Role (Service)   │
│ - No credentials     │
│ - Temporary access   │
└──────────────────────┘

⚙️ Practical IAM Use Cases

🧩 Example 1 — EC2 Instance → S3 Access via Role

When launching an EC2 instance, you can attach an IAM Role called an Instance Profile.
That role tells AWS, “this instance can access S3.”


┌──────────────┐
│ EC2 Instance │
└──────┬───────┘
       │  AssumeRole (via metadata)
       ▼
┌──────────────────────┐
│ IAM Role: EC2S3Role  │
│ - Trust: ec2.amazonaws.com │
│ - Policy: s3:GetObject │
└──────────┬───────────┘
           ▼
     ┌─────────────┐
     │ S3 Bucket   │
     └─────────────┘

Trust Policy (who can assume):


{
  "Effect": "Allow",
  "Principal": { "Service": "ec2.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

Permission Policy (what it can do):


{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": ["arn:aws:s3:::my-app-config/*"]
}

✅ EC2 now fetches configuration files securely — no static keys stored.

🧩 Example 2 — EKS Pod → S3 via IAM Role (IRSA)

EKS pods can assume roles using IAM Roles for Service Accounts (IRSA).


Pod → ServiceAccount → IAM Role → S3

Trust Policy:


{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::<acct>:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/XXXX"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.us-east-1.amazonaws.com/id/XXXX:sub": "system:serviceaccount:default:s3-reader"
    }
  }
}

✅ The pod automatically assumes its role and retrieves temporary credentials — no access keys required.

🧩 Example 3 — IAM User → S3

Human user (Vinod) accessing S3 via AWS CLI using an access key.


1. User authenticates → IAM
2. IAM reads attached policy
3. If policy allows s3:GetObject → Access granted

Policy:


{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-analytics-data/*"
}

🧩 Example 4 — Cross-Account Role

Account A’s EC2 instance can access a Role in Account B if trust policy allows:


Account A EC2  →  AssumeRole  →  Role in Account B  →  S3

🧩 IAM Summary Table

Identity Type	Used By	Credentials	Duration	Example Access
User	Human / app	Access key / password	Long-term	Developer CLI
Role (EC2)	AWS Service	STS Token	Temporary	EC2 → S3
Role (IRSA)	EKS Pod	OIDC Token → STS	Temporary	Pod → S3
Cross-Account Role	External AWS account	STS Token	Temporary	Backup jobs

🔐 IAM – Complete Flow Overview


┌──────────────┐
│ Identity     │  (User / Role / Pod / EC2)
└──────┬───────┘
       │ Signed Request
       ▼
┌──────────────┐
│ AWS STS      │ Issues temp credentials
└──────┬───────┘
       ▼
┌──────────────┐
│ IAM Policies │ Evaluate allow/deny
└──────┬───────┘
       ▼
┌──────────────┐
│ AWS Service  │ (e.g., S3)
└──────────────┘

🧠 Quick IAM Takeaways

IAM User → permanent human or app identity
IAM Role → temporary AWS identity for services or federated users
IAM Policy → rules describing what actions are allowed
Trust Policy → defines who can assume a role
Permission Policy → defines what a role can do
Default = Deny; explicit Deny always wins

🔑 2. AWS KMS — Key Management Service

KMS handles all encryption keys used across AWS.
It provides centralized control for key generation, rotation, access, and audit.

🧩 Envelope Encryption


┌──────────────┐
│ Your App     │
└──────┬───────┘
       │ Request Data Key
       ▼
┌──────────────┐
│ AWS KMS CMK  │
└──────┬───────┘
       │ Generates Data Key
       ▼
┌──────────────────────────┐
│ Data encrypted with Key  │
│ Key encrypted by CMK     │
└──────────────────────────┘

🧠 KMS Interview Essentials

Question	Answer
CMK vs Data Key?	CMK = master key in KMS; Data Key = temporary key used by app
Key rotation?	Auto every 365 days
Share across accounts?	Add principal in key policy
Integrated services?	S3, EBS, RDS, DynamoDB, Lambda
Logs?	All actions logged in CloudTrail

🛡️ 3. Amazon GuardDuty — Threat Detection

GuardDuty continuously analyzes logs (CloudTrail, VPC Flow Logs, DNS, EKS Audit Logs) to identify malicious activity or compromised resources.

🧠 GuardDuty Essentials

Feature	Description
No agents	Works by analyzing logs
Findings	Reconnaissance, credential theft, exfiltration
Integration	Security Hub, EventBridge, Lambda
Response	Automate isolation or alerting

🧩 GuardDuty Flow


┌──────────────┐
│ Logs: VPC, CT│
└──────┬───────┘
       ▼
┌──────────────┐
│ GuardDuty    │  (ML + Threat Intel)
└──────┬───────┘
       ▼
Findings → EventBridge → Lambda / SNS

🧭 End-to-End Security Architecture

🧠 Interview Cheat Sheet

Area	Key Points
IAM	User = human, Role = temporary identity, Policy = rules
KMS	CMK for key mgmt, Data Key for encryption
GuardDuty	ML-driven threat detection
STS	Generates short-lived tokens for roles
Best Practice	Use roles over users, least privilege, encryption everywhere
Audit	CloudTrail + Security Hub integration

✅ Key Takeaways

IAM: Who can do what
KMS: How data is encrypted
GuardDuty: Who’s doing something suspicious

Together they form the security triad of AWS:
Access → Encryption → Detection — protecting your cloud end-to-end.

The Backend Engineer’s Journal