Stories by Sapna Yadav on Medium

Resolving 403 Errors on API (Cloudflare WAF Block)

Sapna Yadav — Wed, 22 Apr 2026 15:43:17 GMT

We recently investigated an issue where clients experienced HTTP 403 Forbidden errors while uploading images via the API:

PRE:
https://**********/Ve*****/v1/up****e
PROD:
https://**********/Ve*****/v1/up****e

Despite the error on the client side, backend logs confirmed that:

No corresponding 403 errors were generated by the application.

🔍 Initial Observations

Client received a Cloudflare HTML error page (not a backend JSON response)
Error message: “Client error — the request contains bad syntax or cannot be fulfilled”
Backend logs showed successful processing.
Issue appeared intermittent .

No clear error patterns found in:

Application logs
Kubernetes pod logs
Service-level logging.

🧭 Investigation Journey

1. Infrastructure Checks

Reviewed ALB (Application Load Balancer):
~72 routing rules configured
Default fallback route → 404
Verified correct routing for affected domain
Traced traffic flow:
Cloudflare → ALB → Target Group → EKS Pods

2. Kubernetes (EKS) Analysis

Identified:
Pod restart occurred ~5 days prior (around issue timeline)
However:
No 403-related logs
No application-level failures

➡️ Conclusion: Issue not originating from application or pods .

3. Key Breakthrough: Cloudflare Layer

Evidence pointing to Cloudflare:

Response contained Cloudflare-branded HTML
Presence of CF-Ray ID
No matching backend error logs .


I/flutter ( 4966): *** Response ***
I/flutter ( 4966): uri: ***********
I/flutter ( 4966): statusCode: 403
I/flutter ( 4966): statusMessage: Forbidden
I/flutter ( 4966): headers:
I/flutter ( 4966):  connection: keep-alive
I/flutter ( 4966):  cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
I/flutter ( 4966):  transfer-encoding: chunked
I/flutter ( 4966):  date: Wed, 22 Apr 2026 08:53:48 GMT
I/flutter ( 4966):  vary: accept-encoding
I/flutter ( 4966):  content-encoding: gzip
I/flutter ( 4966):  strict-transport-security: max-age=0; includeSubDomains
I/flutter ( 4966):  referrer-policy: same-origin
I/flutter ( 4966):  server-timing: cfEdge;dur=149,cfOrigin;dur=0
I/flutter ( 4966):  content-type: text/html; charset=UTF-8
I/flutter ( 4966):  server: cloudflare
I/flutter ( 4966):  cf-ray: 9fc-JNB
I/flutter ( 4966):  x-frame-options: SAMEORIGIN
I/flutter ( 4966):  expires: Thu, 01 Jan 1970 00:00:01 GMT
I/flutter ( 4966): Response Text:
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966):   
I/flutter ( 4966): 
I/flutter ( 4966): Attention Required! | Cloudflare
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
2
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966):   
I/flutter ( 4966):     Please enable cookies.

I/flutter ( 4966):     
I/flutter ( 4966):       
I/flutter ( 4966):         Sorry, you have been blocked

I/flutter ( 4966):         You are unable to access 

I/flutter ( 4966):       

I/flutter ( 4966): 
I/flutter ( 4966):       
I/flutter ( 4966):         
I/flutter ( 4966):           
I/flutter ( 4966):             
I/flutter ( 4966):               
I/flutter ( 4966):             
I/flutter ( 4966):           

I/flutter ( 4966):         

I/flutter ( 4966):       

I/flutter ( 4966): 
I/flutter ( 4966):       
I/flutter ( 4966):         
I/flutter ( 4966):           
I/flutter ( 4966):             Why have I been blocked?

I/flutter ( 4966): 
I/flutter ( 4966):             This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

I/flutter ( 4966):           

I/flutter ( 4966): 
I/flutter ( 4966):           
I/flutter ( 4966):             What can I do to resolve this?

I/flutter ( 4966): 
I/flutter ( 4966):             You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

I/flutter ( 4966):           

I/flutter ( 4966):         

I/flutter ( 4966):       

I/flutter ( 4966): 
I/flutter ( 4966):       
I/flutter ( 4966):     
I/flutter ( 4966):       •
I/flutter ( 4966):       
I/flutter ( 4966):         Your IP:
I/flutter ( 4966):         
I/flutter ( 4966):         169.1.122.127
I/flutter ( 4966):         •
I/flutter ( 4966):       
I/flutter ( 4966):       Performance & security by Cloudflare
I/flutter ( 4966):       
I/flutter ( 4966):     

I/flutter ( 4966):     
I/flutter ( 4966):   

I/flutter ( 4966): 
I/flutter ( 4966):     

I/flutter ( 4966):   

I/flutter ( 4966): 
I/flutter ( 4966):   
I/flutter ( 4966): 
I/flutter ( 4966): 
I/flutter ( 4966):

Cloudflare team confirmed:

Requests were being blocked by a Managed WAF Rule: “PHP Code Injection” .

⚠️ Root Cause

Cloudflare’s Web Application Firewall (WAF) incorrectly flagged legitimate API requests as:

🛑 PHP Code Injection Attack

This resulted in:

Cloudflare blocking the request
Returning HTTP 403
Preventing response from reaching client correctly

Even though:

Backend had already processed the request successfully

🚨 Security Event Log (The Problem)

This screen shows an actual blocked request event.

Key details:

Action taken: Block
Rule triggered: PHP - Code Injection
Ruleset: Cloudflare Managed Ruleset
Endpoint:
Method: POST
User-Agent: Dart (Flutter app)
Country: ****
Ray ID: 9f03639c

👉 Translation:

A real API request was blocked by Cloudflare WAF, thinking it was a PHP injection attack.

Request hits Cloudflare
WAF evaluates payload
Matches PHP Code Injection rule
❌ Request blocked → 403 returned

✅ Resolution

Created WAF exception rule in Cloudflare
Excluded affected endpoints from the PHP Code Injection rule

Adding cloudflare managed ruleset .

Request hits Cloudflare
Rule condition matches your API domain
WAF skips PHP injection checks
✅ Request allowed through
Client gets proper response.

✅ The 403 errors were NOT from your backend
✅ They were caused by Cloudflare WAF blocking requests
✅ Specifically due to false positives in PHP Code Injection rule

✔️ Applied to:

PRE environment
PROD environment

🧪 Validation

Post-change testing confirmed:

✅ No more 403 errors
✅ API functioning as expected
✅ Image uploads successful end-to-end

📚 Key Learnings

1. Not All 403s Come From Your Backend

If you see:

HTML error pages
Cloudflare branding
Missing backend logs

➡️ Always suspect edge layers (WAF/CDN)

2. WAF Rules Can Cause False Positives

Managed rules are powerful but:

Can misinterpret payloads (especially file uploads)
Require fine-tuning via exceptions

3. Shared Responsibility Still Applies

Dev team → Owns application behavior & investigation
DevOps / Infra → Platform stability & routing
Network / Cloudflare → Edge security & filtering

➡️ Effective RCA requires collaboration + strong initial analysis.

🛠 Recommendations

Add structured logging:
Request IDs
Timestamps
Correlation IDs across layers
Capture failing payload samples
Monitor WAF logs proactively
Maintain a known exceptions list for APIs handling:
File uploads
Encoded payloads
Add alerting on Cloudflare blocks.

🧩 Final Takeaway

This was not:

A backend failure ❌
A Kubernetes issue ❌
A load balancer misconfiguration ❌

It was:

✅ A Cloudflare WAF false positive (PHP Code Injection rule)

If you run into similar symptoms:

403 + Cloudflare page
Backend success logs
Intermittent failures

👉 Check WAF before diving deep into application code.

Fixing SSH Key Authentication for AD User After RHEL Migration

Sapna Yadav — Fri, 17 Apr 2026 11:59:17 GMT

Introduction

After a recent RHEL migration, we encountered an issue where SSH key-based authentication failed for the AD user ansible, which is used by Jenkins for automation.

This post documents the root cause, troubleshooting, and final resolution.

Issue

While attempting SSH login using a private key:

ssh -i ~/ansible-key-rsa ansible@10.xxx.xxx.xx

Instead of key-based login, the system prompted for a password:

ansible@10.xxx.xxx.xx's password:

Root Cause

The issue was introduced after the RHEL migration.

👉 The ansible user is an AD/LDAP (domain) user, not a local Linux user.

After migration:

The home directory /home/ansiblewas missing
The .ssh/authorized_keys file was not present
SSH key authentication had nothing to validate against

As a result:

SSH fell back to password authentication

Investigation

We verified the user:

id ansible

Confirmed:

It belongs to domain users
It is resolved via AD (SSSD)

Checked home directory:

ls -ld /home/ansible

Observed:

Directory either missing or improperly initialized
.ssh directory missing or incorrect

Resolution Steps

1. Create Home SSH Structure

mkdir -p /home/ansible/.ssh

2. Set Correct Permissions

chmod 700 /home/ansible
chmod 700 /home/ansible/.ssh

3. Fix Ownership (Important for AD user)

chown ansible:"domain users" /home/ansible
chown -R ansible:"domain users" /home/ansible/.ssh

4. Add Public Key

vi /home/ansible/.ssh/authorized_keys

Paste the public key.

5. Secure the Key File

chmod 600 /home/ansible/.ssh/authorized_keys

Final Expected State

/home/ansible            -> drwx------ (700)
/home/ansible/.ssh       -> drwx------ (700)
/home/ansible/.ssh/authorized_keys -> -rw------- (600)

Ownership:

ansible:domain users

Key Learnings

AD users do not automatically recreate SSH configurations after OS migration
SSH key authentication depends entirely on:
Home directory
.ssh directory
authorized_keys file
Missing any of the above → authentication fails silently
Permissions and ownership must be exact

Impact

Jenkins jobs using ansible failed SSH authentication
Automation pipelines were blocked

Conclusion

The issue was not with SSH itself, but with missing user-level configuration after RHEL migration.

Once the home directory and authorized_keys were properly restored, SSH key authentication worked as expected.

Recommendation

After any OS migration:

Validate service users (especially AD users)
Ensure:
Home directories exist
SSH keys are restored
Permissions are correct

This avoids unexpected failures in automation tools like Jenkins and Ansible.

A simple missing .ssh directory can break an entire automation pipeline—always verify user environments post-migration.

A Lesson That Still Defines Today’s Job Market

Sapna Yadav — Tue, 07 Apr 2026 16:44:41 GMT

Our dads: “Duniya ke saath chalna seekho, warna peeche reh jaoge.”

Us back then: “Relax papa, sab control mein hai…” 😎

Us now in job market:

“Yeh new skill kab aayi?! Kal tak toh sab theek tha!” 😭

Moral of the story:

Papa was not giving advice… he was just 10 years ahead of the trend. 😃

Trust Your Gut: Why AI Can’t Replace Human Judgment

Sapna Yadav — Fri, 06 Mar 2026 18:14:03 GMT

Imagine this: you’re in an AI-driven interview. The AI asks questions, you answer, and it keeps digging deeper — but here’s the catch: it never challenges you. Even if some of your answers are slightly off, the AI just accepts them as correct. That’s exactly what happened to me this afternoon.

The Eye-Opener

AI is incredible at processing data, spotting patterns, and generating insights. But there’s one thing it can’t do: question your gut. Whatever you feed AI — even if it’s wrong — it treats as truth until corrected. That made me pause and think: if AI can’t detect wrong information, how reliable is it as a decision-maker?

Why Your Gut Matters

Humans have an edge AI can’t replicate: intuition. When something doesn’t feel right, your instincts nudge you to pause, rethink, and cross-check. That inner skepticism is critical when interacting with AI. Here’s why:

AI follows patterns, not principles: It can’t judge morality, context, or nuance the way humans can.
AI mirrors input: If you feed it misinformation, it will treat it as fact.
Humans can question assumptions: Your gut helps you spot inconsistencies and errors that AI might miss.

Make AI Work for You

Think of AI as a collaborator, not a replacement. Here’s how to use it effectively:

Feed it carefully: Make sure your data is accurate.
Question its output: Don’t accept answers blindly — ask yourself, “Does this feel right?”
Trust your gut: If something seems off, investigate further before moving forward.
Combine intuition and AI: Let AI analyze, but let your judgment decide.

Interactive Exercise

Try this: next time you use AI, write down three answers it gives you. Then, pause and ask:

Does this match what I know?
Are there gaps or inconsistencies?
What would my gut tell me if I had no AI?

Notice the difference between AI’s “certainty” and your human intuition. That’s the power you bring to the table.

The Takeaway

AI is a powerful tool, but it’s not infallible. Its strength lies in analyzing information, not questioning it. Your strength lies in critical thinking, intuition, and the courage to say, “Wait, that doesn’t seem right.”

The future isn’t about AI replacing humans — it’s about humans using AI wisely, while trusting themselves enough to challenge what seems wrong.

Thanks for reading , Feedbacks are always welcome !!!!

How We Resolved a Critical P1 Incident Triggered by a Network Configuration Change

Sapna Yadav — Mon, 09 Feb 2026 06:40:17 GMT

Friday mornings are usually calm… until they aren’t.
On this particular Friday, our team was met with a sudden surge of alerts from one of our core services. The service was attempting to call an external endpoint — but every attempt failed.

This marked the beginning of a long troubleshooting journey that touched our application, middleware, and network layers, eventually uncovering a subtle yet impactful network configuration change.

🔔 Phase 1: Initial Alerts & Investigation

1. First Alert — External Service Failure

The first alert indicated that one of our services was unable to reach an external client system. Requests were failing continuously, prompting us to notify the client to confirm whether their system was receiving our calls.

2. Second Alert — Claim Appointment Service Failure

By evening, another service started throwing errors. This service is responsible for appointing a 3rd‑party vendor for claim assessments. It too was unable to call the vendor’s endpoint.

Log Analysis Reveals Core Error

Digging deeper into logs, we encountered:

java.io.IOException: A connection with a remote socket was reset by that socket.

🔍 What Does This Error Mean?

This error refers to a TCP RST (reset) packet being sent by the remote server.
In simple terms:

Your application created a connection.
The remote endpoint forcefully closed it.
The connection ended abruptly before completion.

Usually, this is caused by:

Network devices blocking traffic
Firewall actions
Protocol mismatch
Improper TCP teardown
Server issues on the destination side

Despite restarting WAS services, Liberty, and even redeploying affected services — the issue persisted.

🔄 Phase 2: New Error Emerges

After multiple retries and restarts, a new exception surfaced:

WSDLException: faultCode=WSDL4JWrapper : 
javax.wsdl.WSDLException: WSDLException: faultCode=WSDL4JWrapper :
java.net.SocketException: A system call received a parameter that is not valid. (Read failed)

🔍 Meaning of This Error

This typically happens when:

The WSDL cannot be fetched due to network interruption.
Communication between client and SOAP service is broken.
Underlying TCP connection receives invalid or malformed packets.

In essence, this error confirmed that the SOAP/WSDL endpoints were unreachable due to a deeper network-level issue.

🌐 Phase 3: Network-Level Troubleshooting

At this stage, we involved both network and middleware teams.

🖥️ Commands Used to Identify Source & Destination IPs

To determine which source IP our server was using:

curl -v 

Or using ip route: 
ip route get 

To resolve the destination IP:
nslookup 
or
dig

🔥 Firewall (Fortigate) Observation

Network team checked:

Source IP of our server
Destination IP
Destination port

Connectivity was present, but the firewall logs showed:

❌ Firewall Action: server-rst

This means the firewall injected a TCP Reset packet on behalf of the server, forcefully closing the connection.
This usually happens when a firewall rule or security profile blocks or interferes with the traffic.

🆚 Phase 4: PRE vs PROD Comparison

To narrow down the issue, we logged into both PRE and PROD servers and ran:

curl -u :

PRE: Returned full client response successfully
PROD: Failed to connect

This confirmed:
✔ Application layer working
✔ Client endpoint working
❌ Issue isolated to PROD network path

🕵️ Root Cause Identified

Upon deeper investigation, we learned that a network configuration change had been implemented on Thursday night:

⚙️ Change Implemented

FortiDDos — Enable Prevention Mode for DTO SPP
Multiple SPPs were moved from Detection Mode → Prevention Mode.

The plan involved:

Editing SPP
Changing inbound/outbound mode from Detection to Prevention

This caused our PROD traffic to be classified as suspicious and forcibly reset.

🔁 Fix: Rolling Back the Change

Once the configuration was reverted:

All endpoints became reachable
CURL calls succeeded
Application logs cleared
Alerts stopped immediately

✅ Final Outcome

We successfully resolved a Critical P1 incident triggered by a network-level security configuration change.

Key Takeaways

Always compare PRE vs PROD paths — it narrows down culprits quickly.
TCP Reset errors often point to firewall/security layer interventions.
Cross-team collaboration (App, Middleware, Network) is essential for P1 resolution.
Documenting firewall and DDOS rule changes helps prevent unexpected production outages.

🛡️ Mitigation & Preventive Action Plan

To prevent similar incidents and ensure early detection of connectivity issues, we are implementing the following mitigation steps across application, middleware, and network layers.

1. Implement Vendor‑Provided Health‑Check Endpoint

We will work with the vendor to expose a lightweight health‑check endpoint that returns a simple HTTP status.
Our monitoring systems will periodically ping/curl this endpoint to validate real‑time connectivity.

Benefits:

Early detection of network disruptions
Immediate alerting if vendor endpoint becomes unreachable
Helps differentiate between application vs. network problems
Allows validation of SSL/TLS, DNS, and routing paths

curl -I https://

This gives us proactive visibility and prevents outages from going unnoticed until business transactions fail.

2. Move All Vendor Integrations from HTTP to HTTPS

During the incident, HTTP calls were more likely to be flagged by the DDOS/IPS security policies.
To avoid being classified as suspicious traffic:

All vendor endpoints in PROD will be migrated from HTTP → HTTPS
TLS encryption ensures better compatibility with FortiDDos, firewalls, and security inspection tools
Encrypted traffic is less prone to being reset or terminated by network appliances

This also aligns with modern security standards and vendor best practices.

3. Introduce Synthetic Transaction Monitoring

Beyond basic health checks, we will set up periodic synthetic tests that simulate a minimal real call to the vendor.

These tests will:

Validate connectivity
Confirm authentication is working
Ensure response format is valid
Measure latency and timeouts

Any failure will alert teams before impacting consumers.

4. Strengthen Change Management for Network & Security Rules

We will improve the approval and review process for firewall, DDOS, and IDS/IPS configuration changes:

Mandatory impact assessment for changes to Prevention/Blocking modes
Change review by Application, Middleware, and Network stakeholders
Scheduled post‑change validation testing using agreed test scripts
Documented rollback plans for each rule change

This ensures high‑risk network changes do not unintentionally block production traffic.

5. Add Continuous Firewall Log Monitoring & Alerts

We will configure:

Real‑time alerting on TCP resets generated by firewall or DDOS appliances
Threshold-based alerts for spikes in blocking, drops, or resets
Correlation dashboards for app errors vs. firewall events

This lets us detect anomalies as soon as they occur.

6. Implement PRE vs. PROD Environment Validation Scripts

Before any major change:

Connectivity checks
Curl tests
DNS resolution
Firewall rule validation
Endpoint handshake tests

Comparison between PRE and PROD helps catch misconfigurations early.

7. Maintain a Registry of Critical External Endpoints

We will create and maintain a registry that includes:

Vendor URLs (PRE/PROD)
Ports and protocols
Expected response codes
TLS versions/cipher requirements
Source IP requirements
Whitelisting/Firewall rules

This centralized reference ensures nothing is missed during audits or changes.

✅ Summary

By combining health checks, improved monitoring, better network change governance, and security‑aligned protocols, we significantly reduce the risk of similar outages recurring. These preventive measures strengthen our overall observability and ensure faster detection and response during any network‑related disruptions.

Production incident : The “No Space Left on Device” Crisis: How We Rescued Our Docker Jenkins…

Sapna Yadav — Sun, 11 Jan 2026 12:46:34 GMT

Production incident : The “No Space Left on Device” Crisis: How We Rescued Our Docker Jenkins Agents

We’ve all been there. Everything is running smoothly until a Jenkins build fails with a cryptic error message: No space left on device.

Suddenly, the CI/CD pipeline is paralyzed. In our case, the culprit was our Docker server hosting two high-traffic Jenkins agents. Here is the story of how we diagnosed the issue, cleaned up the mess, and what we learned.

1. The Symptoms

The first sign of trouble wasn’t a warning; it was a total halt. When a Docker host runs out of disk space, it doesn’t just slow down — it stops being able to write logs, create temporary build files, or pull new images.

Upon logging into the server, a quick df -h confirmed our fears: the partition hosting /var/lib/docker was at 100% capacity.

2. Identifying the Culprit

While Jenkins agents are incredibly powerful, they are also “disk hungry.” Every time a build runs, the agent:

Pulls new base images.
Creates intermediate build layers.
Leaves behind “dangling” images when a build is interrupted or updated.

With two agents running side-by-side, the volume of orphaned data grew faster than our manual cleanup could keep up with.

3. The Rescue: docker system prune

To get back online, we needed a surgical but effective cleanup. We turned to the built-in Docker Swiss Army knife:

Step 1: Analyze the Waste

First, we checked exactly how much space Docker was consuming:

Bash

docker system df

This command showed us a massive amount of “reclaimable” space held by images that were no longer associated with a running container.

Step 2: The Prune

We executed the prune command to wipe away the clutter:

Bash

docker image prune -a

What it does: Removes all unused images, not just dangling ones.

The Result: We reclaimed gigabytes of space in seconds, allowing the Jenkins agents to resume their work immediately.

4. Lessons Learned & Prevention

Cleaning up after a crash is a reactive fix. To stop this from happening again, we are implementing a few “best practices”:

Automated Cleanup: Adding a cron job or a Jenkins “Post-build” step to run docker image prune -f weekly.
Monitoring Alerts: Setting up thresholds (e.g., at 80% disk usage) to alert the DevOps team before the server hits 100%.
Docker Data Root: Moving the Docker data directory to a larger, dedicated partition to isolate it from the OS.

Final Thoughts

Disk space management is often overlooked in the world of containerization until it becomes a crisis. By understanding how Jenkins agents interact with the Docker daemon, you can turn a “server down” emergency into a routine maintenance task.

Has your CI/CD ever been taken down by a full disk? Let us know your favorite cleanup tricks in the comments!

AWS STEP FUNCTION .

Sapna Yadav — Sat, 19 Apr 2025 18:10:52 GMT

AWS STEP FUNCTION .

Hey all , we will learn step functions .

We will craete 3 EC2 instances .

We will create lambda fucntion which will start servers in order : Active directroy server will start first , then will start database server , then web server .

We will create lambda functions for all , which will run in order one after the other .

Craete lambda function for ad server and attach role to lambda .

This function will start the server .

Similarly create function for other servers as well .

Let’s create step function .

Create state machine for our workflow .

Add lambda to the workflow and provide details .

Add lambda to the workflow and provide details , we will also add next step wiat and lambda function similarly .

Add wait state , thereafter add lambda function .

Similarly add other lambda and wait state .

This is how our step function workflow works .

Add role to step function to invoke lambda functions .

This is how we can design a workflow which will run all steps in aws .

In a dataflowsimulator we can edit and view all our steps .

If we want our step function to execute daily at specific time , then we can create eventbridge rule .

We can specify cron expression in eventbridge .

Thanks for reading !!

Working with AWS ECS .

Sapna Yadav — Fri, 18 Apr 2025 19:32:52 GMT

Working with AWS ECS .

Hey all , we will work with aws ecs .

We will be craeting ECS containers and attach it to load baalncer .

We will configure VPC for our containers.

We will use this architecture . For this arch , we need 1 VPC , 4 Subnets ,

Create vpc .

Create Public Subnet . Similarly create all subnets with specfied range as in architecture .

Craete internet gateway .

Attach IG to VPC .

Craete route table in VPC .

Add public subnets to newly craeted route table .

Add route for public RT to IG .

Create NAT gateway .

Add nat gateway route to main route table .

Now , we will create load balancer . When we creat container we can attach lb with that and load balance our traffic from ECS and EC2 .

Create internet facing alb with public subnet .

Let’s allow internet traffic over port 80 .

Add targets for routing . right now we dont have any targets . This will provision the load balancer .

Let’s test load balancer with ECS .

We will craete ECS cluster and add containers to them . We will also add load balancer to load balance the traffic .

Craete linux cluster for ECS .

Select the details for instance in our cluster .

Select all details for ECS . Attach sg with all traffic allowed .

We will need to add roles so that ECS cluster will be able to manage containers agents on EC2 host .

We have created the ECS instances host in cluster .

Let’s create container .

Let’s create a task definition for our EC2 host to create containers .

We have differnet kind of network mode for containers , for this lab we will be using : bridge mode .

We wont attach role to our task since we dont want to access any other service for our application , we are craeting simple application .

We will craete container within the task .

Create task definition .

We will be creating load balancing service for our cluster .

Creating service for EC2 .

I have selected 6 task since we want to craete 6 containers .

This will balance conatiers automatically in load balancer .

Now create load balancer in next step .

Listener port is 80 .

We will specify setting for auto scaling as well .

Our service is deployed .

We can see containers on our target group which is using dynamic ports . So we have to enable traffic from all ports in our security group attached .

Test load balancer it should give nginx page .

We can also specify EC2 to allow traffic only from SG of ALB , for better security , So ALB will route requests to ECS which have task definotion for EC2 containers .

Thanks for reading .

Working with streaming data in AWS kinesis .

Sapna Yadav — Thu, 17 Apr 2025 16:35:05 GMT

Working with streaming data in AWS kinesis .

Hey all we will work with kinesis in this lab .

This will be architecture on which we will work .

Craete a data stream .

Create kinesis firehose for source .

We will be setting source as kinesis for stream in firehose and use s3 for stream destination .

Now , lets create a bucket which will receive data from firehose .

In destination setting of firehose specify the bucket created .

We will be using this for kinesis data generator .

Lets craete cognito user as above for our steeam .

We have received url for kinesis generator .

Let’s login to our kinesis data generator using the cognito user created . We will send the stream data .

Data will be captured in kinesis .

Our data will be captured in s3 from firehose since we have used s3 as destination .

This is how we will connect kinesis , firehose and s3 and stream application data .

Thanks .

Creating SQS queue which will poll messages to lambda function .

Sapna Yadav — Thu, 17 Apr 2025 14:24:36 GMT

Creating SQS queue which will poll messages to lambda function .

Hey , we will be creating queue which will poll messages to lambda function as consumer .

Creating queue .

We will be creating SQS poller lambda function using blueprint .

We will also need to specify role to lambda so that lambda can poll messages from SQS .

Will specify SQS queue in lambda and enable trigger which will trigger lambda whenever new messages are being polled to SQS queue .

Create blueprint function .

Now , in SQS lambda trigger is added but its disabled .

We can enable trigger from lambda config .

We can send message from SQS and it will trigger lambda .

We can view messages in lambda function logs for SQS .

This is how we can integrate SQS and lambda .