DEV Community: Prashik besekar

5 Python Scripts Every AWS Developer Should Have

Prashik besekar — Tue, 31 Mar 2026 07:25:45 +0000

Save these. Run these. Thank me later.

Why I Wrote This

When I started learning AWS I spent hours doing repetitive tasks manually.

Checking instance status in the console. Downloading files from S3 one by one. Manually checking my bill every week. Logging into EC2 just to check if it was running.

Then I discovered something — everything I was doing manually could be automated with Python and boto3 in minutes.

These are the 5 scripts I wish someone had given me when I started. Each one solves a real problem. Each one saves real time. And every AWS developer — beginner or experienced — should have these in their toolkit. 🐍

Script 1 — EC2 Instance Manager

The problem: Forgetting to stop EC2 instances and getting unexpected bills.

The solution: A complete EC2 manager that lets you start, stop, and check all your instances from terminal in seconds.

import boto3
import sys
from datetime import datetime

def get_ec2_client(region='ap-south-1'):
    return boto3.client('ec2', region_name=region)

def list_all_instances():
    ec2 = get_ec2_client()
    response = ec2.describe_instances()

    print("\n" + "="*60)
    print(f"{'ID':<22} {'Type':<12} {'State':<12} {'IP':<16} {'Name'}")
    print("="*60)

    for reservation in response['Reservations']:
        for instance in reservation['Instances']:
            instance_id = instance['InstanceId']
            instance_type = instance['InstanceType']
            state = instance['State']['Name']
            public_ip = instance.get('PublicIpAddress', 'No IP')

            name = 'No Name'
            if instance.get('Tags'):
                for tag in instance['Tags']:
                    if tag['Key'] == 'Name':
                        name = tag['Value']

            # Color code by state
            state_display = f"🟢 {state}" if state == 'running' else f"🔴 {state}"
            print(f"{instance_id:<22} {instance_type:<12} {state:<12} {public_ip:<16} {name}")

    print("="*60 + "\n")

def start_instance(instance_id):
    ec2 = get_ec2_client()
    print(f"⏳ Starting {instance_id}...")
    ec2.start_instances(InstanceIds=[instance_id])

    waiter = ec2.get_waiter('instance_running')
    waiter.wait(InstanceIds=[instance_id])

    response = ec2.describe_instances(InstanceIds=[instance_id])
    ip = response['Reservations'][0]['Instances'][0].get('PublicIpAddress', 'No IP')
    print(f"✅ Instance started! Public IP: {ip}")

def stop_instance(instance_id):
    ec2 = get_ec2_client()
    print(f"⏳ Stopping {instance_id}...")
    ec2.stop_instances(InstanceIds=[instance_id])

    waiter = ec2.get_waiter('instance_stopped')
    waiter.wait(InstanceIds=[instance_id])
    print(f"✅ Instance stopped! You are no longer being charged.")

def main():
    if len(sys.argv) < 2:
        print("Usage:")
        print("  python ec2_manager.py list")
        print("  python ec2_manager.py start <instance-id>")
        print("  python ec2_manager.py stop <instance-id>")
        return

    command = sys.argv[1].lower()

    if command == 'list':
        list_all_instances()
    elif command == 'start' and len(sys.argv) == 3:
        start_instance(sys.argv[2])
    elif command == 'stop' and len(sys.argv) == 3:
        stop_instance(sys.argv[2])
    else:
        print("Invalid command. Use: list, start, or stop")

if __name__ == '__main__':
    main()

How to use:

python ec2_manager.py list                          # See all instances
python ec2_manager.py start i-0abc123def456789     # Start instance
python ec2_manager.py stop i-0abc123def456789      # Stop instance

Why this saves you: Never forget a running instance again. Check everything in 2 seconds from terminal. 💰

Script 2 — S3 File Manager

The problem: Uploading, downloading, and managing S3 files through the console is slow and tedious.

The solution: A Python script that handles all S3 operations from your terminal.

import boto3
import os
import sys
from pathlib import Path

def get_s3_client():
    return boto3.client('s3', region_name='ap-south-1')

def list_buckets():
    s3 = get_s3_client()
    response = s3.list_buckets()

    print("\n📦 Your S3 Buckets:")
    print("-" * 40)
    for bucket in response['Buckets']:
        print(f"  • {bucket['Name']} (created: {bucket['CreationDate'].strftime('%Y-%m-%d')})")
    print()

def list_files(bucket_name, prefix=''):
    s3 = get_s3_client()

    try:
        response = s3.list_objects_v2(Bucket=bucket_name, Prefix=prefix)

        if 'Contents' not in response:
            print(f"📭 Bucket '{bucket_name}' is empty")
            return

        print(f"\n📁 Files in {bucket_name}/{prefix}:")
        print("-" * 50)

        total_size = 0
        for obj in response['Contents']:
            size_kb = obj['Size'] / 1024
            total_size += obj['Size']
            print(f"  • {obj['Key']} ({size_kb:.1f} KB) — {obj['LastModified'].strftime('%Y-%m-%d')}")

        print(f"\n  Total: {len(response['Contents'])} files ({total_size/1024:.1f} KB)\n")

    except Exception as e:
        print(f"❌ Error: {e}")

def upload_file(local_path, bucket_name, s3_key=None):
    s3 = get_s3_client()

    if not os.path.exists(local_path):
        print(f"❌ File not found: {local_path}")
        return

    if s3_key is None:
        s3_key = Path(local_path).name

    file_size = os.path.getsize(local_path) / 1024
    print(f"⏳ Uploading {local_path} ({file_size:.1f} KB) to s3://{bucket_name}/{s3_key}...")

    try:
        s3.upload_file(local_path, bucket_name, s3_key)
        print(f"✅ Upload successful!")
        print(f"   URL: https://{bucket_name}.s3.amazonaws.com/{s3_key}")
    except Exception as e:
        print(f"❌ Upload failed: {e}")

def download_file(bucket_name, s3_key, local_path=None):
    s3 = get_s3_client()

    if local_path is None:
        local_path = Path(s3_key).name

    print(f"⏳ Downloading s3://{bucket_name}/{s3_key} to {local_path}...")

    try:
        s3.download_file(bucket_name, s3_key, local_path)
        file_size = os.path.getsize(local_path) / 1024
        print(f"✅ Download successful! ({file_size:.1f} KB saved to {local_path})")
    except Exception as e:
        print(f"❌ Download failed: {e}")

def delete_file(bucket_name, s3_key):
    s3 = get_s3_client()

    confirm = input(f"⚠️  Delete s3://{bucket_name}/{s3_key}? (yes/no): ")
    if confirm.lower() != 'yes':
        print("Cancelled.")
        return

    try:
        s3.delete_object(Bucket=bucket_name, Key=s3_key)
        print(f"✅ File deleted successfully!")
    except Exception as e:
        print(f"❌ Delete failed: {e}")

# Quick usage
if __name__ == '__main__':
    # List all buckets
    list_buckets()

    # Example usage — replace with your bucket name
    BUCKET = 'your-bucket-name'

    # List files
    list_files(BUCKET)

    # Upload a file
    # upload_file('myfile.txt', BUCKET)

    # Download a file
    # download_file(BUCKET, 'myfile.txt', 'downloaded_file.txt')

Why this saves you: No more clicking through S3 console. Upload, download, delete from terminal in seconds. ⚡

Script 3 — AWS Cost Tracker

The problem: AWS bills surprise you at end of month.

The solution: Check your costs any time in seconds — broken down by service.

import boto3
from datetime import datetime, timedelta

def get_aws_costs(days=30):
    # Cost Explorer is only in us-east-1
    ce = boto3.client('ce', region_name='us-east-1')

    end_date = datetime.now().strftime('%Y-%m-%d')
    start_date = (datetime.now() - timedelta(days=days)).strftime('%Y-%m-%d')

    print(f"\n💰 AWS Cost Report")
    print(f"Period: {start_date} to {end_date}")
    print("="*50)

    try:
        response = ce.get_cost_and_usage(
            TimePeriod={'Start': start_date, 'End': end_date},
            Granularity='MONTHLY',
            Metrics=['UnblendedCost'],
            GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
        )

        total_cost = 0
        service_costs = []

        for result in response['ResultsByTime']:
            for group in result['Groups']:
                service = group['Keys'][0]
                cost = float(group['Metrics']['UnblendedCost']['Amount'])
                if cost > 0.001:
                    service_costs.append((service, cost))
                    total_cost += cost

        # Sort by cost — highest first
        service_costs.sort(key=lambda x: x[1], reverse=True)

        for service, cost in service_costs:
            inr = cost * 83
            bar = "█" * int(cost / total_cost * 20)
            print(f"{service[:35]:<35} ${cost:.4f} (₹{inr:.2f}) {bar}")

        print("="*50)
        print(f"{'TOTAL':<35} ${total_cost:.4f} (₹{total_cost*83:.2f})")

        # Warning if cost is high
        if total_cost > 5:
            print(f"\n⚠️  WARNING: Your bill is above $5!")
            print("Check for forgotten resources — NAT Gateways, Load Balancers, EC2 instances")
        else:
            print(f"\n✅ Cost is within safe range")

    except Exception as e:
        print(f"❌ Error fetching costs: {e}")
        print("Make sure Cost Explorer is enabled in your AWS account")

def check_free_tier_usage():
    print("\n📊 Checking key services usage...")

    ec2 = boto3.client('ec2', region_name='ap-south-1')
    s3 = boto3.client('s3', region_name='ap-south-1')

    # Count running instances
    response = ec2.describe_instances(
        Filters=[{'Name': 'instance-state-name', 'Values': ['running']}]
    )
    running_count = sum(len(r['Instances']) for r in response['Reservations'])
    print(f"  EC2 Running Instances: {running_count}")

    if running_count > 0:
        print(f"  ⚠️  Remember: Free tier only covers 750 hours/month for t2.micro")

    # Count S3 buckets
    buckets = s3.list_buckets()['Buckets']
    print(f"  S3 Buckets: {len(buckets)}")
    print()

if __name__ == '__main__':
    get_aws_costs(days=30)
    check_free_tier_usage()

How to use:

python cost_tracker.py

Why this saves you: Know exactly what you're spending before the bill arrives. No more surprises. 💸

Script 4 — Automatic S3 Backup System

The problem: Important files on your EC2 or local machine could be lost anytime.

The solution: Automatic daily backup to S3 with timestamps.

import boto3
import os
import gzip
import shutil
from datetime import datetime
from pathlib import Path

def backup_to_s3(source_path, bucket_name, backup_prefix='backups'):
    s3 = boto3.client('s3', region_name='ap-south-1')

    timestamp = datetime.now().strftime('%Y-%m-%d_%H-%M-%S')

    print(f"\n🔄 Starting backup at {timestamp}")
    print(f"Source: {source_path}")
    print(f"Destination: s3://{bucket_name}/{backup_prefix}/")
    print("-"*50)

    backed_up = 0
    failed = 0
    total_size = 0

    source = Path(source_path)

    if source.is_file():
        files = [source]
    else:
        files = list(source.rglob('*'))
        files = [f for f in files if f.is_file()]

    for file_path in files:
        try:
            if source.is_dir():
                relative_path = file_path.relative_to(source)
                s3_key = f"{backup_prefix}/{timestamp}/{relative_path}"
            else:
                s3_key = f"{backup_prefix}/{timestamp}/{file_path.name}"

            file_size = file_path.stat().st_size
            total_size += file_size

            s3.upload_file(str(file_path), bucket_name, s3_key)
            print(f"  ✅ {file_path.name} ({file_size/1024:.1f} KB)")
            backed_up += 1

        except Exception as e:
            print(f"  ❌ Failed: {file_path.name} — {e}")
            failed += 1

    print("-"*50)
    print(f"✅ Backup complete!")
    print(f"   Files backed up: {backed_up}")
    print(f"   Failed: {failed}")
    print(f"   Total size: {total_size/1024:.1f} KB")
    print(f"   S3 location: s3://{bucket_name}/{backup_prefix}/{timestamp}/")

def list_backups(bucket_name, backup_prefix='backups'):
    s3 = boto3.client('s3', region_name='ap-south-1')

    response = s3.list_objects_v2(
        Bucket=bucket_name,
        Prefix=backup_prefix,
        Delimiter='/'
    )

    print(f"\n📦 Available backups in s3://{bucket_name}/{backup_prefix}/:")

    if 'CommonPrefixes' not in response:
        print("  No backups found")
        return

    for prefix in response['CommonPrefixes']:
        backup_name = prefix['Prefix'].split('/')[-2]
        print(f"  • {backup_name}")

if __name__ == '__main__':
    # Configuration — change these
    BUCKET_NAME = 'your-backup-bucket'
    SOURCE_PATH = '/path/to/your/files'  # File or folder to backup

    # Run backup
    backup_to_s3(SOURCE_PATH, BUCKET_NAME)

    # List all backups
    list_backups(BUCKET_NAME)

    # To automate daily — add to crontab:
    # 0 2 * * * /usr/bin/python3 /home/ubuntu/backup.py
    # This runs every day at 2am automatically

Why this saves you: Never lose important files. Automated backups running while you sleep. 🛡️

Script 5 — AWS Security Checker

The problem: Security misconfigurations in AWS can expose your entire infrastructure.

The solution: A script that automatically scans your AWS account for common security issues.

import boto3

def check_aws_security():
    print("\n🔐 AWS Security Check")
    print("="*50)

    issues_found = 0
    checks_passed = 0

    ec2 = boto3.client('ec2', region_name='ap-south-1')
    iam = boto3.client('iam')

    # Check 1 — Security Groups with open SSH
    print("\n📋 Checking Security Groups...")
    response = ec2.describe_security_groups()

    for sg in response['SecurityGroups']:
        for rule in sg.get('IpPermissions', []):
            if rule.get('FromPort') == 22:
                for ip_range in rule.get('IpRanges', []):
                    if ip_range.get('CidrIp') == '0.0.0.0/0':
                        print(f"  ⚠️  {sg['GroupName']} — SSH open to ALL (0.0.0.0/0)")
                        print(f"     Fix: Restrict SSH to your IP only")
                        issues_found += 1

    if issues_found == 0:
        print("  ✅ No security groups with open SSH found")
        checks_passed += 1

    # Check 2 — IAM Users without MFA
    print("\n📋 Checking IAM Users for MFA...")
    users = iam.list_users()['Users']

    mfa_issues = 0
    for user in users:
        mfa_devices = iam.list_mfa_devices(UserName=user['UserName'])['MFADevices']
        if not mfa_devices:
            print(f"  ⚠️  User '{user['UserName']}' has NO MFA enabled")
            mfa_issues += 1
            issues_found += 1

    if mfa_issues == 0:
        print("  ✅ All IAM users have MFA enabled")
        checks_passed += 1

    # Check 3 — Old Access Keys
    print("\n📋 Checking Access Key Age...")
    from datetime import datetime, timezone

    old_key_issues = 0
    for user in users:
        keys = iam.list_access_keys(UserName=user['UserName'])['AccessKeyMetadata']
        for key in keys:
            if key['Status'] == 'Active':
                age = (datetime.now(timezone.utc) - key['CreateDate']).days
                if age > 90:
                    print(f"  ⚠️  {user['UserName']} — Access key is {age} days old")
                    print(f"     Fix: Rotate keys every 90 days")
                    old_key_issues += 1
                    issues_found += 1

    if old_key_issues == 0:
        print("  ✅ All access keys are less than 90 days old")
        checks_passed += 1

    # Check 4 — Public S3 Buckets
    print("\n📋 Checking S3 Bucket Public Access...")
    s3 = boto3.client('s3')
    buckets = s3.list_buckets()['Buckets']

    public_bucket_issues = 0
    for bucket in buckets:
        try:
            acl = s3.get_bucket_acl(Bucket=bucket['Name'])
            for grant in acl['Grants']:
                if grant['Grantee'].get('URI', '') == 'http://acs.amazonaws.com/groups/global/AllUsers':
                    print(f"  ⚠️  Bucket '{bucket['Name']}' is PUBLIC")
                    print(f"     Fix: Remove public access unless intentional")
                    public_bucket_issues += 1
                    issues_found += 1
        except:
            pass

    if public_bucket_issues == 0:
        print("  ✅ No unexpected public S3 buckets found")
        checks_passed += 1

    # Final Report
    print("\n" + "="*50)
    print(f"🔐 Security Check Complete")
    print(f"   ✅ Checks passed: {checks_passed}")
    print(f"   ⚠️  Issues found: {issues_found}")

    if issues_found == 0:
        print("\n🎉 Your AWS account looks secure!")
    else:
        print(f"\n⚠️  Fix {issues_found} issue(s) to improve your security")
    print()

if __name__ == '__main__':
    check_aws_security()

Why this saves you: Catch security issues before attackers do. Run this weekly. 🔒

How to Set Up All 5 Scripts

# 1. Install dependencies
pip install boto3

# 2. Configure AWS credentials
aws configure

# 3. Create a folder for your scripts
mkdir aws-python-scripts
cd aws-python-scripts

# 4. Save each script as:
# ec2_manager.py
# s3_manager.py
# cost_tracker.py
# backup.py
# security_checker.py

# 5. Run any script
python ec2_manager.py list
python cost_tracker.py
python security_checker.py

Put These on GitHub Right Now

Create a repo called aws-python-scripts and push all 5 scripts.

This becomes a real portfolio project showing:

Python proficiency ✅
AWS knowledge ✅
Security awareness ✅
Automation skills ✅
Clean code practices ✅

Mention it in every job application. Link it in your resume. 💪

Quick Reference

Script	What it does	Run with
ec2_manager.py	Manage EC2 instances	`python ec2_manager.py list`
s3_manager.py	Manage S3 files	`python s3_manager.py`
cost_tracker.py	Track AWS costs	`python cost_tracker.py`
backup.py	Backup files to S3	`python backup.py`
security_checker.py	Check security issues	`python security_checker.py`

Final Thoughts

These 5 scripts represent something important.

The difference between a developer who uses AWS and a developer who masters AWS — is automation.

Anyone can click buttons in the AWS console. But the developer who automates repetitive tasks, monitors costs, secures infrastructure, and backs up data automatically — that's the developer companies want to hire.

Save these scripts. Customize them. Put them on GitHub. Use them in interviews.

They're yours now. 💪

Follow LearnWithPrashik for more practical AWS and Python content.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

I Built a Real AI Chatbot With AWS Bedrock and Python in 30 Minutes

Prashik besekar — Thu, 26 Mar 2026 08:37:37 +0000

No OpenAI API key needed. No expensive subscriptions. Just AWS and Python.

Why I Built This

Everyone is talking about AI chatbots.

But every tutorial I found required:

OpenAI API key (costs money)
Complex setup
Third party services
Hours of configuration

Then I discovered AWS Bedrock.

Bedrock gives you access to powerful AI models — Claude, Llama, Mistral — directly through your existing AWS account. No separate subscription. No new account. Just boto3 and Python.

I built a working AI chatbot in 30 minutes. Here's exactly how. 🚀

What We're Building

By the end of this article you'll have:

✅ A working AI chatbot in Python
✅ Powered by Claude model via AWS Bedrock
✅ Runs from your terminal
✅ Remembers conversation history
✅ Handles errors gracefully

Let's build it. ⏱️

Prerequisites

Before starting make sure you have:

AWS account (free tier works)
Python installed
boto3 installed (pip install boto3)
AWS credentials configured (aws configure)

That's it. Nothing else needed. ✅

Step 1 — Enable AWS Bedrock Access (5 minutes)

By default Bedrock models are not enabled. You need to request access first.

1. Go to AWS Console → Amazon Bedrock
2. Click "Model access" in left sidebar
3. Click "Manage model access"
4. Select "Claude" models (Anthropic)
5. Click "Request model access"
6. Wait 2-3 minutes for approval

Once approved you'll see green checkmarks next to Claude models. ✅

Important: Bedrock is available in specific regions. Use us-east-1 (N. Virginia) for best model availability.

Step 2 — Test Your First Bedrock API Call (5 minutes)

Before building the chatbot let's make sure everything works.

Create a file called test_bedrock.py:

import boto3
import json

def test_bedrock():
    # Create Bedrock client
    # Note: Use us-east-1 for best model availability
    bedrock = boto3.client(
        service_name='bedrock-runtime',
        region_name='us-east-1'
    )

    # Prepare the request
    body = json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 500,
        "messages": [
            {
                "role": "user",
                "content": "Say hello and tell me what you can help with in one sentence."
            }
        ]
    })

    # Call Claude model
    response = bedrock.invoke_model(
        body=body,
        modelId="anthropic.claude-3-haiku-20240307-v1:0",
        accept="application/json",
        contentType="application/json"
    )

    # Parse and print response
    response_body = json.loads(response.get('body').read())
    message = response_body['content'][0]['text']
    print(f"AI Response: {message}")

test_bedrock()

Run it:

python test_bedrock.py

If you see an AI response — everything is working! 🎉

Step 3 — Build the Complete Chatbot (15 minutes)

Now let's build the real chatbot with conversation memory.

Create a file called chatbot.py:

import boto3
import json
import sys

class BedrockChatbot:
    def __init__(self):
        # Initialize Bedrock client
        self.bedrock = boto3.client(
            service_name='bedrock-runtime',
            region_name='us-east-1'
        )

        # Model ID — Claude Haiku is fast and cost effective
        self.model_id = "anthropic.claude-3-haiku-20240307-v1:0"

        # Conversation history — this gives chatbot memory
        self.conversation_history = []

        # System prompt — defines chatbot personality
        self.system_prompt = """You are a helpful AI assistant specializing in 
        AWS cloud services and Python development. You give clear, practical 
        answers with code examples when relevant. Keep responses concise and useful."""

        print("🤖 AWS Bedrock Chatbot initialized!")
        print("Type 'quit' to exit, 'clear' to reset conversation\n")

    def chat(self, user_message):
        # Add user message to history
        self.conversation_history.append({
            "role": "user",
            "content": user_message
        })

        # Prepare request body
        body = json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 1000,
            "system": self.system_prompt,
            "messages": self.conversation_history
        })

        try:
            # Call Bedrock API
            response = self.bedrock.invoke_model(
                body=body,
                modelId=self.model_id,
                accept="application/json",
                contentType="application/json"
            )

            # Parse response
            response_body = json.loads(response.get('body').read())
            assistant_message = response_body['content'][0]['text']

            # Add assistant response to history
            # This is what gives the chatbot memory of conversation
            self.conversation_history.append({
                "role": "assistant",
                "content": assistant_message
            })

            return assistant_message

        except Exception as e:
            error_msg = f"Error calling Bedrock: {str(e)}"
            print(f"❌ {error_msg}")
            # Remove failed message from history
            self.conversation_history.pop()
            return None

    def clear_history(self):
        self.conversation_history = []
        print("✅ Conversation history cleared!\n")

    def run(self):
        print("=" * 50)
        print("   AWS Bedrock AI Chatbot")
        print("   Powered by Claude via Amazon Bedrock")
        print("=" * 50)
        print()

        while True:
            # Get user input
            try:
                user_input = input("You: ").strip()
            except KeyboardInterrupt:
                print("\n\nGoodbye! 👋")
                break

            # Handle special commands
            if not user_input:
                continue

            if user_input.lower() == 'quit':
                print("Goodbye! 👋")
                break

            if user_input.lower() == 'clear':
                self.clear_history()
                continue

            if user_input.lower() == 'history':
                print(f"\n📝 Conversation has {len(self.conversation_history)} messages\n")
                continue

            # Get AI response
            print("\n🤖 AI: ", end="", flush=True)
            response = self.chat(user_input)

            if response:
                print(response)

            print()

# Run the chatbot
if __name__ == "__main__":
    chatbot = BedrockChatbot()
    chatbot.run()

Run it:

python chatbot.py

Step 4 — See It In Action

Here's what a real conversation looks like:

==================================================
   AWS Bedrock AI Chatbot
   Powered by Claude via Amazon Bedrock
==================================================

You: What is AWS Lambda?

🤖 AI: AWS Lambda is a serverless compute service that runs your code 
in response to events without requiring you to manage servers. You pay 
only for the compute time you consume — there's no charge when your 
code is not running.

Key benefits:
- No server management
- Automatic scaling
- Pay per use
- Supports Python, Node.js, Java, and more

You: Can you show me a simple Python Lambda function?

🤖 AI: Here's a simple Python Lambda function:

def lambda_handler(event, context):
    name = event.get('name', 'World')
    return {
        'statusCode': 200,
        'body': f'Hello, {name}!'
    }

Notice the chatbot remembers you asked about Lambda!

You: clear
✅ Conversation history cleared!

You: quit
Goodbye! 👋

Your AI chatbot is working! 🎉

Step 5 — Make It Better (5 minutes)

Let's add a few improvements:

Add conversation saving

import json
from datetime import datetime

def save_conversation(self):
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    filename = f"conversation_{timestamp}.json"

    with open(filename, 'w') as f:
        json.dump(self.conversation_history, f, indent=2)

    print(f"✅ Conversation saved to {filename}")

Add to your chatbot's run() method:

if user_input.lower() == 'save':
    self.save_conversation()
    continue

Change the personality

Want a different chatbot? Just change the system prompt:

# Customer support bot
self.system_prompt = "You are a friendly customer support agent. Be helpful and empathetic."

# Code review bot  
self.system_prompt = "You are an expert code reviewer. Review code for bugs, security issues, and improvements."

# Interview prep bot
self.system_prompt = "You are a technical interviewer. Ask coding and system design questions."

One line change. Completely different chatbot. 🔥

How Much Does This Cost?

This is the question everyone asks. Let me be honest.

AWS Bedrock pricing (Claude Haiku):

Input tokens: $0.00025 per 1,000 tokens
Output tokens: $0.00125 per 1,000 tokens

What that means in real terms:

One average conversation (20 messages): ~$0.002 (less than 0.2 rupees!)
100 conversations per day: ~$0.20 per day (about ₹17)
For personal use and learning: practically free

This is why Bedrock is perfect for developers learning AI — the cost is negligible. ✅

Common Errors and Fixes

Error 1 — AccessDeniedException

botocore.exceptions.ClientError: AccessDeniedException

Fix: You haven't requested model access yet. Go to Bedrock console → Model access → Enable Claude models.

Error 2 — Could not connect to endpoint

EndpointResolutionError: Could not resolve endpoint

Fix: Bedrock is not available in all regions. Change region to us-east-1.

Error 3 — ValidationException

ValidationException: The provided model identifier is invalid

Fix: Double check the model ID. Use exactly: anthropic.claude-3-haiku-20240307-v1:0

What You Just Built

Let's appreciate what you created in 30 minutes 👇

✅ Real AI chatbot powered by Claude
✅ Conversation memory across messages
✅ Customizable personality via system prompt
✅ Error handling
✅ Conversation saving
✅ Running on AWS infrastructure

This is not a toy. This is production-quality foundation code.

With a few more hours you could add:

Web interface with Flask
Deploy on AWS Lambda
Connect to a database
Add user authentication

Why This Matters For Your Career

Here's something important yaar.

Most developers applying for jobs in 2026 know EITHER cloud OR AI.

You now know BOTH — AWS infrastructure AND AI integration.

That combination is genuinely rare and genuinely valuable.

Put this project on your GitHub. Add "AWS Bedrock" and "LLM Integration" to your LinkedIn. Mention it in interviews.

You just joined a very small group of developers who have actually built something with AWS AI services. 💪

What's Next?

Now that you have a working chatbot — here's what to build next:

Add a web interface — Flask + Bedrock chatbot
Deploy to AWS Lambda — serverless chatbot API
Add RAG — chatbot that answers from your documents
Connect to S3 — chatbot that reads your files

I'll be writing about all of these. Follow LearnWithPrashik so you don't miss them! 🙌

Final Thoughts

AWS Bedrock removes the biggest barrier to AI development — cost and complexity.

You don't need an expensive OpenAI subscription. You don't need a new account. You don't need complex setup.

Just your existing AWS account, Python, and boto3.

30 minutes from zero to working AI chatbot.

Now go build something with it. 💪

Follow LearnWithPrashik for more practical AWS and AI development content.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

EC2 vs Lambda — When to Use Which (With Real Examples)

Prashik besekar — Fri, 20 Mar 2026 08:39:23 +0000

The question every AWS developer gets asked. Here's the honest, practical answer.

The Confusion Is Real

When I first started learning AWS I was genuinely confused.

Both EC2 and Lambda run your code on AWS infrastructure. Both scale. Both are used by millions of companies.

So why do both exist? When do you use one over the other?

I spent weeks reading documentation and tutorials that gave me theoretical answers but no real clarity.

So I built things with both. Made mistakes with both. And now I'm writing the guide I wish existed when I started.

Let's settle this once and for all. 🚀

Quick Overview — What Are They?

EC2 (Elastic Compute Cloud)

EC2 is a virtual server in the cloud.

Think of it like renting a computer from AWS. You get a machine with a specific CPU, RAM, and storage. You install whatever you want on it. You run whatever you want on it. It runs 24/7 until you stop it.

You are responsible for:

The operating system
Installing software
Managing updates
Scaling when needed
Security configuration

Lambda

Lambda is serverless computing.

Think of it like a function that runs only when called. You write code. AWS runs it when triggered. You pay only for the exact milliseconds it runs. When it's not running — you pay nothing.

You are responsible for:

Just your code
Nothing else

AWS handles everything else automatically.

The Key Differences — Simple Table

Feature	EC2	Lambda
Server management	You manage everything	AWS manages everything
Pricing	Pay per hour running	Pay per millisecond executed
Max runtime	Unlimited	15 minutes maximum
Startup time	Minutes	Milliseconds
Scaling	Manual or Auto Scaling	Automatic instantly
State	Stateful — keeps data	Stateless — no memory between runs
Use case	Long running processes	Short event-driven tasks
Cost when idle	Costs money always	Costs nothing

EC2 — When to Use It

Use EC2 when your application runs continuously

If your application needs to be running 24/7 — EC2 is the right choice.

Real examples:

A web server serving your website all day
A Node.js API that needs to always be available
A database server running continuously
A background worker processing jobs constantly

# EC2 is perfect for this:
# A Node.js API server running all day
node server.js  # Runs continuously on EC2

Use EC2 when you need more than 15 minutes

Lambda has a hard limit of 15 minutes per execution. If your task takes longer — EC2 is your only option.

Real examples:

Video processing — encoding a 2 hour video
Large data migrations — moving millions of records
Machine learning model training
Complex report generation

Use EC2 when you need full server control

Sometimes you need complete control over the environment.

Real examples:

Custom software that needs specific OS configuration
Legacy applications that can't be broken into functions
Applications with specific hardware requirements
When you need to install custom software or tools

Use EC2 when you have consistent predictable traffic

If you know your traffic is steady and consistent — EC2 is more cost effective.

Traffic pattern where EC2 wins:
Monday 9am - Friday 6pm: 1000 requests/hour consistently
EC2 cost: $0.0116/hour × 24 hours = $0.28/day
Lambda cost at this volume: More expensive

Lambda — When to Use It

Use Lambda for event-driven tasks

Lambda shines when something happens and you need to react to it.

Real examples:

User uploads image to S3 → Lambda resizes it automatically
New record in DynamoDB → Lambda sends notification
API Gateway receives request → Lambda processes it
Scheduled task runs every hour → Lambda executes

# Perfect Lambda use case — resize image when uploaded to S3
import boto3
from PIL import Image
import io

def lambda_handler(event, context):
    s3 = boto3.client('s3')

    # Get the uploaded image details from event
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # Download image
    response = s3.get_object(Bucket=bucket, Key=key)
    image_data = response['Body'].read()

    # Resize image
    image = Image.open(io.BytesIO(image_data))
    image.thumbnail((800, 800))

    # Save resized image
    buffer = io.BytesIO()
    image.save(buffer, format='JPEG')
    buffer.seek(0)

    # Upload resized image
    s3.put_object(
        Bucket=bucket,
        Key=f"resized/{key}",
        Body=buffer
    )

    return {"statusCode": 200, "body": "Image resized successfully"}

This runs only when an image is uploaded. Zero cost when nothing is uploaded. ✅

Use Lambda for unpredictable or spiky traffic

If your traffic is unpredictable — Lambda scales automatically with zero configuration.

Traffic pattern where Lambda wins:
Normal day: 10 requests/hour
Viral moment: 100,000 requests/hour suddenly
Lambda: Scales automatically, handles all requests
EC2: Would crash without manual intervention

Use Lambda for small background tasks

Short tasks that run occasionally are perfect for Lambda.

Real examples:

Send welcome email when user registers
Clean up old files every night
Generate daily report at 6am
Validate data when form is submitted

# Perfect Lambda use case — send welcome email
import boto3

def lambda_handler(event, context):
    ses = boto3.client('ses', region_name='ap-south-1')

    user_email = event['email']
    user_name = event['name']

    ses.send_email(
        Source='hello@yourapp.com',
        Destination={'ToAddresses': [user_email]},
        Message={
            'Subject': {'Data': f'Welcome {user_name}!'},
            'Body': {'Text': {'Data': 'Thanks for joining us!'}}
        }
    )

    return {"statusCode": 200}

Runs only when someone registers. Costs fractions of a rupee per execution. ✅

Use Lambda when you want zero server management

If you want to focus purely on code and not worry about servers — Lambda is perfect.

No OS updates. No security patches. No capacity planning. Just write your function and deploy.

Real World Architecture — Using Both Together

Here's the secret most tutorials don't tell you —

Most real applications use BOTH EC2 and Lambda together.

They're not competitors. They're teammates.

Example — A Real Application Architecture

User visits website
        ↓
EC2 — Node.js API Server (runs 24/7)
        ↓
User uploads profile photo
        ↓
Photo saved to S3
        ↓
Lambda triggered automatically
        ↓
Lambda resizes photo to 3 sizes (thumbnail, medium, large)
        ↓
Resized photos saved back to S3
        ↓
EC2 API notified — updates user profile

User registers
        ↓
EC2 saves user to MongoDB
        ↓
Lambda triggered — sends welcome email
        ↓
Another Lambda — creates free trial in billing system

EC2 handles the main application. Lambda handles event-driven tasks around it. Perfect combination. 💪

Cost Comparison — Real Numbers

Scenario 1 — Simple API with low traffic

EC2 t2.micro running 24/7:

Cost: $0.0116/hour × 720 hours = $8.35/month
Whether you get 1 request or 10,000 requests — same cost

Lambda for same API:

100,000 requests/month × avg 200ms = $0.20/month
Pay only for actual usage

Winner for low traffic: Lambda 🏆

Scenario 2 — High traffic application

Lambda at 10 million requests/month:

10M requests × avg 500ms × 512MB memory
Cost: approximately $16.70/month

EC2 t2.medium handling same traffic:

Cost: $0.0464/hour × 720 hours = $33.41/month

Winner for high traffic: Lambda 🏆

Scenario 3 — Always-on complex application

EC2 running a full MERN stack:

Predictable cost — $8-35/month depending on instance
Everything included — database, API, frontend

Lambda for same complex app:

Cold starts add latency
State management is complex
Can become expensive at scale

Winner for always-on complex apps: EC2 🏆

The Decision Framework

Ask yourself these 4 questions:

Question 1: Does it need to run longer than 15 minutes?
YES → EC2
NO → Continue

Question 2: Is it triggered by an event?
YES → Lambda
NO → Continue

Question 3: Is traffic unpredictable or spiky?
YES → Lambda
NO → Continue

Question 4: Do you need full server control?
YES → EC2
NO → Lambda probably works

Common Mistakes I've Seen

Mistake 1 — Using EC2 for everything

Running EC2 24/7 for a task that runs once a day. Lambda would cost 99% less.

Mistake 2 — Using Lambda for long processes

Trying to process a large video with Lambda — it times out at 15 minutes every time.

Mistake 3 — Ignoring cold starts with Lambda

Lambda functions that haven't run recently take 1-3 seconds to start. For real-time APIs this can frustrate users.

Fix: Use Provisioned Concurrency for latency-sensitive Lambdas, or keep them warm with scheduled pings.

Mistake 4 — Not considering state

Lambda is stateless — it doesn't remember anything between invocations. If your application needs to maintain state — EC2 or use external storage like Redis.

Quick Decision Guide

Your situation	Use
Web server always running	EC2
Process triggered by S3 upload	Lambda
Video encoding job	EC2
Send notification on event	Lambda
Machine learning training	EC2
Scheduled daily report	Lambda
Full stack application	EC2
Microservices	Lambda
Unpredictable traffic spikes	Lambda
Consistent steady traffic	EC2

What I Use in My Projects

For my personal projects I use both:

EC2 — for my main Nginx web server that serves my portfolio site. Needs to be always available. Makes sense to run continuously.

Lambda — for small background tasks like sending notifications, processing uploads, and scheduled cleanups. Runs only when needed. Costs almost nothing.

The combination gives me the best of both worlds — reliability from EC2, efficiency from Lambda.

Final Thoughts

EC2 and Lambda are both powerful tools. Neither is universally better.

The right choice depends on your specific use case — how long your task runs, how predictable your traffic is, and how much control you need.

Now you have a clear framework to make that decision every time. 💪

Start with Lambda for new projects — it's simpler to get started and cheaper for low traffic. Add EC2 when you need more control or longer running processes.

And remember — most real applications use both. They're teammates, not competitors.

Follow LearnWithPrashik for more practical AWS and backend development content.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

I Left My AWS EC2 Running for 30 Days — Here's Exactly What It Cost Me

Prashik besekar — Tue, 17 Mar 2026 07:16:12 +0000

The AWS bill that taught me more than any tutorial ever could.

The Mistake Every Beginner Makes

It was 2am.

I had just finished setting up my first production EC2 instance. Nginx configured. CI/CD pipeline working. Website live on the internet.

I was so excited I forgot one small thing.

I forgot to stop the instance.

For 30 days.

When I opened my AWS billing dashboard that month — my heart stopped for a second. I had been running a t2.micro instance 24 hours a day, 7 days a week, for an entire month without realizing it.

Today I'm sharing exactly what it cost me, what I learned, and how you can avoid the same mistake. 💸

My EC2 Setup — What Was Running

Before I share the numbers let me tell you exactly what I had running:

Instance type: t2.micro (free tier eligible)
Region: ap-south-1 (Mumbai)
Operating system: Ubuntu 22.04 LTS
What was on it: Nginx web server with a simple static website
Storage: 8GB EBS gp2 volume
Data transfer: Minimal — just occasional visits to the live site

This is as basic as EC2 gets. No database. No heavy processing. Just a simple web server running 24/7.

The Actual Bill — Real Numbers

Here's exactly what AWS charged me 👇

Compute (EC2)

t2.micro instance — 744 hours running
Free tier covers 750 hours per month
I used 744 hours — technically within free tier! 😅
Cost: $0.00

Storage (EBS)

8GB gp2 volume for 30 days
Free tier covers 30GB per month
Cost: $0.00

Data Transfer

Outbound data transfer — minimal traffic
Free tier covers 1GB outbound per month
I used less than 100MB
Cost: $0.00

Elastic IP

I had attached an Elastic IP to keep consistent public IP
Elastic IPs are FREE when attached to a running instance
But if instance is stopped — AWS charges $0.005 per hour
My instance was running so — Cost: $0.00

Total Bill: $0.00 ✅

Wait — So Nothing Bad Happened?

Correct. Because I was on free tier.

But here's the thing — I got extremely lucky.

Free tier only lasts 12 months from account creation. And it only covers ONE t2.micro instance.

If I had:

Been past my 12 month free tier period
Run a larger instance like t2.small or t2.medium
Had multiple instances running
Generated significant traffic

The story would be very different.

Let me show you exactly what it WOULD have cost in different scenarios. 💰

What It Would Have Cost — Real Scenarios

Scenario 1 — Past Free Tier (t2.micro)

Same setup but free tier expired:

t2.micro in Mumbai = $0.0116 per hour
744 hours × $0.0116 = $8.63 per month
In INR = approximately ₹720 per month

Not terrible. But it adds up over months.

Scenario 2 — Running t2.small

If I had used a slightly bigger instance:

t2.small in Mumbai = $0.023 per hour
744 hours × $0.023 = $17.11 per month
In INR = approximately ₹1,430 per month

Scenario 3 — Running t2.medium

A medium instance for development:

t2.medium in Mumbai = $0.0464 per hour
744 hours × $0.0464 = $34.52 per month
In INR = approximately ₹2,880 per month

Scenario 4 — The Horror Story

Running t2.medium + RDS database + high traffic:

EC2 t2.medium: $34.52
RDS db.t3.micro: $25.00
Data transfer 10GB: $0.90
Total: ~$60 per month = ₹5,000 per month

For a student or fresher with no income — ₹5,000 per month on a forgotten instance is genuinely painful.

The Developers Who Weren't So Lucky

My story ended with a $0 bill. But many developers aren't so lucky.

Here are real scenarios that happen constantly:

The Crypto Miner Attack
Developer pushes AWS credentials to GitHub → bots find them in seconds → spin up 50 GPU instances for crypto mining → $10,000 bill in 24 hours.

The Forgotten NAT Gateway
Developer sets up a NAT Gateway for testing → forgets to delete it → NAT Gateways cost $0.045 per hour → $32.40 per month just sitting there doing nothing.

The Data Transfer Surprise
Developer builds an app that transfers lots of data between regions → doesn't realize inter-region data transfer costs money → $200 bill at end of month.

The Snapshots Pile Up
Developer takes EBS snapshots for backup → never deletes old ones → 50 snapshots accumulate over months → significant storage costs.

These are real situations. They happen to real developers every week.

How to Protect Yourself — Complete Guide

Protection 1 — Set Up Billing Alerts Immediately

This is the single most important thing you can do right now.

1. Go to AWS Console → Billing → Budgets
2. Click "Create Budget"
3. Select "Cost Budget"
4. Set amount: $5 (₹420)
5. Add your email for alerts
6. Create Budget ✅

Now AWS will email you the MOMENT your bill approaches $5. You'll never be surprised again.

Also set up free tier alerts:

AWS Console → Billing → Billing Preferences →
Check "Receive Free Tier Usage Alerts" →
Enter your email ✅

Protection 2 — Always Stop Instances When Not Using

Develop this habit from day one:

Before closing your laptop — ask yourself:
"Is my EC2 instance stopped?"

# Check instance status
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name]' --output table

# Stop instance from terminal
aws ec2 stop-instances --instance-ids i-0abc123def456789

Or use the Python automation script from my Boto3 Part 2 article — automatically stop your instance every night at 10pm. 🎯

Protection 3 — Use AWS Cost Explorer Weekly

AWS Console → Cost Explorer → Enable it (free)

Check this every week. Takes 2 minutes. Shows you exactly where every dollar is going.

If you see something unexpected — investigate immediately before it grows.

Protection 4 — Delete Resources You Don't Need

After finishing a project or tutorial — clean up everything:

# Things to delete when done:
# ✅ Stop or terminate EC2 instances
# ✅ Release Elastic IPs
# ✅ Delete NAT Gateways
# ✅ Delete unused Load Balancers
# ✅ Clean up old EBS snapshots
# ✅ Empty and delete unused S3 buckets
# ✅ Delete unused RDS instances

NAT Gateways and Load Balancers are the most expensive forgotten resources. Always delete these first.

Protection 5 — Use AWS Trusted Advisor

AWS Console → Trusted Advisor → Cost Optimization

Trusted Advisor automatically scans your account and tells you:

Idle EC2 instances
Underutilized resources
Cost saving opportunities

Free tier gives you basic checks. Worth checking monthly. ✅

My Complete AWS Cost Tracking Setup

After my 30 day forgotten instance experience I set up this system:

import boto3
from datetime import datetime, timedelta

def check_monthly_costs():
    # Create Cost Explorer client
    ce = boto3.client('ce', region_name='us-east-1')

    # Get current month dates
    today = datetime.now()
    start_of_month = today.replace(day=1).strftime('%Y-%m-%d')
    today_str = today.strftime('%Y-%m-%d')

    # Get costs
    response = ce.get_cost_and_usage(
        TimePeriod={
            'Start': start_of_month,
            'End': today_str
        },
        Granularity='MONTHLY',
        Metrics=['UnblendedCost'],
        GroupBy=[
            {
                'Type': 'DIMENSION',
                'Key': 'SERVICE'
            }
        ]
    )

    print(f"AWS Costs from {start_of_month} to {today_str}:")
    print("-" * 50)

    total = 0
    for result in response['ResultsByTime']:
        for group in result['Groups']:
            service = group['Keys'][0]
            cost = float(group['Metrics']['UnblendedCost']['Amount'])
            if cost > 0:
                print(f"{service}: ${cost:.4f}")
                total += cost

    print("-" * 50)
    print(f"Total this month: ${total:.4f} (₹{total*83:.2f})")

# Run weekly
check_monthly_costs()

Run this script every week. Takes 2 seconds. Shows exactly what you're spending and where. ✅

The Lesson That Changed How I Use AWS

Leaving my EC2 running for 30 days taught me something important.

Not about billing. Not about costs.

About attention.

Real production systems demand attention. They demand that you know what's running, what it costs, and why it exists.

The developers who get hired and trusted with real infrastructure are the ones who treat even their personal projects like production systems.

Monitor your costs. Clean up after yourself. Know what's running.

That mindset is worth more than any certification. 💪

Quick Reference — AWS Pricing for India (Mumbai ap-south-1)

Resource	Cost	Free Tier
t2.micro	$0.0116/hour	750 hours/month for 12 months
t2.small	$0.023/hour	None
t2.medium	$0.0464/hour	None
EBS gp2	$0.114/GB/month	30GB for 12 months
S3 Storage	$0.025/GB/month	5GB for 12 months
Data Transfer Out	$0.109/GB	1GB/month always free
Elastic IP (unattached)	$0.005/hour	Free when attached
NAT Gateway	$0.045/hour + data	None

Save this table. Check it before launching any new resource. ✅

Final Thoughts

My 30 day forgotten EC2 instance cost me $0 thanks to free tier.

But it gave me something more valuable than money — it gave me the habit of thinking about costs, monitoring resources, and cleaning up after myself.

Those habits are exactly what separates a junior developer from someone who can be trusted with real infrastructure.

Set up your billing alerts today. Right now. Before you do anything else.

It takes 5 minutes and could save you thousands of rupees. 💪

Follow LearnWithPrashik for more honest AWS stories and practical cloud development content.

I share the real experiences — not just the highlight reel.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

AWS + AI in 2026 — What Every Developer Needs to Know

Prashik besekar — Mon, 16 Mar 2026 03:29:32 +0000

The developers who understand this combination right now will be the most hireable in the next 2 years.

Why I'm Writing This

Six months ago I was focused purely on backend development and cloud infrastructure.

EC2. S3. Node.js. MongoDB. The usual stack.

Then I started noticing something in every job description I read —

"Experience with AI/ML services preferred"
"Familiarity with AWS Bedrock or SageMaker is a plus"
"Understanding of LLM integration is beneficial"

AI was everywhere. And AWS was right at the center of it.

I realized — the developers who combine cloud skills with AI knowledge right now are going to be extremely valuable in the next 2 years.

This is everything I've learned about AWS + AI in 2026. 🚀

The Big Picture — Why AWS + AI Matters Right Now

AI is not the future anymore. It's the present.

Every company — from tiny startups to massive enterprises — is trying to integrate AI into their products right now. They need developers who can build and deploy these AI systems on cloud infrastructure.

AWS saw this coming and built an entire ecosystem of AI services.

The result? A developer who understands both AWS cloud infrastructure AND AI services is worth significantly more than one who knows only one of these things.

This is your opportunity. 🎯

The AWS AI Ecosystem — What Actually Exists

AWS has built a complete stack of AI services organized in three layers:

Layer 1 — AI Services (Easiest to use)

Pre-built AI that you call via API. No ML knowledge needed.

Service	What it does
Amazon Rekognition	Image and video analysis
Amazon Textract	Extract text from documents
Amazon Comprehend	Natural language processing
Amazon Polly	Text to speech
Amazon Transcribe	Speech to text
Amazon Translate	Language translation

These are plug and play. Call the API, get results. Perfect for adding AI features to existing applications.

Layer 2 — Amazon Bedrock (Most important in 2026)

Access to powerful foundation models — Claude, Llama, Titan, Mistral — all through one AWS API.

This is the game changer. Instead of building AI models from scratch — you use world class pre-trained models through simple API calls.

Layer 3 — Amazon SageMaker (For ML Engineers)

Build, train, and deploy custom machine learning models. More complex but more powerful.

Amazon Bedrock — The Most Important AWS AI Service Right Now

If you learn only one AWS AI service in 2026 — make it Bedrock.

Here's why —

Companies don't want to build their own AI models. They want to use existing powerful models like Claude or Llama and customize them for their specific use case.

Bedrock lets them do exactly that — all within AWS infrastructure they already use.

As a developer you can build AI powered applications using Bedrock without any machine learning knowledge.

Your First Bedrock API Call

import boto3
import json

def call_bedrock(prompt):
    # Create Bedrock client
    bedrock = boto3.client(
        service_name='bedrock-runtime',
        region_name='us-east-1'  # Bedrock available in specific regions
    )

    # Prepare request body for Claude model
    body = json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 1024,
        "messages": [
            {
                "role": "user",
                "content": prompt
            }
        ]
    })

    # Call the model
    response = bedrock.invoke_model(
        body=body,
        modelId="anthropic.claude-3-sonnet-20240229-v1:0",
        accept="application/json",
        contentType="application/json"
    )

    # Parse response
    response_body = json.loads(response.get('body').read())
    return response_body['content'][0]['text']

# Test it
result = call_bedrock("Explain AWS S3 in simple terms for a beginner")
print(result)

That's it. You just called a world class AI model from Python using AWS. 🔥

Real Project — Build an AI Powered Document Analyzer

Let me show you something practical you can build right now.

Imagine a system that:

Takes any document or text
Analyzes it with AI
Returns a summary and key insights

Here's how to build it with AWS:

import boto3
import json

class DocumentAnalyzer:
    def __init__(self):
        self.bedrock = boto3.client(
            service_name='bedrock-runtime',
            region_name='us-east-1'
        )
        self.s3 = boto3.client('s3', region_name='ap-south-1')

    def analyze_document(self, text):
        prompt = f"""
        Analyze the following document and provide:
        1. A brief summary (3-4 sentences)
        2. Key points (bullet points)
        3. Action items if any

        Document:
        {text}
        """

        body = json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 1024,
            "messages": [{"role": "user", "content": prompt}]
        })

        response = self.bedrock.invoke_model(
            body=body,
            modelId="anthropic.claude-3-sonnet-20240229-v1:0",
            accept="application/json",
            contentType="application/json"
        )

        result = json.loads(response.get('body').read())
        return result['content'][0]['text']

    def save_analysis_to_s3(self, analysis, bucket_name, file_name):
        self.s3.put_object(
            Bucket=bucket_name,
            Key=f"analyses/{file_name}",
            Body=analysis,
            ContentType='text/plain'
        )
        print(f"Analysis saved to S3: {file_name}")

# Use it
analyzer = DocumentAnalyzer()

sample_document = """
AWS re:Invent 2025 announced several new AI features.
Amazon Bedrock now supports more foundation models.
New pricing tiers make AI more accessible for startups.
"""

analysis = analyzer.analyze_document(sample_document)
print(analysis)

# Save to S3
analyzer.save_analysis_to_s3(analysis, "my-bucket", "document-analysis.txt")

This is a real, useful application combining AWS Bedrock + S3 + Python. You can put this on your GitHub RIGHT NOW as a project. 💪

Amazon Rekognition — Add Computer Vision in 5 Minutes

Want to add image analysis to your application? Rekognition makes it simple.

import boto3

def analyze_image(image_path):
    rekognition = boto3.client('rekognition', region_name='ap-south-1')

    # Read image
    with open(image_path, 'rb') as image_file:
        image_bytes = image_file.read()

    # Detect labels in image
    response = rekognition.detect_labels(
        Image={'Bytes': image_bytes},
        MaxLabels=10,
        MinConfidence=80
    )

    print("Objects detected in image:")
    for label in response['Labels']:
        print(f"  - {label['Name']}: {label['Confidence']:.1f}% confidence")

    return response['Labels']

# Analyze any image
analyze_image('my-image.jpg')

Output:

Objects detected in image:
  - Person: 99.2% confidence
  - Laptop: 97.8% confidence
  - Desk: 95.1% confidence
  - Coffee Cup: 88.3% confidence

Five minutes to add computer vision to your application. This is the power of AWS AI services. 🔥

The Skills That Make You Valuable in 2026

Companies right now are desperately looking for developers who can:

1. Integrate AI APIs into existing applications
Taking a normal web app and adding AI features using Bedrock or other services.

2. Build RAG systems
RAG = Retrieval Augmented Generation. Building systems where AI can answer questions based on your company's specific documents and data.

3. Deploy AI applications on AWS
Not just building AI locally but deploying it properly on EC2, Lambda, or ECS with proper security and scaling.

4. Optimize AI costs on AWS
AI API calls cost money. Knowing how to cache responses, batch requests, and choose the right model for the right task saves companies significant money.

How This Changes Your Job Search

Here's something important yaar.

Right now most fresher developers are competing for the same backend and frontend roles. Thousands of applications for every position.

But developers who understand AWS + AI? Much less competition. Much higher demand.

Adding even basic Bedrock knowledge to your profile puts you in a completely different category.

Update your LinkedIn and resume to include:

Amazon Bedrock
AWS AI Services
LLM Integration
Python + AWS AI

These keywords alone will get your profile seen by different recruiters. 🎯

Where to Start — Your Learning Path

Week 1 — Understand the basics

Read AWS Bedrock documentation
Understand what foundation models are
Set up Bedrock in your AWS account (free tier available)

Week 2 — Build something small

Run the Bedrock example from this article
Build a simple question answering system
Put it on GitHub

Week 3 — Combine with your existing skills

Build a Node.js API that uses Bedrock
Store results in MongoDB
Deploy on EC2

Week 4 — Write about it

Document what you built
Publish on Medium and Dev.to
Share on LinkedIn

Four weeks. Real AI project. On your GitHub. In your resume. 💪

The Honest Reality

You don't need to become an AI researcher.

You don't need to understand neural networks deeply.

You don't need a data science degree.

You just need to understand how to USE these AWS AI services as a developer. How to call the APIs. How to integrate them into applications. How to deploy them properly.

That's it. And that knowledge is accessible to anyone willing to spend a few weeks learning it.

Quick Summary

AWS AI Service	Use case	Difficulty
Amazon Bedrock	LLM integration, chatbots, text generation	Easy
Amazon Rekognition	Image and video analysis	Easy
Amazon Transcribe	Speech to text	Easy
Amazon Comprehend	Text analysis, sentiment	Easy
Amazon SageMaker	Custom ML models	Advanced

Start with Bedrock and Rekognition. Master those two and you're already ahead of most developers. ✅

Final Thoughts

AWS + AI is not a trend. It's the new normal.

Every application being built in 2026 has some AI component. Every company is looking for developers who understand both cloud infrastructure and AI integration.

You already know AWS. You already know Python. Adding AI services on top of that is just a few weeks of learning.

The opportunity is right in front of you. 💪

Follow LearnWithPrashik for more practical AWS and backend development content.

I'm documenting my entire journey from fresher to developer — sharing everything I learn.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

Your AWS Credentials Are Still on GitHub Even After You Delete Them

Prashik besekar — Sun, 15 Mar 2026 04:37:34 +0000

I thought deleting the file was enough. I was wrong. Here's what actually happens.

Originally published on Medium — follow me there for more

The Mistake That Haunts Developers

You're coding late at night.

You hardcode your AWS credentials to test something quickly — just this once.

It works. Great.

You delete the credentials from the file. Push to GitHub.

Safe right?

Wrong. Completely wrong. 😰

Your credentials are still on GitHub. Visible to anyone who knows where to look. And automated bots DO know where to look.

This happens to developers every single day. Today I'm going to show you exactly why this happens and how to protect yourself completely.

How Git History Works

Git doesn't just save your current code. Git saves every single version of every file you've ever committed.

Think of git like a time machine. Every commit is a snapshot of your entire project at that moment.

When you delete credentials and push — git saves:

Commit 1 — file WITH credentials ← still here forever
Commit 2 — file WITHOUT credentials

Anyone can travel back to Commit 1 and see your credentials. It's that simple.

Let Me Show You Exactly How Easy It Is

If someone wanted to find your deleted credentials they would just run:

# See all commits
git log

# See what changed in a specific commit
git show abc123def

# Search entire git history for keywords
git log -p | grep -i "aws_access_key"
git log -p | grep -i "secret"
git log -p | grep -i "password"

Three commands. Less than 30 seconds. Your "deleted" credentials are right there.

And GitHub makes this even easier — anyone can browse your commit history directly in the browser. No commands needed.

The Bots Are Already Looking

Here's what makes this terrifying.

There are automated bots constantly scanning every public GitHub repository for:

AWS access keys
Secret keys
API tokens
Passwords
Private keys

These bots find new commits within seconds of being pushed.

By the time you realize your mistake and delete the credentials — the bots have already found them. Already saved them. Already started using them.

In 2024 a developer pushed AWS credentials to GitHub at 2am. By 4am — $50,000 worth of EC2 instances were running in his account mining cryptocurrency.

Two hours. $50,000.

How to Properly Remove Credentials From Git History

If you've already pushed credentials — deleting them is NOT enough. You need to rewrite git history.

Method 1 — git filter-branch (Built into git)

# Remove a specific file from entire git history
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch path/to/file-with-credentials.py" \
  --prune-empty --tag-name-filter cat -- --all

# Force push to GitHub
git push origin --force --all
git push origin --force --tags

Method 2 — BFG Repo Cleaner (Faster and easier)

BFG is a faster alternative to git filter-branch.

# Install BFG
brew install bfg  # Mac
# or download bfg.jar from rtyley.github.io/bfg-repo-cleaner/

# Remove all files containing passwords
bfg --delete-files id_{dsa,rsa}

# Replace specific text in all commits
bfg --replace-text passwords.txt

# Clean up
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push origin --force --all

Method 3 — GitHub's Built-in Secret Scanning

GitHub now automatically scans for exposed secrets and notifies you.

Go to your repository → Settings → Security → Secret scanning → Enable

GitHub will alert you if it finds credentials in your code. ✅

The Right Way — Prevent It Before It Happens

Fixing exposed credentials is stressful. Preventing it is easy.

Solution 1 — Use .gitignore Always

Create a .gitignore file in every project:

# .gitignore

# Environment files
.env
.env.local
.env.development
.env.production

# AWS credentials
.aws/credentials
credentials.json

# Key files
*.pem
*.key
id_rsa
id_dsa

Any file listed here will NEVER be committed to git. Ever. ✅

Solution 2 — Use Environment Variables

Never put credentials in your code files. Always use environment variables.

# WRONG ❌ - Never do this
aws_access_key = "AKIAIOSFODNN7EXAMPLE"
aws_secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# RIGHT ✅ - Always do this
import os
aws_access_key = os.environ.get('AWS_ACCESS_KEY_ID')
aws_secret_key = os.environ.get('AWS_SECRET_ACCESS_KEY')

Set environment variables in terminal:

export AWS_ACCESS_KEY_ID=your_key_here
export AWS_SECRET_ACCESS_KEY=your_secret_here

Or use a .env file with python-dotenv:

pip install python-dotenv

from dotenv import load_dotenv
import os

load_dotenv()  # Loads .env file

aws_access_key = os.environ.get('AWS_ACCESS_KEY_ID')

Your .env file:

AWS_ACCESS_KEY_ID=your_key_here
AWS_SECRET_ACCESS_KEY=your_secret_here
AWS_DEFAULT_REGION=ap-south-1

.env is in .gitignore so it never gets pushed. ✅

Solution 3 — git-secrets Pre-Commit Hook

This is the best solution shared by a reader in the comments of my previous article — and it's brilliant.

git-secrets automatically scans your code BEFORE every commit. If it finds credentials — it blocks the commit completely.

# Install git-secrets
brew install git-secrets  # Mac

# For Linux
git clone https://github.com/awslabs/git-secrets
cd git-secrets && sudo make install

# Set up in your repository
cd your-project
git secrets --install
git secrets --register-aws

# Now try to commit credentials - it will be blocked!

Once installed — you literally cannot accidentally commit AWS credentials. The commit is blocked before it happens.

This is the cheapest insurance you can get. 🔐

Solution 4 — Use AWS IAM Roles Instead of Access Keys

The ultimate solution — no access keys at all.

When your code runs on EC2, Lambda, or other AWS services — use IAM Roles instead of access keys.

IAM Roles provide temporary credentials automatically. Nothing to hardcode. Nothing to accidentally expose.

# With IAM Role attached to EC2 - no credentials needed at all!
import boto3

# boto3 automatically uses the EC2 instance's IAM Role
s3 = boto3.client('s3')
response = s3.list_buckets()

Zero credentials in code. Zero risk of exposure. ✅

What To Do RIGHT NOW

Go through this checklist immediately:

☐ Search your GitHub repos for "aws_access_key" in commit history
☐ Search for "secret_key" in commit history  
☐ Add .gitignore to every project
☐ Move all credentials to environment variables
☐ Install git-secrets on your machine
☐ Enable GitHub secret scanning on your repos
☐ Rotate any credentials that were ever in git history

Even if you think you're safe — check anyway. You might be surprised what you find.

If You Find Exposed Credentials — Do This Immediately

Deactivate the keys immediately — AWS Console → IAM → Users → Security Credentials → Deactivate
Create new access keys — fresh keys, stored safely
Check AWS CloudTrail — see if anyone used your exposed keys
Check your AWS bill — look for unexpected charges
Clean git history — use BFG or filter-branch
Report to AWS — if you see unauthorized usage contact AWS Support immediately

Speed matters here. Every minute counts.

Summary

Mistake	Reality
"I deleted the file"	Credentials still in git history
"My repo is private"	Private repos can become public, employees change
"Nobody will find it"	Bots scan GitHub 24/7 automatically
"It was only for 5 minutes"	Bots find credentials in seconds

Solution	Protection level
.gitignore	Prevents accidental commits
Environment variables	Keeps credentials out of code
git-secrets hook	Blocks commits with credentials
IAM Roles	Eliminates credentials entirely

Final Thoughts

This article exists because of a comment from a fellow developer on my previous article about IAM mistakes.

They mentioned git-secrets as "the cheapest insurance" — and they were absolutely right.

The best security lessons come from the community. From real developers who've seen real things go wrong.

If you learned something from this — share it with one developer friend. You might save them from a $50,000 AWS bill. 💪

Follow LearnWithPrashik for more practical AWS security and backend development content.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

AWS IAM Mistakes That Can Destroy Your Infrastructure

Prashik besekar — Sat, 14 Mar 2026 07:13:47 +0000

I almost made mistake #3. It would have exposed my entire AWS account to the internet.

The Day I Realized IAM Was Serious

When I first started learning AWS I thought IAM was boring.

EC2 was exciting. S3 was cool. Lambda felt like magic.

But IAM? Just users and permissions. Snooze. 😴

Then one day while reviewing my AWS account I found something terrifying — my root account had been used to create access keys. Those keys were sitting in my code. My code was on GitHub.

Public GitHub.

My entire AWS infrastructure was one Google search away from being destroyed.

That day I stopped treating IAM as boring. IAM is the lock on your front door. Get it wrong and everything else doesn't matter.

Here are the 7 biggest IAM mistakes I've seen — and how to fix every single one. 🔐

Mistake 1 — Using the Root Account for Everything

This is the most common mistake beginners make.

When you create an AWS account you get a root user. This root user has unlimited access to everything in your account — billing, services, settings, everything.

Many beginners use this root account for daily work. Creating EC2 instances, uploading to S3, everything.

Why this is dangerous:
If someone gets your root credentials — they own your entire AWS account. They can delete everything. Run up a $10,000 bill. Lock you out permanently.

The fix:

1. Log into AWS Console with root account
2. Go to IAM → Users → Create User
3. Give it AdministratorAccess policy
4. Log out of root account
5. Log in with new IAM user for ALL daily work
6. Lock away your root credentials — only use for billing

Enable MFA on your root account immediately. Go to IAM → Security recommendations → Enable MFA. This adds a second layer of protection even if password is stolen.

Mistake 2 — Giving Everyone AdministratorAccess

I see this all the time.

Developer needs access to S3 — give them AdministratorAccess. Developer needs to read from RDS — give them AdministratorAccess. It's easier than figuring out exact permissions right?

Wrong. Very wrong.

Why this is dangerous:
If that developer's credentials are compromised — the attacker now has full admin access to your entire infrastructure. They can create new users, delete databases, access all S3 buckets, run expensive EC2 instances.

The fix — Principle of Least Privilege:
Give users ONLY the permissions they absolutely need and nothing more.

Developer needs S3 read access only?

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

Only S3 read. Nothing else. This is how real companies manage IAM. ✅

Mistake 3 — Hardcoding AWS Credentials in Code

This one destroys people.

It's so tempting when you're learning:

# Please NEVER do this ❌
import boto3

s3 = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
)

You write this locally. It works. You push to GitHub.

Now your credentials are public. On the internet. Forever.

GitHub has bots that scan every public repository for AWS credentials within SECONDS of a commit. Within minutes your account can be compromised, crypto miners deployed on EC2, and you're looking at a bill for thousands of dollars.

AWS will email you. But the damage is already done.

The fix — Use Environment Variables:

# Always do this ✅
import boto3
import os

s3 = boto3.client(
    's3',
    aws_access_key_id=os.environ.get('AWS_ACCESS_KEY_ID'),
    aws_secret_access_key=os.environ.get('AWS_SECRET_ACCESS_KEY'),
    region_name=os.environ.get('AWS_DEFAULT_REGION')
)

Set environment variables on your machine:

export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_DEFAULT_REGION=ap-south-1

Or even better — use AWS IAM Roles for EC2 instances. Zero credentials needed in code at all.

Add .env to your .gitignore ALWAYS:

# .gitignore
.env
*.pem
credentials

Mistake 4 — Never Rotating Access Keys

Access keys are like passwords. They should be changed regularly.

Many developers create one access key and use it for years. If that key was ever exposed — even briefly — an attacker could have been using it silently for months.

The fix:
Rotate access keys every 90 days minimum.

1. Go to IAM → Users → your user → Security credentials
2. Create new access key
3. Update your applications with new key
4. Test everything works
5. Delete the old key

Also — regularly audit your access keys:

IAM → Users → Security credentials → 
Check "Last used" column

If a key hasn't been used in 90 days — delete it. Unused keys are unnecessary risk.

Mistake 5 — Not Using IAM Roles for EC2

This is a big one that even intermediate developers get wrong.

When your EC2 instance needs to access S3 or other AWS services — beginners put access keys directly on the server:

# On EC2 server - WRONG ❌
aws configure
# Then type access key and secret key

This means credentials are sitting on your server. If the server is compromised — those credentials are gone.

The fix — IAM Roles:

IAM Roles give your EC2 instance temporary credentials automatically. No keys stored anywhere.

1. Go to IAM → Roles → Create Role
2. Select "AWS Service" → EC2
3. Attach the permissions your EC2 needs (e.g. AmazonS3ReadOnlyAccess)
4. Name the role (e.g. "ec2-s3-read-role")
5. Go to EC2 → your instance → Actions → Security → Modify IAM Role
6. Attach your new role

Now your EC2 can access S3 without any credentials stored anywhere. This is production-grade security. ✅

Mistake 6 — Ignoring IAM Policy Conditions

Most people write IAM policies like this:

{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
}

This allows S3 access from ANYWHERE — any IP, any time, any condition.

The fix — Add Conditions:

Restrict access to specific IP addresses:

{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
        "IpAddress": {
            "aws:SourceIp": "203.0.113.0/24"
        }
    }
}

Require MFA for sensitive operations:

{
    "Effect": "Deny",
    "Action": ["s3:DeleteObject", "s3:DeleteBucket"],
    "Resource": "*",
    "Condition": {
        "BoolIfExists": {
            "aws:MultiFactorAuthPresent": "false"
        }
    }
}

Conditions add a powerful extra layer of security that most beginners completely ignore.

Mistake 7 — Not Monitoring IAM Activity

Many people set up IAM and forget about it.

They never check who is accessing what. They never look at failed login attempts. They never review which permissions are actually being used.

This means if something goes wrong — you find out too late.

The fix — Enable CloudTrail:

1. Go to AWS CloudTrail → Create Trail
2. Enable for all regions
3. Store logs in S3 bucket
4. Enable CloudWatch integration for alerts

CloudTrail records every API call made in your account — who did what, when, from where. If someone accesses your account — you'll know.

Also use IAM Access Analyzer:

IAM → Access Analyzer → Create Analyzer

This automatically finds resources in your account that are shared with external entities. It will show you things you didn't even know were public.

Quick Security Checklist

Go through this right now for your AWS account:

☐ Root account MFA enabled
☐ Root account access keys deleted
☐ IAM users created for daily work
☐ Least privilege applied to all users
☐ No credentials hardcoded in code
☐ .env files in .gitignore
☐ Access keys rotated in last 90 days
☐ IAM Roles used for EC2 instances
☐ CloudTrail enabled
☐ IAM Access Analyzer enabled

If you can check all 10 — your AWS account is more secure than 90% of beginners out there. ✅

Real Cost of Getting IAM Wrong

This is not theoretical. Real people lose real money.

A developer pushes AWS credentials to GitHub → bots find it in seconds → spin up 100 GPU instances for crypto mining → $50,000 bill in 24 hours.

This happens every single week to developers around the world.

AWS has a process to appeal these bills — but it's stressful, not guaranteed, and completely avoidable.

Take IAM seriously from day one. It takes 30 minutes to set up properly. It can save you thousands of rupees and weeks of stress.

Summary

Mistake	Fix
Using root account	Create IAM user for daily work
AdministratorAccess everywhere	Principle of least privilege
Hardcoded credentials	Environment variables + IAM Roles
Never rotating keys	Rotate every 90 days
Keys on EC2	Use IAM Roles instead
No conditions on policies	Add IP and MFA conditions
Not monitoring	Enable CloudTrail + Access Analyzer

Final Thoughts

IAM is not the exciting part of AWS. But it's the most important part.

Every other AWS service you build — EC2, S3, Lambda, RDS — is only as secure as your IAM setup.

Get IAM right and your infrastructure is protected. Get it wrong and everything else doesn't matter.

Take 30 minutes today and go through that security checklist. Your future self will thank you. 💪

Follow LearnWithPrashik for more practical AWS security and backend development content.

I write the honest, practical guides I wish existed when I started.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

What is AWS S3 and How I Used It — A Beginner's Guide

Prashik besekar — Fri, 13 Mar 2026 03:22:20 +0000

No theory overload. Just real, simple explanation from someone who actually used it.

Why I'm Writing This

When I first heard "S3 bucket" I thought — what does a bucket have to do with cloud storage? 😄

I was confused. Every tutorial I found was either too technical or too shallow. So after actually using S3 in my own projects, I decided to write the guide I wish I had when I started.

If you're a beginner trying to understand AWS S3 — this is for you.

So What Exactly is AWS S3?

S3 stands for Simple Storage Service.

Think of it like this — imagine Google Drive or Dropbox, but built for developers and applications. You can store any file — images, videos, PDFs, code files, database backups — and access them from anywhere in the world.

The things you store inside S3 are called objects.
The container that holds those objects is called a bucket.

Simple as that. 🪣

Why Do Developers Use S3?

It never goes down — AWS guarantees 99.999999999% durability (11 nines!)
It scales infinitely — store 1 file or 1 billion files, S3 handles it
It's cheap — you only pay for what you store and transfer
It's fast — files are served from AWS data centers worldwide
Free tier available — 5GB free storage for 12 months

In my own projects I used S3 to:

Store static website files
Save user uploaded images
Keep database backup files
Host assets for my web applications

Key Concepts You Must Know

1. Bucket

A bucket is like a folder at the top level. Every file you store in S3 lives inside a bucket.

Rules for buckets:

Bucket name must be globally unique across ALL of AWS
Choose a region close to your users for faster access
You can create multiple buckets for different purposes

2. Object

An object is any file you store — image, video, document, anything.
Every object has:

A key — basically the file name and path
A value — the actual file content
Metadata — information about the file

3. Access Control

By default everything in S3 is private. Only you can access it.
You can make specific files or entire buckets public if needed — like for a website.

Step by Step — How to Use S3

Step 1 — Create a Bucket

Go to AWS Console → S3 → Create Bucket
Enter a unique bucket name (example: "prashik-portfolio-files")
Choose your region (ap-south-1 for Mumbai if you're in India)
Keep "Block all public access" ON for now
Click Create Bucket ✅

Step 2 — Upload a File

Click on your bucket name
Click Upload
Drag and drop any file
Click Upload

Your file is now stored in the cloud! 🎉

Step 3 — Access Your File

Click on the file → you'll see an Object URL.

If your bucket is private, this URL won't work publicly.
If you want to share it, you can generate a Pre-signed URL — a temporary link that expires after a time you choose.

How I Used S3 in My Project

In my AWS High Availability Architecture project I used S3 for:

1. Static Asset Storage
All images and frontend assets were stored in S3 instead of on the EC2 server. This way even if the server restarts, the files are safe.

2. CloudWatch Log Storage
I configured CloudWatch to export logs to an S3 bucket automatically. This way I had a permanent backup of all server logs.

3. EC2 Backup Files
I wrote a simple shell script that automatically backed up important files from EC2 to S3 every day.

#!/bin/bash
# Simple backup script to S3
DATE=$(date +%Y-%m-%d)
aws s3 cp /var/www/mywebsite s3://my-backup-bucket/backup-$DATE/ --recursive
echo "Backup completed: $DATE"

This gave me peace of mind — even if the EC2 instance crashed, my files were safe in S3.

S3 with Node.js — Quick Example

Here's how to upload a file to S3 using Node.js:

const AWS = require('aws-sdk');

// Configure AWS
const s3 = new AWS.S3({
    accessKeyId: process.env.AWS_ACCESS_KEY,
    secretAccessKey: process.env.AWS_SECRET_KEY,
    region: 'ap-south-1'
});

// Upload file function
const uploadFile = async (fileName, fileContent) => {
    const params = {
        Bucket: 'your-bucket-name',
        Key: fileName,
        Body: fileContent
    };

    try {
        const data = await s3.upload(params).promise();
        console.log('File uploaded successfully:', data.Location);
        return data.Location;
    } catch (error) {
        console.error('Upload failed:', error);
    }
};

// Use it
uploadFile('profile-image.jpg', imageBuffer);

Simple right? This is how real applications store user uploaded images on S3.

S3 Pricing — Don't Worry It's Cheap

For beginners the free tier covers:

5 GB storage free for 12 months
20,000 GET requests free
2,000 PUT requests free

After free tier:

Storage: around $0.023 per GB per month
For a small project you'll spend less than $1/month

Common Mistakes Beginners Make

Mistake 1 — Making everything public
Never make your entire bucket public unless it's specifically for a static website. Keep sensitive files private always.

Mistake 2 — Storing AWS credentials in code
Never do this:

// WRONG ❌
accessKeyId: 'AKIAIOSFODNN7EXAMPLE'

Always use environment variables or IAM roles.

Mistake 3 — Choosing wrong region
Choose the region closest to your users. For India — use ap-south-1 (Mumbai) for best performance.

Mistake 4 — Not versioning important files
Enable S3 versioning for important buckets. If you accidentally delete a file, you can recover it.

Quick Summary

Term	Simple meaning
S3	Cloud storage service by AWS
Bucket	Container that holds your files
Object	Any file stored in S3
Key	The file name/path
ACL	Controls who can access your files
Pre-signed URL	Temporary shareable link

What's Next?

Now that you understand S3, here's what to explore next:

S3 Static Website Hosting — host a complete website on S3 for almost free
S3 + CloudFront — deliver your files super fast worldwide using CDN
S3 Lifecycle Policies — automatically move old files to cheaper storage

I'll be writing about these in upcoming articles. Follow me so you don't miss them! 🙌

Final Thoughts

S3 is one of those AWS services you'll use in almost every real project. Once you understand it, a whole world of cloud architecture opens up.

Start simple — create a bucket, upload a file, access it. That's all it takes to begin.

And remember — the best way to learn AWS is to actually use it. Free tier gives you enough to experiment without spending a single rupee.

Go build something! 💪

Found this helpful? Follow me for more practical AWS and backend development content.

Connect with me:
LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar

How I Deployed a Production Server on AWS EC2 as a Fresher — Step by Step

Prashik besekar — Thu, 12 Mar 2026 11:37:03 +0000

A real story from someone who figured it out with no job, no mentor, and no money

A Little Background

I'm Prashik. 25 years old. Computer Science graduate from Maharashtra.
No job yet. No salary. Just a laptop, an internet connection, and a burning desire to build something real.

While most freshers were busy applying to jobs and waiting, I decided to do something different — I wanted to actually deploy something live on the internet. Not localhost. Not a tutorial project. A real, production-style server that anyone in the world could access.

This is the story of how I did it — and everything I learned along the way.

Why AWS EC2?

Honestly? Because every job description I read mentioned AWS.

I kept seeing "AWS experience preferred" in job listings. I had done the AWS Cloud Practitioner course. I understood the concepts. But concepts and actually doing it are two completely different things.

So I decided — let me just do it. Let me set up a real server, deploy a real website, and figure out the problems as they come.

Spoiler: there were a LOT of problems. 😅

What I Built

Here's what the final setup looked like:

AWS EC2 instance — a virtual server running Ubuntu in the cloud
Nginx — a web server configured with custom server blocks
GitHub CI/CD pipeline — automatic deployment every time I push code
AWS Security Groups — firewall rules to control traffic
A live, publicly accessible website — visible to anyone with the link

Sounds simple. Getting there was not. 😄

Step 1 — Launch Your EC2 Instance

First things first — you need a server.

Go to AWS Console → EC2 → Launch Instance
Choose Ubuntu Server 22.04 LTS (free tier eligible)
Select t2.micro — this is free tier, costs you nothing
Create a new Key Pair — download the .pem file and keep it safe. If you lose this, you lose access to your server forever.
Configure Security Group — for now allow SSH (port 22) and HTTP (port 80)
Launch the instance

Your server is now running somewhere in Amazon's data center. Pretty cool right? 🚀

Step 2 — Connect to Your Server

On your local machine, open terminal and run:

chmod 400 your-key-pair.pem
ssh -i "your-key-pair.pem" ubuntu@your-ec2-public-ip

You're now INSIDE your cloud server. This felt like magic to me the first time. 😄

Step 3 — Install Nginx

Nginx is the web server that will serve your website to the world.

sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx

Now go to your EC2 public IP in a browser — you should see the Nginx welcome page.

Your server is live on the internet. 🎉

Step 4 — Configure Nginx Server Blocks

Server blocks let you host multiple websites on one server (like virtual hosts in Apache).

sudo nano /etc/nginx/sites-available/mywebsite

Add this configuration:

server {
    listen 80;
    server_name your-ec2-public-ip;

    root /var/www/mywebsite;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Then enable it:

sudo ln -s /etc/nginx/sites-available/mywebsite /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Step 5 — Deploy Your Website Files

Create your website directory and add your files:

sudo mkdir -p /var/www/mywebsite
sudo chown -R ubuntu:ubuntu /var/www/mywebsite

Now copy your website files here. Your site is live!

Step 6 — Set Up CI/CD with GitHub

This was my favourite part. Every time I push code to GitHub — it automatically deploys to the server. No manual copying files.

On your EC2 server:

cd /var/www/mywebsite
git init
git remote add origin https://github.com/yourusername/your-repo.git
git pull origin main

Then create a simple deploy script:

nano /home/ubuntu/deploy.sh

#!/bin/bash
cd /var/www/mywebsite
git pull origin main
sudo systemctl reload nginx
echo "Deployed successfully!"

chmod +x /home/ubuntu/deploy.sh

Now whenever you want to deploy — just SSH in and run ./deploy.sh. Or set up a GitHub Action to do it automatically!

Step 7 — Configure Security Groups Properly

This is where I made mistakes and learned hard lessons.

In AWS Console → EC2 → Security Groups, make sure you have:

Type	Protocol	Port	Source
SSH	TCP	22	Your IP only
HTTP	TCP	80	0.0.0.0/0
HTTPS	TCP	443	0.0.0.0/0

Important: Never leave port 22 open to 0.0.0.0/0 (everyone). Only allow your own IP for SSH. I learned this the hard way when I saw unknown login attempts in my logs. 😅

Problems I Hit (And How I Solved Them)

Problem 1 — 403 Forbidden Error

Cause: Wrong file permissions on /var/www/
Fix:

sudo chown -R www-data:www-data /var/www/mywebsite
sudo chmod -R 755 /var/www/mywebsite

Problem 2 — Port 80 Already in Use

Cause: Apache was running alongside Nginx
Fix:

sudo systemctl stop apache2
sudo systemctl disable apache2
sudo systemctl restart nginx

Problem 3 — Can't Connect via SSH

Cause: Security group didn't have port 22 open
Fix: Go to AWS Console → Security Groups → Edit Inbound Rules → Add SSH rule

Problem 4 — Changes Not Reflecting

Cause: Nginx wasn't reloaded after config changes
Fix:

sudo nginx -t        # Always test config first
sudo systemctl reload nginx

What I Learned

Technical lessons:

AWS Security Groups are your first line of defense — configure them carefully
Always run nginx -t before reloading — it saves you from breaking your server
File permissions matter more than you think in Linux
Git-based deployments are simple but powerful

Life lessons:

You don't need a job to build production-level things
Every error message is just a puzzle waiting to be solved
The best way to learn cloud is to actually break things and fix them
Building something real gives you more confidence than any certification

What's Next

After this I built a High Availability Architecture on AWS with:

Application Load Balancer
Auto Scaling Groups
Multiple Availability Zones
CloudWatch monitoring
99.9% uptime design

But that's a story for another article. 😄

Final Thoughts

If you're a fresher reading this feeling stuck — just start building.

You don't need a job to gain experience. You don't need money to use AWS free tier. You don't need a mentor to figure things out.

You just need to start, make mistakes, fix them, and keep going.

That's exactly what I did. And I'm still going. 💪

If this helped you, follow me for more real stories about backend development, AWS, and the journey of building things from scratch.

Connect with me on LinkedIn: linkedin.com/in/prashik-besekar
GitHub: github.com/prashikBesekar