Chapter 59: AWS Cloud Security
AWS Cloud Security
This is not a single service or a checkbox you tick once. AWS Cloud Security is a complete mindset + shared responsibility model + dozens of tools that together decide whether your application is reasonably safe from attackers, compliant with Indian laws (RBI, DPDP Act, MeitY guidelines), protected against data leaks, and resilient to misconfiguration disasters.
Let me teach it the way I wish someone had explained it to me when I started — like a real teacher who actually cares that you understand why things are done this way, not just what the buttons are called.
1. The Foundation — The AWS Shared Responsibility Model
This is the very first thing every single person must understand — and unfortunately many skip it.
AWS divides security responsibilities into two parts:
| Responsibility | Who is responsible? | What it includes (2026 reality) | Hyderabad startup example |
|---|---|---|---|
| Security of the cloud | AWS | Physical security of data centers, hardware, hypervisor, global network, patching AWS-managed services | AWS protects the Mumbai & Hyderabad data centers from floods, power cuts, physical intruders |
| Security in the cloud | You (customer) | Everything you configure: IAM permissions, VPC security groups, encryption, logging, patching your OS/code, data classification | You decide who can read your DynamoDB tables, whether your S3 bucket is public, whether your EC2 instances have public IPs |
Golden rule everyone must memorize:
AWS is responsible for protecting the infrastructure. You are responsible for protecting your data and your configuration.
Most breaches in India happen because of mistakes in your part — not AWS.
2. The Security Pillars — The 7 Big Areas You Must Think About
AWS officially talks about the AWS Well-Architected Framework Security Pillar, which has six design principles (2026 version):
- Implement a strong identity foundation — least privilege everywhere
- Enable traceability — log everything, monitor everything
- Apply security at all layers — defense in depth
- Automate security best practices — use IaC, guardrails
- Protect data in transit and at rest — encrypt everything
- Keep people away from data — reduce human access
- Prepare for security events — incident response plan
Now let’s look at the most important tools you actually use every day in Hyderabad startups in 2026.
3. The Core Security Services & Patterns (The Ones You Must Know)
| Category | Most Important Service(s) | What it really protects / controls | Typical Hyderabad startup example (2026) |
|---|---|---|---|
| Identity & Access Management | IAM + IAM Identity Center + AWS Organizations | Who can do what (users, roles, policies) | Developer role can’t delete S3 buckets |
| Network Security | Security Groups, NACLs, VPC Endpoints, PrivateLink | Who can talk to your resources (firewall rules) | RDS only reachable from ECS tasks |
| Encryption | KMS, ACM, S3 SSE, EBS encryption | Data at rest & in transit | All S3 buckets encrypted with KMS |
| Web Application Firewall | AWS WAF | Protects against SQL injection, XSS, bots | Block malicious login attempts on ALB |
| DDoS Protection | AWS Shield (Standard free, Advanced paid) | Protects against DDoS attacks | Shield Standard protects public ALB |
| Logging & Monitoring | CloudTrail, CloudWatch Logs, GuardDuty, Config, Security Hub | Who did what, when, anomaly detection | GuardDuty alerts on crypto-mining on EC2 |
| Secrets Management | AWS Secrets Manager, SSM Parameter Store | Store & rotate passwords, API keys | RDS password rotated every 30 days |
| Compliance & Governance | AWS Config, AWS Organizations SCPs, AWS Audit Manager | Enforce rules, audit readiness | SCP prevents anyone from making S3 public |
4. Real Hyderabad Example — Full Security Setup for a Food Delivery App
Your startup “TeluguBites” (restaurant discovery + ordering):
Security setup (very typical production pattern in 2026):
- IAM & Organizations
- AWS Organization with SCPs → no one can make S3 buckets public or disable CloudTrail
- IAM roles instead of access keys
- Developers get read-only access via IAM Identity Center + MFA
- VPC & Network
- Custom VPC with public + private subnets
- ALB in public subnets, ECS Fargate tasks + Aurora PostgreSQL in private subnets
- Security Groups: ALB allows 443 from anywhere; ECS allows 3000 only from ALB
- VPC Endpoints for S3 & DynamoDB → no internet traffic for internal calls
- NAT Gateway in public subnet → private resources can reach internet for updates
- Encryption
- All S3 buckets encrypted with KMS (customer-managed key)
- EBS volumes encrypted
- RDS Aurora encrypted at rest & in transit
- ACM certificate on ALB → free HTTPS
- WAF & Shield
- AWS WAF on ALB → blocks SQL injection, XSS, known bad bots
- AWS Shield Standard enabled (free) → basic DDoS protection
- Logging & Monitoring
- CloudTrail enabled (all API calls logged to S3)
- GuardDuty enabled → alerts on crypto-mining, credential compromise
- Security Hub enabled → central dashboard of findings
- CloudWatch alarms → CPU > 80 % for 5 min → SNS email/SMS to team
- Secrets
- RDS password stored in Secrets Manager → rotated every 30 days
- API keys in SSM Parameter Store → fetched at runtime
Monthly security-related cost (moderate traffic):
- GuardDuty + Security Hub → ~₹1,500–4,000
- KMS + Secrets Manager → ~₹500–1,500
- WAF rules → ~₹1,000–3,000
- Total extra security cost → ₹3,000–10,000/month (very cheap insurance)
5. Quick Hands-On – Feel Basic Security Setup
- Create VPC → public + private subnets
- Launch EC2 in private subnet → try curl google.com → fails (no NAT)
- Add NAT Gateway in public subnet → update private route table → curl works
- Create Security Group → allow SSH only from your IP → attach to EC2
- Enable GuardDuty → wait 24 h → see sample findings
Summary Table – AWS Cloud Security Cheat Sheet (2026 – India Focus)
| Area | Most Important Tools | Golden Rule / Best Practice |
|---|---|---|
| Identity | IAM, IAM Identity Center, Organizations SCPs | Least privilege, no root user, MFA everywhere |
| Network | VPC, Security Groups, NACLs, VPC Endpoints | Private subnets for databases, VPC endpoints for S3/DDB |
| Encryption | KMS, ACM, SSE-KMS, TLS | Encrypt everything at rest & in transit |
| Web protection | WAF, Shield | WAF on every public ALB/API Gateway |
| Logging & threat detection | CloudTrail, GuardDuty, Security Hub | Enable all three — central visibility |
| Secrets | Secrets Manager, SSM Parameter Store | Never hard-code secrets — rotate regularly |
| Compliance | Config, Audit Manager, Artifact | Use SCPs & Config rules to enforce policies |
Teacher’s final note (real talk – Hyderabad 2026):
AWS Cloud Security is 20 % AWS tools and 80 % your configuration decisions.
The biggest breaches and compliance failures in India happen because of misconfigurations (public S3 buckets, overly permissive IAM roles, no encryption, no logging), not because AWS infrastructure was hacked.
Follow these three rules and you’ll be safer than 80 % of companies:
- Least privilege everywhere — IAM roles, Security Groups
- Encrypt everything — KMS, ACM, SSE
- Log everything — CloudTrail + GuardDuty + Security Hub
Got it? This is the “make sure your app doesn’t become tomorrow’s news headline” lesson.
Next?
- Step-by-step: Build a secure VPC + Security Groups + WAF + GuardDuty?
- Deep dive: IAM roles vs users vs Identity Center?
- Or how to use AWS Security Hub to get a single security score?
Tell me — next whiteboard ready! 🚀🔒
