This week, I dove into the world of DevOps by setting up a CI/CD pipeline to automatically deploy a static website every time I push changes to GitHub. The goal was to streamline the deployment process and eliminate manual uploads — and it worked like a charm!

Whether you're a beginner or just getting into automation, this guide will give you a quick overview of how I achieved this using GitHub, AWS CodePipeline, CodeBuild, S3, and CloudFront.

What I Built

I created a simple static website using plain HTML and CSS. Here’s the flow of the deployment process I implemented:

1. Code on GitHub – Version-controlled and easy to manage.

2. AWS CodePipeline – Triggers automatically whenever I push to the main branch.

3. CodeBuild – Optional for static sites, but I used it for future scalability (e.g., compiling assets or linting).

4. S3 Bucket – Hosts the static files as a public website.

5. CloudFront – Ensures fast, global content delivery via CDN.

Tools & Services Used

• GitHub – Code hosting and version control

• AWS CodePipeline – Orchestrates the CI/CD process

• AWS CodeBuild – Handles the build stage (even for static projects)

• Amazon S3 – Static site hosting

• Amazon CloudFront – Content Delivery Network (CDN) for speed

• IAM (Identity & Access Management) – Ensures secure communication between services

Key Takeaways

• 🔁 Fully automated deployments = no more manual uploads — just push to GitHub and done!

• 🌍 S3 + CloudFront = blazing fast delivery, anywhere in the world

• 🔐 IAM roles are critical in securely allowing services like CodePipeline and CodeBuild to interact with S3 and other AWS resources

Final Thoughts

Setting up CI/CD for a static website might seem like overkill at first — but once it’s up and running, it saves tons of time and ensures consistency in your deployments. I

Overview

For this week blogs, I will talk about how I implemented a real-world automation workflow using Amazon S3, AWS Lambda, and Amazon SNS. My goal? To automatically send myself an email notification every time a new file was uploaded to a specific S3 bucket.

This kind of automation is not only useful for personal projects but also a common pattern in enterprise workflows for building responsive, event-driven systems.

🧠 What I Did

Here’s a breakdown of the steps I followed:

1. Created an S3 Bucket

I started by creating a new Amazon S3 bucket where files would be uploaded. This bucket serves as the trigger source for the event notifications.

2. Wrote a Lambda Function to Process Events

Next, I created a Lambda function using Node.js (you can use Python or other supported runtimes). The function is designed to receive S3 event data and publish a message to SNS.

javascriptCopyEditconst AWS = require('aws-sdk');
const sns = new AWS.SNS();

exports.handler = async (event) => {
    const bucketName = event.Records[0].s3.bucket.name;
    const objectKey = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " "));

    const message = `New file uploaded:\nBucket: ${bucketName}\nFile: ${objectKey}`;

    const params = {
        Message: message,
        Subject: "S3 Upload Notification",
        TopicArn: process.env.SNS_TOPIC_ARN,
    };

    await sns.publish(params).promise();

    return {
        statusCode: 200,
        body: JSON.stringify('Notification sent.'),
    };
};

I also set the SNS_TOPIC_ARN as an environment variable in the Lambda console.

3. Set Up Amazon SNS for Email Notifications

I created an SNS topic and subscribed my email address to it. Once confirmed, this topic could now receive messages from Lambda and forward them via email.

4. Integrated Everything

The final step was connecting the pieces:

• S3 bucket → Lambda trigger: I enabled event notifications in the S3 bucket settings to trigger the Lambda function on PUT events (file uploads).

• Lambda → SNS: The Lambda function sends a message to SNS when triggered.

• SNS → Email: SNS forwards the message as an email notification to my subscribed address.

⚙️ Tools Used

• Amazon S3 – For storing uploaded files.

• AWS Lambda – To process S3 events and publish messages.

• Amazon SNS – To send email notifications.

• IAM Roles – For securely granting permissions between services.

🚀 Why This Matters

In modern cloud-native applications, automated notifications and serverless event-driven pipelines reduce manual intervention and boost operational responsiveness. Whether you're monitoring logs, triggering batch jobs, or alerting on file uploads, this architecture pattern is powerful and scalable.

🔍 Key Learnings

• IAM roles and permissions are crucial. Lambda needs permissions to read from S3 and publish to SNS. Setting up the correct execution role was key to getting this workflow running.

• CloudWatch Logs made debugging Lambda functions straightforward. I was able to trace the event structure and confirm that the message was being sent as expected.

• SNS supports multiple subscribers – not just email, but also SMS, HTTP endpoints, and AWS Lambda functions. This makes it a flexible tool for multi-channel alerting.

Hi, I’m Sadikshya Baral — a recent computing graduate and a cloud enthusiast. A few months ago, I started my journey into the world of Amazon Web Services (AWS) with no prior cloud experience. Today, I’ve completed over 35 hands-on AWS projects ranging from hosting static sites to automating infrastructure with Terraform.

This blog is the first in a 4-week series where I’ll share my journey, projects, learnings, and key takeaways — in the hope that it will inspire or guide others stepping into cloud computing.

How It Started: Spinning Up My First EC2 Instance

Like many, my AWS learning began with EC2, Amazon’s virtual server. I started by:

• Creating an EC2 instance from scratch

• Hosting a WordPress site

• Learning how to SSH into instances

• Understanding key pairs and security groups

The first time I saw my WordPress site live from an EC2 instance, it was an "aha" moment. I realized how powerful and accessible cloud infrastructure could be.

IAM, S3, and Lambda: Exploring AWS Core Services

After EC2, I dived deeper into:

• IAM: Created custom IAM roles and policies to understand access control

• S3: Built and hosted static websites, explored lifecycle policies, versioning, and replication

• Lambda: Developed my first serverless functions, including one that analyzes text uploaded to S3

I also hosted Jenkins on EC2 and used the AWS pricing calculator to estimate costs, reinforcing how cloud is both technical and financial.

Learning by Building: Databases, CI/CD & Serverless

As I got more confident, I started integrating multiple services:

• Installed MySQL on EC2, connected it with MySQL Workbench

• Created and managed RDS databases

• Set up CI/CD pipelines using:

  • GitHub

  • CodeCommit

  • CodePipeline

  • CodeBuild

• Built and deployed static websites automatically

One of my favorite serverless projects was counting words from a text file automatically using Lambda triggered by S3 events.

Evolving into DevOps & Infrastructure as Code

Once I mastered individual services, I wanted to automate the whole process.

That’s when I discovered CloudFormation and Terraform:

• Used CloudFormation to automate S3 website hosting

• Wrote Terraform scripts to:

  • Provision EC2

  • Set up S3 buckets

  • Automate S3 replication

  • Deploy scalable websites using ALB, EC2, and CloudFront

This was a turning point — I saw how infrastructure as code (IaC) could reduce time, errors, and boost productivity.

API Security & Cloud Compliance

With the foundation laid, I focused on security and scalability:

• Used Amazon Cognito for securing API access

• Learned about AWS Service Catalog for governance and compliance

• Backed up EC2 instances using AWS Backup

• Accessed EC2 securely using Session Manager and OpenVPN

Key Takeaways So Far

• Hands-on is the best way to learn AWS. Reading is not enough — build!

• Start small, but keep scaling your knowledge as you go.

• Automation is powerful. Once you get into CloudFormation and Terraform, everything clicks.

• Security matters: IAM, Cognito, and backups are just as important as deploying services.

What’s Next in Week 2?

In Week 2, I’ll dive deeper into a technical post about most practical and exciting projects I’ve done.

Final Note

If you’re just starting out with AWS, don’t be intimidated. I was there too — confused by acronyms and overwhelmed by the AWS dashboard. But with consistency and curiosity, I turned that confusion into confidence.

Thanks for reading! 😊
Let’s keep building.