DEV Community: gurpreet kaur

🚨 Incident Response in AWS: A Step-by-Step Guide for Beginners

gurpreet kaur — Mon, 28 Jul 2025 23:14:48 +0000

Cloud environments are dynamic and powerful, but they also open the door to security incidents if not monitored effectively. Imagine this: a suspicious login attempt is detected in your AWS infrastructure—what would you do?

In this blog, we’ll walk through how to detect, respond to, and isolate a potentially compromised EC2 instance using AWS native tools like CloudWatch, SNS, Lambda, and Systems Manager.

By the end, you’ll not only learn how to set up an automated incident response pipeline but also understand the “why” behind each step—even if you're new to AWS.

🎯 Objectives of this Lab
Here’s what we’ll accomplish:
✅ Understand what infrastructure incidents are and why they matter.
✅ Configure your application to log events into Amazon CloudWatch.
✅ Create alarms and notifications when malicious activity is detected.
✅ Automate EC2 isolation using Lambda and Security Groups.
✅ Notify stakeholders using Amazon SNS.

🛠 AWS Services You’ll Use
Amazon CloudWatch – For monitoring logs and creating alarms.

AWS Lambda – To automate response actions (like isolating EC2).

Amazon SNS (Simple Notification Service) – To notify stakeholders.

AWS Systems Manager (Fleet Manager & Run Command) – For managing EC2 without SSH.

Pro tip for beginners: Each of these services is serverless, meaning you don’t need to manage servers or infrastructure to run them!

🔍Step 1: Understand Infrastructure Incidents
An incident in cloud security typically means unexpected or unauthorized activity within your environment—think failed login attempts, privilege escalations, or abnormal traffic spikes.

In AWS, such incidents are often detected through logs (CloudTrail, application logs) and metrics (unusual CPU/network usage). That’s why centralized logging and monitoring are essential.

📝 Step 2: Configure CloudWatch Logging
Before you can detect anything, you need visibility! Let’s enable CloudWatch Agent to collect logs:

Commands to Install and Configure:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

This wizard will:

Ask for OS type (choose Linux if using EC2 Linux AMI).
Configure user permissions (root or cwagent).
Enable log collection (provide your application log path, e.g., /home/ssm-user/record.log).
Save and push configuration to AWS Systems Manager Parameter Store for consistency.

After running, your logs are shipped to CloudWatch → Log Groups where they can be monitored.

🚨 Step 3: Detect Suspicious Activity with CloudWatch Alarms
Now that logs are centralized:

Go to CloudWatch → Logs → Log Groups → record.log.
Create a metric filter for suspicious patterns (e.g., HTTP 401 Unauthorized errors).
Name it something meaningful like "LabApplications".

Why?
This filter will scan logs in real-time for your defined pattern. If a match is found, CloudWatch triggers an alarm.

📢 Step 4: Set Up Notifications (Amazon SNS)
Create an SNS topic named IncidentResponse-Alerts:

Go to Amazon SNS → Topics → Create Topic.
Choose "Standard".
Add email subscriptions for stakeholders (e.g., security@company.com).

Now, link your CloudWatch Alarm (from Step 3) to this SNS topic. This ensures real-time alerts when an incident occurs.

🖥 Step 5: Automate Instance Isolation with AWS Lambda
Here’s where automation shines. Instead of manually logging in and isolating the instance (which wastes precious time during an incident), let Lambda do it for you.

Lambda Function 1– Traffic Generator (for testing):
This function simulates failed login attempts to trigger alarms:

import boto3, requests, logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)
ec2_client = boto3.client('ec2')

def lambda_handler(event, context):
    pub_ip = get_public_ip("App-Server")
    url = f"http://{pub_ip}:8443/"
    for _ in range(40):
        requests.post(url, data="username=admin&password=test123")

def get_public_ip(tag):
    response = ec2_client.describe_instances(Filters=[{'Name':'tag:Name','Values':[tag]}])
    return response['Reservations'][0]['Instances'][0]['PublicIpAddress']

Lambda Function 2 – Instance Isolation:
Triggered by the alarm SNS notification, it:

Removes IAM role (to cut off API access).
Attaches an Isolated Security Group (no ingress/egress).

Code snippet:

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]["Sns"]['Message'])
    instance_id = message['Trigger']['MetricName']
    isolate_instance(instance_id)

def isolate_instance(instance_id):
    ec2_client.modify_instance_attribute(
        InstanceId=instance_id,
        Groups=[create_isolated_sg()]
    )

def create_isolated_sg():
    sg = ec2_resource.create_security_group(GroupName="Isolated_SG", VpcId=vpc_id)
    sg.revoke_egress(IpPermissions=[{'IpProtocol':'-1','IpRanges':[{'CidrIp':'0.0.0.0/0'}]}])
    return sg.id

🔒Step 6: Validate the Response
Once triggered:

Check EC2 IAM Role – it should now be removed.
Check Security Groups – EC2 should be assigned Isolated_SG (no ingress/egress rules).

At this stage, the instance is quarantined, preventing lateral movement by attackers while you perform forensic analysis.

🛠 Step 7: Manage Instances Securely (Systems Manager Fleet Manager)
Instead of SSH/RDP:

Use AWS Systems Manager Fleet Manager to run commands securely (ideal for restricted or isolated instances).
Run automated scripts or view logs directly without opening risky network ports.

✅What Did We Achieve?

Centralized logging using CloudWatch.
Real-time threat detection with alarms & metric filters.
Automated incident response via SNS + Lambda.
Instance isolation to stop threats instantly.

This workflow is scalable and serverless, making it perfect for enterprises and even AWS learners experimenting in a sandbox.

🔥 Final Thoughts
Security incidents are inevitable, but preparedness makes the difference. By combining AWS-native services, you can build an automated, proactive incident response pipeline without external tools.

Automating Resource Tagging in AWS : Lambda, AWS Config & Systems Manager

gurpreet kaur — Wed, 23 Jul 2025 23:26:39 +0000

In cloud environments, enforcing compliance is not just a best practice—it’s a necessity. One simple yet powerful way to do this in AWS is through resource tagging. Tags allow you to identify, organize, and control your resources by assigning meaningful key-value metadata such as Environment: Prod.

In this blog, we’ll walk through a hands-on approach to automatically enforce compliance using a combination of AWS services including Lambda, EC2, AWS Config, and Systems Manager (SSM). Our goal: ensure all EC2 instances are correctly tagged with Environment: Prod.

🧠 Understanding the AWS Services Involved
To automate compliance enforcement using tagging, we’ll leverage the following AWS services:

AWS Lambda:
A serverless compute service that runs your code in response to events—like changes in AWS resources—without needing to manage servers. It’s ideal for lightweight automation tasks.

AWS Systems Manager (SSM):
A management service that helps you automate operational tasks across AWS resources. In this context, it triggers Lambda functions as part of automated remediation workflows.

AWS Config:
A monitoring service that tracks AWS resource configurations and evaluates them against compliance rules. It alerts and remediates when resources don’t meet defined standards—like missing required tags.

Steps involved:
🏷️Step 1: Tag Your EC2 Instance

Start by launching an EC2 instance and apply a few initial tags manually (such as Owner: DevOps, Project: Alpha, etc.). This forms the baseline for what compliant tagging should look like.

🧠 Step 2: Create a Lambda Function to Auto-Tag Resources

Next, create an AWS Lambda function in Python that auto-applies the Environment: Prod tag to a given EC2 instance. Here's the core functionality:

Accepts an instance ID as input.
Constructs the correct resource ARN.
Uses the tag_resources method of boto3’s resourcegroupstaggingapi to apply tags.
Returns a compliance annotation.

import boto3
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info(event)

    client = boto3.client('sts')
    account_id = client.get_caller_identity()['Account']

    instance_id = event['instanceId']
    resource_arn = f"arn:aws:ec2:us-east-1:{account_id}:instance/{instance_id}"

    tagging_client = boto3.client('resourcegroupstaggingapi')
    try:
        response = tagging_client.tag_resources(
            ResourceARNList=[resource_arn],
            Tags={'Environment': 'Prod'}
        )
        print(response)
    except Exception as e:
        logger.exception(e)

    return {
        "compliance_type": "COMPLIANT",
        "annotation": "This resource is compliant with the rule."
    }

⚙️ Step 3: Create an SSM Automation Document

Head over to AWS Systems Manager and create a custom SSM Automation Document that invokes the Lambda function created in Step 2. This automation will apply the required Environment: Prod tag to any EC2 instance found non-compliant.

schemaVersion: '0.3'
parameters:
  InstanceId:
    type: String
    description: ID of the instance to be tagged
mainSteps:
  - name: updatetags
    action: aws:invokeLambdaFunction
    isEnd: true
    inputs:
      InvocationType: Event
      Payload: |
        {
          "instanceId": "{{ InstanceId }}"
        }
      FunctionName: arn:aws:lambda:us-east-1:<account_id>:function:labFunction

📊 Step 4: Set Up AWS Config to Monitor Compliance

In AWS Config, create a configuration recorder that logs changes in your resource states and sends them to an S3 bucket.

Make sure to:

Choose an S3 bucket prefixed with config-bucket-.
Set a prefix such as Config to help organize config data.

✅ Tip: AWS Config's Rules Development Kit (RDK) is highly useful for implementing compliance-as-code patterns, especially when working with custom Lambda-backed rules.

🛠️ Step 5: Create a Config Rule to Enforce Tags

Let’s now create a rule in AWS Config that checks whether EC2 instances have the required Environment: Prod tag.

Resource type: AWS::EC2::Instance
Parameter tag1Key: Environment
Parameter tag1Value: Prod

⚠️ Note: Tag keys and values are case-sensitive in AWS Config.
Once set, this rule automatically flags any EC2 instance that lacks the specified tag as non-compliant.

🔁 Step 6: Automate Remediation Through AWS Config

After creating the rule:

Click the rule and choose Manage Remediation.
Select Manual remediation.
Choose the remediation action that runs your SSM document (from Step 3).
Map the Resource ID parameter to instanceId.

Finally:

Select the instance from the Resources in scope.
Click Remediate.

After a few minutes, refresh the page. The resource's compliance status should change to Compliant once the tag is successfully applied.

✅ Outcome: Automated Compliance for EC2 Instances
With this setup, any EC2 instance missing the Environment: Prod tag is automatically detected and remediated, ensuring your environment stays compliant with organizational tagging policies.

This approach leverages:

Lambda for automation,
AWS Config for compliance monitoring,
SSM for remediation,
And tags as the foundation of governance.

🚀** Final Thoughts**
Tagging isn’t just for cost management or organization—it’s also a crucial part of security and compliance enforcement. By combining native AWS services, you can ensure that your cloud environment remains compliant, auditable, and easy to manage at scale.

🔐 Securing Amazon RDS Credentials with AWS Secrets Manager

gurpreet kaur — Sat, 19 Jul 2025 19:17:26 +0000

In cloud-native environments, secrets management is critical. Hardcoding database credentials or API keys within code repositories is not only bad practice—it’s a serious security risk. In this guide, I’ll walk you through how to securely manage Amazon RDS credentials using AWS Secrets Manager, including automatic secret rotation with AWS Lambda.

As part of my hands-on learning, I implemented this solution to secure database credentials for an application deployed in AWS Lambda. This walkthrough covers storing, retrieving, and rotating secrets using native AWS integrations—enabling secure, uninterrupted database connectivity.

🔧 Why Use AWS Secrets Manager?
AWS Secrets Manager allows you to:

Securely store and encrypt secrets (e.g., database credentials).
Programmatically retrieve secrets via applications or scripts.
Enable automated rotation of secrets to meet compliance needs.
Eliminate hardcoded secrets in your codebase.

🧩 Architecture Overview
Here’s what the architecture looks like:

Application runs inside AWS Lambda.
Lambda retrieves secrets from AWS Secrets Manager.
Secret contains RDS credentials and is set up for automated rotation.
Rotation is handled using another Lambda function.
Interface VPC Endpoints are used to securely access Secrets Manager inside the VPC.

🪜 Step-by-Step Implementation
✅ Step 1: Launch an RDS Instance

Create an Amazon RDS (MySQL/Aurora) instance.
Ensure the Security Group attached to the instance allows inbound traffic on TCP port 3306 (MySQL/Aurora default).
Note down the DB endpoint and credentials (we'll use them in the secret).

✅ Step 2: Store Credentials in AWS Secrets Manager

Go to AWS Secrets Manager > Store a new secret.
Choose Credentials for RDS database.
Add the database username, password, and connection details.
Provide an encryption key (KMS) and link to the RDS database from Step1.
Name your secret (e.g., MyRDS/ProdApp).

✅ Step 3: Create a VPC Interface Endpoint

Navigate to VPC > Endpoints > Create Endpoint.
Choose com.amazonaws.region.secretsmanager.
Select the VPC and subnets from each AZ.
Attach a Security Group that allows Lambda functions in the VPC to access the endpoint.

This enables AWS PrivateLink connectivity to Secrets Manager.

✅ Step 4: Create a Lambda to Retrieve Secrets

Create a Lambda function inside the same VPC.
Attach IAM permissions: secretsmanager:GetSecretValue, rds:Connect.
Install PyMySQL library via Lambda layers or zip package.

Sample code snippet:

import boto3
import pymysql
import json
import os

def lambda_handler(event, context):
    secret_name = os.environ['SECRET_NAME']
    region = os.environ['AWS_REGION']
    client = boto3.client('secretsmanager', region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    secret = json.loads(response['SecretString'])

    connection = pymysql.connect(
        host=secret['host'],
        user=secret['username'],
        password=secret['password'],
        db='your_db_name',
        port=3306
    )
    print("Connection successful!")

Test the Lambda to ensure it connects to RDS using the secret.

✅ Step 5: Set Up Rotation Lambda

Create a second Lambda function to handle rotation logic.

This function follows four steps:

createSecret: Generate new credentials.
setSecret: Update credentials in the RDS DB.
testSecret: Test connectivity.
finishSecret: Promote new secret to current.

Grant the following resource-based policy:

{
  "Sid": "secret-rotation",
  "Effect": "Allow",
  "Principal": {
    "Service": "secretsmanager.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:region:account-id:function:rotation-function-name"
}

Add the PyMySQL layer as a custom Lambda layer.

✅ Step 6: Enable Secret Rotation

Go to the secret created in Step 2.
Enable automatic rotation.
Assign the Lambda rotation function from Step 5.
Choose a rotation interval (e.g., every 30 days).

✅ Step 7: Test Secret Rotation

Trigger a manual rotation.
Check logs in CloudWatch Logs.
Confirm: Secret is rotated.
Lambda rotation function updated the RDS database.
Your application still connects successfully using new credentials.

🧪 Validating Rotation via AWS CLI
You can also retrieve secrets using the CLI:

aws secretsmanager get-secret-value --secret-id MyRDS/ProdApp

🔄 How Secret Rotation Works (Under the Hood)
AWS Secrets Manager uses Lambda and version labels:

AWSPENDING: New version created by rotation function.
AWSCURRENT: Active version used by applications.
AWSPREVIOUS: Previous version before rotation.

Each rotation function must:
Generate new credentials.
Update the RDS DB.
Test connectivity.
Finalize the rotation and update version labels.

✅ Benefits of This Approach
✔ No hardcoded credentials in code
✔ Automated compliance with rotation policies
✔ Reduced risk of credential leakage
✔ Secure, programmatic access to secrets from inside VPC
✔ Seamless integration with Lambda and RDS

📝 Final Thoughts
Secrets management isn’t just a best practice—it’s a necessity. AWS Secrets Manager, coupled with Lambda and RDS, provides a powerful solution to automate secret handling and reduce security risks.

I’ve personally implemented this solution to securely manage database access for cloud applications—and it's become a foundational security building block in my AWS learning journey.

🔒 Stay secure, automate wisely, and always validate with logs!
Let me know in comments if you’ve tried this or plan to implement it.

🔐 Encrypting and Decrypting Files Using AWS KMS and Data Keys

gurpreet kaur — Thu, 17 Jul 2025 22:06:38 +0000

A Practical Guide to Using KMS Keys, Data Keys, and Envelope Encryption in AWS

In today’s cloud-first world, security is paramount — especially when handling sensitive data. AWS Key Management Service (KMS) provides a secure and scalable way to create and manage cryptographic keys and control their usage across a wide range of AWS services and applications.

In this blog, we’ll walk through a step-by-step process to encrypt and decrypt files using AWS KMS keys and generated data keys, covering both symmetric encryption and envelope encryption scenarios.

📌 Step 1: Create an EC2 Instance with IAM Role
Launch an EC2 instance and attach an IAM role that allows it to communicate with other AWS services securely.

📌 Step 2: Attach IAM Policy to EC2 Role
Add the following IAM policy to allow access to EC2, KMS, and S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances",
        "kms:*",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:PutObject"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ]
}

📝 Note: IAM policies define what actions identities (like roles or users) are allowed to perform on resources.

📌 Step 3: Create a Symmetric KMS Key
In the AWS KMS console, create a symmetric key in a specific region.
Symmetric keys use the same key for both encryption and decryption. These 256-bit keys never leave AWS unencrypted.

🔐 Key Concepts:
Symmetric Key: Same key for encrypt/decrypt.
Asymmetric Key: Public-private key pair for encryption or signing.
Key Rotation: Ensure it is enabled for better key lifecycle security.

📌 Step 4: Review the Automatically Generated Key Policy
When assigning Key Administrators and Key Users, AWS automatically generates a policy like this:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::<account-id>:role/YourRole"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey*"
  ],
  "Resource": "*"
}

Key policy governs access control to KMS keys.

📌 Step 5: Connect to EC2 Using Session Manager
Use AWS Session Manager to connect securely without exposing ports.

sudo su ec2-user
cd ../../home/ec2-user
echo "This is my Secret Text to encrypt." > samplesecret.txt
cat samplesecret.txt

🔐 Generate a Data Key Using AWS KMS
Run the command:

aws kms generate-data-key \
  --key-id alias/myKMSKey \
  --key-spec AES_256 \
  --encryption-context project=practice \
  --region us-east-1

This returns:

A plaintext data key (for encryption)
A ciphertext blob (encrypted data key, safe to store)

Save both to files:

echo '<PlaintextKey>' | base64 --decode > datakeyPlainText.txt
echo '<CiphertextBlob>' | base64 --decode > datakeyEncrypted.txt

🔐 Encrypt a File Using the Data Key

openssl enc -e -aes256 -in samplesecret.txt -out encryptedSecret.txt -k fileb://datakeyPlainText.txt

🔍 View encrypted data:

more encryptedSecret.txt

🧹 Remove plaintext key for security:

rm datakeyPlainText.txt

🔓_ Decrypt the File_
First, decrypt the data key:

aws kms decrypt \
  --encryption-context project=practice \
  --ciphertext-blob fileb://datakeyEncrypted.txt \
  --region us-east-1

Then decode and use it:

echo '<DecryptedPlaintextKey>' | base64 --decode > datakeyPlainText.txt
openssl enc -d -aes256 -in encryptedSecret.txt -k fileb://datakeyPlainText.txt

🎉 You should now see the original text — decryption successful!

🛠️ Encrypting Without Generating Data Keys (Direct KMS Encryption)
Create a new file:

echo "New secret file: encrypt without using a data key." > NewSecretFile.txt

Encrypt it directly using your KMS key:

aws kms encrypt \
  --key-id alias/myKMSKey \
  --plaintext fileb://NewSecretFile.txt \
  --encryption-context project=practice \
  --output text \
  --query CiphertextBlob \
  --region=us-east-1 | base64 --decode > NewSecretsEncryptedFile.txt

Decrypt it with:

aws kms decrypt \
  --ciphertext-blob fileb://NewSecretsEncryptedFile.txt \
  --encryption-context project=practice \
  --output text \
  --query Plaintext \
  --region=us-east-1 | base64 --decode > NewSecretsDecryptedFile.txt

Verify:

cat NewSecretsDecryptedFile.txt

📌 Important Notes on AWS KMS

AWS KMS is optimized for small data (<4KB).
Use Envelope Encryption: Encrypt large data with a data key, and encrypt the data key with KMS. -Always delete plaintext keys from memory after use.
KMS does not store or manage your data keys — you manage them outside using tools like OpenSSL or AWS Encryption SDK.

🔐 Final Thoughts
Using AWS KMS with data keys allows you to build highly secure, scalable encryption workflows. Whether you’re protecting secrets, encrypting files, or automating secure data flows, mastering KMS is a crucial cloud skill.

🔐 Amazon S3 Security: Best Practices for Data Protection

gurpreet kaur — Sun, 13 Jul 2025 19:31:02 +0000

As cloud adoption continues to rise, securing data stored in Amazon S3 becomes a top priority for organizations. This post explores a comprehensive approach to S3 security using encryption, versioning, replication, and lifecycle policies—ensuring your data is protected from unauthorized access, loss, or corruption.

🛡️ Core Security Features Implemented
The following solution demonstrates how to secure files stored in Amazon S3:

Encryption at Rest:
Files uploaded to the primary S3 bucket are automatically encrypted using Server-Side Encryption with S3-Managed Keys (SSE-S3).

Versioning Enabled:
When users upload updated versions of a file, Amazon S3 maintains previous versions. This protects against accidental deletions or overwrites.

Cross-Region Replication (CRR):
Live replication ensures that every new object uploaded to the primary S3 bucket is automatically copied to a secondary backup bucket in another region.

Server Access Logging:
All requests made to the primary bucket are logged to a designated logging bucket. These logs are essential for security audits and access tracking.

Lifecycle Policies for Archival:
Older versions of files are automatically transitioned to a cheaper storage class using S3 Lifecycle rules, reducing storage costs while maintaining data durability.

📁 Step-by-Step: S3 Security Lab
To implement this S3 security setup, follow these practical steps:

Create an S3 Bucket:
Enable encryption, versioning, and server access logging during setup.

Configure a Lifecycle Policy:
Define rules to automatically transition older versions of files to Amazon S3 Glacier or Glacier Deep Archive for long-term storage.

Enable Server Access Logging:
Choose a destination logging bucket. Grant Log Delivery Group write access to the target bucket to receive logs.

Upload a File:
Upload a sample file (e.g., record.txt) containing private information. It will be encrypted automatically using SSE-S3.

Update and Re-Upload the File:
Modify the file and upload it again. S3 will retain the previous version while treating the new upload as the current version.

Enable Cross-Region Replication:
Configure replication rules to copy files from the primary bucket to the backup bucket automatically.

🔐 Managing Access with ACLs
Amazon S3 provides Access Control Lists (ACLs) to define access permissions at the bucket and object levels.
By default, if another AWS account uploads an object to your bucket, that account owns the object.
ACLs let you grant read/write access to specific AWS accounts or predefined groups.

📦 Understanding S3 Lifecycle Policies
S3 Lifecycle configurations automate storage management:
Transition Actions: Move objects to different storage classes (e.g., S3 Standard → Glacier).
Expiration Actions: Automatically delete outdated or unnecessary objects.

❄️ Amazon S3 Glacier for Archival
For long-term storage and compliance requirements:
S3 Glacier Flexible Retrieval provides low-cost storage with expedited, standard, and bulk retrieval options.
S3 Glacier Deep Archive is designed for data that is rarely accessed but must be retained for years.

✅ Practice Lab Goals
To reinforce your understanding, here are your practice goals:

✅ Create an Amazon S3 bucket with logging, encryption, and versioning.

✅ Upload and re-upload a file to simulate version control.

✅ Enable replication to a secondary bucket.

✅ Create an S3 Lifecycle rule to transition previous versions to an archival class.

✅ View and analyze S3 server access logs.

💡 Final Thoughts
Implementing S3 security best practices not only protects sensitive data but also helps you meet compliance and governance requirements. By combining encryption, access control, versioning, replication, and lifecycle policies, you're building a highly resilient and secure storage strategy within AWS.

Building a Custom Amazon VPC from Scratch 🚀

gurpreet kaur — Wed, 25 Jun 2025 12:47:40 +0000

What is Amazon VPC?

Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you can define and control your networking environment. It allows you to launch AWS resources securely, controlling access and connectivity without exposing everything to the public internet.
In short, VPCs enable secure, private communication between your cloud resources while providing flexibility in network design.

How I Used Amazon VPC in This Project

Today, I built a custom Amazon VPC setup that included:
• A public subnet with internet access
• A private subnet isolated from the internet
• Internet Gateway to connect the VPC to the internet
• Route tables for directing traffic between subnets and internet
• Security Groups and Network ACLs for layered security
• EC2 instances deployed in both public and private subnets
• Connectivity setup between EC2 instances for internal communication

This project gave me hands-on experience with networking fundamentals on AWS and how different VPC components work together.

Key Concepts Explored

Virtual Private Cloud (VPC)
A VPC is your private network within AWS. It uses a CIDR block (IP address range) to organize resources and enables secure resource communication without exposing them publicly. AWS provides default VPCs, but creating your own gives you full control.

Subnets
Subnets partition the VPC into smaller network segments.
• Public subnet: Connected to the internet via an Internet Gateway; EC2 instances here can have public IPs.
• Private subnet: No direct internet access; used for sensitive or backend resources.

Internet Gateway
This gateway attaches to your VPC and allows resources in public subnets to access the internet and receive inbound connections.

Route Tables
Route tables control the traffic flow within your VPC. They contain rules (routes) that determine where network traffic is directed—whether to other subnets, the internet gateway, or virtual private gateways. Each subnet is associated with a route table that defines how its traffic is routed.

Security Groups
Security Groups act as virtual firewalls at the instance level. They control inbound and outbound traffic by allowing or denying specific IP addresses, ports, and protocols. Unlike NACLs, security groups are stateful, meaning they automatically allow response traffic for requests initiated by the instance.

Network ACLs (NACLs)
Network Access Control Lists act as a firewall at the subnet level. They provide an additional layer of security by controlling inbound and outbound traffic for subnets using stateless rules, which are evaluated before security groups.

Step-by-Step: What I Built

☁️ Create a VPC: You've taken your first steps by setting up a Virtual Private Cloud (VPC) using Amazon VPC.

🥅 Create subnets: Moving deeper into your VPC, you created subnets, which act like neighborhoods within your city, each with unique access rules. You learned the difference between public and private subnets and set up a subnet to allow instances within it to automatically receive public IP addresses, making them accessible from the internet.

🚪 Set up an internet gateway: Lastly, you added an internet gateway to your VPC, acting as the main gate that allows data to flow in and out. This setup is essential for any applications that require internet access, such as web servers. You've configured the gateway and linked it to your VPC, ensuring your public instances can reach the outside world and vice versa.

🚏 Bonus - configure IP addresses and CIDR blocks: You've configured your VPC with an IPv4 CIDR block, understanding that IP addresses are like street addresses for your resources! You explored how different CIDR blocks dictate the size and scale of your VPC

🚏 Set up route tables: You configured a route table in your VPC to send Internet-bound traffic to your internet gateway, turning your subnet into a public subnet.

👮‍♀️ Implement security groups: You created a security group to control inbound and outbound traffic at a resource level, specifying allowed IP addresses, protocols, and ports.

📋 Deploy network ACLs: You set up network ACLs as an additional layer of security, managing both incoming and outgoing traffic at the subnet level.

🚷 Create a private subnet: You created a new subnet and set its CIDR block to avoid an overlap with your public subnet.

🚧 Create a private route table: You also made this subnet private by assigning it to a dedicated route table that doesn't route traffic to an internet gateway!

🚔 Create a private network ACL: Then, you set up custom network ACLs to control inbound and outbound traffic for this private subnet - denying all traffic by default.

💻 Launch a public EC2 instance You launched an EC2 instance in your public subnet, set up the appropriate AMI and instance type, and configured key pairs for secure access.

🤐 Launch a private EC2 instance You launched an EC2 instance in your private subnet, created a security group within the same flow, and used the same key pair for access.

How Traffic Flows in My VPC

• 💻 Client/User: A user enters the URL of your website into their web browser and hits enter.
• 🚪 Internet Gateway: The request is sent from the user's browser through the internet and reaches your internet gateway.
• 🌐 VPC: The internet gateway forwards the user's request to the VPC it's attached to.
• 🚏 Route Table: Your VPC has a route table for your public subnet, which directs traffic to your EC2 instance hosting the website. The user's request get put on the local route in the route table.
• 📋 Network ACL: While en route to your EC2 instance, the request has to pass through the network ACL associated with your public subnet. The network ACL has an inbound rule (rule 100) that lets in traffic from anywhere (0.0.0.0/0), so your request is let through.
• 🥅 Public Subnet: The request enters your public subnet and travels to your EC2 instance within the subnet.
• Response is sent back following the reverse path through Security Group, subnet, route table, VPC, and Internet Gateway
This flow ensures that traffic is filtered and secured at multiple points.

What I Learned

• The importance of subnet segmentation for security and organization
• How routing and gateways connect your VPC to the internet safely
• The role of Security Groups and Network ACLs in protecting your cloud environment
• Setting up EC2 instances in both public and private contexts
• Hands-on experience with configuring and visualizing network components in AWS

Building this custom VPC gave me a foundational understanding of AWS networking essentials and prepared me for more complex cloud infrastructure projects ahead.

Have you worked with AWS VPCs before? What’s your go-to architecture setup? Let me know in the comments!

💬 Building BankerBot: A Conversational Banking Assistant Using Amazon Lex, Lambda & CloudFormation

gurpreet kaur — Sat, 14 Jun 2025 19:03:33 +0000

In today’s fast-paced digital world, users expect quick, intelligent, and accessible banking services—often without speaking to a human agent. That’s exactly what inspired BankerBot: a cloud-native chatbot designed to help users check account balances and transfer funds between accounts seamlessly via natural conversation.

🚀 Project Overview
BankerBot is a voice/text-enabled chatbot developed using Amazon Lex, capable of assisting users with everyday banking queries such as:
• Checking account balances for credit, savings, and checking accounts
• Initiating fund transfers between accounts
• Responding to general inquiries with fallback handling
The bot was integrated with AWS Lambda to handle backend logic and uses CloudFormation for automated deployment—making it a robust and scalable cloud-based solution.

🧰 Tools & Services Used
• Amazon Lex – Conversational interface to understand and respond to user input
• AWS Lambda – Serverless compute to fulfill intent logic
• Amazon CloudWatch – Monitoring logs and debugging
• AWS CloudFormation – Infrastructure-as-Code to deploy chatbot components

🛠️ Step-by-Step Implementation

📌 Project 1: Welcome & Fallback Intents
• Defined a basic WelcomeIntent with a friendly greeting.
• Configured FallbackIntent to catch unrecognized input.
• Used MessageGroups to randomize welcome messages.
• Tested interactions using both text and speech input.

💳 Project 2: CheckBalance Intent
• Introduced a custom slot type for account types (credit, savings, checking).
• Bound built-in slots and parsed them directly from the user’s utterance.
• Allowed users to say things like "What's my savings balance?" for contextual understanding.

🧠 Project 3: Lambda Integration
• Created and deployed a Lambda function to fulfill backend logic.
• Integrated the Lambda function with the chatbot using code hooks.
• Enabled the bot to return live balance details by simulating backend response.

🔁 Project 4: Context Carryover
• Implemented slot value carryover between related intents.
• Maintained context across multi-turn conversations, improving UX.

🔄 Project 5: Fund Transfer Flow
• Configured multiple slots to collect transfer details (source, destination, amount).
• Added confirmation prompts before executing simulated transfers.
• Enhanced user flow using Lex's visual conversation builder.
• Automated deployment using CloudFormation templates.

🧩 Challenges & Learnings
One major hurdle emerged during Lambda integration:
After deploying the bot, Amazon Lex couldn't invoke the Lambda function due to missing permissions.
Solution:
By navigating to the Lambda function’s permissions tab, I added a resource-based policy statement allowing Lex to access the function—resolving the issue and restoring full bot functionality.
This experience taught me the importance of cross-service permissions in AWS and how essential it is to understand IAM policies when working in a serverless environment.

📘 Conclusion
Projects like BankerBot demonstrate the powerful synergy between AI and cloud services. By combining natural language processing (Amazon Lex) with serverless execution (AWS Lambda) and IaC (CloudFormation), we can rapidly develop intelligent applications that scale effortlessly.
As AI becomes more embedded into user-facing systems, cloud-native chatbot development offers a glimpse into the future of customer experience, automation, and intelligent assistance—driving efficiency and user satisfaction across industries.