It is 3 AM in Bengaluru. Your phone buzzes. An EC2 instance in your production VPC just started sending traffic to an IP address in a country your company has no customers in. Nobody logged into the AWS console. Nobody ran a deployment. Something got in, and it is currently trying to get out with your data. This is the scenario every AWS security engineer eventually faces. On-premises, you control the building, the cables, the switches. In AWS, the physical layer is Amazon's problem. Your job starts at the account boundary and goes up from there - identities, keys, network paths, application code, and the data itself. **The Shared Responsibility Model** defines exactly where AWS's job ends and yours begins. AWS secures the cloud - the physical data centers, the hardware, the hypervisor, the global network backbone. You secure what you run in the cloud - your IAM policies, your security group rules, your unencrypted S3 bucket, your application's input validation. AWS is responsible for You are responsible for ----------------------- ----------------------- Physical data centers IAM users, roles, policies Hardware and hypervisor Security groups and NACLs Global network infrastructure Data encryption choices Managed service internals OS patching (on EC2, not Lambda) (RDS engine, Lambda runtime) Application-level vulnerabilities Miss this distinction and you make one of two mistakes. Either you assume AWS is handling something it never touches (leaving an S3 bucket public because "AWS is secure by default"), or you waste time trying to patch something AWS already manages for you (worrying about the OS on a Lambda function). > 📌 **Remember:** For managed services like RDS, Lambda, and DynamoDB, AWS's share of responsibility grows. For EC2, most of the stack above the hypervisor is yours. Always check which model applies before assuming a service is "secure by default." ### Where This Module Fits in Your Cloud Engineering Path If you have worked through IAM fundamentals, VPC networking, and EC2, you already know how permissions flow and how traffic moves inside a VPC. This module builds directly on that. Every service here - GuardDuty, KMS, WAF, Security Hub - exists to protect or monitor the infrastructure you already know how to build. Think of this as the layer that watches, encrypts, and locks down everything you deployed in the AWS Core Services module. ---
AWS does not give you one giant "security" service. It gives you five specialized tools, each watching a different part of your environment. Confusing what each one does is the single most common mistake in security architecture interviews and real production setups. Think of it like a hospital. You do not have one doctor for every problem - you have a radiologist reading scans, a lab tech running blood tests, and a specialist who reviews everything together to form a diagnosis. AWS security services work the same way: each one looks at a different signal, and you need all of them working together for full coverage. ### GuardDuty - Threat Detection **GuardDuty** is a continuous, intelligent threat detection service. It analyzes AWS activity using threat intelligence, anomaly detection, machine learning, and other detection techniques to identify potentially malicious behavior. Its core data sources are CloudTrail management and data events, VPC Flow Logs, and DNS query logs, and it also supports optional protection plans that extend detection into S3, EKS, RDS, Lambda, and malware scanning. GuardDuty does not need you to write a single rule. You enable it, and it starts flagging activity that its detection models consider anomalous or consistent with known attacker behavior. VPC Flow Logs ─┐ CloudTrail Logs ├──> GuardDuty (ML + threat intel) ──> Findings DNS Query Logs ─┘ Example findings GuardDuty generates: an EC2 instance suddenly communicating with a known cryptocurrency mining pool, an IAM user credential being used from two geographically impossible locations within minutes, or an S3 bucket being accessed by a Tor exit node. > 💡 **Tip:** GuardDuty findings come with a severity score from 0.1 to 10.0. Route High severity findings (7.0+) straight to a Slack channel or PagerDuty via EventBridge - do not make a human check a dashboard for critical threats. ### Inspector - Vulnerability Scanning **Inspector** answers a completely different question than GuardDuty. GuardDuty asks "is something bad happening right now?" Inspector asks "does my infrastructure have a known weakness that could be exploited later?" Inspector automatically and continuously scans EC2 instances, container images in ECR, and Lambda functions for software vulnerabilities (CVEs) and unintended network exposure. It cross-references installed packages against the National Vulnerability Database and tells you exactly which instances are running a library with a known exploit. > 🔴 **Common Mistake:** Engineers often expect GuardDuty to catch vulnerable software. It will not - GuardDuty detects active malicious behavior, not passive weaknesses. If you want to know "which of my EC2 instances have an outdated OpenSSL version," that is Inspector's job, not GuardDuty's. ### Macie - Sensitive Data Discovery **Macie** uses machine learning and pattern matching to scan S3 buckets and find sensitive data you may not know exists there - credit card numbers, Aadhaar numbers, PAN numbers, AWS credentials accidentally saved as text files, or health records. S3 Buckets across your account | Macie scans object content | Finds: "This bucket has 4,200 files containing what look like PAN numbers" | You decide: encrypt, restrict access, or delete This matters because data sprawl is silent. A developer exports a customer table to CSV for debugging, uploads it to S3 "temporarily," and three years later nobody remembers it is there. Macie finds it before an attacker does. ### Security Hub - Centralized Findings **Security Hub** is primarily an aggregation, correlation, and security-posture service. It consumes findings from services such as GuardDuty, Inspector, Macie, and third-party tools into a single dashboard with a unified severity scoring format, and it also runs its own control evaluations against enabled security standards. Without Security Hub, you would need to check five different consoles every morning. With it, you check one. Security Hub also runs **compliance standards** automatically - most importantly the **CIS AWS Foundations Benchmark**, a checklist of security best practices (root account MFA enabled, no wildcard IAM policies, CloudTrail enabled in every region) that it checks continuously and scores as a percentage. ### Detective - Root Cause Investigation **Detective** is what you reach for after GuardDuty raises an alarm and you need to understand the full story. It automatically builds a visual timeline of API calls, network connections, and resource relationships so you can answer "how did this happen and what else did it touch?" without manually piecing together CloudTrail logs by hand. GuardDuty says: "This IAM role behaved suspiciously at 2:14 AM" | Detective shows: every API call that role made, every resource it touched, and every other principal that assumed it that week > 📌 **Remember:** GuardDuty detects, Inspector scans for weaknesses, Macie finds sensitive data, Security Hub centralizes everything, Detective investigates the story behind a finding. Five different questions, five different tools. ### CloudTrail - The Record Everything Else Reads Every service above depends on one thing existing first: a record of what actually happened. **AWS CloudTrail** logs every API call made in your account - who called it, from where, with what parameters, and whether it succeeded. It does not detect anything or judge whether an action was malicious. It simply records the truth of what occurred. CloudTrail | Records every AWS API call across your account | GuardDuty analyzes relevant CloudTrail activity for malicious patterns | Security Hub aggregates GuardDuty (and other services') findings | EventBridge routes matching findings to a target | Lambda / SNS / a SIEM tool takes action Without CloudTrail, GuardDuty has no management-event history to analyze, and Detective has no timeline to reconstruct. It is the foundation the rest of this landscape sits on, not an optional extra. **One line each, to keep the five services straight:** * CloudTrail - what API activity happened * GuardDuty - does this activity look malicious * Inspector - what vulnerabilities exist * Macie - what sensitive data exists * Detective - what happened and how, in detail * Security Hub - what is my overall security posture ---
For production workloads, encryption at rest should generally be enabled by default, with stronger key-control requirements applied where compliance or data isolation demands it. Once encryption is your default posture, the real question becomes "which key should encrypt this, and who should be able to use that key." **AWS Key Management Service (KMS)** is the service that creates and controls the cryptographic keys used to encrypt data across almost every AWS service - S3, EBS, RDS, DynamoDB, Secrets Manager, and more. Think of a KMS key like a house key: the data is the house, and controlling who holds a copy of the key controls who can get in, regardless of how strong the lock itself is. ### The Three Key Types AWS Owned Keys -> AWS creates and manages the key entirely -> You never see it, never configure it, cannot audit its use -> Free, used by default in some services (e.g. S3 SSE-S3) AWS Managed Keys -> AWS creates the key but it lives in YOUR account -> Automatically rotated by AWS every year -> Visible in your KMS console, usage appears in CloudTrail -> Named like aws/s3, aws/rds - one per service, per account Customer Managed Keys (formerly commonly called CMKs) -> You create it, you control the key policy -> You choose rotation schedule, you control who can use or manage it -> You can disable, schedule deletion, or restrict to specific principals -> Required for cross-account sharing and detailed audit requirements The decision comes down to how much control your compliance or architecture requirements demand. | Requirement | Key type to use | |:---|:---| | Just need encryption at rest, nothing else | AWS Owned Key | | Need to see key usage in CloudTrail, default rotation is fine | AWS Managed Key | | Need to control exactly who can use the key | Customer Managed Key | | Need to share encrypted data across AWS accounts | Customer Managed Key | | Compliance mandates custom rotation schedule or key deletion control | Customer Managed Key | > 🔴 **Common Mistake:** Engineers create a customer managed key for everything "to be safe," then get stuck managing dozens of key policies with no real benefit over an AWS Managed Key. Use a customer managed key only when you specifically need the control it gives you - cross-account access, custom rotation, or fine-grained audit requirements. ### Key Policies - The Access Control Layer A **key policy** is a resource-based policy attached directly to the KMS key, similar to an S3 bucket policy. This is different from a regular IAM policy attached to a user - the key policy decides who is even allowed to be considered for access, before IAM permissions are checked at all. ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowFinanceTeamDecrypt", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/finance-team-role" }, "Action": "kms:Decrypt", "Resource": "*" } ] } ``` > **Note:** A KMS key policy is a foundational part of KMS authorization. Within the same account, the key policy can either directly grant access to a principal, as shown here, or it can delegate to IAM policies within the account so that IAM alone decides who gets access. Cross-account access is different - it requires permissions on both sides: the key policy in the key's own account, and a matching IAM policy in the external account requesting access. ---
Every application needs to store something sensitive - a database password, an API token, a third-party service key. AWS gives you two ways to do this, and picking the wrong one either wastes money or creates a security gap. Think of Parameter Store as a locked filing cabinet and Secrets Manager as a bank vault with an automatic combination-changing robot inside it. Both keep things safe. Only one changes the combination for you on a schedule. SSM Parameter Store Secrets Manager ------------------------ ------------------------ Free (Standard tier) Costs per secret per month Manual rotation only Automatic rotation built in Simple key-value storage Built for credential lifecycle No native cross-account sharing Native cross-account sharing Good for: config values, Good for: database passwords, feature flags, non-rotating API keys, anything needing secrets scheduled rotation **Automatic rotation** is the deciding factor for most real decisions. When Secrets Manager rotates a database password, it uses a Lambda function to generate a new password, update the database, and update the secret - all without any application downtime, as long as your app reads the secret fresh instead of caching it forever. ```bash ## Create a secret and enable rotation every 30 days aws secretsmanager create-secret \ --name prod-mumbai/rds-app-password \ --secret-string '{"username":"appuser","password":"changeme123"}' ## initial value, rotated Lambda replaces this aws secretsmanager rotate-secret \ --secret-id prod-mumbai/rds-app-password \ --rotation-lambda-arn arn:aws:lambda:ap-south-1:123456789012:function:SecretsManagerRDSRotation \ --rotation-rules AutomaticallyAfterDays=30 ``` > **Note:** The `rotation-lambda-arn` points to a Lambda function AWS provides templates for - it knows how to log into the database with the old password, set a new one, and update the secret atomically so no request fails mid-rotation. > 📌 **Remember:** If it needs to rotate on a schedule automatically, use Secrets Manager. If it is a static config value or you are cost-sensitive and can rotate manually, use Parameter Store. ---
Your Application Load Balancer is doing its job perfectly - routing every request to a healthy backend, including the ones trying to inject SQL into your login form. A load balancer routes traffic. It does not inspect intent. That is what **AWS WAF (Web Application Firewall)** exists for. WAF sits in front of your ALB, API Gateway, or CloudFront distribution and inspects each request against a set of rules before deciding whether to allow, block, or count it. Request from the internet | AWS WAF (evaluates rules in order) | Allow -> forwarded to ALB / API Gateway / CloudFront Block -> rejected, attacker gets a 403 ### Rule Types * **Managed Rule Groups** - pre-built rule sets AWS or AWS Marketplace partners maintain for you. The `AWSManagedRulesSQLiRuleSet` and `AWSManagedRulesCommonRuleSet` cover SQL injection and cross-site scripting (XSS) without you writing a single rule. * **Rate-based rules** - track the request rate from each IP address over a rolling time window and automatically apply an action, typically a block, once a configured threshold is crossed. This is your primary defense against brute-force login attempts and basic denial-of-service attempts. * **Custom rules** - written by you, matching specific headers, query strings, or IP ranges relevant to your application. ```json { "Name": "RateLimitLogin", "Priority": 1, "Statement": { "RateBasedStatement": { "Limit": 100, "AggregateKeyType": "IP" } }, "Action": { "Block": {} } } ``` > **Note:** `"Limit": 100` means once a single IP address crosses 100 requests within a rolling 5-minute window, WAF automatically blocks that IP. This is a common defense against credential-stuffing attacks on a login endpoint. > 💡 **Tip:** Always deploy a new WAF rule in **Count mode** first instead of Block mode. Count mode logs what would have been blocked without actually blocking it, so you can verify the rule does not accidentally block legitimate customers before it goes live. ---
**AWS Shield** protects against Distributed Denial of Service (DDoS) attacks - the kind where thousands of compromised machines flood your infrastructure with traffic trying to knock it offline. Shield Standard Shield Advanced ------------------------- ------------------------- Free, automatic for every Paid subscription AWS customer ($3,000/month) Protects against common, Protects against larger, frequently occurring network more sophisticated attacks layer attacks (L3/L4) Includes 24/7 DDoS Response Team (DRT) access Cost protection for scaling charges during an attack Shield Standard is always on, for everyone, at no cost - you cannot turn it off and you do not need to configure it. It handles the vast majority of DDoS attempts automatically at the network edge. Shield Advanced is for organizations where a successful DDoS attack has serious financial or reputational consequences - a fintech payment gateway, a major e-commerce platform during a sale event. It adds direct access to AWS's DDoS Response Team during an active attack and protects you from the AWS bill spike that can happen when Auto Scaling reacts to attack traffic by scaling out. > 📌 **Remember:** Shield Standard is free and automatic - you get it by default. Shield Advanced is an active decision you make for high-value, high-risk workloads and costs real money. ---
It is 3 AM in Bengaluru. Your phone buzzes. An EC2 instance in your production VPC just started sending traffic to an IP...
AWS does not give you one giant "security" service. It gives you five specialized tools, each watching a different part ...
For production workloads, encryption at rest should generally be enabled by default, with stronger key-control requireme...
Every application needs to store something sensitive - a database password, an API token, a third-party service key. AWS...
Your Application Load Balancer is doing its job perfectly - routing every request to a healthy backend, including the on...
AWS Shield protects against Distributed Denial of Service (DDoS) attacks - the kind where thousands of compromised machi...
No single security control should ever be the only thing standing between an attacker and your data. Defence in depth me...
Traditional network security assumes anything inside your perimeter is trustworthy. Zero Trust rejects that assumption e...
Detection is only half the job. When GuardDuty fires a High severity finding at 3 AM, what you do in the next ten minute...
Manually checking "is MFA enabled on the root account" and "is CloudTrail logging in every region" across dozens of acco...
By this point you have met ten security services. In an interview or a real architecture review, the skill that matters ...
Real security work rarely looks like a list of unrelated commands. It looks like one scenario, moving through detection,...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.