DEV Community: CHANDRA PRABHA V

Chandra Meets CodeDeploy: My First AWS Deployment Journey

CHANDRA PRABHA V — Wed, 16 Sep 2026 01:30:57 +0000

Chandra Meets CodeDeploy: My First AWS Deployment Journey ☁️

Exploring how AWS CodeDeploy makes application deployment easier, faster, and more reliable.

Introduction

In software development, creating an application is only the beginning. After writing code, developers must move it from their computers to a server where users can access it. This process is called deployment.

Imagine a student team developing a college placement prediction application. Every time the team improves the machine learning model or updates the website, they need to transfer the new files to the server, configure the application, and restart it. Doing this manually can be time-consuming and may cause errors.

This is where AWS CodeDeploy becomes useful. It automates the deployment of application updates to supported computing environments. In this blog, I will explore what AWS CodeDeploy is, how it works, its important features, and how a college student project can benefit from it.

What Is AWS CodeDeploy?

AWS CodeDeploy is a fully managed deployment service provided by Amazon Web Services (AWS). It helps developers automatically deploy application code, configuration files, scripts, and other application content to computing environments.

CodeDeploy supports three major compute platforms:

Amazon EC2 and on-premises servers: Deploy applications to cloud-based or supported physical servers.
AWS Lambda: Deploy new versions of serverless functions.
Amazon ECS: Deploy updated containerized applications.

It can retrieve application revisions from sources such as Amazon S3 and supported source-code repositories, depending on the deployment platform.

Why Was CodeDeploy Created?

Before automated deployment tools became common, developers often copied files manually to servers and executed several commands to update an application. This process could lead to configuration mistakes, inconsistent deployments, and application downtime.

AWS CodeDeploy was created to simplify this process. It allows developers to define deployment instructions once and reuse them whenever a new application version is released.

Instead of repeatedly performing deployment tasks manually, developers can allow CodeDeploy to install the new version, execute required scripts, monitor the deployment, and report whether it succeeded.

How It Works

At a high level, CodeDeploy follows a simple pattern:

You store your application code in a source location (GitHub, S3, or CodeCommit).
You describe the deployment steps in a file called appspec.yml, which lives with your code.
CodeDeploy picks up the revision, copies it to your target instances (or updates your Lambda/ECS version), and runs the lifecycle hooks defined in appspec.yml in order — stopping the old version, installing the new one, and starting it back up.
If you've attached CloudWatch alarms, CodeDeploy watches them during the rollout and automatically rolls back if something looks unhealthy.

Here's a simplified view of that flow:

(Diagram: Developer → Source Repo → CodeDeploy reads appspec.yml → Deployment Group runs lifecycle hooks (ApplicationStop → DownloadBundle → BeforeInstall → Install/AfterInstall → ApplicationStart/ValidateService) → CloudWatch monitors health and can trigger rollback.)

Key Features

Automated, consistent deployments Once configured, deployments happen the same way every time — no manually remembering which command to run on which server. This removes a huge class of human error.
Multiple deployment strategies CodeDeploy supports in-place deployments (update the existing instances one at a time or in batches) and blue/green deployments (spin up a new fleet, shift traffic over, and terminate the old one only after the new one is verified). This lets you choose between speed and safety depending on the project.
Automatic rollback on failure If a deployment fails a lifecycle event or trips a CloudWatch alarm, CodeDeploy can automatically roll back to the last known good version — something that's genuinely hard to build reliably by hand.
Works across compute types The same core service deploys to EC2/on-premises servers, Lambda functions, and ECS containers, so you don't need a completely different tool depending on your architecture.

College / Student Use Case

Here's where this becomes directly relevant to campus life. At CIT, several departments run small internal web apps — placement portals, event registration pages, club websites (like our Rotaract Club page), or student project demos hosted for review. Right now, most of these are deployed manually: someone logs into a server, pulls the latest code, and restarts it, often right before a demo deadline.

A practical use case: our department could host student mini-project demos (like a Flask-based ML model demo) on a small EC2 instance, with CodeDeploy watching the GitHub repository. Every time a student pushes an update before their review, CodeDeploy automatically redeploys the latest version to the demo server — no manual server access needed, and no risk of forgetting a step under deadline pressure. If the new version crashes, CodeDeploy rolls back automatically, so the demo server never goes down entirely.

Simple Example

A minimal appspec.yml for deploying a small web app to EC2 looks like this:

yaml
version: 0.0
os: linux
files:

source: / destination: /var/www/student-project hooks: BeforeInstall:
- location: scripts/stop_server.sh timeout: 60 AfterInstall:
- location: scripts/install_dependencies.sh timeout: 180 ApplicationStart:
- location: scripts/start_server.sh timeout: 60 ValidateService:
- location: scripts/health_check.sh timeout: 60

And triggering a deployment through the AWS CLI is just:

bash
aws deploy create-deployment \
--application-name student-demo-app \
--deployment-group-name demo-server-group \
--github-location repository=my-username/student-project,commitId=

CodeDeploy then runs each hook script in order and reports success or failure in the console.

Key Features of AWS CodeDeploy

1. Automated Deployments

CodeDeploy automates the process of transferring and installing application updates. It reduces the need for developers to manually copy files, execute installation commands, and restart services.

For example, a team can prepare a new version of a web application and use CodeDeploy to release it to a group of EC2 instances.

2. In-Place and Blue/Green Deployments

CodeDeploy supports different deployment strategies.

In-place deployment: The existing servers are updated with the new application version. The application may be stopped during the update, depending on the configuration.

Blue/green deployment: A new environment is prepared with the updated application. After testing, traffic can be redirected from the old environment to the new one. This can reduce service interruptions and make testing safer.

For EC2 deployments, CodeDeploy supports both in-place and blue/green strategies. Lambda and ECS deployments use blue/green deployment methods with traffic-shifting configurations.

3. Deployment Scripts Using AppSpec

The AppSpec file is an important part of CodeDeploy. It defines how files should be copied and which scripts should run during different deployment stages.

For example, a deployment may need to:

Copy application files to a particular folder.
Install Python dependencies.
Stop an older application process.
Start the updated application.
Run a validation command.

These instructions can be stored in the AppSpec file and reused during future deployments.

4. Monitoring and Rollback Support

CodeDeploy provides deployment status information through the AWS Management Console and AWS CLI. Developers can check whether a deployment succeeded, failed, or is still in progress.

Deployment configurations can also work with health checks and alarms. In suitable setups, failed deployments can be stopped or rolled back to a previous application version.

College/Student Use Case 🎓

Consider a student team at a college developing a Placement Prediction Web Application.

The project uses:

Python and Flask for the backend.
A machine learning model to predict placement outcomes.
HTML, CSS, and JavaScript for the frontend.
An Amazon EC2 instance to host the application.

Initially, the team manually uploads updated Python files and the machine learning model to the EC2 server whenever they make changes. As the project grows, this becomes difficult to manage, especially when several students contribute code.

The team can use AWS CodeDeploy to automate the process.

Whenever the team prepares a new application version, they can package the Flask application, configuration files, and deployment scripts into a revision. The revision can be uploaded to Amazon S3. CodeDeploy can then deploy the revision to the EC2 instance.

For example, when the team improves the prediction model, CodeDeploy can install the updated model and application files, execute the required scripts, and report the deployment result.

This approach helps students understand real-world DevOps practices, reduces repetitive manual work, and creates a more organized deployment workflow.

Simple Practical Example

Let us consider a basic Python Flask application deployed to an Ubuntu EC2 instance.

Project Structure

my-flask-app/
│
├── app.py
├── requirements.txt
├── appspec.yml
└── scripts/
    ├── install_dependencies.sh
    └── start_application.sh

1. Flask Application

The app.py file contains a simple web application:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello from AWS CodeDeploy!"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

2. AppSpec File

The appspec.yml file tells CodeDeploy where to copy the application files and which scripts to execute.

version: 0.0
os: linux

files:
  - source: /
    destination: /home/ubuntu/my-flask-app

hooks:
  AfterInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: ubuntu

  ApplicationStart:
    - location: scripts/start_application.sh
      timeout: 300
      runas: ubuntu

The files section specifies the destination directory. The hooks section defines scripts that run after installation and when the application starts.

3. Deployment Scripts

The install_dependencies.sh script can install the Python packages required by the application.

#!/bin/bash
cd /home/ubuntu/my-flask-app
python3 -m pip install -r requirements.txt

The start_application.sh script can start the Flask application.

#!/bin/bash
cd /home/ubuntu/my-flask-app
nohup python3 app.py > app.log 2>&1 &

These scripts are only a basic demonstration. In a production environment, a process manager such as systemd should normally be used instead of repeatedly starting background processes with nohup.

4. Deployment Process

The student team can follow these steps:

Create the application files and deployment scripts.
Add the AppSpec file to the project.
Package the files into a ZIP archive.
Upload the archive to an Amazon S3 bucket.
Create a CodeDeploy application using the EC2/On-Premises compute platform.
Create a deployment group and identify the target EC2 instance.
Install and configure the CodeDeploy agent on the instance.
Start a deployment using the AWS Management Console or AWS CLI.
Check the deployment status and test the Flask application.

The EC2 instance must have the necessary IAM permissions, and the CodeDeploy agent must be correctly installed and running.

Advantages of AWS CodeDeploy

AWS CodeDeploy offers several advantages:

Saves time: Automates repetitive deployment tasks.
Reduces manual errors: Uses predefined deployment instructions.
Supports different environments: Works with EC2, supported on-premises servers, Lambda, and ECS.
Improves release management: Makes it easier to deploy new application versions consistently.
Supports safer updates: Blue/green deployment strategies can reduce downtime and allow testing before shifting traffic.
Works with scaling infrastructure: Deployments can target multiple instances and integrate with AWS services.

Limitations and Things to Consider

Although CodeDeploy is useful, it is not a complete replacement for every DevOps tool.

Cost

CodeDeploy does not charge an additional fee for deployments to Amazon EC2, on-premises instances, AWS Lambda, or Amazon ECS. However, the AWS resources used alongside it may incur charges.

For example, students may need to pay for EC2 instances, Amazon S3 storage, data transfer, CloudWatch monitoring, or other services. AWS Free Tier eligibility and pricing conditions should be checked before using resources.

Complexity

CodeDeploy requires configuration of IAM roles, deployment groups, application revisions, and, for EC2 deployments, the CodeDeploy agent. Beginners may need time to understand these components.

Security

IAM permissions should follow the principle of least privilege. S3 buckets should be protected, credentials should not be stored inside application files, and deployment scripts should be reviewed before execution.

Application Compatibility

CodeDeploy automates deployment, but it does not automatically fix bugs in application code, configure every server dependency, or guarantee that an application will work after deployment. Developers must prepare correct scripts and test their applications.

Conclusion

AWS CodeDeploy is a useful AWS service for automating application deployments. It helps developers move application updates to servers, Lambda functions, or ECS services in a more consistent and controlled manner.

For college students, CodeDeploy provides practical experience with cloud computing, DevOps, deployment automation, IAM, and application release management. A student project such as a placement prediction application can benefit from fewer manual deployment steps and a more organized release process.

As I explore AWS services, CodeDeploy shows me that building an application is only one part of software engineering. Delivering and maintaining that application reliably is equally important.

Chandra's takeaway: CodeDeploy helps turn the process of “I finished my code” into “My updated application is deployed and ready to use.” ☁️

References

My AWS Learning Journey: CloudWatch, Lambda, IAM & CloudFront

CHANDRA PRABHA V — Wed, 16 Sep 2026 01:17:47 +0000

As part of my cloud learning journey, I recently explored some important AWS services and learned how they work together to build, secure, monitor, and deliver cloud-based applications.

The four services I focused on were:

☁️ AWS CloudWatch
⚡ AWS Lambda
🔐 AWS IAM
🌍 Amazon CloudFront

Each service has a different purpose, but together they helped me understand some of the core concepts behind cloud computing.

☁️ 1. AWS CloudWatch

Amazon CloudWatch is a monitoring and observability service in AWS.

I learned how CloudWatch can be used to monitor AWS resources and applications by collecting metrics, logs, and events.

What I learned:

Monitoring AWS resources
Viewing metrics and logs
Creating dashboards
Setting alarms
Understanding application and resource performance

For example, CloudWatch can help monitor whether a service is running normally or whether something needs attention.

This helped me understand that deploying an application is only one part of cloud computing. We also need to monitor what is happening after deployment.

⚡ 2. AWS Lambda

AWS Lambda is a serverless computing service that allows us to run code without managing servers.

Instead of setting up a server and keeping it running continuously, we can create a Lambda function that runs when a particular event occurs.

What I learned:

Creating Lambda functions
Running Python code using Lambda
Understanding serverless computing
Working with event-driven execution
Understanding Lambda triggers

A simple example is:

Event → Lambda Function → Process → Response

This was one of the interesting concepts I learned because it showed me how applications can execute code only when it is needed.

🔐 3. AWS IAM

AWS Identity and Access Management (IAM) is used to control access to AWS resources.

I learned that security is a major part of cloud computing. IAM allows us to control who can access what in an AWS account.

What I learned:

Users
Groups
Roles
Policies
Permissions
Access control

One important concept I understood was the principle of least privilege, where users and services should receive only the permissions they actually need.

For example:

User → IAM Policy → AWS Resource

This helped me understand why permissions should be carefully managed instead of simply giving every user full access. Apparently, giving everyone the keys to the kingdom is not considered a security strategy.

🌍 4. Amazon CloudFront

Amazon CloudFront is a Content Delivery Network (CDN) service used to deliver content to users with low latency.

I learned how CloudFront works with edge locations to deliver content closer to users.

A simplified flow is:

User → CloudFront Edge Location → Origin → Content

The origin could be services such as Amazon S3 or an application server.

What I learned:

CDN concepts
Edge locations
Origins
Caching
Faster content delivery
HTTPS and secure content delivery

This helped me understand how websites and applications can serve content efficiently to users in different geographical locations.

🔗 How These Services Connect

One of the most useful things I learned was that AWS services don't necessarily work in isolation.

A simple cloud application could use:

IAM → Controls access 🔐

Lambda → Runs application logic ⚡

CloudFront → Delivers content globally 🌍

CloudWatch → Monitors the application ☁️

So, together:

             👤 User
                |
                v
        🌍 CloudFront
                |
                v
          ⚡ Application
                |
             Lambda
                |
                v
        ☁️ CloudWatch
          Monitoring

        🔐 IAM
     Access & Permissions

This gave me a better understanding of how different AWS services can form parts of a complete cloud architecture.

🎓 What I Gained From This Learning

Exploring these services helped me understand several important cloud concepts:

✅ Serverless computing
✅ Cloud monitoring
✅ Identity and access management
✅ CDN and content delivery
✅ Event-driven architecture
✅ Cloud security
✅ AWS resource management

More importantly, I started looking at cloud applications not just as code running somewhere on the internet, but as a combination of compute, security, monitoring, and delivery.

Keep learning. Keep building. ☁️🚀

AWS #AmazonWebServices #CloudComputing #CloudWatch #AWSLambda #IAM #CloudFront #Serverless #DevOps #LearningInPublic #TechLearning

Hosting My Portfolio on AWS S3 with CloudFront

CHANDRA PRABHA V — Tue, 15 Sep 2026 06:59:07 +0000

Hosting My Portfolio on AWS S3 with CloudFront

Introduction

I wanted to host my personal portfolio using AWS and understand how a static website can be deployed using cloud services.

For this project, I used Amazon S3 to store my portfolio files and Amazon CloudFront to deliver the website through a secure and fast content delivery network (CDN).

The final architecture is:

Internet
   |
   v
CloudFront
   |
   | Origin Access Control
   v
S3 Bucket
   |
   +-- index.html

One important part of this setup is that the S3 bucket remains private.

Technologies Used

Amazon S3 - Stores the portfolio files.
Amazon CloudFront - Delivers the website globally through a CDN.
HTML - Creates the structure of the portfolio.
CSS - Provides styling for the portfolio.

Step 1: Creating the S3 Bucket

First, I logged in to the AWS Management Console and searched for S3.

I opened Amazon S3 and selected:

Create bucket

I entered a unique bucket name.

Example:

chandra-prabha-portfolio-2026

The bucket name must be globally unique because S3 bucket names are shared across AWS.

For the AWS Region, I selected:

Asia Pacific (Mumbai) - ap-south-1

Bucket Configuration

For Object Ownership, I kept:

ACLs disabled
Bucket owner enforced

For Block Public Access, I kept all public access blocked.

This is important because I wanted the S3 bucket to remain private and allow CloudFront to access the files instead.

I then clicked:

Create bucket

Screenshot

Step 2: Uploading Portfolio Files

After creating the bucket, I opened it from the S3 bucket list.

My portfolio contained files such as:

├── index.html

I selected:

Upload → Add files

and uploaded my portfolio files.

The index.html file acts as the main page of the portfolio.

The style.css file contains the styling, while the images folder contains images used by the website.

Step 3: Creating a CloudFront Distribution

After uploading the files, I created a CloudFront distribution.

I opened:

AWS Console → CloudFront

and selected:

Create distribution

For the Origin domain, I selected my S3 bucket.

The origin points to the S3 bucket where my portfolio files are stored.

The important point here is that I selected the S3 bucket origin, not the S3 static website endpoint.

This allows CloudFront to securely communicate with the S3 bucket.

Screenshot

Step 4: Updating the S3 Bucket Policy

After configuring OAC, CloudFront needs permission to read the objects from the S3 bucket.

AWS provides a bucket policy for allowing the CloudFront distribution to access the bucket.

I went to:

S3 → My Bucket → Permissions → Bucket Policy

The policy allows the CloudFront service to perform:

s3:GetObject

on the objects inside the bucket.

The policy is associated with my specific CloudFront distribution.

The general structure looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::YOUR-AWS-ACCOUNT-ID:distribution/YOUR-DISTRIBUTION-ID"
        }
      }
    }
  ]
}

I used the policy generated for my own CloudFront distribution rather than manually guessing the values.

Screenshot

Step 5: Setting `index.html` as the Default Root Object

The next step was configuring the default page of the CloudFront distribution.

Inside the CloudFront distribution settings, I set:

Default root object: index.html

This is useful because users can simply visit:

https://my-cloudfront-domain/

instead of:

https://my-cloudfront-domain/index.html

CloudFront automatically serves index.html when the root URL is requested.

Screenshot

Step 6: Deploying the CloudFront Distribution

After completing the configuration, I created the CloudFront distribution.

Initially, CloudFront may show a deployment status while AWS creates the distribution and applies the configuration.

After deployment, the distribution becomes available.

The CloudFront console provides a domain name similar to:

d2ze62elibenrh.cloudfront.net

This domain can be used to access the portfolio.

Step 7: Testing the Portfolio

After the CloudFront distribution was deployed, I opened the CloudFront URL in my browser.

Example:

https://d1234567890abc.cloudfront.net

The portfolio website was displayed successfully.

The request flow was:

Browser
   |
   v
CloudFront
   |
   v
S3
   |
   v
index.html

Screenshot

Why Use CloudFront?

CloudFront is a Content Delivery Network (CDN).

Instead of every user directly accessing the S3 bucket, CloudFront handles requests and delivers the content through its distributed infrastructure.

This provides several advantages:

Faster content delivery
HTTPS support
Caching of static files
Reduced load on the origin
Better global performance
Integration with AWS security features

For a simple portfolio, the performance difference may not be dramatic, but the architecture is much more representative of a real cloud deployment.

What I Learned

Through this project, I learned how to:

Create and configure an Amazon S3 bucket.
Upload static website files to S3.
Create a CloudFront distribution.
Configure an S3 origin for CloudFront.
Configure Origin Access Control.
Use an S3 bucket policy to allow CloudFront access.
Configure index.html as the default root object.
Deploy and test a website using a CloudFront URL.
Understand the difference between public S3 hosting and private S3 with CloudFront.

Conclusion

Hosting a portfolio using S3 and CloudFront is a simple way to understand the basics of AWS cloud deployment.

The main idea is straightforward:

S3 stores the website, CloudFront delivers it, and Origin Access Control keeps the S3 origin private.

This project also helped me understand that cloud deployment is not only about getting a website online. Security, access control and how services communicate with each other are equally important.

A small portfolio ended up being a useful introduction to real-world AWS architecture.

DEV Community: CHANDRA PRABHA V

Chandra Meets CodeDeploy: My First AWS Deployment Journey

Chandra Meets CodeDeploy: My First AWS Deployment Journey ☁️

Introduction

What Is AWS CodeDeploy?

Why Was CodeDeploy Created?

How It Works

Key Features of AWS CodeDeploy

1. Automated Deployments

2. In-Place and Blue/Green Deployments

3. Deployment Scripts Using AppSpec

4. Monitoring and Rollback Support

College/Student Use Case 🎓

Simple Practical Example

Project Structure

1. Flask Application

2. AppSpec File

3. Deployment Scripts

4. Deployment Process

Advantages of AWS CodeDeploy

Limitations and Things to Consider

Cost

Complexity

Security

Application Compatibility

Conclusion

References

My AWS Learning Journey: CloudWatch, Lambda, IAM & CloudFront

☁️ 1. AWS CloudWatch

What I learned:

⚡ 2. AWS Lambda

What I learned:

🔐 3. AWS IAM

What I learned:

🌍 4. Amazon CloudFront

What I learned:

🔗 How These Services Connect

🎓 What I Gained From This Learning

AWS #AmazonWebServices #CloudComputing #CloudWatch #AWSLambda #IAM #CloudFront #Serverless #DevOps #LearningInPublic #TechLearning

Hosting My Portfolio on AWS S3 with CloudFront

Hosting My Portfolio on AWS S3 with CloudFront

Introduction

One important part of this setup is that the S3 bucket remains private.

Technologies Used

Step 1: Creating the S3 Bucket

Bucket Configuration

Screenshot

Step 2: Uploading Portfolio Files

Step 3: Creating a CloudFront Distribution

Screenshot

Step 4: Updating the S3 Bucket Policy

Screenshot

Step 5: Setting index.html as the Default Root Object

Screenshot

Step 6: Deploying the CloudFront Distribution

Step 7: Testing the Portfolio

Screenshot

Why Use CloudFront?

What I Learned

Step 5: Setting `index.html` as the Default Root Object