| Tool / Service | Purpose |
|---|---|
| AWS WAF (Web Application Firewall) | Filter & block malicious HTTP/S traffic at the edge |
| Application Load Balancer (ALB) | Distribute traffic across EC2 instances; WAF attachment point |
| Amazon EC2 | Application servers behind the ALB |
| AWS Route 53 | DNS routing to direct traffic to ALB |
| AWS Managed Rule Groups | Pre-built rules for OWASP threats (SQLi, XSS, etc.) |
| AWS CloudWatch | WAF metrics, logging, and alerting |
| AWS S3 / CloudWatch Logs | Store WAF request logs for analysis |
| Concept | What it Means |
|---|---|
| WAF (Web Application Firewall) | Sits in front of your app and inspects every HTTP/S request before it reaches your server |
| Web ACL | The top-level WAF container — holds all your rules and is attached to ALB/CloudFront |
| Rule Group | A reusable collection of rules (managed by AWS or custom) added to a Web ACL |
| Managed Rule Groups | AWS-maintained, pre-built rule sets covering common attack patterns |
| IP Set | A list of IP addresses/CIDRs used to allow or block specific sources |
| Geo Match | Condition that matches requests based on the country of origin |
| SQLi Rule | Detects and blocks SQL injection patterns in request parameters |
| XSS Rule | Detects and blocks cross-site scripting patterns in requests |
| Allow / Block / Count | WAF actions — pass, deny, or just monitor matching requests |
| Default Action | What WAF does when no rule matches — typically Allow for whitelist mode |
| Sampled Requests | WAF stores a sample of matched requests for debugging and analysis |
Internet
│
▼
┌─────────────────┐
│ Route 53 DNS │
└────────┬────────┘
│
▼
┌─────────────────┐
│ AWS WAF │ ◄── IP Block, Geo Block,
│ (Web ACL) │ SQLi, XSS, Custom Rules
└────────┬────────┘
│
▼
┌─────────────────┐
│ App Load │
│ Balancer (ALB) │
└────────┬────────┘
│
┌────────┴────────┐
▼ ▼
EC2 (AZ-1) EC2 (AZ-2)
(App Server) (App Server)
WAF intercepts every request before it reaches the ALB or your EC2 — malicious traffic never touches your application.
1. Launch EC2 instances across multiple AZs
2. Create an Application Load Balancer (ALB)
- Register EC2 instances as targets
- Configure health checks on /health endpoint
3. Point Route 53 A record (Alias) → ALB DNS name
4. Verify app is accessible via domain before attaching WAF
AWS Console → WAF & Shield → Web ACLs → Create Web ACL
Name : prod-web-acl
Resource Type : Regional (for ALB)
Region : ap-south-1 (your ALB region)
Associated Resource : Select your ALB
Default Action : Allow (block only what rules match)
Use case: Block specific IPs — malicious actors, scrapers, known bad sources.
WAF → IP Sets → Create IP Set
Name : blocked-ip-set
Region : same as Web ACL
IP version: IPv4
Addresses : 203.0.113.x/32 ← specific IP
192.0.2.0/24 ← entire CIDR range
Web ACL → Add Rule → IP Set Rule
Name : block-ip-rule
IP Set : blocked-ip-set
Action : Block
Priority : 1 (evaluated first)
Tested: Blocked own IP and confirmed 403 response. Verified access restored after removing IP from set.
Use case: Restrict access from countries irrelevant to your user base or required for compliance.
Web ACL → Add Rule → Geo Match Rule
Name : geo-block-rule
Action : Block
Priority : 2
Countries : Select regions to block
(e.g., CN, RU, KP — or any specific country)
Note: Geo match uses the MaxMind database. Some IPs (VPNs, proxies) may not resolve to accurate locations — use alongside IP rules for stronger coverage.
Tested: Validated access behavior from different regions using VPN to confirm geo block enforcement.
Use case: Instantly add AWS-maintained protection against OWASP Top 10 and common attack patterns.
Web ACL → Add Managed Rule Groups
Recommended groups to enable:
| Rule Group | Protects Against |
|---|---|
AWSManagedRulesCommonRuleSet |
General OWASP Top 10 — XSS, path traversal, bad bots |
AWSManagedRulesSQLiRuleSet |
SQL injection in URI, body, query string, headers |
AWSManagedRulesKnownBadInputsRuleSet |
Log4j, Spring4Shell, SSRF patterns |
AWSManagedRulesAmazonIpReputationList |
AWS threat intel — known malicious IPs |
AWSManagedRulesLinuxRuleSet |
Linux-specific LFI/path traversal attacks |
Action : Block (or Count first to observe before enforcing)
Priority: 10–50 (after custom rules)
Tip: Start with Count mode on managed rules for 1–2 days. Review sampled requests to ensure no false positives before switching to Block.
Use case: Add targeted rules for your application's specific request structure.
Rule Type : Regular rule
Name : custom-sqli-rule
Inspect : Query string + Body + URI path
Match Type : Contains SQL injection attack
Action : Block
Priority : 5
Rule Type : Regular rule
Name : custom-xss-rule
Inspect : Query string + Body + Headers (User-Agent, Referer)
Match Type : Contains XSS attack
Action : Block
Priority : 6
Web ACL → Logging & Metrics → Enable Logging
Destination options:
- CloudWatch Logs Log Group → /aws/waf/prod-web-acl
- S3 Bucket → s3://your-waf-logs-bucket/
- Kinesis Firehose → for real-time streaming
Log fields captured:
- timestamp
- action (ALLOW / BLOCK / COUNT)
- rule triggered
- client IP
- country
- URI, headers, body (configurable)
CloudWatch Alarm:
Metric : BlockedRequests
Threshold: > 100 in 5 minutes
Action : SNS notification → alert team
Priority 1 → IP Block Rule (custom — most specific, first)
Priority 2 → Geo Block Rule (custom — regional restriction)
Priority 5 → Custom SQLi Rule (app-specific injection check)
Priority 6 → Custom XSS Rule (app-specific script check)
Priority 10 → AWS IP Reputation List (managed — known bad actors)
Priority 20 → AWS Common Rule Set (managed — OWASP Top 10)
Priority 30 → AWS SQLi Rule Set (managed — broad SQLi coverage)
Priority 40 → AWS Bad Inputs (managed — Log4j, SSRF, etc.)
Default Action → Allow
Lower priority number = evaluated first. Custom rules should always have lower numbers than managed rules.
Block own IP → confirm 403 Forbidden response
Remove own IP from block list → confirm access restored
Test geo block with VPN → confirm traffic blocked from restricted region
Send SQLi payload in query string → confirm 403 from WAF
Example: GET /search?q=' OR 1=1--
Send XSS payload in request → confirm 403 from WAF
Example: GET /page?name=<script>alert(1)</script>
Verify legitimate traffic is unaffected — confirm 200 responses
Check WAF sampled requests in console to verify correct rules are firing
Confirm CloudWatch metrics show BlockedRequests incrementing
Always test in Count mode before switching to Block
Set low TTL on WAF rules during initial rollout to catch false positives early
Use IP sets instead of hardcoding IPs in rules — easier to update
Scope rules to specific paths (e.g., /api/*) to reduce false positives
Enable logging from day one — you need the data during incidents
Review sampled requests weekly to tune rules
Combine WAF with Shield Standard (free) for DDoS protection at network layer
Use Rate-Based rules to auto-block IPs exceeding request thresholds
| Action | Behavior |
|---|---|
| Allow | Request passes through to ALB and application |
| Block | Request stopped; 403 returned to client immediately |
| Count | Request allowed but logged — used for testing/observing |
| CAPTCHA | Challenge the client before allowing (bot protection) |
AWS WAF is not just a checkbox — it is an active, real-time security layer that sits between the internet and your application. Combining IP blocking, geo restrictions, managed rule groups, and custom rules creates a defense-in-depth posture where malicious traffic is filtered at the edge, long before it can reach your servers, databases, or users.