Forem: sourav chakraborty

🔐 OWASP Top 10 in AWS: A Practical Security Series for Builders

sourav chakraborty — Thu, 09 Apr 2026 18:49:29 +0000

Most security breaches don’t happen because attackers are geniuses.
They happen because:

Access control is missing one check
Encryption is configured “later”
Input validation is assumed, not enforced

The OWASP Top 10 documents these exact failures—the most common, most dangerous application security risks seen across the internet.
This series is about understanding them deeply and fixing them practically, specifically in AWS‑based architectures.

🎯 What This Series Is (and Isn’t)
✅ What You’ll Get

Clear explanations of each OWASP Top 10 category
Realistic AWS examples (API Gateway, ALB, ECS, Lambda, WAF)
Practical mitigation strategies you can apply immediately
Security reasoning that developers, DevOps, and architects can align on

❌ What You Won’t Get

Vendor fluff
Overly academic theory
Fear‑driven security talk
“Enable this checkbox and you’re done” advice

This is about how vulnerabilities actually happen in real systems—and how to stop them.

🧭 Why the OWASP Top 10 Still Matters
The OWASP Top 10 is more than a list. It’s the common language of application security.
It matters because it:

🛠 Aligns Engineering & Security
Tools like AWS WAF, F5, Burp Suite, and SAST/DAST scanners reference OWASP risks directly.

📜 Defines Compliance Baselines
Standards like SOC 2, PCI DSS, HIPAA, and ISO 27001 map directly to OWASP categories.

🚨 Focuses on Real‑World Breaches
Addressing the OWASP Top 10 mitigates the majority of web application attacks seen in production.

If you build or operate applications, you’re already dealing with OWASP—whether you realize it or not.

🗺️ The 10‑Day Roadmap
Each post covers one OWASP category per day, with hands‑on cloud context.

✅ Day 1: Broken Access Control (A01:2021)
🔐 Day 2: Cryptographic Failures
💉 Day 3: Injection
🔄 Day 4: Insecure Design
⚙️ Day 5: Security Misconfiguration
🧩 Day 6: Vulnerable & Outdated Components
🔑 Day 7: Identification & Authentication Failures
📊 Day 8: Software & Data Integrity Failures
📝 Day 9: Security Logging & Monitoring Failures
🌐 Day 10: Server‑Side Request Forgery (SSRF)

Each post stands alone—but together they form a complete security mindset.

☁️ AWS‑First, Vendor‑Aware
Examples and mitigations will focus on:

AWS WAF & Shield
API Gateway
Application Load Balancers
ECS, EKS, and Lambda
IAM, CloudWatch, and CloudTrail

Where useful, I’ll also reference advanced WAFs (like F5) to show how defense‑in‑depth actually works in real enterprises.

👥 Who This Series Is For

Backend & frontend developers
Cloud & DevOps engineers
Architects responsible for secure design
Security engineers working with product teams
Anyone tired of security advice that doesn’t map to real systems

If you’ve ever said:

“We’ll fix security later…”

This series is for you.

📌 Follow the series to get each post as it drops
Let’s build systems that are harder to break—and easier to defend.

# 🧹 Build an AWS Orphan Resource Cleaner with Go (Step-by-Step + Visual Guide)

sourav chakraborty — Sun, 22 Mar 2026 18:45:47 +0000

💸 Stop wasting money on unused AWS resources — automate cleanup with Go

🚀 Introduction

Cloud environments grow fast… and so do unused resources.

Unattached EBS volumes, unused Elastic IPs — they sit quietly and increase your AWS bill every month.

In this tutorial, you’ll build a real-world Orphan Resource Cleaner using Go and the AWS SDK for Go v2.

🧠 What Are Orphan Resources?

Orphan resources are:

AWS resources that are no longer in use but still cost money

Examples:

🪫 Unattached EBS volumes
🌐 Unassociated Elastic IPs

🖼️ Architecture Overview

Flow:

EventBridge (Scheduler)
        ↓
Go Program (Scanner)
        ↓
AWS APIs (EC2)
        ↓
Detect Orphan Resources
        ↓
Alert / Delete

⚡ Why Use Go for This?

🟢 Single Binary Deployment

No runtime dependency → perfect for automation & Lambda

⚡ High Performance

Fast execution for large AWS environments

🧵 Built-in Concurrency

Scan multiple regions in parallel using goroutines

🔐 Safer Automation

Strong typing → reduces accidental deletion risks

🟢 Go Basics (Quick Primer)

If you're new to Go, here’s what you need:

Hello World

package main

import "fmt"

func main() {
    fmt.Println("Hello, Go!")
}

Variables

name := "AWS Cleaner"
count := 5

Error Handling

if err != nil {
    fmt.Println("Error:", err)
}

🛠️ Step-by-Step Setup

1️⃣ Install Go

Check:

go version

If not installed:
👉 https://go.dev/dl/

2️⃣ Create Project

mkdir orphan-cleaner
cd orphan-cleaner

3️⃣ Initialize Module

go mod init orphan-cleaner

4️⃣ Add Code

Create file:

nano main.go

Paste the Orphan Cleaner code.

5️⃣ Install Dependencies

go mod tidy

6️⃣ Configure AWS Credentials

aws configure

export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
export AWS_REGION=ap-south-1

7️⃣ Run the Program

go run main.go

🖼️ Example Output

🔍 Discovering regions...

🌍 Scanning region: ap-south-1
🌐 [ap-south-1] Orphan Elastic IP: 13.xxx.xxx.xxx

🌍 Scanning region: us-east-1
🌐 [us-east-1] Orphan Elastic IP: 100.23.233.31

📊 Summary Report
-------------------------
🪫 Total Orphan EBS Volumes: 2
🌐 Total Orphan Elastic IPs: 3

⚠️ Safety First

🔒 Always Start with Dry Run

const autoDelete = false

🏷️ Use Tags to Protect Resources

Keep=true
Critical=yes

⏳ Add Grace Period

Only delete resources older than 7 days.

🔔 Add Alerts (Optional)

Use Amazon SNS to:

Send email alerts
Notify before deletion
Integrate with Slack

🔥 Real-World Impact

This simple tool can:

Save real money 💰
Improve AWS hygiene
Reduce attack surface

🤔 Why Not Python?

Feature	Go	Python
Deployment	Single binary	Runtime needed
Performance	Fast	Slower
Concurrency	Native	Limited
Lambda cold start	Low	Higher

🎯 Conclusion

You’ve built a production-relevant AWS automation tool using Go.

This isn’t just a demo — it’s something:

DevOps teams use daily
FinOps teams rely on
Companies build internally

🚀 Next Steps

Want to take it further?

🔔 Add SNS alerts
⚡ Add parallel scanning
🌍 Multi-account support
☁️ Deploy as Lambda

💡 Final Thought

“Unused cloud resources are silent money leaks — automation is the only scalable fix.”

🔐 TLS Encryption & Decryption in AWS Network Firewall

sourav chakraborty — Sun, 22 Feb 2026 16:28:07 +0000

Today, over 90% of internet traffic uses TLS (HTTPS). While this protects confidentiality, it also prevents traditional firewalls from seeing what’s inside the traffic.

That’s where TLS inspection in AWS Network Firewall becomes critical.

In this article, we’ll cover:

Why TLS inspection is required
How TLS normally works
How AWS Network Firewall performs TLS decryption & inspection
Architecture design (EC2 → Firewall → NAT → IGW)
Certificate requirements
Common deployment mistakes
Best practices

🚨 Why TLS Inspection Is Required

Without TLS inspection, a firewall can only see:

Source IP
Destination IP
Port (443)
Limited SNI/domain info

But it cannot see:

Malware downloads
Command & Control traffic
Data exfiltration
Exploit payloads
Unauthorized SaaS usage

Encrypted traffic becomes a blind spot.

TLS inspection restores visibility.

🔎 How TLS Normally Works

Before encryption begins, two steps happen:

1️⃣ TCP 3-Way Handshake

Client → SYN → Server
Server → SYN-ACK → Client
Client → ACK → Server

TCP session established.

2️⃣ TLS Handshake

ClientHello
ServerHello
Certificate exchange
Key negotiation
Encrypted session established

After this, traffic becomes encrypted:

Client ⇄ Encrypted ⇄ Server

A traditional firewall cannot inspect payload contents.

🔐 How TLS Inspection Works in AWS Network Firewall

When TLS inspection is enabled, the firewall becomes a proxy.

Instead of:

EC2 ⇄ Google

We now have:

EC2 ⇄ Firewall ⇄ Google

The firewall acts as:

Server toward EC2
Client toward Google

Packet Flow Example (Outbound HTTPS)

Architecture:

Private Subnet (EC2)
        ↓
AWS Network Firewall
        ↓
NAT Gateway
        ↓
Internet Gateway
        ↓
Internet (google.com)

Return traffic:

Internet → IGW → NAT → Firewall → EC2

Step-by-Step Flow

1️⃣ EC2 sends HTTPS request

EC2 → Firewall

2️⃣ Firewall intercepts TLS handshake

Receives ClientHello
Creates second TLS session to Google

3️⃣ Firewall validates certificate

OCSP / CRL check
Certificate inspection

4️⃣ Firewall decrypts traffic

Applies IPS rules
Applies domain filtering
Checks for malware

5️⃣ Firewall re-encrypts traffic

Firewall → NAT → Internet

🔑 Certificate Requirements

TLS inspection requires:

1️⃣ Inspection Certificate

Stored in AWS Certificate Manager
Presented by firewall to clients
Must be trusted by EC2/workloads

2️⃣ Revocation Policy

Best practice:

GOOD → Allow
UNKNOWN → Allow
REVOKED → Reject

Strictly rejecting UNKNOWN often causes outages.

Cloudwatch logs for Unknown revocation -> passed traffic.

🧱 Required Configuration Building Blocks

To make TLS inspection work correctly:

✅ 1) Routing (Symmetric)

Private subnet:

0.0.0.0/0 → Firewall endpoint

NAT subnet:

Private subnet CIDR → Firewall endpoint

Return traffic must pass through firewall.

✅ 2) Layer 4 Rule (TCP 443)

You must allow TCP first:

pass tcp $HOME_NET any -> $EXTERNAL_NET 443

TLS runs on top of TCP.

✅ 3) TLS Rule (Layer 7)

Then allow TLS:

pass tls $HOME_NET any -> $EXTERNAL_NET 443

✅ 4) Default Action

Recommended:

Drop everything else

Sample Firewall Policy

So for an HTTPS connection:

TCP session is established (port 443)
Then TLS handshake happens inside that TCP session
Then encrypted data flows

⚠️ Common Deployment Mistakes

❌ Asymmetric Routing

Return traffic bypasses firewall → TLS resets

❌ Revocation Policy Too Strict

UNKNOWN → REJECT

Causes unexpected connection resets.

❌ Missing TCP Rule

Allowing TLS but blocking TCP 443 breaks handshake.

❌ Inspecting All Ports

Only inspect required ports (usually 443).

📈 Performance Considerations

TLS inspection adds:

CPU overhead
Latency
Reduced throughput

Best practice:

Inspect only necessary traffic
Bypass trusted domains
Monitor firewall capacity

🏢 Enterprise Deployment Model

For multi-VPC environments:

Spoke VPCs
      ↓
Transit Gateway
      ↓
Inspection VPC
      ↓
AWS Network Firewall
      ↓
Internet

Centralized inspection reduces cost and improves control.

🎯 When TLS Inspection Is Most Valuable

TLS inspection is especially important for:

Developer environments
Outbound internet access
SaaS-heavy organizations
Data exfiltration protection
Compliance environments

🧠 Final Thoughts

TLS encryption protects data — but it also hides threats.

AWS Network Firewall TLS inspection allows organizations to:

✅ Regain visibility
✅ Detect malware in encrypted traffic
✅ Prevent data exfiltration
✅ Enforce SaaS policies
✅ Maintain compliance

When deployed with proper routing, policy design, and certificate handling, TLS inspection becomes a powerful security control without disrupting business operations.

[Boost]

sourav chakraborty — Mon, 02 Feb 2026 06:36:07 +0000

Minutes for Attackers, Weeks for Defenders: Reducing Attack Surface in AWS

sourav chakraborty for AWS Community Builders ・ Jan 31

#aws #cloud #cybersecurity #security

Minutes for Attackers, Weeks for Defenders: Reducing Attack Surface in AWS

sourav chakraborty — Sat, 31 Jan 2026 17:02:48 +0000

🚨 Attack Surface Blind Spots: The Reality Security Teams Face

Despite increased investment in security tooling 🛡️, most organizations still struggle to gain a complete and accurate view of their attack surface. Research consistently shows that nearly 40% of publicly accessible assets remain unknown 👻 to the organization that owns them.

These blind spots are not theoretical—they are actively exploited 🚨. Attackers often begin scanning for vulnerabilities within minutes ⏱️ of a new remote code execution (RCE) exploit being disclosed. In contrast, many organizations take weeks 🐢 to identify and remediate risky exposures.

This growing gap between attacker speed ⚡ and defender visibility 👀 creates a dangerous imbalance. Organizations cannot protect assets they don’t know exist, and response times cannot be compressed for exposures that remain invisible 🕶️.

💡 You can’t secure what you can’t see — visibility is the foundation of attack surface reduction.

🛡️ Reducing Attack Surface with AWS Native Security Tools

An organization’s attack surface 🚨 is no longer limited to a physical data center or a clearly defined network perimeter. It now spans every method, service, identity, and configuration used to access workloads across:

🏢 On-premises environments
☁️ Public cloud platforms
📦 SaaS applications
🌐 Internet-facing services
💻 Remote and mobile users

In AWS, this attack surface grows rapidly due to automation, identity-driven access, and elastic infrastructure. Misconfigurations, excessive permissions, exposed services, and unpatched workloads are among the most common entry points for attackers.

The good news? AWS offers a powerful set of native security services 🛡️ that help discover, reduce, and monitor your attack surface—without relying on third-party tools.

🔍 Understanding Attack Surface in AWS

In a cloud-native environment, the attack surface commonly includes:

🌐 Public-facing EC2 instances, load balancers, and APIs
🔐 Over-permissive IAM users, roles, and policies
🚪 Open security groups and network ACLs
🪣 Public S3 buckets and exposed EBS snapshots
🧪 Unpatched AMIs and vulnerable container images
🧹 Unused or forgotten cloud resources

💡 Attackers don’t “hack the cloud”—they exploit misconfigurations, weak identity controls, and lack of visibility.

🛡️ Key AWS Services That Reduce Attack Surface

🔐 Identity and Access Management (IAM)

Identity is the new perimeter in the cloud. Poor identity hygiene dramatically expands the attack surface.

Best practices include:

✅ Enforcing least privilege with scoped IAM policies
🔑 Replacing long-term access keys with IAM roles
📲 Enabling MFA for all privileged users
🔍 Using IAM Access Analyzer to detect unintended external access

Reducing identity exposure limits how far attackers can move—even after an initial compromise.

🕵️ Amazon GuardDuty – Continuous Threat Detection

Amazon GuardDuty provides always-on threat detection 🔎 by analyzing:

🧾 AWS CloudTrail logs
🌊 VPC Flow Logs
🌐 DNS activity

It detects threats such as:

🚨 Compromised credentials
🤖 Command-and-control traffic
⛏️ Cryptocurrency mining
🧠 Suspicious API behavior

Early detection prevents attackers from expanding your attack surface.

Sample GD dashboard

🧭 AWS Security Hub – Centralized Security Visibility

AWS Security Hub acts as a single pane of glass 🧭 by aggregating findings from services such as GuardDuty, Inspector, Macie, and Firewall Manager.

Security Hub helps teams:

👀 Gain centralized security visibility
🚪 Identify exposed or misconfigured resources
📋 Track compliance against CIS AWS Foundations Benchmarks
🎯 Prioritize high-risk findings

🛑 You can’t reduce what you can’t see.

🔄 AWS Config – Prevent Configuration Drift

AWS Config continuously monitors and evaluates resource configurations 🔄.

It helps reduce attack surface by:

🚫 Detecting security groups open to 0.0.0.0/0
🪣 Identifying public S3 buckets
🔐 Flagging unencrypted storage
🏷️ Enforcing required tagging and ownership

With automated remediation, risky configurations can be fixed before attackers find them.

🧪 Amazon Inspector – Vulnerability Management at Scale

Amazon Inspector continuously scans for vulnerabilities 🧪 across:

🖥️ EC2 instances
📦 Amazon ECR container images
⚙️ AWS Lambda functions

It identifies missing patches, known CVEs, and vulnerable packages.

🚨 Unpatched workloads significantly expand the attack surface—continuous scanning helps close those gaps.

🌐 Network Controls – Shrinking Entry Points

Network-level controls remain essential to limiting exposure 🌐.

Best practices include:

🚪 Using security groups as default-deny firewalls
🧱 Deploying AWS Network Firewall for deep packet inspection
🔒 Leveraging VPC endpoints to remove unnecessary internet access

Every closed port reduces attacker opportunity.

🔎 Amazon Macie – Protecting Sensitive Data Exposure

Amazon Macie discovers and classifies sensitive data stored in Amazon S3 🔎, including:

🧍 Personally identifiable information (PII)
💳 Financial data
🔑 Credentials and secrets

Macie helps answer a critical question:

❓ Do we have sensitive data exposed where it shouldn’t be?

Reducing data exposure lowers breach impact.

🧠 Defense-in-Depth: Bringing It All Together

Reducing attack surface in AWS is not a one-time task—it’s a continuous security discipline 🧠.

Each service plays a role:

🔐 IAM controls who can act
🌐 Network controls restrict where access is possible
🧪 Inspector reduces what vulnerabilities exist
🕵️ GuardDuty detects active threats
🧭 Security Hub provides centralized awareness

Together, they enable proactive, scalable cloud security.

🏁 Final Thoughts

In the cloud, speed and scale can amplify risk—but only when visibility and controls are missing.

AWS native security services enable organizations to:

👀 Continuously discover exposed assets
🔐 Enforce least privilege at scale
🚨 Detect threats in near real time
💥 Reduce blast radius before incidents escalate

🛡️ Reducing attack surface isn’t just security—it’s resilience, compliance, and confidence.

From Alerts to Answers: AWS Security Hub & Amazon Detective

sourav chakraborty — Wed, 24 Dec 2025 17:41:42 +0000

Cloud security doesn’t fail because of missing tools — it fails when alerts don’t turn into answers fast enough.

AWS provides two powerful services that solve different parts of the same security problem:

AWS Security Hub → Centralized detection & compliance
Amazon Detective → Deep investigation & root-cause analysis

Used together, they create a complete detection → investigation workflow.

🔍 The Problem: Too Many Alerts, Too Little Context

In real-world AWS environments, security teams face:

Hundreds of findings across accounts & regions
Alerts from GuardDuty, Inspector, IAM Access Analyzer
Manual log analysis across CloudTrail and VPC Flow Logs

This leads to:

🚨 Alert fatigue
🕒 Slow incident response
❌ Unclear blast radius

🧠 What is AWS Security Hub?

AWS Security Hub acts as a centralized security posture dashboard.

Key capabilities

Aggregates findings from:
- Amazon GuardDuty
- Amazon Inspector
- IAM Access Analyzer
- AWS Firewall Manager
Continuous compliance checks (CIS, AWS FSBP)
Multi-account and multi-region visibility
Supports automation using EventBridge

Limitation:

Security Hub tells you what happened, but not always why.

🕵️ What is Amazon Detective?

Amazon Detective helps security teams investigate incidents faster.

Why Detective matters

Automatically ingests:
- AWS CloudTrail
- VPC Flow Logs
- GuardDuty findings
Builds a behavior graph of users, IPs, and resources
Visual timelines and relationship mapping
No manual log correlation required

Think of Detective as your cloud forensics engine.

🔗 How Security Hub Integrates with Detective

The integration is automatically enabled when you enable the Detective service. No other configuration besides turning on the service is required

End-to-end workflow

GuardDuty detects suspicious activity
Security Hub aggregates and normalizes the finding
One-click investigation opens in Amazon Detective

Deep analysis of API calls, network traffic, and resources
Confirm severity and trigger remediation

This dramatically reduces MTTR (Mean Time to Respond).

Example: IAM Credential Compromise

Scenario:

GuardDuty reports unusual IAM credential usage from a new location.

Without Detective

Manual CloudTrail analysis
Time-consuming IP validation
Delayed containment

With Security Hub + Detective

Open finding directly in Detective
View login history and API activity
Identify affected resources immediately

High-Level Architecture

GuardDuty / Inspector / IAM Access Analyzer
↓
AWS Security Hub
↓
Amazon Detective
↓
SOC / IR Team / Automation

📊 Why the Integration Matters

Capability	Security Hub	Detective	Combined
Detection	✅	❌	✅
Aggregation	✅	❌	✅
Investigation	❌	✅	✅
Visualization	❌	✅	✅
Faster MTTR	⚠️	⚠️	🚀

✅ Best Practices

Enable Security Hub organization-wide
Enable Detective wherever GuardDuty is active
Use EventBridge and Lambda for automated response
Focus on high-severity findings
Regularly test investigation workflows

🎯 Final Thoughts

AWS Security Hub answers:

What security issues exist in my AWS environment?

Amazon Detective answers:

What actually happened and how bad is it?

Together, they turn alerts into answers.

If you found this useful, consider sharing or dropping a comment below.

🌟 The Ultimate Memory Hooks for AWS Certified AI Practitioner (AIF-C01)

sourav chakraborty — Sun, 07 Dec 2025 16:47:27 +0000

Preparing for the AWS Certified AI Practitioner (AIF-C01) can feel overwhelming — not because the concepts are complex, but because the exam covers a wide range of AI terminology, AWS services, ML workflows, prompt engineering, RAG, and evaluation metrics.

When I started preparing for the AWS Certified AI Practitioner (AIF-C01) exam, I quickly realized something — the content wasn’t “hard,” but there was so much to remember, and many terms sounded similar:

Supervised vs Unsupervised
Evaluation metrics
SageMaker services
Bedrock features
Prompt engineering techniques
RAG components

To keep things simple, I began writing down small memory hooks, short patterns, and mental shortcuts on a notepad.

These hooks helped me instantly recall concepts during the exam — especially when faced with confusingly worded scenario questions.

During my preparation, I followed the excellent QA/CloudAcademy course:“AWS Certified AI Practitioner (AIF-C01) Certification Preparation” by Danny Jessee.

This course helped me understand how different services fit together, while my memory hooks helped me recall the details under exam pressure.

This blog post is a summary of all the memory hooks that helped me pass the exam — shared so you (and others) can benefit as well.

To make learning efficient, here is a single consolidated guide of the best memory hooks and mnemonics used to successfully pass the exam — now shared so others can benefit too.

🧠 1. Machine Learning Basics

Supervised vs Unsupervised

Labels → Supervised
No Labels → Unsupervised

✔ Supervised = Teacher + Correct Answers
✔ Unsupervised = Find patterns (clustering, segments)

Classification vs Regression

Classes → Classification
Numbers → Regression

Overfitting vs Underfitting

Overfitting = Too complex → Increase regularization
Underfitting = Too simple → Decrease regularization

🧠 2. Key Algorithms

Clustering

Group customers? No labels? → K-Means

Image Classification

Flower Classification → k-NN or Decision Tree

Anomaly Detection

No labels + abnormal detection → Autoencoders

🧠 3. GenAI Prompt Engineering

Few-shot prompting
Show format → Few-shot prompting.
Prompt chaining
Multi-step workflow → Prompt chaining.
ReAct prompting

Reason + Action + Tool use → ReAct.

Temperature

Creativity ↑ → Temperature ↑
Consistency ↑ → Temperature ↓

🧠 4. LLM Inference Parameters

Temperature: Creativity
Top-K: Number of token choices
Top-P: Probability bucket
Max Tokens: Output length
Frequency Penalty: Reduce repeated words
Presence Penalty: Discourage repeated topics

Creativity → Temp / Top-K / Top-P
Length → Max Tokens
Repetition → Frequency & Presence

🧠 5. RAG (Retrieval-Augmented Generation)

Purpose of Chunking

Chunking = Better retrieval → Better context

Batch Steps in RAG

✔ Content embeddings
✔ Build search index
(NOT query embeddings or response generation)

LLM Type for Multimodal Search

Text + Image queries → Multimodal model

🧠 6. Evaluating ML Models

Summarization Metrics

Summarization → ROUGE
(If ROUGE missing → Choose BLEU)

Translation Metrics

Translation → BLEU / METEOR
Classification Metrics
Imbalanced data → F1 Score
Balanced → Accuracy

Regression Metrics

Numeric prediction → MSE / RMSE
LLM Quality

Perplexity → How surprised is the model?

🧠 7. AWS Services — Quick Memory Hooks
Model Cards

Governance + Documentation → Model Cards

Model Monitor

Detect drift in production → Model Monitor

Ground Truth

Human labeling → Ground Truth

JumpStart

Pre-built models + quick deploy → JumpStart

SageMaker Canvas

No-code data prep → Canvas

HealthScribe

Medical speech-to-text → HealthScribe

Guardrails for Bedrock

Responsible AI (safety filters) → Guardrails

PartyRock

Experiment + Learn + No cost → PartyRock
(Not for VPC, not for deployments)

🧠 8. GenAI Lifecycle

Design → Data → Train → Evaluate → Deploy → Monitor

Evaluation Stage

Accuracy testing

Safety + toxicity testing

Hallucination measurements

Inference

Train = Learn
Infer = Predict
Deploy = Serve

🧠 9. Embeddings

Embeddings = Meaning → Vectors
Reduced dimension → Same meaning → Similarity search

🧠 10. Foundational Concepts

Fine-tuning

Teach big model a small task well.
✔ Domain-specific labeled data
✔ Improves specific task performance
✔ NOT retraining from scratch
✔ NOT updating model to recent events

Responsible AI

Safety + Filters + Detect toxicity → Use Guardrails

🎉 Final Thoughts

These memory hooks are designed with one purpose:

👉 Make recall instant during the exam
👉 Reduce confusion between similar concepts
👉 Build confidence with patterns instead of memorising definitions

AWS Route 53 Resolver DNS Firewall — The First Line of Egress Defense

sourav chakraborty — Sun, 09 Nov 2025 16:09:56 +0000

🧭 Securing Outbound Traffic at the DNS Layer with AWS Route 53 Resolver DNS Firewall

When you think of network security in AWS, you probably picture Security Groups, NACLs, or AWS Network Firewall.

But what if you could stop malicious traffic before it even knows where to go — before an IP address is ever resolved?

That’s the power of AWS Route 53 Resolver DNS Firewall.

🔒 Why DNS-Layer Protection Matters

Every outbound connection starts with a DNS query.

Whether your EC2 instance is reaching an API, a SaaS endpoint, or — in a worst-case scenario — a command-and-control (C2) domain — the first step is always:

“What’s the IP of this domain?”

Attackers exploit this by using DNS for malware callbacks and data exfiltration.

Traditional firewalls inspect packets after DNS resolution.

DNS Firewall stops threats before they even resolve.

🧩 What Is AWS Route 53 Resolver DNS Firewall?

It’s a managed security layer inside Route 53 Resolver that lets you filter outbound DNS queries from your VPCs.

🧱 Key Components

Domain Lists – Collections of domains you allow or block.
Rule Groups – Sets of filtering rules (allow, block, alert).
VPC Associations – Bind rule groups to VPCs for enforcement.
Managed Domain Lists – AWS-maintained threat feeds for malware, botnets, and phishing domains.

In short:

When a resource in your VPC queries a domain, DNS Firewall checks it before the resolver returns an IP.

If the domain matches a block rule, the lookup fails — and the connection never happens.

⚙️ Step-by-Step Setup

1. Create a Domain List from CLI

aws route53resolver create-firewall-domain-list   --name blocked-domains   --domains file://blocked.txt

2. Add a Rule

aws route53resolver create-firewall-rule   --firewall-rule-group-id <rule-group-id>   --firewall-domain-list-id <domain-list-id>   --priority 100   --action BLOCK

You can create from AWS console

You can create new domain list seperately or while creating rules or refer to an existing domain list

AWS also provided a managed domain list for threats

3. Associate with a VPC

aws route53resolver associate-firewall-rule-group   --firewall-rule-group-id <rule-group-id>   --vpc-id <your-vpc-id>

✅ Result: Any instance in that VPC trying to resolve a blocked domain will receive an NXDOMAIN — connection denied at the DNS layer.

From console also it's simple to attach VPC

🧠 Practical Use Cases

🛡️ Prevent data exfiltration by blocking known or suspicious domains.
🏢 Enforce corporate DNS policies — allow only trusted domains.
🤖 Integrate with GuardDuty — auto-block malicious domains detected in findings.
⚙️ Automate updates using Lambda to refresh blocklists from threat feeds.

🔍 DNS Firewall vs. AWS Network Firewall for Egress Control

Both can manage outbound traffic — but they work at different OSI layers.

“DNS Firewall stops bad domains before they resolve.

Network Firewall inspects packets after they resolve.”

Feature / Aspect	AWS DNS Firewall	AWS Network Firewall
Layer	DNS (Name Resolution)	Network / Transport
Controls	Outbound DNS queries	Outbound TCP/UDP packets
Actions	Allow / Block / Alert	Allow / Drop / Inspect
Deployment Scope	VPC-level (Resolver)	Subnet-level (Routing)
Cost Profile	Low (per DNS query)	Higher (per GB processed)
Latency	Negligible	Slight (due to inspection)

🧱 Why DNS Firewall Shines for Egress Security

✅ 1. Stops Threats Early

Blocks queries before IP resolution — no data leaves your network.

✅ 2. Cost-Efficient

Charged per DNS query, not per GB of traffic. Ideal for workloads with heavy egress.

✅ 3. Easy to Deploy

No routing changes or extra endpoints — just associate and enforce.

✅ 4. Works with Network Firewall

Use DNS Firewall for domain filtering, Network Firewall for deep inspection.

Together they provide defense in depth.

🔐 Combined Example

An EC2 instance tries steal-data.bad-domain.com.
DNS Firewall blocks the DNS query.
If not blocked, Network Firewall inspects packets for threats.

💡 Result: Threats stopped early, less bandwidth wasted, lower cost.

🧮 Cost & Logging Tips

DNS Firewall pricing → per query inspected + rule group associations.
Network Firewall pricing → per GB processed + endpoint hours.

Enable Route 53 Resolver Query Logging to send logs to:

CloudWatch Logs
S3
Kinesis Data Firehose

✅ Best Practices

✅ Use AWS Managed Domain Lists as baseline.
🧾 Layer custom blocklists for organization-specific policies.
📊 Enable CloudWatch metrics for visibility.
🧩 Use AWS Firewall Manager for central governance.
🤝 Combine with GuardDuty findings for automated domain blocking.

⚠️ Common Pitfalls

❌ Assuming it controls inbound DNS — it only handles outbound queries.
❌ Forgetting VPC associations.
❌ Over-blocking — test lists before applying globally.

🏦 Real-World Example

A financial organization noticed beaconing attempts to suspicious .ru domains.

By deploying AWS DNS Firewall, they blocked these at the DNS level — cutting off the connection before it began.

No routing updates, no inspection overhead — just clean, effective protection.

🧩 Defense-in-Depth Summary

Layer	Service	Purpose
DNS	Route 53 Resolver DNS Firewall	Block malicious domains before resolution
Network	AWS Network Firewall	Inspect IPs, ports, protocols
Application	AWS WAF	Filter HTTP/S web layer attacks

🏁 Conclusion

AWS Route 53 Resolver DNS Firewall gives your VPCs an invisible yet critical layer of egress protection — stopping bad domains before they resolve.

When combined with AWS Network Firewall, it forms a multi-layered egress defense that’s cost-efficient, scalable, and easy to manage.

🧱 DNS Firewall = DNS Gatekeeper

🚧 Network Firewall = Border Guard

Together, they ensure nothing untrusted leaves your cloud unchecked.

💬 Have you used DNS Firewall in your AWS environment?

Share your setup, automation tricks, or lessons learned in the comments below! 👇

🛡️ Beyond the Model: How Amazon Bedrock Guardrails Protect Your Users and Data

sourav chakraborty — Fri, 12 Sep 2025 18:35:33 +0000

Generative AI is transforming how we build products — from conversational bots 🤖 to creative content engines ✍️. But as these systems become more powerful, they’re also being probed in harmful and unsafe ways.

Users may try to submit prompts that are inappropriate ⚠️ or manipulate models to bypass built-in security mechanisms. And because foundation models can occasionally “hallucinate,” they might produce responses that violate your company’s standards or reveal sensitive information.

Amazon Bedrock already includes automated mechanisms to detect and prevent potential misuse and abuse, but there’s still a need for enhanced, configurable security controls. That’s where Guardrails come in 🚦.

Amazon Bedrock is AWS’s fully managed platform for building and running generative AI applications without managing servers or training models from scratch.

✨ Key benefits:

Choose from top-tier foundation models — Amazon Titan, Anthropic Claude, Cohere Command.
Invoke them via API; optionally fine-tune them with your own data.
Serverless — pay only for what you use.

🔒 Privacy & Data Protection by Design:

Your prompts and outputs aren’t used to train Amazon Titan or any other foundation model and are not stored in service logs.
When you fine-tune a model, Bedrock creates a private copy just for you and trains only that copy.
All data is encrypted with AWS KMS, and you control the keys.
Connect via AWS PrivateLink so your traffic never traverses the public internet; lock it down further with a custom endpoint policy.

This combination gives you access to powerful models while keeping corporate data under your control.

What Are Guardrails? 🚦

Guardrails are like policy fences for your AI models. They sit between your application and the model to control both user inputs and model outputs — including any fine-tuned models you deploy.

They help you keep user interactions “within the lanes” you define, giving administrators granular controls over filtering strength and scope. You can define multiple Guardrail policies and reuse them across your portfolio of Bedrock applications, regardless of which foundation model you’re using.

The Four Guardrail Categories

📝 Category	🛠️ What it does	💡 Example
Denied Topics	Define topics your application should avoid using natural language descriptions and sample phrases.	A financial institution prevents its banking chatbot from answering investment advice questions.
Content Filters	Set thresholds (None, Low, Medium, High) for four categories of potentially harmful or sensitive content. Apply independently to prompts and outputs.	A customer-facing chatbot uses a High filter to reduce the chance of offensive content reaching users.
PII Redaction	Detect and filter personally identifiable information (PII) in prompts and redact it from model responses.	A call-center app summarizes customer calls with all names and account numbers removed.
Word Filters	Filter specific words or phrases such as profanity, competitors’ names, or product names. You can mask or respond with a pre-configured message.	Block a competitor’s product names in generated copy.

🛡️ Most foundation models already have some safeguards built in, but Guardrails add a **customizable, consistent protection layer* that you control.*

Setting Up Guardrails in the Console

Log into the AWS Management Console and navigate to Amazon Bedrock → Guardrails.
Click Create Guardrail.
Configure the four categories: denied topics, content filters (thresholds per category), PII redaction, and word filters.
Save and attach the Guardrail to your chosen model(s).
Test with sample prompts to verify that your settings work before deploying to production.

Programmatic Example 💻

import boto3

bedrock = boto3.client('bedrock-runtime')

response = bedrock.invoke_model(
    modelId='your-model-id',
    guardrailId='your-guardrail-id',
    contentType='application/json',
    accept='application/json',
    body='{"inputText":"Test prompt"}'
)

print(response['body'])

Every invocation automatically goes through your Guardrail policies.

Best Practices 🧠

Start broad, refine later. Begin with default filters and adjust thresholds based on monitoring data.
Monitor metrics. Use CloudWatch to see how often Guardrails trigger and adjust accordingly.
Combine automated and human review. Route flagged outputs to a human moderator for high-risk cases.
Reuse policies. Create a library of Guardrails for different apps to ensure consistent enforcement.

Wrapping Up 🎁

With the recent proliferation of AI-based systems and conversational applications, attempts to exploit them are rising. Amazon Bedrock Guardrails give you a second line of defense — on top of the foundation models’ own protections — to ensure user interactions stay appropriate and your data stays safe.

By combining Bedrock’s privacy-first design with the granular controls of Guardrails, you can deploy generative AI faster and with greater confidence, whether it’s a public chatbot, an internal knowledge assistant, or a custom-tuned model running in your VPC.

Simplifying Cross-VPC Communication with AWS VPC Lattice

sourav chakraborty — Thu, 24 Jul 2025 05:42:23 +0000

🚀 Tired of managing complex VPC peering or Transit Gateway configurations? Discover how AWS VPC Lattice simplifies service-to-service communication across VPCs.

NetworkingMadeSimple 🌐✨

💡In modern cloud architectures, applications are often distributed across multiple VPCs for better isolation and security. However, this creates
challenges for service-to-service communication. Traditional solutions like VPC peering or Transit Gateway can be complex to manage and scale.

AWS VPC Lattice offers a simpler approach by providing a fully managed service networking solution. In this post, I'll walk through a practical proof
of concept (POC) that demonstrates how VPC Lattice can connect services across different VPCs without complex networking configurations.

The Problem: Cross-VPC Service Communication

🔁 Consider this common scenario:

• SpokeA VPC: Contains your application logic (Lambda functions)
• SpokeC VPC: Contains your backend services (web servers)

🧱 Traditionally, you'd need to set up VPC peering, Transit Gateway, or use an Application Load Balancer (ALB) to enable communication between these VPCs.
Each approach has its own complexities and limitations.

The Solution: VPC Lattice

VPC Lattice provides a service-oriented approach to networking. Instead of focusing on network connectivity, you register services and let VPC Lattice
handle the discovery and routing.

Our POC demonstrates this by connecting a Lambda function in SpokeA VPC to an Apache web server in SpokeC VPC through VPC Lattice.

POC Architecture

SpokeC VPC: Contains an EC2 instance running Apache
SpokeA VPC: Contains a Lambda function that accesses the Apache server
VPC Lattice: Connects the two VPCs and enables service discovery

Step-by-Step Implementation

1. Create a VPC Lattice Service Network

bash
$ aws vpc-lattice create-service-network --name "poc-service-network" --region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:servicenetwork/sn-0735c8dcd85f31ba0",
"createdAt": "2025-07-06T13:34:38.065000+00:00",
"id": "sn-0735c8dcd85f31ba0",
"lastUpdatedAt": "2025-07-06T13:34:38.065000+00:00",
"name": "poc-service-network",
"numberOfAssociatedResourceConfigurations": 0,
"numberOfAssociatedServices": 0,
"numberOfAssociatedVPCs": 0
}

2. Associate VPCs with the Service Network

bash
$ aws vpc-lattice create-service-network-vpc-association \
--service-network-identifier sn-0735c8dcd85f31ba0 \
--vpc-identifier vpc-09e69971ba778dc66 \
--region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:servicenetworkvpcassociation/snva-0b31c3c150f75e0cd",
"createdBy": "XXYY112233",
"id": "snva-0b31c3c150f75e0cd",
"status": "CREATE_IN_PROGRESS"
}

$ aws vpc-lattice create-service-network-vpc-association \
--service-network-identifier sn-0735c8dcd85f31ba0 \
--vpc-identifier vpc-06bb9f3453465ee95 \
--region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:servicenetworkvpcassociation/snva-088beb43dc9cc2e88",
"createdBy": "XXYY1122333",
"id": "snva-088beb43dc9cc2e88",
"status": "CREATE_IN_PROGRESS"
}

3. Create a VPC Lattice Service for the Apache Server

bash
$ aws vpc-lattice create-service \
--name "apache-service" \
--region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:service/svc-0b5ef28909b938204",
"authType": "NONE",
"dnsEntry": {
"domainName": "apache-service-0b5ef28909b938204.7d67968.vpc-lattice-svcs.us-east-1.on.aws",
"hostedZoneId": "Z0681547Z82L3THDFSCZ"
},
"id": "svc-0b5ef28909b938204",
"name": "apache-service",
"status": "CREATE_IN_PROGRESS"
}

4. Create a Target Group for the Apache EC2 Instance

bash
$ aws vpc-lattice create-target-group \
--name "apache-target-group" \
--type INSTANCE \
--config '{"port": 80, "protocol": "HTTP", "vpcIdentifier": "vpc-09e69971ba778dc66"}' \
--region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:targetgroup/tg-08a1d70cb62776f59",
"config": {
"healthCheck": {
"enabled": true,
"healthCheckIntervalSeconds": 30,
"healthCheckTimeoutSeconds": 5,
"healthyThresholdCount": 5,
"matcher": {
"httpCode": "200"
},
"path": "/",
"protocol": "HTTP",
"protocolVersion": "HTTP1",
"unhealthyThresholdCount": 2
},
"ipAddressType": "IPV4",
"port": 80,
"protocol": "HTTP",
"protocolVersion": "HTTP1",
"vpcIdentifier": "vpc-09e69971ba778dc66"
},
"id": "tg-08a1d70cb62776f59",
"name": "apache-target-group",
"status": "CREATE_IN_PROGRESS",
"type": "INSTANCE"
}

5. Register the EC2 Instance with the Target Group

bash
$ aws vpc-lattice register-targets \
--target-group-identifier tg-08a1d70cb62776f59 \
--targets '[{"id": "i-012ab2d1599a3a7f5", "port": 80}]' \
--region us-east-1

{
"successful": [
{
"id": "i-012ab2d1599a3a7f5",
"port": 80
}
],
"unsuccessful": []
}

6. Create a Listener for the Service

bash
$ aws vpc-lattice create-listener \
--service-identifier svc-0b5ef28909b938204 \
--name "http-listener" \
--protocol HTTP \
--port 80 \
--default-action '{"forward": {"targetGroups": [{"targetGroupIdentifier": "tg-08a1d70cb62776f59"}]}}' \
--region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:service/svc-0b5ef28909b938204/listener/listener-0db2fbc883a854bf3",
"defaultAction": {
"forward": {
"targetGroups": [
{
"targetGroupIdentifier": "tg-08a1d70cb62776f59",
"weight": 100
}
]
}
},
"id": "listener-0db2fbc883a854bf3",
"name": "http-listener",
"port": 80,
"protocol": "HTTP",
"serviceArn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:service/svc-0b5ef28909b938204",
"serviceId": "svc-0b5ef28909b938204"
}

7. Associate the Service with the Service Network

bash
$ aws vpc-lattice create-service-network-service-association \
--service-network-identifier sn-0735c8dcd85f31ba0 \
--service-identifier svc-0b5ef28909b938204 \
--region us-east-1

{
"arn": "arn:aws:vpc-lattice:us-east-1:XXYY112233:servicenetworkserviceassociation/snsa-0091d77572ee6e123",
"createdBy": "XXYY112233",
"dnsEntry": {
"domainName": "apache-service-0b5ef28909b938204.7d67968.vpc-lattice-svcs.us-east-1.on.aws",
"hostedZoneId": "Z0681547Z82L3THDFSCZ"
},
"id": "snsa-0091d77572ee6e123",
"status": "CREATE_IN_PROGRESS"
}

8. Create a Lambda Function to Access the Apache Server

python
import json
import urllib.request
import os

def lambda_handler(event, context):
# Get the VPC Lattice service DNS name from environment variable
service_url = os.environ['SERVICE_URL']

try:
    # Make a request to the Apache server through VPC Lattice
    with urllib.request.urlopen(f"http://{service_url}") as response:
        html = response.read().decode('utf-8')

    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': 'Successfully accessed Apache server through VPC Lattice',
            'html_snippet': html[:500] + '...' if len(html) > 500 else html
        })
    }
except Exception as e:
    return {
        'statusCode': 500,
        'body': json.dumps({
            'message': 'Error accessing Apache server',
            'error': str(e)
        })
    }

bash
$ aws lambda create-function \
--function-name VPCLatticeApacheAccess \
--runtime python3.9 \
--role arn:aws:iam::XXYY112233:role/LatticeAccessRole \
--handler lambda_function.lambda_handler \
--zip-file fileb://~/lambda_function.zip \
--vpc-config "SubnetIds=subnet-02f8a7734c22ff7a5,subnet-0139b62cbd4fc7768,SecurityGroupIds=sg-0760a256370568790" \
--environment "Variables={SERVICE_URL=apache-service-0b5ef28909b938204.7d67968.vpc-lattice-svcs.us-east-1.on.aws}" \
--region us-east-1

9. Test the Lambda Function

bash
$ aws lambda invoke \
--function-name VPCLatticeApacheAccess \
--payload '{}' \
--region us-east-1 \
response.json && cat response.json

{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{"statusCode": 200, "body": "{\"message\": \"Successfully accessed Apache server through VPC Lattice\", \"html_snippet\": \"test web\n\"}"}

10. Make the Lambda Function Publicly Accessible (Optional)

bash
$ aws apigateway create-rest-api \
--name "VPCLatticeApacheAccess-API" \
--region us-east-1

$ aws apigateway create-resource \
--rest-api-id xxyyzzzxx \
--parent-id ju51yslurg \
--path-part "apache" \
--region us-east-1

$ aws apigateway put-method \
--rest-api-id xxyyzzzxx \
--resource-id 129hegto \
--http-method GET \
--authorization-type NONE \
--region us-east-1

$ aws apigateway put-integration \
--rest-api-id xxyyzzxx \
--resource-id 129hegto \
--http-method GET \
--type AWS_PROXY \
--integration-http-method POST \
--uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:XXYY112233:function:VPCLatticeApacheAccess/invocations \
--region us-east-1

$ aws apigateway create-deployment \
--rest-api-id xxyyxxzz \
--stage-name prod \
--region us-east-1

Test the public endpoint:

bash
$ curl -s https://xxxyyyxxx.execute-api.us-east-1.amazonaws.com/prod/apache

{"message": "Successfully accessed Apache server through VPC Lattice", "html_snippet": "test web\n"}

When to Use VPC Lattice with Lambda Instead of ALB

✅ ## When to Use VPC Lattice Instead of ALB

While Application Load Balancers (ALBs) are a common choice for routing traffic to backend services, VPC Lattice with Lambda offers several advantages in specific scenarios:

1. Multi-VPC Architectures 🌐

VPC Lattice Advantage: VPC Lattice is designed for multi-VPC environments. It eliminates the need for complex networking setups like VPC peering or
Transit Gateway.

Business Case: Organizations with strict isolation requirements between different business units or applications that still need to communicate with
each other.

2. Service Discovery 🧭

VPC Lattice Advantage: Built-in service discovery through DNS and service mesh capabilities.

Business Case: Microservices architectures where services need to discover and communicate with each other dynamically.

3. Fine-Grained Access Control 🔐

VPC Lattice Advantage: Supports IAM-based authentication and authorization at the service level.

Business Case: Environments with strict security requirements where you need to control which services can communicate with each other.

4. Serverless-First Architectures ☁️⚡

VPC Lattice Advantage: Seamless integration with Lambda functions, eliminating the need for maintaining networking infrastructure.

Business Case: Organizations embracing serverless architectures that need to connect to legacy or containerized services.

5. Cost Optimization for Variable Traffic 💰📉

VPC Lattice Advantage: Pay-per-use pricing model with no minimum fees or idle charges.

Business Case: Applications with variable or unpredictable traffic patterns where maintaining always-on ALBs would be costly.

🛍️ Real-World Use Cases

1.🏦 Financial Services: Connecting customer-facing applications with backend processing systems while maintaining strict isolation between environments.

2.🏥 Healthcare: Enabling secure communication between patient-facing applications and protected health information (PHI) systems across different
security domains.

3.🛒 Retail: Connecting inventory management systems with order processing services across different business units or acquisitions.

4.🧑‍💻 SaaS Platforms: Providing isolated environments for each customer while enabling shared services to communicate across tenant boundaries.

Conclusion

VPC Lattice provides a simpler, more service-oriented approach to networking in AWS. By focusing on services rather than network connectivity, it
eliminates much of the complexity associated with traditional networking solutions.

Our POC demonstrates how VPC Lattice can connect services across different VPCs with minimal configuration. The Lambda function in SpokeA VPC can
seamlessly access the Apache server in SpokeC VPC through VPC Lattice, without any direct network connectivity between the VPCs.

For organizations with multi-VPC architectures, microservices, or serverless applications, VPC Lattice offers a compelling alternative to traditional
networking approaches. It simplifies service-to-service communication, enhances security through fine-grained access control, and reduces operational
overhead.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💬 Have you tried VPC Lattice in your environment? What challenges did you face with cross-VPC communication?
👇 Drop your thoughts and war stories in the comments! Let’s learn together. 🔍🧵

[Boost]

sourav chakraborty — Tue, 15 Jul 2025 10:39:14 +0000

sourav chakraborty for AWS Community Builders

Jul 12 '25

Serverless Meets Secure Networking: Payment Gateway building block with VPC Lattice

#webdev #aws #serverless #vpclattice

Comments

14 min read

🛡️ Zero Trust for File Uploads in S3: Protecting Amazon S3 with Trend Micro FSS

sourav chakraborty — Sat, 12 Jul 2025 17:43:14 +0000

📥 Introduction

In today’s cloud-native world, Amazon S3 is a cornerstone for storing application uploads—images, documents, archives, and more. But with flexibility comes risk. Users might unknowingly (or intentionally) upload malicious files that can:

❌ Compromise your backend systems
📤 Spread malware through shared downloads
📦 Bypass downstream processors

⚠️ S3 doesn't scan uploaded files for malware.

Trend Micro File Storage Security (FSS) — a real-time, serverless scanning solution to protect your S3 buckets from file-based threats.

🧨 The Problem: Vulnerable File Uploads

Let’s say you’re running a file-sharing or content review app. Malicious users could upload:

📎 Ransomware-infected ZIPs
📄 Trojan-embedded Word docs
🧾 JavaScript exploits hidden in PDFs

Without inspection, these files could:

🖥️ Be processed by backend Lambda or EC2 services
🔗 Be shared with other users
📉 Lead to data breaches or cloud compromise

🛠️ The Solution: Trend Micro File Storage Security (FSS)

Trend Micro FSS Trend Micro FSS is a serverless, event-driven scanning solution built for AWS. It integrates directly with Amazon S3 and uses Trend Micro's advanced malware detection engine to scan files in real-time. The solution classifies scan outcomes and takes defined actions:

🧪 Scan Result	✅ Action Taken
✔️ Clean	Move to ✅ Clean Bucket
🛑 Malicious	Move to 🚫 Quarantine Bucket
❓ Scan Failed	Move to ⚠️ Failure Bucket

Key Features at a Glance

⬇️ Decrease Threat Vectors with Malware Scanning: Block known harmful files using Trend Micro anti-malware signatures for viruses, Trojans, spyware, and more.

🤝 File Reputation: Cross-check files against threat intelligence to determine if they are known to be malicious.

✨ Variant Protection: Detect polymorphic or obfuscated malware using advanced pattern-matching and fragment analysis.

💪 Extensive Flexibility: Scan all file types, including .BIN, .EXE, .JPEG, .MP4, .PDF, .TXT, .ZIP, and more — with no size or type restriction.

📊 Architecture Overview

⚙️ Setup Guide (Step-by-Step)
✅ Step 1: Deploy FSS
Subscribe via AWS Marketplace

Deploy using the CloudFormation template

📂 Step 2: Prepare S3 Buckets
uploads-bucket — Original file uploads

clean-bucket — For scanned, safe files

quarantine-bucket — For detected malware

failure-bucket — For scan failures

🔁 Step 3: Create S3 Event Trigger
json
Copy
Edit
{
"Event": "s3:ObjectCreated:*",
"LambdaFunctionArn": "arn:aws:lambda:your-function-arn"
}
🧠 Step 4: Lambda Pseudocode (Simplified)
python
Copy
Edit
def lambda_handler(event, context):
key = event['Records'][0]['s3']['object']['key']
bucket = event['Records'][0]['s3']['bucket']['name']

scan_result = scan_with_trendmicro(bucket, key)

if scan_result == "CLEAN":
    move_to("clean-bucket", key)
elif scan_result == "MALICIOUS":
    move_to("quarantine-bucket", key)
else:
    move_to("failure-bucket", key)

🔐 Step 5: IAM Role Permissions
Ensure Lambda has access to:

s3:GetObject, PutObject, DeleteObject

Trend Micro FSS API endpoint

Destination buckets

We can also get a report of scan acviity in Trendmicro console

🔔 Bonus Features
📩 Send SNS/Slack alerts on malware detection

🏷️ Tag files with scan_result=clean|malicious|failed

🧩 Connect EventBridge → Security Hub for automatic SOAR response

🧠 Best Practices
✅ Block public access to all buckets
✅ Apply bucket encryption (SSE-S3 or KMS)
✅ Use lifecycle rules to auto-delete old files
✅ Limit file size and scan timeout thresholds

🏁 Final Thoughts
Trend Micro File Storage Security provides a plug-and-play solution to scan every file that hits your S3 bucket. It isolates threats, supports automation, and requires minimal maintenance.

🛡️ Don’t let your file uploads be a backdoor into your cloud.

📚 Resources
🔗 Trend Micro File Storage Security Docs

📝 AWS S3 Event Notifications

🔐 IAM Best Practices