DEV Community: Tapas SInghal

Building a Secure Enterprise Developer Workspace on AWS

Tapas SInghal — Thu, 22 Jan 2026 05:39:37 +0000

I've spent the last few months working with enterprise clients who needed to lock down their developer environments without making life miserable for their engineering teams. The challenge? Give developers powerful workstations while keeping sensitive data and intellectual property locked down tight.

After trying various approaches, I landed on a solution using AWS WorkSpaces and Directory Services that actually works in the real world. Let me walk you through exactly how I built it.

Time to complete: 45-60 minutes

Cost: ~$25-35/month per WorkSpace (Standard bundle with AutoStop)

Prerequisites: AWS account with admin access

What You're Actually Building

Here's the setup we're going for:

Developers get full Windows desktops, but they live in AWS
Authentication ties into your enterprise identity system
Access only works from approved networks
Data stays on the desktop—no copying files out, no USB drives, nothing
Security policies roll out from a central place, not manually on each machine

This isn't theoretical. Companies use this exact pattern when they're serious about data protection.

Step 1: Pick Your Region and Stick With It

First things first—log into your AWS Console and pick a region. I usually go with something close to where my team actually sits to minimize latency.

For this example, let's use ap-south-1 (Mumbai).

Once you've selected it in that top-right dropdown, don't change it. I've seen too many people accidentally create resources across multiple regions and wonder why nothing works together.

Why this matters: WorkSpaces can only use directories in the same region. If you create your directory in Mumbai and try to launch WorkSpaces in Singapore, it simply won't work.

Step 2: Set Up Your Identity System

Every enterprise needs a proper identity system. We're going to use AWS Managed Microsoft AD because it integrates cleanly with WorkSpaces.

Search for Directory Service in the AWS Console
Click Set up directory
Choose AWS Managed Microsoft AD
Pick Standard Edition (unless you're managing thousands of users)
Hit Next

Now configure it:

Directory DNS name:

enterprise.local

Directory NetBIOS name:

ENTERPRISE

Admin password: Create something strong (at least 8 characters with uppercase, lowercase, numbers, and symbols). Save it in your password manager.

For the VPC and subnet selection:

Use your default VPC
Select two subnets in different availability zones (AWS requires this for high availability)
Example: subnet-abc123 (us-east-1a) and subnet-def456 (us-east-1b)

Click through and Create directory.

Grab a coffee. This takes about 20-30 minutes. You'll know it's ready when the status shows Active in green.

Troubleshooting: If directory creation fails, check that your VPC has internet connectivity through an Internet Gateway or NAT Gateway. The directory service needs to reach AWS endpoints.

Step 3: Create Your First Developer User

Now that we've got our identity system running, let's create an actual user.

Go back to Directory Service in the console
Click on your enterprise.local directory
In the directory details page, find the Actions dropdown
You might need to note down the Directory ID (starts with d-) for later
Navigate to the Users section in the left menu
Click Create user

Fill in the details:

Username: dev.user

First name: Dev

Last name: User

Email: (optional but recommended for password resets)

Set a temporary password. Check User must change password at next sign-in if available.

This user represents one of your developers. In production, you'd probably sync users from your on-premise Active Directory using AWS AD Connector, but for this tutorial, we're keeping it simple.

Step 4: Launch Your First WorkSpace

Time to create the actual virtual desktop.

Search for WorkSpaces in the console
Open Amazon WorkSpaces
Click Create WorkSpace

You'll see a wizard. Choose:

Personal (persistent) - each user gets their own desktop that persists
Windows as the OS

Click Next to move forward.

Step 5: Connect the User to Their Desktop

This part's straightforward:

Select your directory: enterprise.local
Click Next
Pick the user: dev.user
Click Next again

You're basically saying "this desktop belongs to this user." One-to-one mapping.

Step 6: Configure the Desktop Hardware

Now we choose what kind of machine this developer gets.

Pick a Standard Windows bundle
- 2 vCPU, 4 GB RAM, 80 GB storage
- Costs about $25-35/month with AutoStop
- Perfect for most development work (coding, git, basic IDEs)
Set Running mode to AutoStop
Configure AutoStop timeout to 1 hour

This last bit saves you money. If the developer walks away for lunch and forgets to log out, AWS automatically shuts down the WorkSpace after an hour of inactivity. You only pay for the hours it's actually running.

Storage settings:

Root volume: 80 GB (default)
User volume: 50 GB (default)
Leave these as-is unless you know developers need more space

Click Next, review everything, and hit Create WorkSpace.

Another waiting game—usually 10-15 minutes until the status shows Available.

What's happening: AWS is provisioning a Windows Server instance, joining it to your directory, installing the WorkSpaces agent, and configuring all the networking.

Step 7: Lock Down Network Access

Here's where we get serious about security. We only want developers connecting from approved networks—not from random coffee shops or compromised home networks.

In WorkSpaces, go to IP Access Controls
Click Create IP Access Control Group

Name it something obvious:

enterprise-trusted-network

Add a description like:

Trusted enterprise network

Now add your first rule. If you're testing from your office or home:

Find your public IP: Google "what's my IP" or visit https://whatismyipaddress.com
Note down the IPv4 address (looks like 49.204.123.45)
In the IP Access Control Group, click Add Rule
Enter your IP with /32 at the end

Example:

49.204.123.45/32

Add a description like "Home Office" or "Testing Location"
Save the rule

That /32 means "only this exact IP address." In production, you'd use your office network's IP range.

For office networks:

203.0.113.0/24  (allows 203.0.113.0 to 203.0.113.255)

Important: If you have a dynamic IP (changes every few days), you'll need to update this rule whenever your IP changes. Most ISPs offer static IP addresses for business accounts.

Step 8: Attach the Network Rules

Creating the rule isn't enough—we need to attach it to our directory.

Go to WorkSpaces → Directories
Select your enterprise.local directory
Find IP access control groups
Attach enterprise-trusted-network
Save

Now anyone trying to connect from outside those approved IPs? They're blocked at the door.

Step 9: Disable Risky Access Methods

People love convenience, but browsers and mobile devices are security nightmares for enterprise VDI.

While you're in the directory settings:

Find Platform access settings
Turn OFF:
- Web access
- Mobile access
Keep only the desktop client enabled

Why? Because the desktop client gives you way more control and security. Browser-based access is a bypass waiting to happen.

Step 10: Start Enforcing Real Security Policies

This is where we stop relying on user behavior and start enforcing rules they can't bypass.

First, you need to connect to the WorkSpace as an administrator:

Download the WorkSpaces client from https://clients.amazonworkspaces.com
Install it on your local machine
Open the client and enter your registration code
- Find this in the WorkSpaces console under your directory details
- Looks like WSpdx+ABC123
Log in with dev.user and the password you set earlier

Once you're in the WorkSpace:

Press Win + R and type:

   gpmc.msc

Press Enter (you'll need to be logged in as a domain admin—you may need to use "Run as different user" with the directory admin account)
Expand Forest: enterprise.local → Domains → enterprise.local
Right-click on Group Policy Objects and select New
Name it:

   Enterprise-VDI-Data-Restrictions

Right-click your new GPO and select Edit

Group Policy is how Windows administrators have been enforcing security for decades. It works, and users can't weasel around it (if you do it right).

Step 11: Block All the Data Leaks

Here's the meat of our security model. Inside that Group Policy Editor:

Navigate to:

Computer Configuration → Policies → Administrative Templates → 
Windows Components → Remote Desktop Services → 
Remote Desktop Session Host → Device and Resource Redirection

Enable these policies:

Do not allow Clipboard redirection
- Set to: Enabled
- Effect: Can't copy-paste between WorkSpace and local machine
Do not allow drive redirection
- Set to: Enabled
- Effect: Can't access local drives from the WorkSpace
Do not allow LPT port redirection
- Set to: Enabled
Do not allow COM port redirection
- Set to: Enabled
Do not allow client printer redirection
- Set to: Enabled
- Effect: Can't print to local printers or "print to PDF"
Do not allow supported Plug and Play device redirection
- Set to: Enabled
- Effect: Can't use USB drives or other devices

Apply the changes:

Close the Group Policy Editor
In Group Policy Management, right-click the GPO
Select Enforced to prevent overrides
Link it to your WorkSpaces OU (usually under Computers)

On the WorkSpace, open PowerShell as administrator and run:

gpupdate /force

You'll see output like:

Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.

Restart the WorkSpace for everything to take effect:

Restart-Computer -Force

I know this sounds draconian, but this is how enterprises actually protect sensitive code and data. If developers need to move files around, they do it through approved channels like git repositories or internal file shares.

Step 12: Remove Local Admin Rights

By default, the first user on a WorkSpace gets local admin rights. That's fine for testing, but terrible for production.

On the WorkSpace, press Win + R and type:

   compmgmt.msc

Navigate to Local Users and Groups → Groups
Double-click the Administrators group
Select dev.user in the list
Click Remove
Click OK

Log out and log back in for the change to take effect.

Without admin rights, users can't disable the security policies we just set up. They can still install approved software through Software Center or SCCM if you set those up, but they can't bypass your security baseline.

Production tip: In real environments, you'd manage this through Group Policy Restricted Groups or use a privileged access management (PAM) solution where users can request temporary admin rights for specific tasks.

Step 13: Test Everything

Try copying text from the WorkSpace and pasting it into Notepad on your laptop → Should fail
Try printing a document or using "Print to PDF" → Blocked
Plug in a USB drive (if you can access the WorkSpace physically) → Nothing happens
Try opening Local Group Policy Editor → Access denied

If all those things fail, congratulations. Your security is actually working.

Step 14: Mind Your Costs

Before you walk away, remember that WorkSpaces costs money while it's running.

Log out when you're done testing
Let AutoStop shut it down after the timeout
When you're completely finished with this tutorial, delete the WorkSpace and directory

I've seen too many people leave test WorkSpaces running for months and get surprised by the bill. Don't be that person.

What's Missing (On Purpose)

This tutorial covers the foundation, but real enterprise deployments usually add:

VPN requirements - users must connect to corporate VPN first
Device certificates - only company-managed devices can connect
MDM integration - works with Intune, Jamf, or other MDM platforms
Zero Trust architecture - continuous verification of user and device posture
CloudWatch monitoring - detailed logging of who accessed what and when
Multi-factor authentication (MFA) - requires additional verification
Session recording - records all sessions for compliance
Data loss prevention (DLP) - additional scanning for sensitive data

Those are all important, but they're layers you add once you've got this foundation solid. Walking before running, and all that.

What You've Actually Built

Take a step back and look at what you've created:

✅ Virtual desktops tied to enterprise identities

✅ Network access restricted to approved locations

✅ Data physically can't leave the environment

✅ Security policies that users can't bypass

✅ A design that scales from 10 users to 10,000

This isn't a toy project. This is the actual pattern companies use when they're handling sensitive intellectual property, financial data, or regulated information.

Final Thoughts

Building secure developer environments is always a balancing act. Lock things down too much and developers find workarounds (usually insecure ones). Too loose and you're one leaked credential away from a data breach.

This WorkSpaces approach isn't perfect, but it's proven. I've deployed variations of this for financial services companies, healthcare organizations, and startups dealing with sensitive customer data.

The key insight? Security works best when it's invisible to the user. Developers don't think about the directory service or the IP restrictions—they just log in and get work done. Meanwhile, your security team sleeps better at night.

If you end up implementing this in production, let me know how it goes. I'm always curious to hear what works (and what doesn't) in different environments.

🌐 My Socials

Feel free to connect with me or collaborate on other serverless & AI projects:

🔗 Portfolio: https://tapasenjinia.me

💼 LinkedIn: https://www.linkedin.com/in/tapas-singhal/

🧠 GitHub: https://github.com/its-tapas

Thanks for reading 🙌 — Tapas Singhal

SAP on AWS: The $200K Skill Gap While Everyone's Learning AI

Tapas SInghal — Fri, 19 Dec 2025 19:34:35 +0000

Last week, I watched a senior developer with 8 years of experience get rejected from a cloud migration project. His resume was impressive—Kubernetes expert, certified in three AWS services, even contributed to some open-source projects. The reason? He had zero SAP experience.

The company was willing to pay $180K for someone who understood both SAP and AWS. They ended up hiring a contractor at $250/hour instead.

That moment stuck with me. While everyone's panicking about AI replacing developers, there's this massive gap in cloud computing that barely anyone talks about.

The Uncomfortable Truth About Enterprise IT

During my internship, a senior architect told me something that changed how I see the tech industry: half the world's business runs on SAP. Not the trendy frameworks we obsess over. Not the latest JavaScript library. SAP.

SAP ERP, S/4HANA, SAP HANA databases—these systems process trillions of dollars in transactions every single day. Your bank uses it. Your favorite retailer uses it. That car you're planning to buy? The entire supply chain runs on SAP.

And here's the kicker: most of these systems are still running in dusty data centers, burning money on hardware refresh cycles and maintenance contracts that cost more than your house.

The AI Reality Check

I've seen the LinkedIn posts. "AI will replace cloud engineers!" "Learn to prompt or become obsolete!"

Here's my honest take: AI absolutely will change this space. I use tools like Claude, ChatGPT, and even newer IDEs like Kiro that help with coding workflows. They're brilliant for explaining SAP concepts, understanding AWS services, or debugging issues. AI will make people in this field more productive, no question.

But here's what I learned during a recent S/4HANA migration that went sideways at 2AM: AI can suggest solutions, but it can't make the call when you're staring at conflicting recommendations and the CIO is asking if we need to roll back. It can't read the room when the SAP Basis team and AWS architects are blaming each other for performance issues. It can't negotiate with the VP who's terrified of downtime during Q4 holiday sales.

AI is a tool that makes skilled people more valuable, not a replacement that makes them obsolete. The gap isn't technical knowledge anymore—Google and AI can fill that. The gap is judgment, experience, and the ability to navigate complex situations where there's no clear right answer.

While everyone's learning prompt engineering, enterprises are bleeding money trying to find people who can actually execute these migrations. That's the opportunity.

What This Actually Looks Like

SAP on AWS isn't about clicking through the AWS Console and launching EC2 instances. It's a different beast entirely.

You're dealing with:

SAP workloads that need HANA-certified instances (x1, x2, u-instances that cost $50/hour)
High-performance storage requirements that make regular EBS look like a toy
Network latency tolerances measured in single-digit milliseconds
Backup strategies for multi-terabyte databases that can't have "oops" moments
Disaster recovery plans that CEOs actually care about because downtime means millions lost per hour

AWS has an entire division dedicated to SAP—SAP on AWS practice, specialized solutions architects, pre-built reference architectures. This isn't some side project. Amazon knows enterprises are spending serious money here.

The Three Paths Nobody Mentions

If you're already in the SAP world: Learning AWS is your ticket out of being seen as "legacy." SAP consultants who add cloud skills instantly jump tax brackets. You already understand HANA, S/4HANA, and the business side. Add AWS architecture skills, and you're suddenly one of maybe 5,000 people globally who can do both well.

If you're an AWS person: SAP is your differentiation. While 50,000 developers are fighting for the same DevOps roles, enterprises are begging for cloud architects who aren't afraid of SAP. You don't need to become an SAP functional consultant. Just understand the infrastructure side—HANA deployments, high availability, backup/recovery, performance tuning.

If you're starting fresh: This is where I am right now. It's honestly intimidating—the learning curve is steep on both sides. But that's also the opportunity. In 3-5 years, you'll have skills that take most people 10+ years to acquire, and you'll be working on projects where budgets have commas in them. I spent a month working with SAP HANA and ERP during my internship, and even that brief exposure showed me how massive and complex this ecosystem is.

So, Where Do I Actually Start?

You need two things: AWS fundamentals and SAP literacy. Not mastery—literacy.

For AWS: Get hands-on. Actually deploy things, break them, fix them. The certification helps, but building real infrastructure teaches more.

For SAP: Understand the basics—what HANA is, what S/4HANA does, why BASIS admins matter. SAP has free learning accounts. Use them.

Then combine both: AWS SAP reference architectures, immersion days, real projects if you can get access.

The truth? Most people quit because it's not as exciting as the latest trend. That's exactly why the opportunity exists.

(I'm working on a detailed learning roadmap with resources, timelines, and hands-on projects. If there's interest, I'll share it—let me know in the comments.)

Why This Matters (At Least to Me)

I'm five months into my career as a developer. I'm still figuring out how to balance learning new technologies with actually getting work done. I'm not making $200K. I'm not leading migration projects.

But that one-month exposure to SAP HANA and ERP systems during my internship showed me how much of enterprise technology operates differently than what we learn in tutorials. The contractor making $250/hour had skills that bridged both SAP and AWS—that's the gap.

I'm starting to invest time in understanding SAP alongside my AWS work. It's vast, it's complex, and honestly, it's not always exciting. But the market gap is real, and someone's going to fill it.

Resources That Actually Matter

AWS Official:

AWS SAP Lens (Well-Architected Framework) - Start here. It's what every SAP on AWS project references.
SAP on AWS Documentation
AWS Partner: SAP on AWS Specialty Certification (advanced, but the target)

SAP Side:

SAP Learning Hub - Free tier available. Focus on HANA basics and S/4HANA overview.

Hands-On:

AWS Skill Builder: SAP on AWS - Free courses and learning paths
AWS Workshops: SAP on AWS - Hands-on labs you can actually do
AWS SAP Community on re:Post - Actual engineers solving actual problems

Reality Check:

Look at SAP BASIS job descriptions—see what skills they value
Compare with AWS Solutions Architect roles focused on enterprise
The overlap is your opportunity

My Plan Moving Forward

Committing to this learning path while maintaining current role and continuing to develop technical skills is going to be difficult especially when there is a race against Ai. It requires discipline—early mornings, focused weekends, and saying no to distractions—but the market demand and career trajectory make it worth the investment.

The challenge is not only about technical. It's staying consistent when progress feels slow, when the concepts are dense, and when friends are learning flashier technologies. But that's also what creates the opportunity. Most people won't put in this work, which is exactly why those who do become valuable.

I'm documenting this journey not as an expert, but as someone in the trenches. If you're considering this path or already working in SAP or AWS, or have insights or thought to share, I would love to connect.

🌐 My Socials

Feel free to connect with me or collaborate on other serverless & AI projects:

🔗 Portfolio: https://tapasenjinia.me
💼 LinkedIn: https://www.linkedin.com/in/tapas-singhal/
🧠 GitHub: https://github.com/its-tapas

Thanks for reading 🙌 — Tapas Singhal

End to End Generative AI mini Project On AWS Using AWS Bedrock, AWS Lambda, API Gateway and S3

Tapas SInghal — Thu, 01 May 2025 19:37:31 +0000

In this blog, I’ll walk you through exactly how I created an AI-powered blog generator bot using Amazon Bedrock, Lambda, S3, and API Gateway. This was a mini project to practice serverless architecture using AWS services and AI text generation models to get introduce to Amazon Bedrock.

🔧 I used a non-chat LLaMA model from Amazon Bedrock, because that was available in my region (ap-south-1) and suited my use case well for blog generation, dont hesitate to use anyother model.

✨ What You’ll Learn

How to access and use Amazon Bedrock models
How to prepare a Lambda function with external libraries like boto3
How to integrate Lambda with API Gateway for POST requests
How to store generated blog content into S3 buckets
How to test the endpoint using free tools like ReqBin

🛠️ Step 1: Enable Amazon Bedrock and Choose Model

🔹 Accessing Bedrock

Go to AWS Console → Services → Amazon Bedrock.
Request model access (you may need to request access for models like LLaMA3, Titan, etc.).
Wait for approval (this can take from minutes to a few hours).

💡 I used meta.llama3-8b-instruct-v1:0, which was available in my region. I didn’t choose a chat model specifically — I used what was available for experimentation. If available you should choose a chat based model or any other good text based model.

🧠 Step 2: Write and Prepare the Lambda Function

🔹 Writing the Function

The Lambda function handles:

Receiving the blog topic from API Gateway
Sending the prompt to the Bedrock model
Receiving and parsing the response
Saving the blog to S3

import boto3
import botocore.config
import json
from datetime import datetime
def blog_generate_using_bedrock(blogtopic:str)->str:
    prompt=f"""Write a blog minimum 300 to 500 words(no need to strictly follow) in a professional mammer with only 5 subtopics and a conclusion {blogtopic}"""
    body={
        "prompt":prompt,
        "max_gen_len":600,
        "temperature":0.5,
        "top_p":0.9
    }
    try:
        bedrock=boto3.client("bedrock-runtime",region_name="ap-south-1",config=botocore.config.Config(read_timeout=300,retries={'max_attempts':3}))
        response=bedrock.invoke_model(body=json.dumps(body),modelId="<Your_Model_ID>")

        response_content=response.get('body').read()
        response_data=json.loads(response_content)
        print(response_data)
        blog_details=response_data['generation']
        return blog_details
    except Exception as e:
        print(f"Error generating the blog:{e}")
        return ""

def save_blog_details_s3(s3_key,s3_bucket,generate_blog):
    s3=boto3.client('s3')
    try:
        s3.put_object(Bucket = s3_bucket, Key = s3_key, Body =generate_blog )
        print("Code saved to s3")

    except Exception as e:
        print("Error when saving the code to s3")

def lambda_handler(event, context):
    # TODO implement

    event=json.loads(event['body'])
    blogtopic=event['blog_topic']
    generate_blog=blog_generate_using_bedrock(blogtopic=blogtopic)
    if generate_blog:
        curr_time=datetime.now().strftime('%H%M%S')
        s3_key=f"blog-output/{curr_time}.txt"
        s3_bucket='<Your_s3_bucket>'
        save_blog_details_s3(s3_key,s3_bucket,generate_blog)
    else:
        print("No blog was generated ")

    return{
        'statusCode':200,
        'body':json.dumps('Blog Generation is Completed')
    }

NOTE: - Replace 'Your_Model_ID' with your bedrock model's ModelID and 'Your_s3_bucket' with your AWS bucket

🔹 Important: Add boto3 Dependency

Amazon Bedrock needs latest boto3 version, which is not included in Lambda by default. You have two options:

✅ Option 1: Create a Lambda Layer with boto3

On your local system, run:

   mkdir python
   pip install boto3 -t python/
   zip -r boto3_layer.zip python

Go to AWS Console → Lambda → Layers → Create Layer
Upload boto3_layer.zip and choose compatible runtimes (Python 3.12, 3.11, or 3.10)
Attach the layer to your Lambda function

Your Result should look like this

🧠 Option 2: Include boto3 manually in deployment zip

(Same as above, but upload the entire zipped folder as your Lambda deployment package.)

🔗 Step 3: Setup API Gateway for Integration

🔹 Create an HTTP API

Go to AWS Console → API Gateway
Choose HTTP API
Click “Build” and name it (e.g., BlogGenAPI)

🔹 Configure Routing

Create a route: POST /blog-generation
Add integration target: Your Lambda function
Deploy the API and create a Stage (in my case: dev)
You’ll get

   Invoke URL
   https://your-api-id.execute-api.region.amazonaws.com/dev/

   AND 

   Route details
   POST /blog-generation

🪣 Step 4: Create and Connect S3 Bucket

Go to AWS Console → S3 → Create a bucket
- Bucket name: awsbedrocktapas (you can name it anything but should be unique)
No need to make it public
Go to IAM role of the Lambda and allow:
- s3:PutObject on your bucket

In your Lambda code, the S3 upload part looks like this:

s3_key = f"blog-output/{curr_time}.txt"
s3_bucket = 'YOUR Bucket'
s3.put_object(Bucket=s3_bucket, Key=s3_key, Body=generated_blog)

Raplace 'YOUR Bucket' with your bucket name you just created

🧪 Step 5: Test the API using any tool, I am using ReqBin (Free Online Tool)

Go to reqbin
Choose method: POST
URL: Your deployed API Gateway endpoint

https://your-api-id.execute-api.region.amazonaws.com/dev/blog-generation

Choose Content-Type: json
Add body:

{
  "blog_topic": "Benefits of Remote Work in 2025"
}

Hit “Send” and check the response

You should see:

{
  "blog_topic": "Benefits of Remote Work in 2025"
}

Now check your S3 bucket — you’ll find a .txt file with your freshly AI-generated blog!

🧾 Example Output Blog

✅ Final Flow Diagram (Optional)

🎯 Conclusion

Using just four core AWS services — Bedrock, Lambda, API Gateway, and S3 — we’ve built a complete, serverless AI-powered blog generator.

This project taught me how to:

Work with LLMs via Bedrock
Integrate custom code into Lambda
Manage external Python libraries via Lambda Layers
Expose a POST API endpoint for external use
Save data persistently using S3

💬 You can build on top of this by adding:

A frontend (React/Next.js)
An email sender to notify when blog is ready
An admin dashboard for blog management

🌐 My Socials

Feel free to connect with me or collaborate on other serverless & AI projects:

🔗 Portfolio: https://tapasenjinia.me
💼 LinkedIn: https://www.linkedin.com/in/tapas-singhal/
🧠 GitHub: https://github.com/its-tapas

📂 Project Repository

🔗 GitHub: https://github.com/its-tapas/blogGen

🤝 Open to improvements, ideas, and suggestions. Don't hesitate to fork, star, or contribute to this project!

Thanks for reading 🙌 — Tapas Singhal

Building a Scalable Web Application on AWS Using Core Services [Perfect for Beginners]

Tapas SInghal — Sun, 02 Feb 2025 22:25:13 +0000

Introduction

In this blog, I’ll walk you through a Level 2 AWS project where we build a scalable web application using AWS core services. Whether you're new to AWS or looking to solidify your understanding, this guide will help you get hands-on with services like VPC, EC2, IAM, S3, and ALB.

Resources

If you prefer a detailed, step-by-step practical implementation, check out my YouTube tutorial here. The video covers every step of the process, from setting up the VPC to deploying the web server and configuring the load balancer. You can also follow along with the AWS Workshop Link for a self-paced learning experience.

Architecture Overview

Here’s an overview of what we’ll build:

VPC: A virtual network to host our resources securely.
EC2: A web server to host our application.
IAM: Role-based access control for secure resource management.
ALB: An Application Load Balancer to distribute traffic.
S3: Cloud storage for static assets.

Step-by-Step Guide

1. Setting Up Networking (VPC)

We started by creating a Virtual Private Cloud (VPC) with public and private subnets across two Availability Zones. This ensures our resources are isolated and secure.

2. Resource Security (Security Groups)

Next, we created Security Groups to control inbound and outbound traffic. One group allows HTTP traffic from the internet, while the other restricts access to the web server.

3. Access Management (IAM)

We configured an IAM Role with the necessary permissions for our EC2 instance to interact with other AWS services securely.

4. Deploying Compute (EC2)

Using Amazon EC2, we launched a web server in the private subnet. We also used User Data to automate the installation of a PHP web server.

5. Administering the Web Server (SSM)

We connected to the EC2 instance securely using AWS Systems Manager (SSM), eliminating the need for SSH keys or public IPs.

6. Load Balancing (ALB)

To distribute traffic, we set up an Application Load Balancer (ALB) that routes incoming HTTP requests to our web server.

7. Testing and Scaling

Finally, we tested the web application and explored scaling options using Auto Scaling Groups (optional challenge).

Clean Up

Don’t forget to clean up your resources to avoid unnecessary charges! Terminate the EC2 instance, delete the ALB, and remove any unused resources.

Conclusion

By following this guide, you’ve built a scalable and secure web application on AWS. This project is a great way to get hands-on experience with core AWS services and understand how they work together.

My LinkedIn Profile

If you face any issues, feel free to reach out to me directly on LinkedIn.
The YouTube video provides a detailed, step-by-step practical implementation of this workshop, making it easier to follow along and implement the project yourself.

Let me know if you have any questions or suggestions in the comments below! Happy building! 🚀

[Mini Project] Serverless URL Shortener Using AWS Lambda, Api Gateway and DynamoDB

Tapas SInghal — Sat, 01 Feb 2025 18:04:18 +0000

Before Starting Consider these options too-

For direct steps Go to GitHub - [Mini Project] Serverless URL Shortener
You can Find the Amazon Blog for Build a Serverless, Private URL Shortener - Here
If You Like to Build a serverless URL shortener app without AWS Lambda Go to - Amazon Blog Link

In this tutorial, we will walk through building a Serverless URL Shortener using AWS services like Lambda, API Gateway, and DynamoDB. The goal of this project is to create a highly scalable and serverless system where long URLs are shortened, and users can be redirected to the original URLs using the short codes.

The project is designed to be beginner-friendly and will guide you step-by-step. You’ll also learn about AWS services like Lambda, API Gateway, and DynamoDB, which are commonly used in serverless architectures.

Prerequisites

Before we start, ensure that you have the following prerequisites:

AWS Account: If you don’t already have an AWS account, you can sign up here.

(below if working with CLI)

AWS CLI: The AWS Command Line Interface (CLI) will help you interact with AWS services directly from your terminal. Follow the installation instructions for Windows.
Python 3.x: Our Lambda function will be written in Python. Make sure Python 3.x is installed on your system from python.org.
Postman: For testing our API, we’ll be using Postman. You can download and install it from here.

Step 1: Set Up DynamoDB Table

The first step in building our serverless URL shortener is to create a DynamoDB table where the shortened URLs and their corresponding long URLs will be stored.

DynamoDB is a fully managed NoSQL database provided by AWS. It allows you to store data in a key-value format, and it scales automatically based on your application's needs.

Steps:

Open the AWS Management Console and navigate to DynamoDB.
Click Create Table.
Set the Table name as URLShortener.
Set the Partition key to short_code (Type: String).
- This will uniquely identify each shortened URL by its short code.
Click Create.

Step 2: Create the Lambda Function

Next, we need to create an AWS Lambda function that will generate short codes and handle the URL redirection.

What is AWS Lambda?

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. You upload your code, set a trigger, and Lambda takes care of the rest.

Steps:

Navigate to AWS Lambda in the AWS Management Console.
Click Create Function.
- Select Author from Scratch.
- Set the Function name as URLShortenerFunction.
- Set the Runtime to Python 3.x.
- In the Permissions section, create a new role with basic Lambda permissions (AWS will automatically create the role).
Click Create Function.

Step 3: Add Code to the Lambda Function

After creating the Lambda function, we need to add the Python code that will perform the main logic of the URL shortener. This includes generating a short code for a given long URL and redirecting users when they visit the short code.

Lambda function acts as the business logic handler in this project. It will:

Receive the original long URL.
Generate a short code.
Store the mapping in DynamoDB.
Redirect the user to the original URL when they use the short code.

Code for Lambda function:

Here’s the Python code that will handle the URL shortening and redirection:

import json
import boto3
import string
import random

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('########')

def generate_short_code():
    chars = string.ascii_letters + string.digits
    return ''.join(random.choice(chars) for _ in range(6))

def lambda_handler(event, context):
    http_method = event['httpMethod']

    if http_method == 'POST':
        # Create a short URL
        body = json.loads(event['body'])
        long_url = body['long_url']
        short_code = generate_short_code()

        table.put_item(Item={
            'short_code': short_code,
            'long_url': long_url
        })

        return {
            'statusCode': 200,
            'body': json.dumps({'short_code': short_code})
        }

    elif http_method == 'GET':
        # Redirect to the long URL
        short_code = event['queryStringParameters']['short_code']
        response = table.get_item(Key={'short_code': short_code})

        if 'Item' not in response:
            return {
                'statusCode': 404,
                'body': json.dumps({'error': 'Short URL not found'})
            }

        long_url = response['Item']['long_url']
        return {
            'statusCode': 301,
            'headers': {'Location': long_url}
        }

    else:
        return {
            'statusCode': 400,
            'body': json.dumps({'error': 'Invalid HTTP method'})
        }

Click Deploy to save the changes. ( You can modify the code as per required including DynamoDB Table Name and test it as well)

Step 4: Set Up API Gateway

What is API Gateway?

API Gateway is a service from AWS that allows developers to create, publish, maintain, monitor, and secure APIs. With API Gateway, you can expose HTTP endpoints that can interact with backend services such as AWS Lambda functions.

Follow these steps to set up API Gateway:

Navigate to API Gateway:
- Open the AWS Management Console.
- In the search bar, type API Gateway, and select it from the list.
Create a new API:
- Click on Create API.
- Choose HTTP API, and then click Build to begin creating a new API.
Define the API Routes:
- POST /shorten: This route will handle the creation of short URLs.
- GET /redirect: This route will redirect users to the original URL based on the short code provided.
Integrate Routes with Lambda:
- For each route, select the URLShortenerFunction Lambda function that we created in Step 2.
- API Gateway will automatically link the function to the routes.
Deploy the API:
- After setting up the routes, you need to deploy the API.
- Click on Deploy to create a new stage. A stage is an environment for your API (e.g., prod).
- Name the stage, such as prod.
- AWS will provide a URL for the deployed API. This is the URL you will use to interact with your API.

Example API endpoint URL format:

https://.execute-api..amazonaws.com/prod

Explanation of API Gateway's Role:

API Gateway serves as a bridge between the frontend (users) and the backend (Lambda). When a user requests a short URL or tries to access the original URL using the short code, API Gateway routes the requests to the Lambda function, which processes the logic (e.g., generating a short code or retrieving the original URL).

Step 5: Test the URL Shortener

Once you have set up the Lambda function and API Gateway, it’s time to test the URL shortener functionality.

Testing Using Postman (Recommended for Windows)

Postman is a tool that allows you to send HTTP requests and view responses, making it perfect for testing APIs.

Create a Short URL:

Open Postman and create a new request.
Set the request type to POST.
Enter the URL for the shorten route: > https://.execute-api..amazonaws.com/prod/shorten
In the Body tab, select raw and choose JSON as the format.
Add the following JSON payload to the body:

{
  "long_url": "https://www.example.com"
}

Click Send

If everything works correctly, you should receive a response with a short_code

Redirect to the Original URL:

Create a new request in Postman, set it to GET, and enter the following URL:

https://.execute-api..amazonaws.com/prod/redirect?short_code=
Replace with the code you received from the previous step.
Click Send

You should be redirected to the original URL

Testing Using Command Prompt or PowerShell

If you prefer using the Command Prompt or PowerShell, you can test the API using Invoked.

Create a Short URL:

Open Command Prompt or PowerShell.
Use the following command to send a POST request:

   Invoke-RestMethod -Uri "https://<api-id>.execute-api.<region>.amazonaws.com/prod/shorten" `
    -Method Post `
    -ContentType "application/json" `
    -Body '{"long_url": "https://www.example.com"}'

You should receive a short_code in the response.

Redirect to the Original URL:

Use the following command to send a GET request:

   Invoke-RestMethod -Uri "https://<api-id>.execute-api.<region>.amazonaws.com/prod/redirect?short_code=<short_code>"

Replace <short_code> with the code you received earlier.

You should be redirected to the original URL.

Step 6: Clean Up

After you’ve finished testing and exploring your serverless URL shortener, you should clean up your AWS resources to avoid ongoing charges.

How to Clean Up:

Delete the DynamoDB Table:
- Navigate to DynamoDB in the AWS Management Console.
- Select the URLShortener table, and click Delete.
Delete the Lambda Function:
- Navigate to Lambda in the AWS Management Console.
- Select the URLShortenerFunction function, and click Delete.
Delete the API Gateway:
- Navigate to API Gateway.
- Select the API you created, and click Delete.

Conclusion

In this tutorial, we’ve built a simple yet scalable serverless URL shortener using AWS Lambda, API Gateway, and DynamoDB. This solution is lightweight and fully serverless, which means you only pay for the compute power you use and the resources you consume.

We covered the following key components:

DynamoDB for storing short codes and URLs.
AWS Lambda for handling the logic of generating short codes and redirecting users.
API Gateway to expose HTTP routes and connect the Lambda functions to the web.

With this knowledge, you can build other serverless applications using AWS services. Feel free to explore further and enhance this project by adding features like analytics, user authentication, or custom domains.

Contributing

Feel free to contribute to this project by opening issues or submitting pull requests. Here’s how you can help:

Add new features or improve existing ones.
Write documentation or tutorials.
Fix bugs or optimize the code.

Check out the repository: GitHub - [Mini Project] Serverless URL Shortener

Embracing the AWS Community: Unpacking My AWS Community Builder Welcome Swag Kit 🚀

Tapas SInghal — Tue, 26 Dec 2023 14:19:58 +0000

Introduction

Hello fellow developers and AWS enthusiasts! I am beyond excited to share my recent experience as a proud recipient of the AWS Community Builder 1st Welcome Swag Kit! 🙌 The joy was doubled as I had the incredible honor of not only receiving the standard welcome kit but also winning two extra premium swags - the "T-shirt of Building" and the "Builder Hoodie of Protection" in a thrilling trivia and movie guessing contest hosted by the amazing Jason Dunn.

What is the AWS Community Builder Program?

For those unfamiliar with the AWS Community Builder Program and its offerings, you can find more details here. This vibrant community is designed for developers and enthusiasts to learn, connect, and collaborate on all things AWS.

The Swag Unveiling

Let me take you through the contents of the welcome swag kit, which included a diary and pen for note-taking, a sleek tumbler for those long coding sessions, a collection of vibrant stickers to personalize my workspace, AWS badges that symbolize my commitment to the community, and handy sticky notes for quick reminders. Each item is not just a swag but a thoughtful addition to my developer's toolkit.

Premium Bonus Swags

As if the welcome kit wasn't exciting enough, the first welcome call meeting challenges brought an extra layer of fun and rewards. I am proud to say that I emerged victorious, earning not one but two premium bonus swags. The "Builder Hoodie of Protection" is a comfy, ultra-soft, and incredibly stylish addition to my wardrobe, while the "T-shirt of Building" is another badge of honor that I wear with pride.

Fun and Learning with Jason Dunn

A significant highlight of this journey was the engaging trivia and movie guessing contest hosted by Jason Dunn. It was not only a blast but also a fantastic opportunity to showcase our knowledge, connect with fellow community members, and, of course, win those coveted premium swags.

Video Showcase

For a closer look at these fantastic swags, I've put together a video. Check it out here.

Expressing Gratitude

A heartfelt thank you to Amazon Web Services (AWS), Jason Dunn, Shafraz Rahim, and all other community managers for orchestrating this wonderful experience and providing these amazing goodies! 🎉 Your efforts are truly appreciated.

Conclusion

Being part of the AWS Community Builder Program has been an enriching experience, and the welcome swag kit, along with the bonus premium swags, serves as a tangible symbol of the warmth and camaraderie within the AWS community. I eagerly anticipate continued learning, connecting, and collaborating with fellow developers.

Project - Implement Blue/Green deployment of Python (Django) Application on AWS Elastic Beanstalk

Tapas SInghal — Fri, 06 Oct 2023 13:47:30 +0000

buddydome

Result:- www.buddydome.cloud
Github Repo:- https://github.com/its-tapas/buddydome

Major AWS Services used :-

RDS
S3
ELASTICBEANSTALK
ROUTE53

Step-1: Create an AWS database instance of postgreSql database ( Compulsory in both )

    -Login to AWS console and head toward for RDS Service
    -Launch an Postgresql Database instance and note down the username,master username and password of the instance ( it will be shown one time only so make sure to note them down very carefully)
    -Wait for the database instance to be in running state ( Takes approximately 10 min)
    -After Launched, click on the instance and it will show the details of your database
    -Open Django project's Settings.py file, there you will see a section "DATABASE" IN LINE 85 
          >>> Change name to the username to saved earlier
          >>> Change Username to master username
          >>> Change Password to new Password
          >>> Change Host to new host which is shown exactly on aws console database instance page
    -SAVE CHANGES

Step-2: (Follow only if you are working with BuddyDome with s3 only otherwise ignore this step) Setting up S3 bucket

Create an s3 bucket ( with unchecking the box of " Block all public access" )

Change the bucket policy as follows

//S3 Policy//

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::s3-bucket/*"
        }
    ]
}

Create an IAM user

        >>>In AWS Look for IAM service 
        >>>Create an IAM user with S3 Policy
        >>>Generate Access key and secret key and note them down

Go to your Django project and first install two libraries using following command

         pip install boto3 django-storages

Add Following in settings.py file

          import boto3
          from storages.backends.s3boto3 import S3Boto3Storage


          INSTALLED_APPS = [ 
                  'storages'
                  ]

          //Write Corresponding Values//
          AWS_ACCESS_KEY_ID =
          AWS_SECRET_ACCESS_KEY = 
          AWS_STORAGE_BUCKET_NAME = 
          AWS_S3_REGION_NAME='ap-south-1'

          AWS_QUERYSTRING_AUTH = False


          # Set the static files storage backend to S3
          STATICFILES_STORAGE = "storages.backends.s3boto3.S3Boto3Storage"

          # Set the URL for static files
          STATIC_URL = f"https://{AWS_STORAGE_BUCKET_NAME}.s3.amazonaws.com/static/"

          AWS_LOCATION = 'media'

          DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

          # Set the URL for media files
          MEDIA_URL = f"https://{AWS_STORAGE_BUCKET_NAME}.s3.amazonaws.com/{AWS_LOCATION}/"

          STATIC_ROOT = "https://s3.amazonaws.com/my-static-bucket/"
          MEDIA_ROOT = "https://s3.amazonaws.com/my-media-bucket/"

Some Changes in all urls.py file

//urls.py//

          from Buddy import settings
          from django.conf.urls.static import static

//In URL_patterns ending Square bracket Add below code as it is//

           +static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)+ static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Step-3: Deployment Using AWS Elastic Beanstalk( Compulsory in Both)

Install Elastic Beanstalk CLI using following:-

     pip install awsebcli

Create a Config file to speicify settings file and .conf file to specify upload limit for your elasticbeasntalk environment in following format

    ~/BuddyDome/
    |-- .ebextensions
    |   `-- django.config
    |-- .platform
    |   --nginx
    |        --conf.d
    |                `--proxy.conf

Write the following in django.config file

    container_commands:
      01_collectstatic:
        command: "source $PYTHONPATH/activate && python manage.py collectstatic --noinput"
    option_settings:
      aws:elasticbeanstalk:container:python:
        WSGIPath: Buddy.wsgi:application
      aws:elasticbeanstalk:environment:proxy:staticfiles:
        static: "static"

Write the Following in proxy.conf

    client_max_body_size 400M;

In terminal initialize the application for elasticbeanstalk using awsebcli

Make sure you are in main directory where you can access manage.py file ( Use dir or ls command to verify)

    eb init -i

    Select a default region 
    (Default is 3): 6  

    application name: Buddydome

    Enter Application Name
    (default is "BuddyDome "): BuddyDome

    Select a platform
    (make a selection): 9       //Python

    Select a platform branch. 3

In Terminal Create Elastic beanstalk environment:-

    eb create Buddydome-env

use the following to get the status and to open the deployed application:-

    eb status
    eb open

Use the following only in case you make some changes after environment creation

    eb deploy

Step-4 : Setting Up DNS (Route53 and Hostinger)

Go to Route53 and create a "Hosted Zone" with corresponding Hostinger domain name ( e.g. buddydome.cloud)
Change Hostinger Nameservers to Route53 Generated Nameservers (changes might take upto 24hr)
In Hosted Zone, create a "A" type Record
- Leave Subdomain as blank
- Toggle "Alias"
- In Endpoint, choose Alias to "Elastic Beanstalk environment"
- CHoose Corresponding Region, ap-south-1 "Asia Pacific (Mumbai)"
- Choose Environment, select the corresponding elasticbeanstalk environment that directs to Buddydome Project
- > > Write "www" in subdomain
- > > Choose Type as "CNAME"
- > > In Value write original domain i.e. buddydome.cloud
- Click "Create Records"

Note:- You can add more subdomains similarly by adding another record

With this your application has been successfully deployed and hosted with a Domain