SonarQube is an effective tool for the continuous inspection of code quality. This step-by-step guide will provide detailed instructions on setting up SonarQube 9.9.2 LTS on an Amazon EC2 instance running Ubuntu. Upon completing this tutorial, you will have a fully operational SonarQube server to analyse your code quality.

Prerequisites:

Before you get started, make sure you have these things ready:

• An AWS account with an active EC2 instance.

• A basic understanding of the Linux command line.

• Internet access from your EC2 instance.

Step 1: Create and Connect to an EC2 Instance

First up, you'll need to create and connect to an EC2 instance. If you're not sure how to do this, check out for a detailed guide. Once your EC2 instance is all set, you can move on to installing SonarQube.

Step 2: Update Ubuntu

After connecting to your EC2 instance, it's important to keep your system updated. Run these commands to refresh the package list and upgrade the installed packages:

sudo apt update
sudo apt upgrade -y

Step 3: Install Java 17

SonarQube requires Java 17. Install it using the following command:

sudo apt install fontconfig openjdk-17-jre -y

Step 4: Download SonarQube 9.9.2 LTS

Download SonarQube 9.9.2 LTS and place it in the /opt directory. You can use the wget command to download the package:

sudo wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-9.9.2.77730.zip -P /opt

Step 5: Add a User for SonarQube

Create a user named "sonar" that will be used to run the SonarQube service:

sudo useradd sonar

Step 6: Install Unzip

If unzip is not already installed, you can install it with the following command:

sudo apt install unzip -y

Step 7: Rename the Extracted Directory

Unzip the SonarQube package and rename the extracted directory to "sonar":

sudo unzip /opt/sonarqube-9.9.2.77730.zip -d /opt
sudo mv /opt/sonarqube-9.9.2.77730 /opt/sonar

Step 8: Set Permissions for the Sonar Directory

Give the "sonar" user ownership of the SonarQube directory:

sudo chown -R sonar:sonar /opt/sonar

Step 9: Add Sonar User to the sudoers File

To allow the "sonar" user to execute commands without a password prompt, add the following line to the sudoers file:

sudo vim /etc/sudoers

Add the following line under the "User privilege specification" section:

sonar   ALL=(ALL:ALL) NOPASSWD:ALL

Save and exit the visudo editor.

Step 10: Write a Service for SonarQube

Create a systemd service unit file for SonarQube. Create a file named /etc/systemd/system/sonar.service

sudo vim /etc/systemd/system/sonar.service

and add the following content:

[Unit]
Description=SonarQube service
After=network.target

[Service]
Type=forking
User=sonar
ExecStart=/opt/sonar/bin/linux-x86-64/sonar.sh start
ExecStop=/opt/sonar/bin/linux-x86-64/sonar.sh stop
Restart=always
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Step 11: Start the SonarQube Service

Start the SonarQube service using the following commands:

sudo systemctl start sonar
sudo systemctl enable sonar

Step 12: Access SonarQube with the Public IP

You can access your SonarQube server by opening a web browser and navigating to http://your-public-ip:9000. Replace your-public-ip with the actual public IP address of your EC2 instance.

Step 13: Log in to SonarQube

Log in to SonarQube using the default username and Password "admin".

Congratulations! You have successfully set up SonarQube 9.9.2 LTS on your EC2 instance. You can now use it to analyze the quality of your code and improve your software development process.

If you’ve ever wanted to see how a real-world microservices-based e-commerce app runs inside Kubernetes, Stan’s Robot Shop is the perfect project to explore.
It’s a sample application designed for learning — a playground where you can deploy multiple services, connect databases, monitor everything, and actually see how cloud-native systems behave.

This project isn’t meant to be production-ready or secure — and that’s okay. It’s intentionally simple, so you can focus on understanding how things fit together: how microservices communicate with each other, how monitoring tools capture data, and how AWS EKS manages everything under the hood.So let’s get started.

🧩 What’s Inside Stan’s Robot Shop

Stan’s Robot Shop is built using a mix of technologies that represent what you’d find in a modern e-commerce platform. Each microservice is written in a different language to show how diverse systems can work together inside containers.

Here’s what it includes:

• Frontend: AngularJS (1.x) served using Nginx

• Backend Services:

  • Node.js (Express) — handles parts of the shop’s logic

  • Java (Spring Boot) — manages key backend services

  • Python (Flask) — supports some lightweight microservices

  • Golang — for performance-oriented modules

  • PHP (Apache) — for older service components

• Databases:

  • MongoDB — stores product and user data

  • MySQL — used for structured data (includes Maxmind data)

• Messaging & Cache:

  • RabbitMQ — handles asynchronous communication

  • Redis — for caching

• Monitoring:

  • Integrated Instana agents for full end-to-end tracing and metrics

Every service already comes pre-configured with monitoring and tracing — so when you deploy it, you can instantly visualise requests, database queries, and performance metrics across all layers.

🏗️ Architecture Overview — The Three Tiers

Stan’s Robot Shop follows the classic three-tier architecture, broken into:

1. Presentation Layer (Frontend):

   • The AngularJS UI served through Nginx.

   • It’s what customers see when they visit the robot shop website.

2. Application Layer (Backend Services):

   • The core logic of the shop — all the Node.js, Java, Python, Go, and PHP services live here.

   • This layer manages products, orders, users, and payment flows.

3. Data Layer (Databases & Cache):

   • Uses MySQL and MongoDB for persistent data storage.

   • Redis is used for caching frequently accessed data to improve performance.

All these components run as individual pods inside an AWS EKS cluster, communicating internally using Kubernetes Services.
An Ingress Controller (like NGINX or AWS ALB) exposes the frontend to users over the internet, while internal services stay private.

📌 Prerequisites

Before performing this project, you need to install these commands on you terminal :

kubectl

A command-line tool for working with Kubernetes clusters. For more information, see Installing or updating kubectl.

LINK : https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html

eksctl

A command-line tool for working with EKS clusters that automates many individual tasks. For more information, see Installing or updating.

LINK : https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html

AWS CLI

A command-line tool for working with AWS services, including Amazon EKS. For more information, see Installing, updating, and uninstalling the AWS CLI in the AWS Command Line Interface User Guide. After installing the AWS CLI, we recommend that you also configure it. For more information, see Quick configuration with aws configure in the AWS Command Line Interface User Guide.

LINK: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

Once you have installed these commands on your Terminal, then do

aws configure

You can get your AWS access and secret access key, just sign in to your AWS Account and go to Security credentials → Access keys

Just copy the things from here and paste them over there.

Why AWS configure ??!!

The aws configure command helps you set up your AWS CLI by entering your credentials, choosing a default region, and picking how you want your AWS service results displayed.

📌 Docker Setup for Microservices

In this project, each microservice has its own Dockerfile, customised for its language and runtime. Instead of showing all 10 Dockerfiles (which might make the blog a bit too much), we'll highlight one example Dockerfile and provide a quick summary table for the others.

This way, the blog stays neat, professional, and easy to follow, while still showing off your technical skills.

Example Dockerfile — Cart Microservice (Node.js)

FROM node:14

# Enable Instana auto-profiling for monitoring
ENV INSTANA_AUTO_PROFILE true

# Set working directory
WORKDIR /opt/server

# Copy package.json and install dependencies
COPY package.json /opt/server/
RUN npm install

# Copy service code
COPY server.js /opt/server/

# Expose service port
EXPOSE 8080

# Start the service
CMD ["node", "server.js"]

💡 Note: Other microservices follow a similar structure, adjusted for their runtime (Node.js, Python, Go, Java, PHP) and dependencies.

Overview of All 10 Microservices

Full Dockerfiles

For all complete Dockerfiles of every microservice, you can explore the GitHub repo:

three-tier-architecture-demo-project

☸️ Kubernetes & EKS Setup for Microservices Deployment

📌 Setting up the cluster

You can create your cluster through the AWS Console, but here we are creating the cluster through CLI.

eksctl create cluster --name demo-cluster-app1 --region ap-south-1

Here, --region will be your region.

It will take some time to create ............

🧩 Kubernetes Deployment and Service Setup (Using Helm)

After setting up the EKS cluster, I deployed all my microservices (like cart, user, payment, etc.) using Helm charts.
Helm made it easier to manage all my Kubernetes YAML files for deployment, service, and ingress.

Below is one simple example for the Cart microservice 👇

🏗️ Deployment (Example: Cart)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cart
  labels:
    service: cart
spec:
  replicas: 1
  selector:
    matchLabels:
      service: cart
  template:
    metadata:
      labels:
        service: cart
    spec:
      {{ if .Values.psp.enabled }}
      serviceAccountName: robot-shop
      {{ end }}
      containers:
      - name: cart
        image: {{ .Values.image.repo }}/rs-cart:{{ .Values.image.version }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        # agent networking access
        env:
          - name: INSTANA_AGENT_HOST
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 200m
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 50Mi
      {{- with .Values.cart.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.cart.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.cart.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
      {{- end }}

🌐 Service (Example: Cart)

apiVersion: v1
kind: Service
metadata:
  name: cart
spec:
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  selector:
    service: cart

👉 Meaning:
This service exposes the Cart pod inside the cluster so that other microservices can communicate with it.

🌐 Ingress for Robot Shop on EKS

Ingress allows external traffic to reach your services in Kubernetes. For AWS EKS, we can use ALB (Application Load Balancer) Ingress.

🏗️ ALB Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: robot-shop
  name: robot-shop
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing   # Public-facing ALB
    alb.ingress.kubernetes.io/target-type: ip          # Targets pods by IP
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /                                     # All requests to "/" path
            pathType: Prefix
            backend:
              service:
                name: web                               # Routes to 'web' service
                port:
                  number: 8080

• alb.ingress.kubernetes.io/scheme: internet-facing → Makes the ALB public-facing so it can be accessed from the internet.

• alb.ingress.kubernetes.io/target-type: ip → Targets the IPs of the pods.

• ingressClassName: alb → Specifies that this uses ALB Ingress.

• service.name: web → Specifies that it routes to the pods of the web service.

• path: / → All requests will be forwarded to the root path.

⚙️ Helm Charts for Microservices Deployment

I used Helm to organise all the deployments and services neatly.
My Helm chart structure looks like this 👇

three-tier-architecture-demo-project/
 ├── EKS/helm/
 ├── Chart.yaml         # Chart metadata (name, version, description)
 ├── values.yaml        # Default values for images, replicas, ports, affinity, etc.
 └── templates/         # Kubernetes manifests templates
      ├── cart-deployment.yaml
      ├── cart-service.yaml
      ├── user-deployment.yaml
      ├── user-service.yaml
      ├── payment-deployment.yaml
      ├── payment-service.yaml
      └── ...           # similar for all other microservices

• Chart.yaml – Defines the chart’s metadata, like name and version.

• values.yaml – Holds configurable parameters like Docker image name, version, replicas, ports, affinity, and tolerations.

• templates/ – Contains all deployment, service, ingress, and other Kubernetes manifest templates.

🔗 Full Code on GitHub

You can check the complete Helm chart and all microservices’ Kubernetes manifests on my GitHub repository here:
👉 GitHub Repository – three-tier-architecture-demo-project

📌 Configure IAM OIDC provider

We use OIDC (OpenID Connect) in our EKS cluster to allow Kubernetes pods to securely access AWS resources without storing AWS credentials inside the containers.

In this project, Redis requires a persistent volume on AWS (EBS) to store its data. By using OIDC:

• The Redis pod can assume an IAM role with permissions to access EBS.

• This ensures secure, scoped, and managed access to the persistent storage.

• No AWS keys are hardcoded in the pods, making the setup safe and maintainable.

✅ In short: OIDC lets Redis pods access EBS securely and efficiently.

Now Commands to configure IAM OIDC provider

export cluster_name=<CLUSTER-NAME>

oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)

Check whether the IAM OIDC is already configured or not :

aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4

If not, run the below command

eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve

📌Installation of ALB-CONTROLLER using helm-chart

Before creating the alb-controller, you have to do these steps so that your alb-controller, which is running as a pod in the kube-system namespace in Kubernetes that can talk to AWS services to create an alb-load-balancer.

✔️Set up alb add-on

Download IAM policy

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/docs/install/iam_policy.json

Create IAM Policy

aws iam create-policy \
    --policy-name AWSLoadBalancerControllerIAMPolicy \
    --policy-document file://iam_policy.json

Here, you will error, but this is not any type of error, this is saying that your policy already exists, that’s why this is showing, because I have done this many times before.

Create IAM Role

eksctl create iamserviceaccount \
  --cluster=<your-cluster-name> \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --role-name AmazonEKSLoadBalancerControllerRole \
  --attach-policy-arn=arn:aws:iam::<your-aws-account-id>: policy/AWSLoadBalancerControllerIAMPolicy \
  --approve

✔️Deploy ALB controller

Add helm repo

helm repo add eks https://aws.github.io/eks-charts

Update the repo

helm repo update eks

Install

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \            
  -n kube-system \
  --set clusterName=<your-cluster-name> \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set region=<region> \
  --set vpcId=<your-vpc-id>

Verify that the deployments are running.

kubectl get deployment -n kube-system aws-load-balancer-controller

📌EBS CSI Plugin configuration

The Amazon EBS CSI plugin requires IAM permissions to make calls to AWS APIs on your behalf.

Create an IAM role and attach a policy. AWS maintains an AWS-managed policy or you can create your own custom policy. You can create an IAM role and attach the AWS managed policy with the following command. Replace my-cluster with the name of your cluster. The command deploys an AWS CloudFormation stack that creates an IAM role and attaches the IAM policy to it.

eksctl create iamserviceaccount \
    --name ebs-csi-controller-sa \
    --namespace kube-system \
    --cluster <YOUR-CLUSTER-NAME> \
    --role-name AmazonEKS_EBS_CSI_DriverRole \
    --role-only \
    --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
    --approve

Run the following command. Replace with the name of your cluster with your account ID.

eksctl create addon --name aws-ebs-csi-driver --cluster <YOUR-CLUSTER-NAME> --service-account-role-arn arn:aws:iam::<AWS-ACCOUNT-ID>:role/AmazonEKS_EBS_CSI_DriverRole --force

🚀 Clone the GitHub Repo & Deploy All Microservices Using Helm

First, clone the project repository to your local machine. Then, using Helm, you can deploy all microservices, their deployment, and their services to your Kubernetes cluster in one go. This makes deployment simple, organised, and reproducible.

✔️Git Clonning

pwd
git clone https://github.com/shreyash81/three-tier-architecture-demo-project

Now, after cloning, go to your repo and after go to where your helm chart is located

#Follow these commands to reach your destination
cd #your repo name
ls #this command will show all the files and folders in your repo.
cd EKS
ls # This command will show all the files and folders in your EKS repo.
cd helm
ls

Now you have finally reached the destination.

✔️Deploy All Microservices Using Helm

Helm v3.x

kubectl create ns robot-shop
helm install robot-shop --namespace robot-shop .

☑️Now check if all the microservices are properly deployed or not

Here, we will write some Kubernetes commands to check that all our pods and services all properly running or not :

kubectl get pods -n robot-shop

#You can check the services also 

kubectl get svc -n robot-shop

🌐 Apply Ingress Manually

After deploying all microservices and services, you can expose your application to the outside world using Ingress.

Steps:👇

1. Go to your Kubernetes manifests folder (where the ingress YAML is):

cd three-tier-architecture-demo-project/EKS/helm

2. Apply the ingress YAML file manually:

kubectl apply -f ingress.yaml -n robot-shop

3. Verify the ingress:

kubectl get ingress -n robot-shop

🌐 Get the DNS from Load Balancer

After applying the Ingress, AWS will automatically create an Application Load Balancer (ALB) to route traffic to your services. To access your application, you need the DNS name of the ALB.

Go to your AWS account in the load balancer section and wait for a few minutes till it becomes active from provisioning state.

Now, here, copy the DNS name and paste it into your favourite browser

🎉 Application Live and Running!

You can now access the Robot Shop application in your browser using the following DNS that you have just copied:

Congratulations🥂, you have finally done this project.

🧹 Cleanup: Deleting the EKS Cluster

Once you are done testing your Robot Shop application, it’s important to clean up resources to avoid unnecessary AWS charges. Here’s how you can delete your EKS cluster and related resources:

eksctl delete cluster --name demo-cluster-app1 --region ap-south-1

⭐️Introduction

In this project, we aim to optimise AWS costs by identifying and deleting stale EBS snapshots and volumes that are no longer needed. This is achieved through an AWS Lambda function that analyses the state of EBS snapshots, their associated volumes, and related EC2 instances. By removing these unused resources, we can significantly reduce storage costs.

⭐️Services used in this Project

• AWS Lambda: Runs the function to manage snapshots and volumes.

• Amazon EC2: Manages instances and volumes.

• Amazon EBS: Stores snapshots and volumes.

• AWS IAM: Provides necessary permissions for Lambda to access EC2 and EBS.

Follow these steps to perform this project

❄️Task 1: Create Launch Instance

✔️Step 1 : Now click on EC2, and let's go for Launch Instance

✔️Step 2: Launch an Instance and select the OS image name

You have to mention the name of your instance and after that select the AMI for this instance

✔️Step 3: Select your Instance type and Key-pair

Then go to the instance type and select t2.micro free tier eligible. After that select the key pair (login) or you can create new pair.

✔️Step 4 : Select Network Setting

The next step is the networking setting there is a firewall (security group), select create a security group and provide the name of the security group and give a description.

✔️Step 5: Create your security group rules and finally launch your Instance

In the type section, we have to set up inbound security rules such as ssh and in the source type section select anywhere and after that launch your instance.

❄️Task 2: Create EBS Snapshots and Volume

**✔️Step 1:**Navigate to the EC2 Dashboard

In the AWS Management Console, find the "Services" menu at the top.Under "Compute," click on "EC2" to open the EC2 Dashboard.

✔️Step 2: Select the Volumes

In the EC2 Dashboard, look at the left-hand navigation pane. Under the "Elastic Block Store" section, click on "Volumes" and now this will display a list of all EBS volumes in your account. Identify and select the volume you want to snapshot by clicking the checkbox next to the volume ID.

**✔️Step 3:**Create Snapshot

With the volume selected, click the "Actions" button at the top of the page.From the dropdown menu, select "Create Snapshot."A dialog box will appear prompting you to enter details for the snapshot.A dialog box will appear prompting you to enter details for the snapshot. Provide a meaningful description for the snapshot. This will help you identify the snapshot later.Click "Create Snapshot."

✔️Now EBS Snapshot Creation is done , go for Volumes

✔️Step 1: Navigate to the EC2 Dashboard and let's go for creating the Volumes

In the EC2 Dashboard, look at the left-hand navigation pane. Under the "Elastic Block Store" section, click on Volumes and create Volume

✔️Step 2: Select the Volume Type and Size

In this only, Select the type of volume you need (e.g., General Purpose SSD (gp2), Provisioned IOPS SSD (io1)), and the Size in Gib.

✔️Step 3: Select the Availability Zone

Select the Availability Zone where the volume will be created and do the other configuration(if needed) such as (e.g., encryption, IOPS for Provisioned IOPS SSD), and after configuring everything create the Volume.

❄️Task 3: Create Lambda Function

✔️Step 1: Now click on Lambda and let's go for Create Function

✔️Step 2: Choose the Option to create your Function

In this, you have to choose the option in which you want to create your Function or Simply go with Author from scratch(By default).

✔️Step 3:Select the function name, Runtime and Architecture

You have to just mention the name of your function and choose runtime according to your code, choose architecture and after doing this all simply create your Function

✔️Step 4: Once your function is created, it's time to do the testing

Now the Function is created, and you have to test your code for this you have to just down scroll through your touchpad or you will see the "Code" section on the left side of the screen, in Code you will see the "test" option. In test option you have to write your codes or instead of writing you can take the reference from my GitHub for codes.

✔️Step 5: Taking the Code from GitHub

In this, we will take the code from GitHub and perform various Functions.

✍️ FUNCTION 1 👇

1. Identifying Stale EBS Snapshots

   In this example, we will create a Lambda function(that we have already done ) that identifies EBS snapshots that are no longer associated with any active EC2 instance and deletes them to save on storage costs. For performing this Function we need code for it.

2. You can take the reference my GitHub(go to my GitHub through the link( https://github.com/shreyash81/AWS-Project... )

3. or I have provided the link in Step 4 . Just simply click on the link and go to

   EBS_Stale_snapshots.py file and take the code from there and paste it in the test section option in screen)

   OR just directly take it from here and paste it.

    import boto3
   
    def lambda_handler(event, context):
        ec2 = boto3.client('ec2')
   
        # Get all EBS snapshots
        response = ec2.describe_snapshots(OwnerIds=['self'])
   
        # Get all active EC2 instance IDs
        instances_response = ec2.describe_instances(Filters=[{'Name': 'instance-state-name', 'Values': ['running']}])
        active_instance_ids = set()
   
        for reservation in instances_response['Reservations']:
            for instance in reservation['Instances']:
                active_instance_ids.add(instance['InstanceId'])
   
        # Iterate through each snapshot and delete if it's not attached to any volume or the volume is not attached to a running instance
        for snapshot in response['Snapshots']:
            snapshot_id = snapshot['SnapshotId']
            volume_id = snapshot.get('VolumeId')
   
            if not volume_id:
                # Delete the snapshot if it's not attached to any volume
                ec2.delete_snapshot(SnapshotId=snapshot_id)
                print(f"Deleted EBS snapshot {snapshot_id} as it was not attached to any volume.")
            else:
                # Check if the volume still exists
                try:
                    volume_response = ec2.describe_volumes(VolumeIds=[volume_id])
                    if not volume_response['Volumes'][0]['Attachments']:
                        ec2.delete_snapshot(SnapshotId=snapshot_id)
                        print(f"Deleted EBS snapshot {snapshot_id} as it was taken from a volume not attached to any running instance.")
                except ec2.exceptions.ClientError as e:
                    if e.response['Error']['Code'] == 'InvalidVolume.NotFound':
                        # The volume associated with the snapshot is not found (it might have been deleted)
                        ec2.delete_snapshot(SnapshotId=snapshot_id)
                        print(f"Deleted EBS snapshot {snapshot_id} as its associated volume was not found.")
   

There is some Prerequisites are required for this particular process.(Identifying Stale EBS Snapshots)

Before going to the Deploying and testing phase. You have to delete the instance to perform this process.

How to Delete the instance?

1. Click on the EC2 Services and Navigate to EC2 Dashboard and click on Instances(running ) option.

2. Now you will see the option like INSTANCE STATE in your upside right-hand corner.

3. Just simply click on the INSTANCE STATE and terminate the Instance.

4. Now go for the Deploy and test code ( Fallow ✔️Step 6:)

✍️ FUNCTION 2 👇

Identifying Stale EBS Snapshots and Volumes

In the case of EBS snapshots are associated with volume and that volume is not attached to any running instance then delete the volume as well to save on storage costs. For performing this Function

we need code for it.

1. You can take the reference my GitHub(go to my GitHub through this link( https://github.com/shreyash81/AWS-Project... )

2. or I have provided in Step 4 . Just simply click on the link and go to

Stale_resource_Volume.py file and take code from there and paste it in the test section option in the screen)

OR just Directly take it from here and paste it.

import boto3

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

    # Get all EBS snapshots
    response = ec2.describe_snapshots(OwnerIds=['self'])

    # Get all active EC2 instance IDs
    instances_response = ec2.describe_instances(Filters=[{'Name': 'instance-state-name', 'Values': ['running']}])
    active_instance_ids = set()

    for reservation in instances_response['Reservations']:
        for instance in reservation['Instances']:
            active_instance_ids.add(instance['InstanceId'])

    # Iterate through each snapshot and delete if it's not attached to any volume or the volume is not attached to a running instance
    for snapshot in response['Snapshots']:
        snapshot_id = snapshot['SnapshotId']
        volume_id = snapshot.get('VolumeId')

        if not volume_id:
            # Delete the snapshot if it's not attached to any volume
            ec2.delete_snapshot(SnapshotId=snapshot_id)
            print(f"Deleted EBS snapshot {snapshot_id} as it was not attached to any volume.")
        else:
            # Check if the volume still exists
            try:
                volume_response = ec2.describe_volumes(VolumeIds=[volume_id])
                if not volume_response['Volumes'][0]['Attachments']:
                    ec2.delete_snapshot(SnapshotId=snapshot_id)
                    print(f"Deleted EBS snapshot {snapshot_id} as it was taken from a volume not attached to any running instance.")
                    # Delete the volume if it's not attached to any running instance
                    ec2.delete_volume(VolumeId=volume_id)
                    print(f"Deleted volume {volume_id} as it was not attached to any running instance.")
                else:
                    # Check if any of the volume attachments are to a running instance
                    attached_to_running_instance = False
                    for attachment in volume_response['Volumes'][0]['Attachments']:
                        if attachment['InstanceId'] in active_instance_ids:
                            attached_to_running_instance = True
                            break

                    if not attached_to_running_instance:
                        ec2.delete_snapshot(SnapshotId=snapshot_id)
                        print(f"Deleted EBS snapshot {snapshot_id} as its associated volume was not attached to any running instance.")
                        # Delete the volume if it's not attached to any running instance
                        ec2.delete_volume(VolumeId=volume_id)
                        print(f"Deleted volume {volume_id} as it was not attached to any running instance.")
            except ec2.exceptions.ClientError as e:
                if e.response['Error']['Code'] == 'InvalidVolume.NotFound':
                    # The volume associated with the snapshot is not found (it might have been deleted)
                    ec2.delete_snapshot(SnapshotId=snapshot_id)
                    print(f"Deleted EBS snapshot {snapshot_id} as its associated volume was not found.")

Same as we did in the previous Function we need some Prerequisites are required for this particular function. (Identifying Stale EBS Snapshots and Volumes)

Before going to the Deploying and testing phase. You have to delete the instance to perform this process.

How to Delete the instance?

1. Click on the EC2 Services and Navigate to EC2 Dashboard and click on Instances(running ) option.

2. Now you will see the option like INSTANCE STATE in your upside right-hand corner.

3. Just simply click on the INSTANCE STATE and terminate the Instance.

4. Now go for the Deploy and test code ( Fallow ✔️Step 6:)

✍️ FUNCTION 3 👇

Identifying Stale EBS Snapshots and Volumes and Running Instances

OR In the case of if EBS snapshot is associated with volume and that volume is attached to any active instance then firstly delete the running instance after that delete the volume and snapshots. For performing this Function we need code for it.

1. You can take the reference my GitHub(go to my GitHub through the link( https://github.com/shreyash81/AWS-Project... )

2. or I have provided the link in Step 4 . Just simply click on the link and go to

   Stale_resource_Active_Instances.py file and take the code from there and paste it in the test section option in screen)

3. Or Just directly take it from here and paste it.

✔️Step 6: Deploy and Test the Code

After writing the code you have to Deploy the code and then test the Code For these three Functions:

How to Deploy. How to Test.

Just simply click on Deploy After Deploying just simply click on

after you finished writing the code Test.

1. Identifying Stale EBS Snapshots

2. Identifying Stale EBS Snapshots and Volumes

3. Identifying Stale EBS Snapshots and Volumes and Running Instances

❄️Task 3: Troubleshoot your Errors

After testing you will face some errors and to Troubleshoot these errors you have to follow these steps.

✔️Step 1: To troubleshoot your first error that is Time out 3 sec.

/

1. Click on the "Configuration" section that will appear on the left of the Screen where you created your Function.

2. In the "Configuration" section, you will see the "General Configuration" option.

3. Click the "General Configuration" option and you will see the "Edit tab" on the right side of your screen.

4. Click on the "Edit" option and increase the Timeout to 10 seconds.

✔️Step 2 :To troubleshoot your second error that is related to IAM Rules and Polices

✔️Step 3 : Now everything is fine and let's go for test the different Function Code

❄️See the Results related to this Project: