Forem: nash9

VPC Part 2 : AWS Site-to-Site VPN (On-Prem Simulation)

nash9 — Fri, 26 Dec 2025 15:23:20 +0000

Connecting an "on-premise" network to an AWS VPC is the most common real-world enterprise scenario.However, you cannot use VPC Peering for this. In the real world,you use AWS Site-to-Site VPN or AWS Direct Connect.

Peering is for AWS-to-AWS only.
VPN is for Anything-to-AWS. You use it to connect your home office, a physical data center, or even a different cloud provider (like Azure or Google Cloud) to your AWS VPC.

The Concept

VPC-A (The Cloud): Uses an AWS Virtual Private Gateway (VGW).
VPC-B (The On-Premise): Uses an EC2 instance running strongSwan (an open-source VPN software) to act as your "Corporate Firewall/Router." This is called a Customer Gateway (CGW).
Using static routing or BGP (Border Gateway Protocol), you create a secure IPsec VPN tunnel between the two gateways over the public internet.

1. Cost Analysis (Still < $2)

Site-to-Site VPN Connection: ~$0.05 per hour.
EC2 (t3.micro): ~$0.01 per hour.
Public IP: ~$0.005 per hour.

Total: If you run this for 2 hours, it will cost roughly $0.15 - $0.20.

2. The Terraform Strategy

To simulate this, we need to:

Create VPC-A (Cloud) and VPC-B (On-Prem).
In VPC-A, create a Virtual Private Gateway (VGW).
In VPC-B, create an EC2 instance. This instance needs an Elastic IP.
Tell AWS that the "Customer Gateway" is the Public IP of that EC2 instance.
Create the VPN Connection.
Update Route Tables in both VPCs to allow traffic flow.
Route Propagation: Unlike Peering, where you manually add routes, in a VPN setup you can enable "Route Propagation." This allows the VGW to automatically tell the VPC about the on-prem routes it learns via BGP (Border Gateway Protocol).
Encryption (IPsec): This project teaches you that traffic between on-prem and AWS is encrypted in transit over the public internet, unlike Peering which stays on the private AWS backbone.
The "Customer Gateway" Concept: You learn that AWS doesn't "reach out" to on-prem; you have to define the entry point (CGW) and establish a tunnel.
Security Groups / NACLs: You will have to allow UDP Port 500 and UDP Port 4500 (ISAKMP/IPsec) for the tunnel to even start.

Project Agenda:

Apply Terraform: Run terraform apply.
Get the Config: Go to AWS Console > VPC > Site-to-Site VPN Connections. Select your new connection and click Download Configuration.Select Vendor: Generic.
Find the Tunnel Info: Open the text file. Look for Tunnel 1. You will see an Outside IP Address (AWS side) and a Pre-Shared Key.
Prepare the Bash Script: sample bash script(refer bash.sh file) to configure strongSwan on your On-Prem EC2 instance. Replace the placeholders with the actual values from the text file.
Run Bash Script: SSH into your "OnPrem-Router" EC2. Paste the bash script above, replacing the placeholders with the data from the text file.
Check Status: In the AWS Console, the VPN Tunnel 1 status should change from Down to Up (Green) after about 1-2 minutes.
Test connection. If it works, congratulations! You have successfully connected your on-prem network to your AWS VPC using Site-to-Site VPN.

Cost Management Checklist

VPN Connection: $0.05/hour.(Deleted immediately after testing).
EC2 t3.micro: $0.01/hour.
Public IP: $0.005/hour per IP.
Total: If you finish this in 2 hours, you will spend roughly $0.25.

Steps to Run the Project and make VPN UP
Note: Amazon Linux 2023 (AL2023) uses dnf and recommends Libreswan instead of strongSwan. Once you can finally connect to your instance, run this script.

Download Config :
Go to AWS Console > VPN > Site-to-Site VPN > Download Configuration. Select Vendor: Generic.
Get Tunnel 1 Data: Find the Pre-Shared Key and the Virtual Private Gateway IP (called "Outside IP").

Run this on the On-Prem EC2 :

Install VPN software
sudo dnf install libreswan -y
Enable IP Forwarding (Essential for a Router)
sudo sysctl -w net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
Create the Secrets file (Replace placeholders)
##Format: <OnPrem_Public_IP> <AWS_VPN_Outside_IP> : PSK "<Your_Pre_Shared_Key>" sudo vi /etc/ipsec.d/aws.secrets
Create the Tunnel config
sudo vi /etc/ipsec.d/aws.conf

Paste this into aws.conf (Replace the bracketed IPs):

conn tunnel1 authby=secret auto=start left=%defaultroute leftid=[YOUR_ONPREM_EIP_PUBLIC_IP] leftsubnet=192.168.0.0/16 right=[AWS_TUNNEL_OUTSIDE_IP] rightsubnet=10.10.0.0/16 ike=aes128-sha1;modp2048 phase2alg=aes128-sha1;modp2048 keyexchange=ike ikev2=no type=tunnel

run the following commands to restart strongSwan and bring up the tunnel:
sudo systemctl restart ipsec sudo ipsec auto --add tunnel1 sudo ipsec auto --up tunnel1

Finally, start the service:

sudo systemctl start ipsec sudo systemctl enable ipsec sudo ipsec status # Check if "tunnel1" is loaded

Testing

From your On-Prem EC2, try to ping a private EC2 in the Cloud VPC (10.10.x.x).
You should see replies if everything is set up correctly!

Learning Outcome : You will finally understand how packets know where to go when they leave a private subnet. You'll see how the "Virtual Private Gateway" handles the cloud side and how a "Customer Gateway" handles the on-prem side.

VPC Part 1 : AWS VPC Peering

nash9 — Fri, 26 Dec 2025 15:23:04 +0000

The "Mergers & Acquisitions" Scenario (VPC Peering)

Description

This project demonstrates how to set up VPC Peering between two Virtual Private Clouds (VPCs) in a cloud environment. VPC Peering allows resources in different VPCs to communicate with each other as if they were within the same network.This project simulates two different companies (or departments) needing to share resources.

Goal to achieve :

Create VPC-A (10.1.0.0/16) and VPC-B (10.2.0.0/16).
Deploy an EC2 in each.
Set up a VPC Peering Connection.
Update Route Tables in both VPCs to point to the other’s CIDR. Challenge: Try to peer VPC-A with a VPC-C that has an overlapping CIDR (10.1.0.0/16) and see why it fails. _ Test connectivity by pinging between the EC2 instances in both VPCs._

Concepts You’ll Learn:
Peering Connections: Request/Accept workflow.
Transitive Routing: Learning that VPC Peering is not transitive (If A peers with B, and B with C, A cannot talk to C).
Overlapping CIDRs: The importance of IP planning.

Prerequisites

AWS CLI installed and configured.
Terraform installed.
Basic understanding of VPCs, subnets, and networking concepts.
An AWS account with necessary permissions.
Two VPCs created in the same or different regions.
Instances or resources deployed in each VPC for testing connectivity.
Familiarity with security groups and route tables.
Permissions to create and manage VPCs and peering connections.

Project Structure

├── README.md
├──terraform
│   ├── variables.tf
│   ├── outputs.tf
│   └── provider.tf
│   ├── ec2.tf
│   ├── security_group.tf
│   ├── vpc_peering.tf
│   ├── vpc_A.tf
│   └── vpc_B.tf

Steps to Set Up VPC Peering

Create VPCs: Set up two separate VPCs in your cloud environment.
Configure Subnets: Create subnets within each VPC to host your resources.
Set Up VPC Peering:
- Initiate a VPC peering connection request from one VPC to the other.
- Accept the peering request in the target VPC.
Update Route Tables: Modify the route tables in both VPCs to allow traffic to flow between them.
Configure Security Groups: Adjust security group rules to permit traffic between resources in the peered VPCs.
Test Connectivity: Launch instances in both VPCs and verify that they can communicate with each other.

VPC peering terraform will look like this:
`resource "aws_vpc_peering_connection" "peer" {
vpc_id = aws_vpc.vpc_a.id
peer_vpc_id = aws_vpc.vpc_b.id
auto_accept = true

tags = {
Name = "VPC-A-to-VPC-B"
Project = var.project_name
}
}
resource "aws_route" "route_a_to_b" {
route_table_id = aws_route_table.rt_a.id
destination_cidr_block = aws_vpc.vpc_b.cidr_block
vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
}
resource "aws_route" "route_b_to_a" {
route_table_id = aws_route_table.rt_b.id
destination_cidr_block = aws_vpc.vpc_a.cidr_block
vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
}`

or simply run the following commands in the terraform directory:

cd terraform(your infra code directory)
terraform init
terraform plan(just see what will be created)
terraform apply --auto-approve (always verfiy the plan before applying in production)
terraform destroy --auto-approve (to clean up the resources)

Conclusion

By following these steps, you can successfully set up VPC Peering between two VPCs, enabling seamless communication between resources in different networks. This setup is useful for various scenarios, including multi-region architectures and resource sharing across different environments.

Critical Learning Points

The Peering Handshake: In this code, we used auto_accept = true. In real life, if peering with another AWS account, they must manually "Accept" the request.
Route Tables: Peering creates the "tunnel," but without the aws_route resource, the VPC doesn't know to send traffic through that tunnel.
Security Groups: Notice we allowed "All Traffic." In a real project, you should only allow the Private CIDR of the other VPC.

Additional Resources

Building a Scalable RAG System for Repository Intelligence

nash9 — Sun, 21 Dec 2025 11:27:32 +0000

# 🧠 CodeSense AI: Building a Scalable RAG System for Repository Intelligence

The Problem: Navigating large, unfamiliar codebases is slow.

The Solution: CodeSense AI—a sophisticated RAG (Retrieval-Augmented Generation) engine that lets you "talk" to your code using AWS Bedrock and Pinecone.

📖 Overview

CodeSense AI isn't just a chatbot; it's a semantic code navigator. Most code search tools rely on keyword matching (Grepping). CodeSense AI uses Vector Embeddings to understand the intent and logic behind your code.

Core Value Props:

Instant Architecture Mapping: Ask "How does the auth flow work?" and get a cross-file explanation.
Contextual Debugging: Share an error and find exactly where that logic resides in a 100-file repo.
Seamless Ingestion: Point to a GitHub URL, and the pipeline handles the rest—from cloning to vectorization.

🛠️ The Modern AI Stack

The Frontend (The User Experience)

React 18.3 & TypeScript: A type-safe foundation for handling complex UI states during long indexing processes.
Tailwind CSS & shadcn/ui: For a high-fidelity, developer-centric aesthetic.
TanStack Query: Manages the server state for real-time indexing progress updates.

The Intelligence (The Reasoning)

AWS Bedrock (Amazon Titan Text Express): Chosen for its high-throughput, low-latency reasoning capabilities.
Titan Embeddings v2: Generates 1024-dimensional vectors, optimized for technical documentation and source code.
Pinecone: A serverless vector database that provides sub-100ms similarity search using Cosine Similarity.

🏗️ Architecture & System Design

High-Level Design (HLD)

The architecture follows a Decoupled Proxy Pattern. To ensure maximum security, the frontend never communicates directly with AWS or Pinecone.

Low-Level Design (LLD)

1. The Code-Aware Indexing Pipeline

Standard text chunking fails for code because it breaks logical blocks. CodeSense AI implements a Sliding Window Chunking strategy:

Chunk Size: 1000 characters.
Overlap: 200 characters (ensures variable declarations aren't cut off from their usage).
Metadata Enrichment: Every vector is tagged with its filePath, repoOwner, and lineRange to ensure the AI can cite its sources.

2. Secure Edge Orchestration

Using Supabase Edge Functions as an orchestration layer allows us to implement AWS Signature V4.

// Example: The signature-v4 process ensures your AWS_SECRET_KEY 
// never leaves the server-side environment.
const headers = await signRequest(
  'POST', 
  bedrockUrl, 
  requestBody, 
  Deno.env.get('AWS_ACCESS_KEY_ID'),
  Deno.env.get('AWS_SECRET_ACCESS_KEY')
);

3. Multi-Tenant Vector Isolation

To prevent data leakage between repositories, we utilize Pinecone Namespaces. Each repository is assigned a unique namespace derived from its GitHub path.

Query Filtering: namespace: "zumerlab-zumerbox"
Security: No user can query code outside of their current repository context.

🚀 Data Flow: The Lifecycle of a Query

Input: User types: "Where is the database connection initialized?"
Vectorization: The query is converted into a 1024-dim vector using AWS Bedrock.
Retrieval: Pinecone identifies the Top-5 most relevant code chunks within that specific repo's namespace.
Augmentation: The system builds a prompt: > "System: You are an expert. Context: [Snippet 1], [Snippet 2]. Question: Where is the database...?"
Generation: Titan Express synthesizes the context and generates a markdown-formatted answer.

Lovable UI

Pinecone UI

⚙️ Engineering Setup

Environment Prerequisites

AWS Bedrock Model Access: Ensure amazon.titan-text-express-v1 and amazon.titan-embed-text-v2:0 are enabled.
Pinecone Index: 1024 dimensions, Cosine metric.

Pinecone Index Setup
Create a new index in Pinecone Console
Set dimensions to 1024 (Titan Embed v2 output)
Use cosine similarity metric
Note the index URL for configuration

AWS Bedrock Setup

Enable Amazon Bedrock in your AWS account
Request access to: preferred model (Chat)
Create IAM credentials with Bedrock access

Development Prerequisites

Node.js 18+ and npm (Used Lovable for building UI)
Supabase project (or Lovable Cloud)

Edge Function Secrets

supabase secrets set AWS_ACCESS_KEY_ID=xxx
supabase secrets set AWS_SECRET_ACCESS_KEY=xxx
supabase secrets set PINECONE_API_KEY=xxx
supabase secrets set PINECONE_INDEX_URL=https://your-index.svc.pinecone.io

🔐 Security Standards

JWT-Locked APIs: All Edge Functions require a valid Supabase Auth header.
Secret Management: Zero hardcoded keys. No client-side exposure.
Rate Limiting: Implemented at the Edge Function layer to protect AWS Bedrock quotas.

📈 Future Roadmap

Language Support: Expanding AST-based parsing for better semantic chunking.
Multi-Repo Chat: Aggregating context across microservices.
Local LLM Support: Integrating Ollama for on-premise deployments.

Building an "Unstoppable" Serverless Payment System on AWS (Circuit Breaker Pattern)

nash9 — Sat, 13 Dec 2025 10:30:38 +0000

Building an "Unstoppable" Serverless Payment System on AWS

What happens when your payment gateway goes down? In a traditional app, the user sees a spinner, then a "500 Server Error," and you lose the sale.
I wanted to build a system that refuses to crash. Even if the backend database is on fire, the user's order should be accepted, queued, and processed automatically when the system heals.

Here is how I implemented the Circuit Breaker Pattern using AWS Step Functions, Java Lambda, and Event-Driven Architecture—without provisioning a single server.

The Tech Stack

I chose a hybrid, cloud-native stack to enforce strict decoupling between the Frontend and the Backend.

Frontend: Python (Streamlit) – Acts as the Store & Admin Dashboard.
Orchestration: AWS Step Functions – The "Brain" handling the logic.
Compute: AWS Lambda (Java 11) – The "Worker" handling business logic.
State Store: Amazon DynamoDB – Stores circuit status (Open/Closed) and Order History.
Resiliency: Amazon SQS – The "Parking Lot" for failed orders.
Observability: Grafana Cloud (Loki) – Log aggregation.
Infrastructure: Terraform – Complete IaC.

Note : Use terraform to manage resources ,best practice to keep all your resources terraform in separate file for creation/deletion/any kind of update.

The Problem: Cascading Failures

In microservices, if Service A calls Service B, and Service B hangs, Service A eventually hangs too. If thousands of users click "Pay," your database gets hammered with retries, effectively DDoS-ing yourself.
The Solution? A Circuit Breaker.
Just like in your house: if there is a surge, the breaker trips to save the house from burning down.

High Level Architecture:

I designed the system to handle three distinct states:

Green Path (Closed): The backend is healthy. Orders process immediately.
Red Path (Open): The backend is crashing. The system detects this, "Trips" the circuit, and stops sending traffic to the backend.
Yellow Path (Recovery): Orders are routed to a Queue (SQS) to be retried later automatically.

HLD may look scary but it is will make your app unstoppable.

How It Works The Logic Flow :

The core of this project is an AWS Step Functions State Machine. It acts as a traffic controller.

The Check Every time a user clicks "Pay," the workflow first checks DynamoDB. Is the Circuit Status OPEN? If YES: Skip the backend entirely. If NO: Proceed to the Java Lambda.
The Execution The workflow invokes a Java Lambda to process the payment. Success: It updates the Order History to COMPLETED and emits an event to EventBridge (triggering a customer email via SNS). Failure: It catches the error and retries with Exponential Backoff (Wait 1s, then 2s). 3.** The "Trip"** If the backend fails repeatedly, the Step Function: Writes Status: OPEN to DynamoDB. Alerts the SysAdmin via SNS ("Critical: Circuit Tripped"). Marks the order as FAILED in the dashboard.
The Self-Healing (Auto-Retry) This is the coolest part. If the circuit is Open, new orders are not rejected. They are marked as QUEUED and sent to Amazon SQS. A "Retry Handler" Lambda listens to this queue. It waits for a delay (e.g., 30s).It re-submits the order to the Step Function.If the backend is fixed, the order processes. If not, it goes back to the queue.

Tested Data Scenarios:

SUCCESS
CHAOS Mode

Observability & Monitoring: I integrated Grafana Cloud (Loki) to ingest logs from CloudWatch.
Streamlit Dashboard: Shows live status of orders (PENDING → COMPLETED or FAILED).
Grafana Explore: Allows deep searching of logs using {service="order-processor"} to find specific stack traces.

Key Learnings & Trade-offs

Complexity vs. Reliability This architecture is more complex than a simple API call. You have more moving parts (Queues, State Machines). However, the trade-off is High Availability. The frontend never sees a crash.
The "Ghost" Data When using Catch blocks in Step Functions, the original input (Order ID) is replaced by the Error Message. I learned to use ResultPath to preserve the original data so I could update the database even after a crash.
Cost Optimization Step Functions Standard Workflows are expensive at scale. For production, I would switch this to Express Workflows and use ARM64 (Graviton) for the Lambdas to reduce costs by ~40%.

Application looks like:

Order placing UI reference
Admin UI

Conclusion
This project demonstrates how Event-Driven Architecture allows you to build systems that degrade gracefully. Instead of losing revenue during a crash, we simply "pause" the traffic and process it when the storm passes.
Technologies used: AWS, Java, Python, Terraform, Grafana.

Follow for more. Thanks for reading !

Supabase with PowerBI Dashboard

nash9 — Thu, 11 Dec 2025 14:54:14 +0000

Real-Time Sales & Inventory Dashboard

A full-stack Business Intelligence demo integrating Supabase (PostgreSQL) as the cloud backend and Microsoft Power BI for frontend data visualization. This project demonstrates how to track sales revenue and monitor inventory levels in real-time.

Project Overview

Backend: Supabase (PostgreSQL) hosted on AWS.
Frontend: Microsoft Power BI Desktop.
Goal: Visualize sales trends, category performance, and low-stock alerts using cloud data.

Tech Stack

Supabase - Open Source Firebase alternative (PostgreSQL Database).
Power BI Desktop - Data Visualization Tool.

Setup Instructions

Part 1: Supabase Setup (Backend)

Create a new project on Supabase.
Navigate to the SQL Editor in the left sidebar.
Run the following SQL script to create the schema and seed dummy data: Run schema.sql in SQL editor.

-- 1. Create Tables
CREATE TABLE public.products (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    category TEXT NOT NULL,
    unit_price DECIMAL(10, 2) NOT NULL,
    stock_quantity INT NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

CREATE TABLE public.orders (
    id SERIAL PRIMARY KEY,
    product_id INT REFERENCES public.products(id),
    quantity INT NOT NULL,
    total_amount DECIMAL(10, 2) NOT NULL,
    order_date DATE NOT NULL DEFAULT CURRENT_DATE
);

-- 2. Insert Dummy Data
INSERT INTO public.products (name, category, unit_price, stock_quantity)
VALUES 
    ('Wireless Mouse', 'Electronics', 25.50, 150),
    ('Mechanical Keyboard', 'Electronics', 85.00, 40),
    ('Gaming Monitor', 'Electronics', 300.00, 15),
    ('Ergonomic Chair', 'Furniture', 150.00, 10),
    ('Desk Lamp', 'Furniture', 45.00, 80),
    ('USB-C Cable', 'Accessories', 12.00, 200);

INSERT INTO public.orders (product_id, quantity, total_amount, order_date)
VALUES 
    (1, 2, 51.00, CURRENT_DATE - INTERVAL '3 days'),
    (2, 1, 85.00, CURRENT_DATE - INTERVAL '3 days'),
    (1, 1, 25.50, CURRENT_DATE - INTERVAL '2 days'),
    (3, 1, 300.00, CURRENT_DATE - INTERVAL '2 days'),
    (5, 4, 180.00, CURRENT_DATE - INTERVAL '1 day'),
    (4, 1, 150.00, CURRENT_DATE),
    (6, 10, 120.00, CURRENT_DATE);

Part 2: Power BI Connection (Frontend)

To connect Power BI to Supabase, you must use the Connection Pooler (IPv4) to avoid connectivity issues. Get Credentials: Go to Supabase > Project Settings > Database.
Enable "Use connection pooling". Set Mode to "Session".
Copy the Host (e.g., aws-0-us-east-1.pooler.supabase.com) and User.
Connect in Power BI: Get Data > PostgreSQL database. Server: Paste the Pooler Host URL. Database: postgres. Data Connectivity Mode: Import. Auth: Use Database authentication (User/Password).

Dashboard Visuals :

KPI Card: Displays Total Sales Revenue (Sum of total_amount).
Pie Chart: Sales distribution by Category (Electronics vs. Furniture).
Table: A specific list for Low Stock Alerts (Items with stock_quantity < 20).

Troubleshooting : (I have faced this issue ,fix and error details added)

"The remote certificate is invalid" Error Supabase uses SSL, and Power BI may reject the certificate by default. Fix: Go to File > Options and settings > Data source settings. Select the data source, click Edit Permissions, and uncheck "Encrypt connections". "Host not found" Ensure you are using the Pooler URL (port 5432 or 6543) found in Supabase Database settings, not the direct connection string.

Thanks for reading !!!

AWS Bedrock with LangChain

nash9 — Thu, 11 Dec 2025 14:44:45 +0000

Demo AWS Bedrock Integration with LangChain , Streamlit ,Titan model along with docker setup (Free tier)
To demonstrates how to integrate AWS Bedrock with LangChain and Streamlit using the Titan model with docker setup .

Prerequisites/Project Structure

requirements.txt
Docker file
AWS config local setup '=/.aws/config' and credentials '/.aws/credentials'
AWS Bedrock access

Code base

Main Python file:

import streamlit as st
import boto3
from botocore.exceptions import ClientError
from langchain_aws import ChatBedrock
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

st.set_page_config(page_title=" AWS Bedrock Docker", layout="wide")

st.title("🐳 AWS Bedrock + Docker + LangChain + Streamlit")
st.caption("Connected to AWS Region: `ap-south-1` via local AWS Config")
# ------------------------------------------------------------------
try:
    boto_session = boto3.Session()
    if not boto_session.get_credentials():
        st.error("❌ No AWS Credentials found. Did you mount ~/.aws in docker-compose?")
        st.stop()

    st.sidebar.success(f"AWS Profile Loaded: {boto_session.profile_name or 'default'}")

except Exception as e:
    st.error(f"AWS Config Error: {e}")
    st.stop()

model_id = st.sidebar.selectbox(
    "Select Model",
    ["anthropic.claude-3-sonnet-20240229-v1:0", "anthropic.claude-v2:1", "amazon.titan-text-express-v1"]
)

llm = ChatBedrock(
    model_id=model_id,
    region_name="ap-south-1",
    model_kwargs={"temperature": 0.5, "max_tokens": 512}
)

#----------------------------------------------
user_input = st.text_area("Enter your prompt:", "Explain how Docker containers work in 3 sentences.")

if st.button("Generate Response"):
    if not user_input:
        st.warning("Please enter a prompt.")
    else:
        try:
            with st.spinner("Calling AWS Bedrock API..."):
                prompt = ChatPromptTemplate.from_messages([
                    ("system", "You are a helpful AI assistant."),
                    ("user", "{input}")
                ])
                output_parser = StrOutputParser()

                chain = prompt | llm | output_parser

                response = chain.invoke({"input": user_input})

                st.subheader("AI Response:")
                st.write(response)

        except ClientError as e:
            st.error(f"AWS API Error: {e}")
            if "AccessDenied" in str(e):
                st.warning("👉 Hint: Did you enable this specific Model ID in the AWS Console > Bedrock > Model Access?")
        except Exception as e:
            st.error(f"An unexpected error occurred: {e}")

Docker file :

FROM python:3.11-slim
LABEL authors="naush"

WORKDIR /chatgpt-bedrock-langchain-demo
COPY requirements.txt .
RUN pip install --upgrade pip && pip install torch --index-url https://download.pytorch.org/whl/cpu && pip install -r requirements.txt
COPY main.py .
EXPOSE 8090
CMD ["streamlit","run","main.py"]

Requirements File

streamlit
boto3
langchain-aws
langchain-community
langchain-core

Setup Instructions
Clone the repository:

git clone or create new repo :
cd repository_name or
create folder and paste above files (main.py , requirements.txt,docker )
Install the required packages:
pip install -r requirements.txt or
do run this command
pip install streamlit boto3 langchain-aws langchain-community langchain-core
Configure your AWS credentials:
Make sure your AWS credentials are set up in ~/.aws/credentials and ~/.aws/config.
Run the Streamlit app:
streamlit run app.py
Open your browser and navigate to http://localhost:8501 to access the url Streamlit app.
Docker Setup To run the application using Docker, follow these steps: Build the Docker image:
bash docker build -t bedrock-langchain-streamlit . Run the Docker container: bash docker run -p 8501:8501 bedrock-langchain-streamlit Open your browser and navigate to http://localhost:8501 to access the Streamlit app running in the Docker container.

Enter your input in the Streamlit app interface and interact with the Titan model powered by AWS Bedrock.

Monolith app to Cloud-Native (Re-platforming)

nash9 — Thu, 11 Dec 2025 14:15:58 +0000

Overview

This project demonstrates the migration of an on-premise Java Spring Boot application to AWS using a "Replatforming" strategy. The application is containerized using Docker and deployed to Amazon ECS (Fargate) for serverless compute, utilizing Amazon RDS for managed persistence.

Problem Statement
An on-premise Java Spring Boot application with a MySQL database needs to be migrated to AWS to leverage cloud scalability, reliability, and managed services while minimising operational overhead.

Migration Strategy: Replatforming
Replatforming involves moving the application to a new platform with minimal changes to the application code.

App: Java Spring Boot "Customer Management Service."
Hosting: Running on a physical Linux server (or VM) using java -jar app.jar.
Database: Local MySQL instance installed on the same server.
Issues: Scaling is hard (manual hardware upgrades), single point of failure (if the server dies, the app dies), maintenance overhead (patching OS).

Goals & Objectives:

Containerize the existing Java Spring Boot application using Docker.
Deploy the containerized application to AWS using ECS Fargate.
Use Amazon RDS for the MySQL database to offload database management tasks.
Implement Infrastructure as Code (IaC) using Terraform for reproducible deployments.
Set up a CI/CD pipeline for automated deployments using GitHub Actions (or AWS CodePipeline).
Ensure security best practices, including network isolation and secrets management.
Optimize for cost and performance.
Document the architecture and decisions made during the migration.
Provide clear instructions for running the application locally and deploying to AWS.
Include monitoring and logging for operational visibility.
Facilitate easy rollback and updates through deployment strategies.
Ensure high availability and fault tolerance in the deployed architecture.
Leverage AWS managed services to reduce operational overhead.
Promote best practices in cloud architecture and DevOps.
Create a modular and reusable Terraform codebase for future projects.

🏗 Architecture

Pattern: Microservices-ready Containerization on Serverless Infrastructure.

Traffic Flow: Internet -> Application Load Balancer (Public Subnet) -> ECS Fargate Tasks (Private Subnet).
Data Flow: ECS Tasks -> RDS MySQL (Private Subnet).
Security:
Database is strictly isolated in private subnets.
Security Groups act as a virtual firewall (App SG -> DB SG on port 3306).
Secrets managed via Environment Variables (in prod, use AWS Parameter Store).
By this , we achieve : >>>>

Application Load Balancer (ALB) (HTTPS/443).
ALB distributes traffic across ECS Tasks (Docker containers) running in private subnets across two Availability Zones (AZ).
ECS Tasks talk to Amazon RDS (MySQL) located in a private database subnet.
ECS Tasks pull database credentials securely from AWS Systems Manager Parameter Store (No hardcoded passwords!).

🧠 Architectural Decisions & Trade-offs

Compute: ECS Fargate vs. EC2 Decision: Fargate. Reasoning: Removing the burden of OS patching and server management allows the team to focus on code. Trade-off: Fargate is slightly more expensive per vCPU than raw EC2, but saves significant operational hours (Human cost > Infrastructure cost).
Database: Amazon RDS vs. EC2 Hosted DB Decision: Amazon RDS. Reasoning: Automated backups, point-in-time recovery, and easy Multi-AZ setup for High Availability. Trade-off: Less control over the underlying OS configuration, but guarantees 99.95% uptime.
Optimization Strategy Cost: Used Linux-based containers (cheaper than Windows). Implemented Auto-scaling based on CPU load.(Here,I used t3.micro for the DB and low CPU for Fargate. In a real scenario, I would implement ECS Service Auto Scaling based on CloudWatch CPU metrics to handle traffic spikes automatically.) Performance: The application is stateless, allowing horizontal scaling behind the Load Balancer.
Security Network Isolation: Placed ECS tasks and RDS instances in private subnets. Access Control: Used Security Groups to restrict traffic between components. Secrets Management: AWS Parameter Store or Secrets Manager for production. IAM Roles: Least privilege principle applied to ECS Task Execution Role. Data Encryption: Enabled encryption at rest for RDS and enforced TLS for data in transit. Monitoring & Logging: Integrated AWS CloudWatch for logs and metrics. 5.Infrastructure as Code Tool: Terraform Reasoning: Enables version control, repeatability, and easy collaboration. Trade-off: Initial learning curve, but long-term benefits outweigh the costs. Modules: Used Terraform modules for VPC, ECS, RDS, and Load Balancer to promote reusability. State Management: Used remote state storage in S3 with state locking via DynamoDB.
CI/CD Pipeline (GitHub Actions) Tool: GitHub Actions (or AWS CodePipeline).

Reasoning: Automates build, test, and deployment processes.

Trade-off: Initial setup time, but reduces manual errors and speeds up deployments.

Steps: On push to main branch, build Docker image, push to ECR, and deploy to ECS.

Workflow Steps:

Integration: On every push to main, Maven builds the JAR and runs unit tests to ensure code quality.
Delivery:
Authenticates with AWS using IAM credentials stored in GitHub Secrets.
Builds a Docker image and pushes it to Amazon ECR.
Deployment:
Triggers an ECS Service Update (--force-new-deployment).
ECS pulls the new image from ECR and performs a rolling update (starts new container, health check passes, drains old container).
Design Choice: 'Rolling Update'
I utilized ECS's native rolling update mechanism. This ensures zero downtime during deployment.

The Load Balancer keeps sending traffic to the old version until the new version is healthy (Green/Blue deployment can be added for advanced scenarios).

🚀 How to Run Locally (Docker)
Build: docker build -t aws-poc-app .
Run: docker run -p 8080:8080 -e DB_URL=jdbc:mysql://host.docker.internal:3306/db -e DB_USER=root -e DB_PASS=root aws-poc-app Alternatively, use Docker Compose if a docker-compose.yml is provided. Access: Open http://localhost:8080 in your browser. Database: Ensure a local MySQL instance is running and accessible.
Stop: docker stop <container_id> Remove: docker rm <container_id> Logs: docker logs <container_id>
Debug: Use docker exec -it <container_id> /bin/bash to access the container shell. Environment Variables: Set DB_URL, DB_USER, and DB_PASS for database connectivity. Network: Use host.docker.internal to connect to host services from Docker on Windows/Mac. Option 2: Use Docker desktop with WSL2 backend for Linux users.(for beginners)
☁️ Deployment Steps (Terraform)
Navigate to infrastructure/.
Run terraform init. Run terraform apply. Terraform will output the Load Balancer URL.

📂 Project Structure
aws-migration-poc/
├── src/ # Java Spring Boot Application Source Code
├── Dockerfile # Dockerfile for containerizing the application
├── infrastructure/ # Terraform scripts for AWS infrastructure
│ ├── provider.tf # provider configuration for AWS
│ ├── vpc.tf # VPC and Subnets configuration
│ ├── ecs-cluster.tf # ECS Cluster
│ ├── ecs-service.tf # ECS Fargate Service configuration
| ├── ecs-task-def.tf # ECS Task Definition

| ├── ecr.tf # ECR Repository configuration
| ├── network.tf # VPC, Subnets, andSecurity Groups configuration
│ ├── database.tf # RDS Instance configuration
│ ├── iam.tf # IAM Roles and Policies

│ ├── variables.tf # Input variables for Terraform
│ ├── outputs.tf # Output values from Terraform
├── README.md # Project documentation
└── .gitignore # Git ignore file

Follow my github account for codebase!!!

Migrating a Legacy Monolith to Serverless on AWS(Strangler Fig Pattern)

nash9 — Wed, 10 Dec 2025 14:40:30 +0000

🚀 Overview

This project demonstrates how to migrate a legacy monolithic application to a serverless architecture using the Strangler Fig Pattern on AWS, leveraging:

Terraform for Infrastructure as Code
Python for application logic

The goal is to show how new features can be carved out from a monolith and replaced with serverless components—without breaking the existing system.

🏗 Architecture

The solution consists of major components:

Legacy Monolith
Python Flask app running on an EC2 instance.

New Serverless Components
AWS Lambda functions,DynamoDB tables,API Gateway (The Strangler Facade)
Routes traffic to the appropriate backend (legacy or new).

🔎 Route Behavior
`/users → Legacy Route
Proxies traffic to EC2 running the Flask app.

/products → Migrated Route
Handled by Lambda + DynamoDB.

/products/restock → Enhanced Route
POST request that simulates a failure 60% of the time to demonstrate resiliency handling.`

🖼 Architecture Diagram

📦 Prerequisites

Before deploying, ensure you have:

AWS Account (Free Tier eligible)
AWS CLI installed & configured (aws configure)
Terraform v1.0+
Postman or curl for testing

📁 Project Structure

strangler-fig-aws-migration-demo/ │ ├── README.md ├── infra-terraform/ │ ├── provider.tf │ ├── variables.tf │ ├── ec2.tf │ ├── dynamodb.tf │ ├── lambda.tf │ ├── apigateway.tf │ ├── outputs.tf │ ├── lambda_function/ │ │ └── lambda_function.py │ └── legacy_app/ │ └── legacy_server.py

🚀 Deployment Instructions

1️⃣ Initialize Terraform

Inside infra-terraform:

terraform init
2️⃣ Deploy Infrastructure
terraform apply
Type yes when prompted.

⏳ Deployment takes ~2 minutes, plus an additional 3 minutes for the EC2 instance to install dependencies and start the legacy server.

3️⃣ Retrieve the API URL

Terraform will output something like:

api_url = "https://<random-id>.execute-api.us-east-1.amazonaws.com"
Copy this value for testing.

🔬 Testing Scenarios

Scenario 1: Legacy Route (/users)
Traffic routed to EC2 Flask app.

Scenario 2: Migrated Route (/products)
Traffic routed to Lambda + DynamoDB.

Scenario 3: Chaos Route (/products/restock)
A POST endpoint simulating 60% failure rate.

Request:

curl -X POST <api_url>/products/restock

Expected Behavior:

Chance Response
40% 200 OK → {"status": "Restock Successful"}
60% 500 Internal Server Error → Simulated external failure

🛠 Troubleshooting Guide

❌ 1. 502 Bad Gateway

Cause: API Gateway couldn't reach EC2 instance.
Fix:
Wait 2–3 minutes after deployment
Ensure EC2 is running
Re-run terraform apply

❌ 2. 400 Bad Request

Cause: Payload version mismatch.
Fix:
Ensure this is inside your Lambda integration block:
payload_format_version = "2.0"

❌ 3. 500 Internal Server Error

Cause: Expected behavior for chaos testing.
Fix:
Run the command multiple times or remove the failure logic in lambda_function.py.

❌ 4. 405 Method Not Allowed

Cause: Using GET on a POST-only route.
Fix:
Use the correct method:
curl -X POST <api_url>/products/restock
🧹 Cleanup (To Avoid Charges)

When finished, destroy all resources:

terraform destroy
Double-check the AWS Console to ensure everything is deleted.

Follow me for more.Thanks !!!