Forem: Lingesh B

Enforcing Zero Trust: AWS VPC Encryption Controls Explained

Lingesh B — Sat, 25 Apr 2026 08:37:19 +0000

“Encryption in transit” is no longer a “nice-to-have” — it’s a mandatory requirement for PCI-DSS, HIPAA, and modern Zero-Trust architectures. But how do you prove to an auditor that every packet in your VPC is encrypted?

You don’t do it with spreadsheets; you do it with VPC Flow Logs. By leveraging the new ${encryption-status} field and VPC Encryption Controls, you can audit, verify, and enforce hardware-level encryption across your entire infrastructure with a single click.

VPC Encryption Controls is a security and compliance feature introduced by AWS to provide centralized visibility and authoritative control over the encryption of data moving within and between your Virtual Private Clouds.

Historically, verifying that all “east-west” traffic (traffic between your internal instances, load balancers, and databases) was encrypted was a manual and complex task, often involving messy spreadsheets and custom auditing scripts. This feature automates that process by leveraging the AWS Nitro System hardware and application-layer metadata.

The Two Core Modes
To help you reach a fully encrypted state without breaking your existing applications, the feature operates in two phases:

Key Capabilities

Detailed Auditing: Adds a new ${encryption-status} field to VPC Flow Logs, showing you at a glance if traffic is encrypted via Nitro hardware (1), application-level TLS (2), both (3), or not at all (0).
Resource Identification: Provides a “To-Do” list in the AWS Console of specific resources (like older EC2 instances or HTTP listeners) that are preventing you from reaching an enforced security posture.
Seamless Upgrades: Automatically migrates managed infrastructure like Application Load Balancers (ALB) and Fargate tasks to Nitro-based hardware to ensure they meet encryption standards transparently.
Compliance Ready: Simplifies the proof required for regulatory frameworks like HIPAA, PCI DSS, and FedRAMP by providing an authoritative dashboard of encryption status.
Why use it?
If your organization follows a Zero Trust architecture, you can no longer assume that internal traffic is “safe” just because it’s inside the VPC. VPC Encryption Controls allow you to verify and mandate that every single packet is encrypted, providing a critical layer of defense-in-depth against internal threats or misconfigurations.

In this demo, I have created a VPC with below resources

Architecture diagram:

My application(static website) has four EC2 instances(webservers) behind an Application load balancer

Created VPC Encryption control in “Monitor” mode to first audit the encryption status of resources in my VPC

In simple terms, Monitor Mode is like a security camera for your network. It watches all the data moving around your VPC and takes notes on whether that data is “scrambled” (encrypted) or “plain text” (unencrypted).

Crucially, it does not block or change anything. Your website and apps will keep running exactly as they are while it gathers information

Below resources have been flagged as resources accepting unencrypted traffic

Internet Gateway

You can configure specific exclusions for resources such as internet gateways or NAT gateways, that don’t support encryption (because the traffic flows outside of the AWS network).

Elastic Network interfaces include the four EC2 instances(t2.micro) and NAT Gateway

Moving to a Fully Encrypted VPC(Enforce mode)
Once you have identified unencrypted resources in Monitor Mode, you can begin migrating them to a secure state. Depending on the service type, this process is either automatic or requires a manual upgrade.

Automatic Migration (No Action Required) Certain managed services will handle the transition for you. AWS will transparently move the underlying infrastructure to Nitro hardware — which provides automatic encryption — with zero service interruption:

Application Load Balancers (ALB)
Network Load Balancers (NLB)
AWS Fargate Tasks

Manual Migration (Action Required) For resources that you manage directly, such as Amazon EC2 instances, you must take one of the following steps to achieve encryption compliance:

Upgrade Hardware: Switch from older, legacy instances (like t2 or m4) to modern Nitro-based types (like t3, m5, c6g, etc.).
Encrypt the App: If you cannot upgrade the hardware, you must configure TLS/SSL encryption (HTTPS) manually at the application level.
I created custom VPC flow logs to capture the encryption status

Sent traffic to my Webservers via Application Load Balancer(Note that I am accessing ALB using http and not https)

Then, I checked my VPC flow logs to identify the encryption status

Encryption Status Code:

For EC2 instances running on t2.micro instance type, the encryption status field is 0 meaning no hardware level or app level encryption was detected

After I manually migrated two of my EC2 instances to m8a.medium(Nitro based instance), the encryption status field in the flow logs is 1 for those specific instances indicating hardware layer encryption

After manual migration to Nitro based instance type, those instances also got removed from the unencrypted resources list and only the remaining two instances(t2.micro) are flagged

IMPORTANT CATCH:
🛑 The “Port 80” Catch: Why isn’t my ALB flagged?
If you are running an Application Load Balancer (ALB) on Port 80, you might be surprised to see it missing from the “Unencrypted Resources” list. It feels like a security hole, but it’s actually due to a “silent upgrade” AWS performs for you.

The Transparent Nitro Migration When you enable Monitor Mode, AWS identifies that the ALB is a managed service. It then automatically and transparently migrates the ALB’s underlying infrastructure to Nitro hardware.

Because Nitro-based hardware has a dedicated security chip that scrambles data at the physical network layer, the ALB is now capable of hardware encryption. In the eyes of VPC Encryption Controls, it is no longer a “blocker” to security — even if your application is still using Port 80.

Status 1: The “Invisible” Internal Shield Even if you haven’t set up an SSL certificate yet, the traffic moving inside your VPC (from the ALB to a modern EC2 instance) is often automatically encrypted by the Nitro chips on both ends.

What you’ll see in logs: An encryption-status of 1.
What it means: Your internal “East-West” traffic is protected by hardware-level AES-256 encryption, even over an unencrypted protocol like HTTP.

The “False Sense of Security” Warning This is the most important part : VPC Encryption Controls only track the journey inside the VPC.

Inside the VPC (ALB → EC2): Safe (Status 1).
Outside the VPC (User → ALB): UNSAFE.
If a user sends a password to your ALB on Port 80 over the public internet, that password is sent in plain text. It only gets “scrambled” by Nitro hardware after it reaches the ALB. To truly be secure, you must still move to Port 443 (HTTPS) to protect the data during its journey across the internet.

The reason Internet Gateways (IGW) and NAT Gateways are flagged while your ALB is not comes down to one thing: The Destination of the Data.

The “Off-Ramp” Problem VPC Encryption Controls are designed to ensure data is encrypted within the AWS network.

The ALB sends data to another resource inside your VPC (like an EC2 instance). Because both ends are inside AWS, AWS can use Nitro hardware to scramble that data.
Gateways are different. Their entire purpose is to send data outside your VPC to the public internet.
Once data leaves through an IGW or NAT Gateway, AWS no longer owns the “wires” it travels on. AWS cannot force the rest of the internet to use Nitro hardware encryption. Therefore, these gateways are marked as Unencrypted because they are essentially “leaks” where protected data turns into unprotected public data.

Physical vs. Logical Limitations ALB/Fargate: These are “Software-Defined” managed services. AWS can simply update the “code” they run on to include Nitro capabilities. That’s why they are automatically moved to the “Encrypted” list. Gateways: These are architectural “edge” points. A NAT Gateway is a middleman. If you send it unencrypted data from an EC2 instance, it must pass that unencrypted data out to the internet. It cannot “Nitro-encrypt” a packet that is destined for a Google or Netflix server.
They are “Blockers” by Design In your dashboard, “Unencrypted Resources” really means “Things that will stop you from enabling Enforce Mode.” If you tried to turn on Enforce Mode without addressing these gateways, AWS would have to drop all your internet traffic to stay “compliant” with your security policy.

To fix this, AWS doesn’t expect you to “encrypt” the gateway. Instead, you must Exclude them

The 3-Step Process:
Monitor (Watch): Turn on Monitor Mode to find out resources that allow unencrypted traffic.
Fix (Upgrade): For resources, such as the previous generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, you will need to switch to modern Nitro based instance types or configure TLS encryption at application level.
Enforce (Lock): Once the monitor shows everything is green, you flip the switch to “Enforce Mode,” which will block any future unencrypted traffic from even starting.

Building an Automated AWS Security Advisor: RAG with AWS Bedrock and OpenSearch Serverless

Lingesh B — Sat, 25 Apr 2026 07:37:45 +0000

The Problem: Security Posture Debt at Scale

In large AWS environments spanning multiple accounts, developers and engineers create cloud resources every day — EC2 instances, S3 buckets, ECS clusters, EKS clusters, RDS databases, Lambda functions, VPCs and so many other resources. But it also means security best practices often get deprioritized in the heat of delivery.

The result? AWS Security Hub flags dozens of findings every week. Resources that don’t conform to CIS AWS Foundations Benchmark, PCI DSS controls, or AWS Foundational Security Best Practices (FSBP) accumulate a growing backlog. The security team then has to chase down resource owners, explain what’s wrong, and guide them through remediation — a reactive, time-intensive process.

What if you could shift security left by providing developers with an AI-powered Security Advisor? By leveraging Retrieval-Augmented Generation (RAG), we can build a system that crawls the latest official security standards and provides actionable, real-time remediation advice.

Reactive Mode

User provisions non-compliant resource → Security Hub flags it → Security team investigates → Manually notifies resource owner → Owner remediates (eventually)

Proactive Mode

User asks chatbot “how should I configure my S3 bucket securely?” → RAG retrieves exact CIS / PCI DSS controls → User gets actionable guidance before provisioning

The Solution: A RAG-Powered Security Advisor Chatbot
Build an internal security advisor chatbot powered by Retrieval-Augmented Generation (RAG) using AWS Bedrock Knowledge Bases. The system ingests official AWS security standard documentation, indexes it in a vector store, and answers natural language questions from developers with grounded, citation-backed responses.

The core premise: instead of security standards living in PDFs that no one reads, they become a queryable, conversational knowledge layer that any developer can access in seconds — directly integrated into their existing workflow.

Architecture Overview
🕸Data Sources

Web Crawler pulling CIS Benchmarks, PCI DSS controls, and AWS FSBP documentation from official URLs

🧠Bedrock Knowledge Base

Managed RAG service handling chunking, embedding generation, and retrieval orchestration

🔍OpenSearch Serverless

Vector store for semantic search — scales automatically, no cluster management overhead

💬Claude on Bedrock

Foundation model for response generation — grounded in retrieved context, not hallucinations

🛡️Security Hub

Posture score baseline — the north star metric our chatbot helps improve over time

👤Developer Interface

Chat UI exposed to development teams — internal Slack bot, portal, or CLI wrapper

Building the Knowledge Base in AWS Bedrock
AWS Bedrock Knowledge Bases is a managed service that abstracts the heavy lifting of a RAG pipeline — document ingestion, chunking strategy, embedding model selection, vector store integration, and retrieval. For our use case, it was the natural choice because we needed production-grade reliability without building custom orchestration.

(a) Create Knowledge Base with vector store

(b) Choose “Web Crawler” as data source

(c ) Enter below URL’s as source URL’s

AWS Foundational Security Best Practices standard in Security Hub CSPM
Learn about the AWS Foundational Security Best Practices standard and the applicable security controls in AWS Security…
docs.aws.amazon.com

CIS AWS Foundations Benchmark in Security Hub CSPM
The Center for Internet Security (CIS) AWS Foundations Benchmark serves as a set of security configuration best…
docs.aws.amazon.com

PCI DSS in Security Hub CSPM
AWS Security Hub CSPM supports v.3.2.1 and v4.0.1 of the Payment Card Industry Data Security Standard (PCI DSS). You…
docs.aws.amazon.com

(d) Continue with default selections for Sync scope, Parsing and chunking

(e) Choose “Amazon Titan Text Embeddingsv2” model as Embedding model

(f) Select quick vector store creation

(g) Wait for Knowledge Base and Vector database creation to complete

(h) Once Knowledge Base is created, select the data source and click on sync which will populate the OpenSearch serverless collection(vector database) with embeddings

Vector Store: OpenSearch Serverless
For a production-grade RAG system, a serverless vector database is ideal. It handles the indexing of high-dimensional embeddings without the overhead of managing clusters.

Collection Type: Vector Search.
Logic: When the web crawler ingests data, it breaks the text into chunks, converts them into vectors (using a model like Titan Text Embeddings), and stores them in OSS.
I chose OpenSearch Serverless over the other supported vector stores (Pinecone, Redis Enterprise, Aurora PostgreSQL) for a specific reason: it’s native AWS, supports IAM-based access control, integrates seamlessly with VPC endpoint policies, and removes the operational overhead of managing an OpenSearch cluster entirely.

Why serverless over provisioned OpenSearch?
A knowledge base for internal developer queries has a spiky, unpredictable query pattern — zero traffic at night, bursts during working hours and incident response. Serverless OCUs (OpenSearch Compute Units) scale to zero and burst automatically, making it significantly more cost-efficient for this use case than a provisioned domain with fixed shard capacity.

Important: Bedrock Knowledge Bases requires the OpenSearch Serverless collection to be of type vector search, not time series or search. Set this at collection creation — it cannot be changed later.

Data Ingestion: Web Crawler for Security Standards
The choice of data source is what makes this system genuinely authoritative. Rather than uploading stale PDFs, we pointed the Bedrock web crawler at official, continuously-maintained documentation URLs.

URLs ingested: CIS AWS Foundations Benchmark,PCI DSS v4.0 Requirements, AWS FSBP Controls, AWS Security Hub Docs

Web crawler ingestion means our knowledge base stays current when AWS updates control documentation or when PCI DSS guidance is revised — we just re-run the sync job, no manual uploads needed.

The crawler handles pagination automatically, and Bedrock's sync job can be scheduled or triggered via EventBridge for freshness.

Test the Knowledge Base
Perform a test whether Knowledge Base(RAG) delivers answers as expected based on the security standard recommendations before integrating with your Chatbot app

Example:

Query: “What’s the Security Hub posture score impact if I leave port 22 open to 0.0.0.0/0 on my security group?”

Response : Unrestricted SSH access (0.0.0.0/0 on port 22) violates EC2.19 in AWS FSBP and CIS control 5.2. Security Hub assigns this a HIGH severity finding. It will negatively impact your overall posture score, especially within the Network Security category. Restrict inbound SSH to known IP ranges using your VPN CIDR, or use AWS Systems Manager Session Manager to eliminate the need for SSH entirely.

The RAG Pipeline in Action When a developer asks a question, here’s what happens end-to-end — in under 3 seconds:

1.User query arrives

“What are the CIS benchmark requirements for S3 bucket encryption?”

↓

2.Query embedding

Bedrock embeds the query using Titan Embeddings v2, producing a 1536-dim vector representation of the semantic intent.

↓

3.Vector retrieval from OpenSearch Serverless

Approximate nearest-neighbor search retrieves the top-K most semantically similar chunks from the indexed security standards. K=5 by default, tunable.

↓

4.Augmented prompt construction

Retrieved chunks are injected into a structured prompt alongside the user query. Source URLs are preserved for citation.

↓

5.Response generation via Claude on Bedrock

The foundation model generates a grounded, structured response citing specific control IDs — never fabricating controls that don’t exist in the retrieved context.

Key configuration decisions
When creating the Knowledge Base, we made the following choices that significantly impacted retrieval quality:

1.Embedding model: Amazon Titan Embeddings v2

Optimized for English technical documentation. Produces 1536-dimensional dense vectors. Good semantic fidelity for regulatory and standards language.

↓

Chunking strategy:

Automatically splits text into chunks of 300 tokens in size

↓

Vector store: OpenSearch Serverless collection

Created a dedicated vector search collection type. Bedrock auto-creates the index schema and handles sync.

↓

4.Retrieval: Hybrid search (semantic + keyword)

Combining dense vector search with BM25 keyword matching improves recall for specific control IDs like “CIS 2.1.2” or “PCI DSS Req 6.4”.

The choice of data source is what makes this system genuinely authoritative. Rather than uploading stale PDFs, we pointed the Bedrock web crawler at official, continuously-maintained documentation URLs.

Web crawler ingestion means our knowledge base stays current when AWS updates control documentation or when PCI DSS guidance is revised — we just re-run the sync job, no manual uploads needed.

Implementation Architecture
The flow works as follows:

Frontend: A Slack bot, Microsoft Teams app, or a simple Streamlit web UI.
API Layer: Amazon API Gateway triggers a Lambda function.
Logic Layer: AWS Lambda calls the Bedrock RetrieveAndGenerateAPI.
Data Layer: Bedrock queries OpenSearch Serverless and generates a response using a model like Claude or Amazon Nova

Conclusion
Security posture improvement doesn’t have to be a reactive, ticket-driven grind. By treating security standards as a living knowledge base — queryable, conversational, and always current — you can shift security left and make best practices the path of least resistance for your development teams.

AWS Bedrock Knowledge Bases, OpenSearch Serverless, and web crawler ingestion make this remarkably accessible to build. The hardest part isn’t the technology — it’s getting developers to use the chatbot instead of guessing. Make it fast, make it actionable, and make it available where they already work.

"How are you currently handling security remediation in your organization? Have you experimented with RAG for internal documentation yet? Let’s discuss in the comments!"

Beyond RAG: Why Google’s Agentic Data Cloud is the Future of Cloud Security

Lingesh B — Fri, 24 Apr 2026 17:40:49 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

If you are a Cloud Security Architect, you have a different set of concerns when evaluating an AI pipeline: Where does sensitive data land? Who—or what—controls access to it? Can an AI agent be tricked into leaking a policy document? And critically, can you audit every retrieval decision for an auditor?

I have spent the last year building a production RAG-powered internal security advisor on AWS using Bedrock. But after watching the keynotes at Google Cloud NEXT '26, it is clear that we are moving past the "static RAG" era. We are entering the Agentic Era.

Here is why Google’s new Agentic Data Cloud isn't just an update—it is the architectural blueprint for the future of secure, autonomous enterprise intelligence.

The Evolution: From Static Pipelines to Ambient Intelligence

My current AWS-based architecture served us well, but it highlighted a chronic issue: operational inertia. Every time our internal security standards or AWS Foundational Security Best Practices (FSBP) updated, we had to trigger manual sync jobs, manage chunking strategies, and fight against "flat" vector retrieval limitations.

Google Cloud NEXT '26 fundamentally changes this narrative with the Agentic Data Cloud

1. Ambient Ingestion via Knowledge Catalog

The standout announcement is the Knowledge Catalog. In my AWS implementation, ingestion was a discrete, manual step. Google’s approach is ambient: the moment a document lands in GCS, it is instantly enriched, indexed, and made agent-ready by Gemini.

For a security architect, this shifts the focus from pipeline maintenance to policy governance. By offloading the "data engineering" of RAG to the platform, we can focus on the critical security layer: defining granular data boundary controls for what the Knowledge Catalog is permitted to index.

2. GraphRAG: The Missing Link for Compliance

Security controls aren't flat—they are a dependency graph. PCI DSS requirement 10.2.1 relates to logging, which links back to identity controls and data protection standards.

Standard vector similarity often misses these implicit relationships. BigQuery Graph— GCP's native implementation of GraphRAG is the architectural answer I’ve been looking for. It allows agents to traverse the logic of a control framework natively, surfacing how a public-facing workload impacts multiple control families. This is a massive leap forward in making AI "security-aware" by default.

3. The Cross-Cloud Lakehouse: The Security Dream

Multi-cloud is the reality of the financial services sector. Until now, querying security findings across AWS, Azure, and GCP required complex ETL or expensive third-party tools. The Cross-Cloud Lakehouse removes the need to move data, reducing the attack surface by eliminating egress and duplicate storage.

This is the platform-level solution to a problem that usually haunts Security Architects: Governance at the speed of query

While AWS provides a battle-tested foundation for today, Google Cloud NEXT '26 has effectively set the roadmap for the next decade.

AWS provides the baseline, but Google is solving the structural limitations of RAG. By integrating GraphRAG and ambient intelligence natively into the data layer, Google is transforming AI from a "query tool" into an "autonomous partner."

My Recommendation for Security Architects

If you are building today, do not wait. The goal is to move beyond the limitations of manual, flat-vector retrieval.

If you are GCP-native: Lean into the Agentic Data Cloud previews immediately. The transition from manual pipelines to ambient knowledge ingestion will drastically reduce your operational overhead.
If you are multi-cloud: Use the Cross-Cloud Lakehouse as your strategic anchor. It represents the future of federated security posture management.
The "Auditor" Test: Regardless of the platform, the primary security boundary is now the Agent Gateway. As you move to Agentic workflows, focus your design on how this gateway logs, monitors, and enforces trust between the Agent and the data it consumes.

The Agentic Enterprise is no longer theoretical—it is here. The question for us as Security Architects is no longer if we build these pipelines, but how we govern the autonomous intelligence that will soon be making security decisions on our behalf.

Google’s vision of ambient, graph-aware, cross-cloud intelligence isn't just a set of new services—it is the architectural roadmap for the next generation of cloud security.

Are you ready to see how your current security controls would map to a graph-augmented architecture?

I’m happy to discuss how we might bridge the gap between static compliance documents and agentic retrieval

Enforcing Zero Trust: VPC Encryption Controls Explained

Lingesh B — Sat, 27 Dec 2025 16:06:20 +0000

You don’t do it with spreadsheets; you do it with VPC Flow Logs. By leveraging the new ${encryption-status} field and VPC Encryption Controls, you can audit, verify, and enforce hardware-level encryption across your entire infrastructure with a single click.

VPC Encryption Controls is a security and compliance feature introduced by AWS to provide centralized visibility and authoritative control over the encryption of data moving within and between your Virtual Private Clouds.

Historically, verifying that all “east-west” traffic (traffic between your internal instances, load balancers, and databases) was encrypted was a manual and complex task, often involving messy spreadsheets and custom auditing scripts. This feature automates that process by leveraging the AWS Nitro System hardware and application-layer metadata.

The Two Core Modes

To help you reach a fully encrypted state without breaking your existing applications, the feature operates in two phases:

Key Capabilities

Detailed Auditing: Adds a new ${encryption-status} field to VPC Flow Logs, showing you at a glance if traffic is encrypted via Nitro hardware (1), application-level TLS (2), both (3), or not at all (0).
Resource Identification: Provides a “To-Do” list in the AWS Console of specific resources (like older EC2 instances or HTTP listeners) that are preventing you from reaching an enforced security posture.
Seamless Upgrades: Automatically migrates managed infrastructure like Application Load Balancers (ALB) and Fargate tasks to Nitro-based hardware to ensure they meet encryption standards transparently.
Compliance Ready: Simplifies the proof required for regulatory frameworks like HIPAA , PCI DSS , and FedRAMP by providing an authoritative dashboard of encryption status.

Why use it?

If your organization follows a Zero Trust architecture, you can no longer assume that internal traffic is “safe” just because it’s inside the VPC. VPC Encryption Controls allow you to verify and mandate that every single packet is encrypted, providing a critical layer of defense-in-depth against internal threats or misconfigurations.

In this demo, I have created a VPC with below resources

Architecture diagram:

My application(static website) has four EC2 instances(webservers) behind an Application load balancer

Created VPC Encryption control in “Monitor” mode to first audit the encryption status of resources in my VPC

In simple terms, Monitor Mode is like a security camera for your network. It watches all the data moving around your VPC and takes notes on whether that data is “scrambled” (encrypted) or “plain text” (unencrypted).

Crucially, it does not block or change anything. Your website and apps will keep running exactly as they are while it gathers information

Below resources have been flagged as resources accepting unencrypted traffic

Internet Gateway

You can configure specific exclusions for resources such as internet gateways or NAT gateways, that don’t support encryption (because the traffic flows outside of the AWS network).

Elastic Network interfaces include the four EC2 instances(t2.micro) and NAT Gateway

Moving to a Fully Encrypted VPC(Enforce mode)

Once you have identified unencrypted resources in Monitor Mode , you can begin migrating them to a secure state. Depending on the service type, this process is either automatic or requires a manual upgrade.

1. Automatic Migration (No Action Required)

Certain managed services will handle the transition for you. AWS will transparently move the underlying infrastructure to Nitro hardware — which provides automatic encryption — with zero service interruption :

Application Load Balancers (ALB)
Network Load Balancers (NLB)
AWS Fargate Tasks

2. Manual Migration (Action Required)

For resources that you manage directly, such as Amazon EC2 instances , you must take one of the following steps to achieve encryption compliance:

Upgrade Hardware: Switch from older, legacy instances (like t2 or m4) to modern Nitro-based types (like t3, m5, c6g, etc.).
Encrypt the App: If you cannot upgrade the hardware, you must configure TLS/SSL encryption (HTTPS) manually at the application level.

I created custom VPC flow logs to capture the encryption status

Sent traffic to my Webservers via Application Load Balancer( Note that I am accessing ALB using http and not https )

Then, I checked my VPC flow logs to identify the encryption status

Encryption Status Code:

For EC2 instances running on t2.micro instance type, the encryption status field is 0 meaning no hardware level or app level encryption was detected

After manual migration to Nitro based instance type, those instances also got removed from the unencrypted resources list and only the remaining two instances(t2.micro) are flagged

IMPORTANT CATCH:

🛑 The “Port 80” Catch: Why isn’t my ALB flagged?

If you are running an Application Load Balancer (ALB) on Port 80 , you might be surprised to see it missing from the “Unencrypted Resources” list. It feels like a security hole, but it’s actually due to a “silent upgrade” AWS performs for you.

1. The Transparent Nitro Migration

When you enable Monitor Mode , AWS identifies that the ALB is a managed service. It then automatically and transparently migrates the ALB’s underlying infrastructure to Nitro hardware.

Because Nitro-based hardware has a dedicated security chip that scrambles data at the physical network layer, the ALB is now capable of hardware encryption. In the eyes of VPC Encryption Controls, it is no longer a “blocker” to security — even if your application is still using Port 80.

2. Status 1: The “Invisible” Internal Shield

Even if you haven’t set up an SSL certificate yet, the traffic moving inside your VPC (from the ALB to a modern EC2 instance) is often automatically encrypted by the Nitro chips on both ends.

What you’ll see in logs: An encryption-status of 1.
What it means: Your internal “East-West” traffic is protected by hardware-level AES-256 encryption, even over an unencrypted protocol like HTTP.

3. The “False Sense of Security” Warning

This is the most important part : VPC Encryption Controls only track the journey inside the VPC.

Inside the VPC (ALB → EC2): Safe (Status 1).
Outside the VPC (User → ALB): UNSAFE.

If a user sends a password to your ALB on Port 80 over the public internet, that password is sent in plain text. It only gets “scrambled” by Nitro hardware after it reaches the ALB. To truly be secure, you must still move to Port 443 (HTTPS) to protect the data during its journey across the internet.

The reason Internet Gateways (IGW) and NAT Gateways are flagged while your ALB is not comes down to one thing: The Destination of the Data.

1. The “Off-Ramp” Problem

VPC Encryption Controls are designed to ensure data is encrypted within the AWS network.

The ALB sends data to another resource inside your VPC (like an EC2 instance). Because both ends are inside AWS, AWS can use Nitro hardware to scramble that data.
Gateways are different. Their entire purpose is to send data outside your VPC to the public internet.

Once data leaves through an IGW or NAT Gateway, AWS no longer owns the “wires” it travels on. AWS cannot force the rest of the internet to use Nitro hardware encryption. Therefore, these gateways are marked as Unencrypted because they are essentially “leaks” where protected data turns into unprotected public data.

2. Physical vs. Logical Limitations

ALB/Fargate: These are “Software-Defined” managed services. AWS can simply update the “code” they run on to include Nitro capabilities. That’s why they are automatically moved to the “Encrypted” list.
Gateways: These are architectural “edge” points. A NAT Gateway is a middleman. If you send it unencrypted data from an EC2 instance, it must pass that unencrypted data out to the internet. It cannot “Nitro-encrypt” a packet that is destined for a Google or Netflix server.

3. They are “Blockers” by Design

In your dashboard, “Unencrypted Resources” really means “Things that will stop you from enabling Enforce Mode.” If you tried to turn on Enforce Mode without addressing these gateways, AWS would have to drop all your internet traffic to stay “compliant” with your security policy.

To fix this, AWS doesn’t expect you to “encrypt” the gateway. Instead, you must Exclude them

The 3-Step Process:

Monitor (Watch): Turn on Monitor Mode to find out resources that allow unencrypted traffic.
Fix (Upgrade): For resources, such as the previous generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, you will need to switch to modern Nitro based instance types or configure TLS encryption at application level.
Enforce (Lock): Once the monitor shows everything is green, you flip the switch to “Enforce Mode,” which will block any future unencrypted traffic from even starting.

AWS Config + SSM: Automated AMI Governance

Lingesh B — Sun, 30 Nov 2025 18:42:57 +0000

In the dynamic world of cloud infrastructure, security and compliance are paramount. One of the simplest, yet most critical, security mistakes is launching an EC2 instance from an unapproved or vulnerable Amazon Machine Image (AMI).

This not only introduces security risks (like unpatched software or misconfigurations) but also immediately causes compliance drift. The solution? Don’t just detect the drift — automatically terminate it using the power of AWS Config Rules and Systems Manager Automation.

This post walks through a robust, automated pattern to enforce your AMI governance policy in real-time.

The Problem: Unapproved AMIs are a Security Sinkhole

Every AMI used in your environment should be approved, patched, and hardened. When developers or tools bypass these approved golden images and launch instances using random public AMIs (or old, stale custom AMIs), they open the door to threats like:

Known Vulnerabilities: Older AMIs likely lack critical patches.
Malware/Backdoors: Unknown public AMIs can be compromised.
Misconfiguration: Images may not adhere to your organizational security baseline.

Our goal is to create a safety net that catches these non-compliant launches instantly and performs an immediate, decisive action.

Step 1: The Detective Control — AWS Config Rule

The first line of defense is a detective control. Use an AWS Config rule to continuously evaluate every newly launched EC2 instance against a predefined standard.

🔎 The Key Config Rule: approved-amis-by-id

AWS provides managed rules for common checks. The rule used here is the approved-amis-by-id rule

Define the Standard: You supply the Config rule with a list of approved AMI IDs for your Region (e.g., ami-12345, ami-54321).
Continuous Evaluation: When a new EC2 instance is launched, the Config service checks the AMI ID against your approved list.
Flag Non-Compliance: If the instance’s AMI ID is not on the approved list, the Config rule flags the resource’s compliance status as NON_COMPLIANT.

Here, I have mentioned “ami-0fa3fe0fa7920f68e” id as my approved AMI. You can pass your authentic AMI id’s in the parameters section

I launched an EC2 instance with AMI “ami-069e612f612be3a2b”

As expected, the config rule has marked this EC2 instance as non-compliant

Step 2: The Proactive Control — Automated Remediation

Detection alone is not enough; we need enforcement. We use AWS Systems Manager (SSM) Automation as the remediation engine linked directly to our Config rule.

🔨 Linking Config to Systems Manager

When setting up the approved-amis-by-id Config rule, you associate it with an SSM Automation Document. This document defines the steps to take when a resource becomes non-compliant.

Define the Action: The simplest and most decisive action is aws:terminateinstances.
Input Parameter: The Config rule provides the Non-Compliant Resource ID (the EC2 instance ID) as an input parameter to the SSM Automation document.
Execution: Upon receiving the non-compliant signal, the SSM Automation Document executes the termination command against the offending EC2 instance.

Select “Manage Remediation” on the config rule

Choose “Automatic remediation” and optionally modify the values for retry attempts and time window

Many pre-built EC2 actions(SSM documents) are available. For this example, I opted for “Terminate EC2 instances” action. You can decide and choose the appropriate action you want to implement for non-compliant EC2 instances

Next, create a role with “Systems Manager” as the trusted entity and below permissions policy

Pass the ARN of the role created and save the configuration

You can wait for the auto-remediation to kick-in or if you want to test quickly in interest of time, click on “Remediate”

Non-Compliant EC2 instance has been terminated by the automated action

A Note on Time and Security

This automated termination occurs within minutes of the instance being launched and flagged. By immediately removing the non-compliant resource, you:

Minimize the “blast radius” of a potential security vulnerability.
Ensure compliance status is instantly restored.
Provide immediate feedback to the developer or service that launched the non-compliant resource.

Best Practices for Deployment

To make this pattern effective and operationally safe, consider the following:

Staging/Testing: Deploy this setup in a non-production (e.g., Development) environment in Monitor Mode first to test the detection accuracy before enabling automated remediation.
Alerting and Notification: Configure Amazon SNS or AWS Chatbot to receive alerts whenever an instance is terminated by this automation. This provides necessary visibility and audit trails.

By pairing AWS Config for detection with Systems Manager for remediation, you move beyond mere auditing and establish a self-healing, compliant infrastructure that enforces security standards without human intervention.

AWS Security Hub vs Security Hub CSPM: Partners in Protecting Your Cloud Journey

Lingesh B — Sat, 08 Nov 2025 19:17:44 +0000

AWS Security Hub and Security Hub CSPM are closely related, but they play distinct roles in AWS security strategy.

What is AWS Security Hub?

AWS Security Hub is a unified cloud security platform. Its primary role is to aggregate, correlate, and prioritize security findings from various AWS services — such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie — as well as select third-party providers. Security Hub provides a comprehensive dashboard where security teams can view exposures, automate responses, and track remediation status across their AWS accounts.

Key Features of AWS Security Hub:

Centralized findings aggregation (from sources like GuardDuty, Inspector, CSPM, etc.)
Automated response orchestration via EventBridge
Attack path correlation and prioritized risk analysis
Unified dashboard with actionable insights
Uses OCSF (Open Cybersecurity Schema Framework) for standardized findings

What is Security Hub CSPM?

Security Hub CSPM stands for Cloud Security Posture Management. It focuses specifically on evaluating cloud resource configurations against best practices and compliance frameworks such as CIS, PCI DSS, or NIST. CSPM functionality runs automated, continuous checks to identify misconfigurations, policy violations, and compliance risks.

Key Features of Security Hub CSPM:

Automated posture and compliance checks (FSBP, CIS, PCI DSS, NIST, etc.)
Continuous cloud resource monitoring
Security scoring and detailed compliance reporting
Uses AWS Security Finding Format (ASFF)
Seamlessly integrates with Security Hub for unified operations

How Are They Different?

How Do They Work Together?

Think of Security Hub as the dashboard that sees everything. CSPM is the engine running compliance and configuration checks in the background. When you enable CSPM, its findings — such as misconfigured S3 buckets, permissive security groups, or non-compliant IAM policies — are fed into Security Hub, where they’re surfaced, correlated with other risks, and prioritized for response.

Security Hub enables workflows and automation (via EventBridge, Lambda, or external tools) so security teams can address exposures rapidly, track remediation, and demonstrate compliance.

When Should You Use Each Service?

Enable CSPM if you need continuous compliance monitoring, resource configuration checks, or detailed reports for frameworks like CIS, PCI DSS, or NIST.
Enable Security Hub if you want a single pane of glass, automated response workflows, and correlation across all your AWS security services.

Best Practice: Most organizations should enable both. CSPM ensures your AWS environment adheres to security best practices, while Security Hub gives you the operational control and visibility to manage real-world cloud security risks.

Summary

AWS Security Hub is the centralized cloud security analytics and response platform.
Security Hub CSPM is the posture management and compliance checking core.
Together, they deliver complete visibility, automated compliance, and actionable insights.

By understanding these differences and how the solutions complement each other, you can build a robust, automated, and scalable cloud security strategy that delivers real-world protection and compliance.

Meet Your New Dev Partner: The Amazon Q CLI Agent (and Our Windows Game!)

Lingesh B — Fri, 23 May 2025 18:14:55 +0000

Introducing Amazon Q: AWS’s AI Assistant

In the rapidly evolving landscape of cloud computing and development tools, Amazon Web Services has introduced Amazon Q,

an AI assistant designed specifically to enhance productivity for developers, cloud practitioners, and AWS users.

Amazon Q serves as your knowledgeable companion for navigating the AWS ecosystem, writing and debugging code, managing

infrastructure, and implementing best practices. Unlike general-purpose AI assistants, Amazon Q specializes in technical

tasks with direct access to your working environment.

What sets Amazon Q apart is its ability to interact directly with your system — executing bash commands, reading and

writing files, making AWS CLI calls, and providing contextual recommendations based on your specific environment.

Whether you’re troubleshooting deployment issues, optimizing resource usage, or accelerating development workflows,

Amazon Q brings AWS expertise directly to your command line.

Use Cases:

Amazon Q can assist with below activities

• **AWS Services**

• Provide guidance on AWS service selection and configuration

• Explain AWS concepts and best practices

• Troubleshoot AWS service issues

• **Code Assistance**

• Write, modify, and debug code

• Review and optimize existing code

• Generate code examples for various programming languages

• Help with unit tests and test frameworks

• **System Operations**

• Execute bash commands on your Linux system

• Read and write files on your filesystem

• List directory contents and navigate your file structure

• **AWS CLI Integration**

• Make AWS CLI calls to manage resources

• Query AWS resources and services

• Help automate AWS operations

• **Infrastructure Management**

• Assist with infrastructure as code (CloudFormation, CDK, Terraform)

• Optimize resource configurations

• Implement security best practices

• **Troubleshooting**

• Debug application errors

• Analyze logs and error messages

• Suggest solutions for common issues

**Development Workflows**

• Automate repetitive tasks

• Improve development processes

• Suggest tools and approaches for specific problems

Installing Amazon Q CLI on Windows:

Native windows installation is not available yet, so we will use Windows Subsystem for Linux(wsl) to install Amazon Q CLI in Windows machine

Step 1:

Run command wsl — install on your windows terminal

Step 2:

Run command wsl -d ubuntu

This will download and install a virtual ubuntu instance on youe wsl environment. You will also be prompted to setup unix user account credentials

Step 3:

Default directory in wsl account points to your windows home directory. Run cd to change your directory path

Run command sudo apt install unzip

Download the installer using command

curl — proto ‘=https’ — tlsv1.2 -sSf https://desktop-release.codewhisperer.us-east-1.amazonaws.com/latest/q-x86_64-linux-musl.zip -o q.zip

Step 4:

Run unzip q.zip to unzip the archive

Step 5:

After unzipping the archive, you will find the directory named q. Switch to q directory and execute the install.sh script

Step 6:

After successful installation, you can interact with Amazon Q

Type q chat

Here, I have prompted it to create a simple 2d game. You can ask it to create a game of your choice

Amazon Q starts building the game using python pygame library

To quit the Amazon Q CLI environment, type /q

Step 7:

Now, I see there is file named simple_game.py created in my home directory.

Run python3 simple_game.py and you will see the game window pop-up

Note: In case, you do not have pip already installed, execute the below commands to install pip

sudo apt-get update

sudo apt-get install python3-pip

To explore additional functions, I have prompted Amazon Q to create and execute a bash script to display system metrics

Amazon Q CLI successfully created and executed the script to give me the below system metrics report

Amazon Q CLI proves to be a versatile and powerful tool that extends far beyond basic AWS interactions. Throughout this blog, we’ve

explored its diverse capabilities — from assisting with everyday development tasks to creating engaging applications like our 2D

game, and even helping with system administration through custom bash scripts for monitoring system metrics. The straightforward

installation process on Windows makes it accessible to developers working in any environment.

What makes Amazon Q CLI particularly valuable is its ability to serve as both a productivity enhancer and a creative tool. Whether

you’re writing scripts to monitor system performance, developing games, or managing AWS resources, Amazon Q CLI provides contextual,

intelligent assistance that adapts to your needs. Its natural language understanding and code-aware capabilities make it an

indispensable companion for developers, DevOps engineers, and system administrators alike.

As we’ve demonstrated through practical examples, Amazon Q CLI isn’t just another command-line tool — it’s an AI-powered assistant

that understands your development environment, helps solve complex problems, and accelerates your workflow. As AWS continues to

enhance its capabilities, Amazon Q CLI will undoubtedly become an even more essential tool in every developer’s toolkit.

Start exploring Amazon Q CLI today, and discover how it can transform your development experience and boost your productivity.

Code-Free AI Magic: Build an image classification model with AWS SageMaker Canvas

Lingesh B — Sat, 19 Apr 2025 12:35:08 +0000

What is SageMaker Canvas?

Amazon SageMaker Canvas empowers you to transform data at petabyte-scale, and build, evaluate, and deploy production-ready machine learning (ML) models without coding. It streamlines the end-to-end ML lifecycle in a unified and secure enterprise environment.

With SageMaker Canvas, you can accelerate innovation and more quickly solve business problems by democratizing ML development across all skill levels and regardless of coding expertise.

Benefits of SageMaker Canvas:

Amazon SageMaker Canvas offers a compelling suite of benefits that democratize machine learning, making it accessible to a wider range of users without requiring coding expertise. Here are some key advantages:

1. No-Code Machine Learning:

Intuitive Visual Interface: SageMaker Canvas provides a user-friendly, point-and-click interface, eliminating the need to write any code for the entire ML lifecycle.
Simplified Workflow: It streamlines the process of data preparation, model building, training, evaluation, and deployment into an easy-to-follow visual workflow.

2. Accessibility for Business Users:

Empowers Non-Technical Teams: Business analysts, domain experts, and other users without deep ML knowledge can build and deploy models, directly addressing their specific business problems.
Bridging the Gap: It reduces the reliance on data scientists and engineers for initial model development and exploration.

3. Accelerated Model Building:

Automated Model Selection (AutoML): Canvas automatically analyzes your data and tests various machine learning algorithms to identify the best-performing models for your specific prediction task.
Rapid Experimentation: The no-code environment allows for quick iteration and experimentation with different data and model configurations.

4. Enhanced Collaboration and Governance:

Seamless Integration with SageMaker Studio: Models built in Canvas can be easily shared with data scientists in SageMaker Studio for further customization and advanced analysis.
Transparency and Explainability: Canvas provides insights into model performance and offers explanations of predictions, fostering trust and understanding.
Model Registry Integration: Models can be registered in the SageMaker Model Registry for governance, version control, and MLOps best practices.
Collaboration Features: Facilitates collaboration across teams through model sharing and integration with other AWS services like Amazon DataZone and Amazon QuickSight.

5. End-to-End ML Lifecycle Support:

Data Preparation: Easily connect to various data sources, visualize data, and perform data transformations without coding.
Model Building & Training: Automatically build and train models using AutoML capabilities.
Model Evaluation: Assess model performance with intuitive visualizations and metrics.
Deployment: Deploy models for real-time or batch predictions with just a few clicks.
Monitoring (via integration with other services): While Canvas itself is no-code, the deployed models can be monitored using other AWS services.

6. Cost-Effective:

Democratization of ML: Reduces the need for large teams of specialized data scientists for every ML task.
Efficiency Gains: Speeds up the model development and deployment process, leading to faster time-to-value.

In essence, SageMaker Canvas empowers a broader audience to harness the power of machine learning to solve business problems, explore data-driven insights, and innovate more quickly, all within a user-friendly, no-code environment

Demo:

In this demo, lets use SageMaker Canvas to build,train and deploy an image classification(dogs & cats) model without any code in just few clicks

Step 1:Create a SageMaker domain

Navigate to SageMaker AI service in AWS console and click on ‘Create a SageMaker domain’

Opt for ‘Quick setup’ for demo purpose

Once domain is ready, you can view it in ‘Domains’ section

Step 2: Open Canvas

Click on ‘My Models’

Click on ‘Create new model’

Name the model as you wish and choose ‘Image analysis’ under problem type

Step 3: Create an image dataset

Data is the lifeblood that fuels machine learning models, enabling them to learn patterns, make predictions, and drive intelligent decisions.

Kaggle is a very popular platform for data scientists and machine learning practitioners. It hosts a vast collection of datasets uploaded by the community, ranging in size and complexity.

For this demo, I have downloaded the below dataset which has labelled images of cats and dogs

Dataset consists of two folders. One folder has images for training and other folder has images for testing the model

Create a training dataset

Upload the dog images folder

Upload the cat images folder

Wait for the dataset to be ready

Step 4: Build model

As you can see below, label distribution among data is even. We have 200 dog images and 200 cat images as part of training data

Click on ‘Quick build’

It takes around 15–30 minutes for the model to be ready

Once the model is ready, you can view and analyze the training results

Step 5: Make model predictions with new data for validation

SageMaker Canvas offers two options, one for single prediction and other for batch prediction

We will go for the batch prediction and create a test dataset

From the already downloaded dataset, open the ‘test’ folder and upload 70 dog images and 70 cat images which will form the test dataset

Once test dataset is ready, click on ‘Generate Predictions’

View and analyze the prediction results

Step 5: Deploy the model

If the prediction results are satisfactory, proceed with the model deployment. You can deploy your model to SageMaker AI hosting services and get an endpoint that can be used for inference. These endpoints are fully managed and support autoscaling.

To send an inference request to a model, you invoke the endpoint that hosts it. You can invoke your endpoints using Amazon SageMaker Studio, the AWS SDKs, or the AWS CLI

And there you have it! You’ve successfully built, trained, and deployed your very own image classification model to distinguish between cats and dogs — all without writing a single line of code, thanks to the intuitive power of Amazon SageMaker Canvas.

This is just the beginning of what you can achieve with visual AI. Imagine classifying different types of flowers, identifying objects in your home, or even analyzing product quality. SageMaker Canvas opens up a world of possibilities, empowering anyone to harness the power of machine learning for image understanding. So go ahead, explore your image data and unleash your inner AI visionary!

Building a Secure AWS Foundation: A Step-by-Step Guide to setup Landing Zone with AWS Control Tower

Lingesh B — Sun, 19 Jan 2025 12:00:54 +0000

Introduction

Cloud computing offers incredible flexibility and scalability, but managing a multi-account AWS environment can quickly become complex. This is where AWS Control Tower comes in. This powerful service helps you establish and govern a secure and compliant foundation for your AWS workloads — a crucial step known as setting up a “Landing Zone.”

This blog will provide a user-friendly guide to understanding AWS Control Tower and walking you through the process of setting up a secure landing zone.

What is AWS Control Tower?

Imagine Control Tower as a skilled architect and construction crew for your AWS environment. It automates the building and management of a secure and compliant foundation, ensuring your AWS workloads operate efficiently and securely.

Here’s a breakdown:

Automated Setup: Control Tower automates the deployment of core AWS security and operational best practices. This includes setting up accounts, configuring networks, and implementing security controls.
Centralized Governance: It provides a central point of control for managing and governing your entire AWS environment, making it easier to enforce policies and maintain consistency.
Simplified Compliance: Control Tower helps you meet industry standards and regulations (like PCI DSS, ISO 27001) by enforcing security best practices and automating compliance checks.
Enhanced Security: It incorporates built-in security guardrails that prevent common misconfigurations and help you maintain a high level of security.

What is an AWS Landing Zone?

Think of your AWS Landing Zone as the secure and well-architected foundation for your entire AWS environment. It’s where you deploy and operate your applications and services. A well-defined landing zone includes:

Account Structure: A well-organized structure for your AWS accounts, separating development, test, and production environments for better security and control.
Network Configuration: A secure and scalable network architecture (using Virtual Private Clouds — VPCs) to isolate and protect your workloads.
Identity and Access Management (IAM): Robust IAM policies and roles to control access to AWS resources and ensure only authorized users can perform specific actions.
Security Best Practices: Implementation of key security measures like encryption, logging, and intrusion detection.

Setting Up Your AWS Landing Zone with Control Tower: A Step-by-Step Guide

Log into your AWS account which you want to use as Management account with Administrator or Root access and open AWS Control Tower console

Step 1: Review pricing and select Region

I have chosen North Virginia as my home region

I have selected Singapore as my additional region for governance. You can choose your regions based on your environment and requirements

Below setting allows you to prevent users from launching resources in other regions to meet company’s compliance and regulatory requirements. I have not enabled it.

Step 2: Configure Organizational units(OU’s)

I have created an additional OU named ‘Applications’

Step 3: Configure shared accounts

I opted to create new accounts as Audit and Log archive accounts instead of using existing accounts

Step 4: Additional configurations

I opted for self managed access since I already had an existing IAM Identity Center setup

Step 5: Review

Four IAM roles are created in the process of setting up a Landing zone by Control Tower

It takes around 60 minutes for Landing Zone creation

Once Landing Zone is created, below dashboard will be available

In Organization tab of Control Tower, you can check the baseline state and create/register new OU’s and enroll new accounts

Account factory: Create new accounts

Centrally enable and manage Controls:

Key Benefits of Using Control Tower for Landing Zone Setup:

Increased Security: Enhances your security posture by enforcing security best practices and preventing common misconfigurations.
Improved Compliance: Helps you meet industry regulations and maintain compliance standards.
Enhanced Efficiency: Automates many manual tasks, saving you time and resources.
Simplified Management: Provides a centralized platform for managing and governing your AWS environment.
Reduced Risk: Minimizes the risk of security breaches and data loss.

Conclusion

AWS Control Tower is a powerful tool that simplifies the process of building and managing a secure and compliant AWS environment. By following the steps outlined in this guide, you can establish a robust foundation for your AWS workloads and accelerate your cloud journey.

I hope this user-friendly guide has provided you with a clear understanding of AWS Control Tower and the process of setting up a secure landing zone.

Optimizing AWS Costs: Setup Cost & Usage Dashboard in 5 minutes

Lingesh B — Fri, 27 Sep 2024 15:54:51 +0000

In the cloud-native era, managing costs is as critical as leveraging the benefits of cloud services. AWS provides a robust tool, the Cost and Usage Dashboard, to help you track and analyze your cloud spending. It offers a comprehensive view of your costs across different services, regions, and time periods.

Track and analyze your cloud spending: Monitor your costs over time and identify areas for optimization.
Understand your usage patterns: Gain insights into how different services are being used and identify potential cost-saving opportunities.
Compare costs across different time periods: Compare your current spending to past trends and identify areas where costs have increased or decreased.
Export data: Export your cost data to CSV format for further analysis in external tools.

AWS Data Exports:

AWS Data Exports enables you to create exports of your billing and cost management data, such as cost and usage or cost optimization recommendations, using basic SQL delivered to your designated S3 bucket on a recurring basis for use with your business intelligence or third-party reporting solutions.

AWS Data Exports also enables you to visualize your billing and cost management data by integrating with Amazon QuickSight, and deploying a pre-built Cost and Usage Dashboard within minutes.

Setup Cost and Usage Dashboard powered by QuickSight:

Pre-requisite:

Configuration:

In AWS Management account, open ‘Billing and Cost Management’ and click on ‘Data Exports’

Click on ‘Cost and Usage Dashboard’

Choose export type option as ‘Cost and usage dashboard powered by QuickSight’

Enter QuickSight username of already configured QuickSight account

Enter a destination in Amazon S3 where your data export will be stored

Choose ‘Create a new service role’ under service access and click ‘Create’

Data Export has created the dashboard successfully and is ready to be accessed

Click on ‘Cost and usage Dashboard’ link and you will be directed to QuickSight dashboard

Initially, there will be no data as it takes around 24 hours for data to be populated in dashboard

After 24 hours, you will find your billing data for your AWS Organization(accounts) in the dashboard and data under different categories can be explored

Sample dashboard : https://cid.workshops.aws.dev/demo?dashboard=cudos

AWS Cost and Usage Dashboard (CUR) offers several advantages for managing your cloud spending:

Comprehensive Visibility:

Detailed cost breakdown: See your costs broken down by service, region, and time period.
Usage patterns: Understand how different services are being used and identify potential cost-saving opportunities.
Historical data: Analyze past spending trends to identify areas for improvement.

Cost Optimization:

Identify cost-saving opportunities: Find areas where you can reduce costs by optimizing usage or choosing more cost-effective options.
Compare costs across different time periods: Compare your current spending to past trends and identify areas where costs have increased or decreased.

Data-Driven Decision Making:

Export data: Export your cost data to CSV format for further analysis in external tools.
Create custom reports: Create custom reports to analyze your spending based on your specific needs.
Make informed decisions: Use data-driven insights to make informed decisions about your cloud spending.

Improved Efficiency:

Avoid overspending: Prevent unnecessary costs by understanding your usage patterns and making informed decisions.

Compliance and Governance:

Track spending against budgets: Monitor your spending against predefined budgets.
Ensure compliance: Ensure compliance with internal or external spending guidelines.
Provide evidence: Provide evidence of cost management practices to auditors or stakeholders.

By setting up data exports from the AWS Cost and Usage Dashboard, you can gain deeper insights into your cloud spending and make informed decisions to optimize your costs. With the flexibility to export data to S3 and analyze it using various tools, you can tailor your analysis to your specific needs and achieve significant cost savings.

Unleash the Power of the Organizational View in AWS Health : Real-Time Alerts to Your Inbox

Lingesh B — Sat, 24 Aug 2024 09:55:42 +0000

Unleash the Power of the Organizational View in AWS Health : Real-Time Alerts to Your Inbox

AWS Health is a service that provides real-time visibility into the health of your AWS services, accounts, and resources. It helps you:

Stay informed about service disruptions and maintenance activities.
Monitor the health of your AWS resources.
Receive alerts and notifications for potential issues.
Proactively manage your AWS environment.

AWS Health provides an organizational view that allows you to monitor the health of your entire AWS Organization.

Aggregate your Health events from all member AWS accounts in your AWS organization. This provides a centralized view for all events, such as operational issues, scheduled maintenance, and account notifications.

Key features of the organizational view in AWS Health:

Centralized dashboard: Provides a single view of the health status of all accounts and resources within your organization.
Account health: Displays the health status of each account in your organization, resources and account activity.
Health events: Provides information about service disruptions, maintenance activities, and other relevant events.
Alerts and notifications: Allows you to configure alerts and notifications for health events at the organization level.

Enabling Organizational view:

Setup an AWS Organization: If you don’t already have one, create an AWS Organization using the AWS Organizations console. Invite or create accounts to join your organization.
Enable organizational view for AWS Health : After setting up AWS Organization, sign into the Management account and enable AWS Health to aggregate all events.

Delegated Administrator for Organizational view (Optional): You can register a member account in your AWS organization, which provides the flexibility for different teams to view and manage health events across your organization.

To establish a delegated administrator, from the management account in your organization, call the following AWS Command Line Interface (AWS CLI) command. You can use this command from the management account. In the following example command, replace ACCOUNT_ID with the member account ID that you want to register along with the AWS Health service principal “health.amazonaws.com”.

“aws organizations register-delegated-administrator — account-id ACCOUNT_ID — service-principal health.amazonaws.com”

Here, I have made one of my member accounts as the Delegated Administrator for the Organizational view of AWS Health dashboard

Now, you can have a centralized view of all health events across accounts in your Organization

Get mail notification for Health events in your Organization:

Use Management account or Delegated Administrator account where Organizational view for Health is enabled

Create a SNS topic with mail subscription

Create an EventBridge rule with event pattern as Health and target as SNS topic created in previous step

With this setup, you will receive mail notification for any health event in your Organization.

Benefits of organizational view in AWS Health:

Proactively monitor the health of your entire AWS Organization.
Identify and address potential issues across multiple accounts.
Ensure consistent health standards across your organization.
Improve service availability and reliability.
Enhance security and compliance.

By effectively using the organizational view in AWS Health, you can ensure the overall health and reliability of your AWS Organization, helping you achieve your business objectives and avoid unnecessary downtime.

Stop Hackers at the Door: Auto-Remediate Open Ports in AWS

Lingesh B — Sat, 18 May 2024 14:07:43 +0000

Let’s face it, managing security in the cloud can be a constant battle. Developers and AWS users, can knowingly/unknowingly leave sensitive ports like SSH (22),RDP (3389) or MySQL (port 3306) open to the public (0.0.0.0/0) in a security group. This creates a security nightmare, leaving your resources vulnerable to attackers.

Traditionally, we relied on SecurityHub to identify these misconfigurations. The process involved manually reviewing findings and then adjusting ingress rules. But what if there was a way to automate this entire process?

Enter AWS Config with auto-remediation: a powerful tool to streamline security management and keep your cloud environment safe.

AWS Config to the Rescue

Here’s how AWS Config with auto-remediation tackles the challenge of open ports:

Continuous Monitoring: The pre-built AWS Managed Config rule “vpc-sg-open-only-to-authorized-ports” constantly monitors your security groups. It acts like a vigilant guard, scanning for any ingress rules allowing unrestricted traffic on sensitive ports.
Non-Compliance Flag: If Config identifies a security group with unrestricted access to these ports, it raises a red flag. This flags the security group as “non-compliant,” highlighting a potential security risk.
Auto-Remediation (Optional): This is where things get exciting. You can configure auto-remediation to take immediate action. Upon detecting a non-compliant security group, Config can automatically close it, effectively shutting the door on potential attackers. This eliminates the need for manual intervention, ensuring a faster and more efficient response to security threats.

Implementation Steps:

(a) Enable AWS Config in the respective regions of your AWS accounts

(b) Add AWS Managed Config rule ‘vpc-sg-open-only-to-authorized-ports’

This rule ‘Checks if security groups allowing unrestricted incoming traffic (‘0.0.0.0/0’ or ‘::/0’) only allow inbound TCP or UDP connections on authorized ports. The rule is NON_COMPLIANT if such security groups do not have ports specified in the rule parameters’

You can also optionally define the list of TCP/UDP ports authorized to be open to public in the ‘Parameters’ section

© For the purpose of demo, I created a security group with ports 22,3389 and 443 exposed to public(0.0.0.0/0). Config rule evaluates and identifies non-compliant security groups. As expected, it identified the below security group created for demo purpose because it has sensitive ports SSH(22) and RDP(3389) open to public

(d) Choose ‘Automatic remediation’ and select ‘AWS-DisablePublicAccessForSecurityGroup’ as the remediation action

Note: ‘AWS-DisablePublicAccessForSecurityGroup’ remediation action works only for SSH and RDP ports exposed.

For automated remediation on other sensitive ports, refer step (g)

(e) Select ‘GroupId’ from the dropdown list of Resource ID parameter.

IpAddressToBlock = 0.0.0.0/0. You can mention other ip addresses as well that you want to block as per your requirement

For ‘AutomationAssumeRole’ mandatory parameter, create a role with ‘Systems Manager’ as the trusted entity and use below permission policy

Click ‘Save Changes’ to complete the setup of remediation action

(f) Auto-remediation kicks in and removes only the ingress rules which allowed SSH(22) and RDP(3389) from the security group leaving the other ingress rule for port https(443) intact.

Before Auto-remediation:

After Auto-remediation:

(g) Choose ‘AWS-CloseSecurityGroup’ as the remediation action when you want to automate the remediation on any of the sensitive ports including (MySQL,MSSQL,PostgreSQL etc) exposed to public. This remediation action removes all ingress and egress rules from the non-compliant security group.

Benefits of Auto-Remediation

Faster Threat Response: Auto-remediation acts swiftly, closing the security gap before attackers can exploit it. This proactive approach minimizes potential damage.
Reduced Manual Work: Gone are the days of manually sifting through SecurityHub findings and meticulously adjusting ingress rules. Config automates the entire process, freeing up your valuable time.
Enhanced Security Posture: By proactively identifying and closing vulnerabilities, you create a more robust security environment for your cloud resources. This gives you peace of mind knowing your infrastructure is less susceptible to attacks.

A Word on Flexibility

While auto-remediation offers a powerful solution, it’s important to consider your specific needs. Perhaps some open ports require temporary public access for troubleshooting purposes. In such cases, leveraging Config for identification and then taking manual action for specific security groups might be preferable.

Conclusion

AWS Config with auto-remediation is a game-changer for cloud security. By automating the identification and remediation of open ports, you can significantly enhance your security posture and free yourself from tedious manual tasks. Remember, security is an ongoing process. Stay vigilant, leverage AWS tools like Config, and keep your cloud environment safe and secure!