Launch an EC2 instance on AWS and connect to it using two methods: the browser-based EC2 Connect method and the PuTTY SSH client using a PPK key file.
Linux-ec2.t3.micro is selected as a free-tier eligible instance..pem file downloads automatically.putty.org)..pem file, open PuTTYgen → Load the .pem file → click Save Private Key to generate the .ppk file..ppk file.ubuntu (for Ubuntu AMI) and press Enter.An EC2 instance was successfully launched on AWS. Two connection methods were demonstrated: the browser-based EC2 Connect method (no client needed) and PuTTY with a PPK key file for SSH access. Security groups control access by allowing only the required port (SSH 22).
Scale an EC2 instance by changing its type, create and attach an EBS volume, perform cross-instance data transfer, and replicate data across AWS regions using snapshots.
t2.nano.gp3/gp2), size, and Availability Zone (must match the target EC2 instance). Click Create Volume.# Check all available disks lsblk # Check filesystem of each device lsblk -fs # Create a partition on the new volume sudo fdisk /dev/nvme1n1 # Press 'm' for help menu, then follow prompts to create partition
# Create mount directory sudo mkdir /mnt/ebstry # Mount the volume partition sudo mount /dev/nvme1n1p1 /mnt/ebstry # Verify mount - all previous data will be available lsblk
lsblk sudo mkdir /mnt/ebstry sudo mount /dev/nvme1n1p1 /mnt/ebstry df -h
EBS volumes were created, attached, mounted, and verified. Scaling was achieved by changing the instance type. Cross-region data replication was demonstrated by copying a snapshot from N. Virginia to Oregon and mounting it on a new instance.
Create an EFS file system and mount it on two EC2 instances in different Availability Zones, demonstrating shared file access across instances.
us-east-1a.efslab. Add an inbound rule: Type: NFS, Source: Anywhere.us-east-1b. Select the existing efslab security group.efslab.# Paste the NFS client command (change directory name at the end) # Example: sudo mount -t nfs4 -o nfsvers=4.1 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ efslab # Navigate to the mounted directory cd efslab # Create a file touch file.txt # Add content to the file echo "Shared via EFS" > file.txt
# Paste the same NFS client mount command (change directory name) sudo mount -t nfs4 -o nfsvers=4.1 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ efslab # Navigate to directory cd efslab # List files (file.txt from Instance 1 appears) ls # Display file content cat file.txt
EFS was configured and mounted on two EC2 instances in different Availability Zones. A file created on Instance 1 was immediately accessible from Instance 2, demonstrating EFS as a shared, elastic NFS file system across multiple instances.
Create an S3 bucket, configure public access via ACLs, enable versioning, and set up cross-region object replication.
S3 was explored in depth: bucket creation, public access via ACLs, object-level permissions, versioning with delete markers, and cross-region replication. These features cover the core S3 capabilities needed for scalable, redundant object storage.
Create a custom VPC with public and private subnets, configure route tables and an Internet Gateway, then launch EC2 instances with proper network connectivity.
10.0.0.0/16).10.0.1.0/24) and a Private Subnet (e.g., 10.0.2.0/24) within the VPC.public-route.private-route in the same VPC.public-route → Actions → Edit routes → Add route. Destination: 0.0.0.0/0, Target: Internet Gateway. Select the gateway → Save changes.public-route → Edit subnet associations. Select the public subnet → Save associations. Repeat for private route and private subnet.A custom VPC was created with both public and private subnets. Route tables were configured to connect the public subnet to the Internet Gateway. EC2 instances were launched in appropriate subnets with security group rules enforcing access control.
Configure a NAT Gateway to allow a private subnet EC2 instance to access the internet without being publicly reachable. Use a Jump Server to access the private instance.
my-vpc with a public and private subnet. Create two route tables and an Internet Gateway. Connect the public route table to the Internet Gateway.# SSH into jump-server first, then into db-server # Test internet from db-server (will fail without NAT) ping google.com # Result: Network unreachable
0.0.0.0/0, Target: select the NAT Gateway. Save changes.ping google.com # Result: replies received (internet now reachable via NAT Gateway)
A NAT Gateway was deployed in the public subnet and the private route table was updated to route internet-bound traffic through it. The private db-server now has outbound internet access while remaining inaccessible from the internet directly.
Create a Lambda function that is automatically triggered when an object is uploaded to an S3 bucket, and stores the object metadata into a DynamoDB table.
lambda-function. Select runtime: Python 3.10.LabRole (which has permissions for S3 and DynamoDB). Click Create function.A serverless workflow was implemented: S3 upload triggers Lambda, which stores object metadata to DynamoDB. CloudWatch Logs verified execution. This is the standard event-driven architecture pattern in AWS serverless applications.
Set up SNS for email notifications and SQS for message queuing, then build an end-to-end pipeline: S3 upload event triggers SNS, which fans out to SQS, which can trigger Lambda for processing.
MyEmailTopic. Click Create topic.MyQueue. Leave defaults → Create queue.MyQueue → Send and receive messages. In Message body, enter a test message → click Send message.s3-sns-sqs-lambda. Create an SNS Standard topic named MyS3SNSTopic. Copy the SNS Topic ARN.MyS3Queue. Copy the Queue ARN.MyS3SNSTopic → Create subscription. Protocol: Amazon SQS. Endpoint: select MyS3Queue. Click Create subscription.MyS3Queue → Access Policy → Edit. Update the policy JSON with the SQS ARN and SNS ARN to allow SNS to send messages to the queue.SNS and SQS were configured independently and then connected into a full event pipeline. An S3 upload triggers SNS, which delivers to SQS, enabling decoupled, asynchronous event-driven processing with Lambda.
Deploy two EC2 web servers behind an Application Load Balancer, then configure an Auto Scaling Group to automatically maintain instance count and recover from failures.
sudo yum update -y sudo yum install httpd -y systemctl start httpd systemctl enable httpd echo "This is Server 1" > /var/www/html/index.html
sudo yum update -y sudo yum install httpd -y systemctl start httpd systemctl enable httpd echo "This is Server 2" > /var/www/html/index.html
Verify: paste each server's public IP in a browser to confirm the correct page loads.
loadbalancer-sg. Inbound rule: HTTP (80) from anywhere. Leave outbound as default.my-loadbalancer. Scheme: Internet-facing. Select all subnets. Choose loadbalancer-sg.my-targetgroup. Target type: Instance. Protocol: HTTP, Port: 80. Select both web server instances → Include as pending → Create target group.my-webserver-AMI. Click Create Image.my-template. Select the AMI created above. Instance type: t2.micro. Select your key pair.An Application Load Balancer distributed traffic across two Apache web servers. An Auto Scaling Group with a custom AMI was configured to maintain instance count between 1 and 4. Terminating an instance confirmed automatic recovery, demonstrating high availability and fault tolerance.
Build and test a Java web application locally in Eclipse, export it as a WAR file, and deploy it to AWS Elastic Beanstalk without manually provisioning any infrastructure.
NotesApp. Target Runtime: Apache Tomcat. Click Finish.NotesApp. Add an optional description. Click Create..war file. Leave remaining settings as default → click through Next and Create.A Java web application was developed and tested locally on Apache Tomcat, exported as a WAR file, and deployed to AWS Elastic Beanstalk. Beanstalk automatically provisioned the underlying EC2, load balancer, and scaling infrastructure without manual configuration.
Build a conversational chatbot using Amazon Lex that can handle hotel booking requests, collect user information via slots, and provide confirmation responses.
HotelBookingBot. IAM role: Create new role. Leave remaining settings as default. Click Next.BookHotel. Click Create.location. Slot type: AMAZON.City. Prompt: Which city do you want?. Mark as Required. Click Add.RoomType. Add values: single, double, suite.BookHotel intent → Add slot. Slot name: RoomType. Slot type: RoomType (the custom type just created).single, double, suite. Click Update prompts.Initial Response: Welcome to Hotel Booking! What is your name? Confirmation prompt: Do you want to confirm booking in {location} for {nights} nights?
A hotel booking chatbot was built with Amazon Lex using intents, utterances, and custom slot types. The bot collected city, room type, and other booking details through a guided conversation, demonstrating AWS Lex for building conversational AI interfaces without any ML expertise.
Create an IAM user with limited S3 permissions, verify access control through the AWS Console GUI, then configure AWS CLI with the user's credentials and confirm the same policy restrictions apply programmatically.
AmazonS3FullAccess. Click Next → Create user.console.aws.amazon.com → select IAM User). Enter the Account ID, username, and password from the CSV.aws.amazon.com/cli.# Configure CLI with access key credentials aws configure # Enter: Access Key ID, Secret Access Key, Default region (ap-south-1), Output format (json) # Test S3 access (should succeed) aws s3 ls # Create an S3 bucket (should succeed) aws s3 mb s3://your-unique-bucket-name # Test IAM access (should fail - Access Denied) aws iam list-users
An IAM user was created with S3-only permissions. Access control was verified through both the Console GUI (EC2 denied, S3 allowed) and the AWS CLI (IAM listing denied, S3 operations allowed). This confirms that IAM policies apply consistently across all access methods.
Create an IAM Role with S3 permissions and attach it to an EC2 instance so the instance can access S3 without storing any access keys on the machine.
AmazonS3FullAccess policy. Click Next.EC2-S3-Role. Click Create role.EC2-S3-Role from the dropdown → click Update IAM role.# List all S3 buckets - works without aws configure aws s3 ls # Access is granted via the attached IAM role, no access keys needed
An IAM Role with S3 full access was created and attached to an EC2 instance as an instance profile. The instance successfully accessed S3 using aws s3 ls without requiring any access keys to be configured, demonstrating the secure and recommended approach to granting AWS service permissions to EC2 instances.