Cloud Assignment 2

Purdue University CS351 Spring 2026

Due February 20th 11:00PM

Introduction

In this assignment, you will implement a new feature in the Software-as-a-Service (Saas) introduced in Cloud Assignment 1 and deploy it to production. You will learn how application requirements drive system architecture decisions. You will have practical experience integrating a cloud service API in an application. You will continue to build skills managing and deploying to virtual machines in the cloud. Docker is introduced and you will build your first container. You'll gain knowledge of virtual networking and virtual storage and how those work together to create secure and elastic environments for software. Finally, you will become aware of how cost and performance are entangled in cloud software systems.

Contents

1. Initial Setup
   1. Set AWS Budget
   2. Set AWS IAM Permissions
2. Update from bird.ai
3. Feature: Containerization
   1. Launch an EC2 instance
   2. Initialize instance vm-ca2
   3. Creating a Dockerfile
   4. Surviving a reboot
4. Feature: Detection History
   1. Model update
   2. Two birds one hash
   3. PUT-ing objects in their place
   4. Push it to the edge
5. Estimating Assignment Cost
6. Teardown

Initial Setup

Use an account eligible for the AWS Free Tier. Make a post on Ed if you don't have an eligible account. This assignment will use AWS region "us-east-1", do not use AWS services in any other region. You can control your current region from the menu bar of the AWS Console.

https://us-east-1.console.aws.amazon.com/console/home?region=us-east-1#

Set AWS Budget

We're going to set up an AWS Budget that will alert you if you get any monetary charges.

1. Navigate to the Billing feature in the AWS Billing and Cost Management Service.
2. Click "Create Budget"
3. Select "Use a template" then "Zero spend budget"
4. Add your email to the "Email recipients" text area.
5. Click "Create budget"

Set AWS IAM Permissions

We're going to change the permission structure that grants instructors read-only access to your account so our autograding scripts can check your progress on a Cloud Assignment.

Follow these steps, and then we'll discuss why this approach is more secure than the approach in previous assignments.

1. Navigate to IAM (Identity and Access Management) in your AWS account.
2. Click on "Users" in the left-hand navigation menu.
3. Select the user "CS351-autograder".
   • Click "Delete"
   • Follow the instructions to delete the user. Make sure to remove any access keys associated with it.
4. Click on "Roles" in the left-hand navigation menu.
   • Click "Create role".
   • Select "Custom trust policy" from the trusted entity type options.
   • Paste in the following JSON

   {
       "Version": "2012-10-17",
       "Statement": [
   	{
   	    "Effect": "Allow",
   	    "Action": "sts:AssumeRole",
   	    "Principal": {
   		"AWS": "arn:aws:iam::897729129333:user/autograder"
   	    },
   	    "Condition": {
   		"StringEquals": {
   		    "sts:ExternalId": "<TODO_REPLACE_WITH_YOUR_OWN_EXTERNAL_ID>"
   		}
   	    }
   	}
       ]
   }
   

   • In the trust policy JSON, set "sts:ExternalId" with a unique string of your own making. Do not share it with anyone, but store it for later use in the credentials file.
   • Click "Next".
   • Filter the permissions policies by "AWS managed - job function" and search for "ReadOnlyAccess".
   • Check "ReadOnlyAccess"
   • Click "Next"
   • Fill in "CS351-autograder" for "Role name"
   • Click "Create role"

Finish by creating a new credentials file in an INI file format.

[default]
aws_account_id = YOUR_AWS_ACCOUNT_ID
external_id = YOUR_EXTERNAL_ID_FROM_THE_TRUST_POLICY

Update from bird.ai

Good news. Investors liked bird.ai's Minimum Viable Product (MVP). You were able to raise a seed round and now are on the hunt for Product-market fit (PMF).

You've set up a few customer calls where you interview and observe people when they use your application. During these sessions you've noticed that your heaviest users will upload the same bird photo to the website multiple times. "Sometimes I forget if a bird was detected or not" one said when asked. Another mentioned they keep the website looping on an old phone for entertainment, checking if a bird has been outside their office window in the last 5 minutes.

When reflecting on your customer calls, you realize that both customers shared a negative user experience. They didn't describe it in negative terms, but Customer 1 has to snap a new picture to remember the detection result, and Customer 2 can only look at his most recent picture to entertain him at work. Neither of them can see their past bird detections. Both these usage patterns increase load on your application servers and frustrate customers. As a product-first cloud-native SaaS startup, that means this common use case is both raising your cloud costs and reducing your customer satisfaction.

Feature: Containerization

Last assignment we had to perform a long series of steps to get our application up and running on the EC2 instance. A lot of manual steps increases the risk of human error (that means you, the human, making a mistake). How can we define the steps needed to package and run an application in a clear way to make our life easier? That's where a Dockerfile comes in. A Dockerfile is a text file in a standard format that holds all the command line instructions needed for building and running an application.

Launch an EC2 instance

Set up an EC2 instance called "vm-ca2". Remember how? If you don't, refer back to Cloud Assignment 1. The instance should be a t4g.small or t3.small. It will be quicker to build and deploy a container if you target the same architecture as your personal computer. Your EC2 instance must be running Amazon Linux with 30GB of disk storage. You'll have to add a key pair to connect to the instance using SSH.

Initialize instance vm-ca2

Add a 2GB to 4GB swapfile to vm-ca2. Where you add the swapfile matters, make sure you create the swapfile on the 30GB storage volume you attached to the EC2 instance. Run df -h to show your file system mounts, you should see an NVMe SSD mounted at root (/). If you need help setting up a swapfile, refer back to Cloud Assignment 1. If you get an "out of memory" error when trying to load the docker image, try reducing the swapfile size to make more room on instance, this may happen to images built for the platform linux/amd64 and deployed on a t3.small.

Add the following public key to the authorized_keys file.

$ cat id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAORDoNEnPakX83lU2uUDnMWQm4L4ytchU3Mi80Uw+H7

Install Docker and start the Docker daemon.

$ sudo dnf update -y
$ sudo dnf install -y docker
$ sudo systemctl start docker
$ sudo usermod -a -G docker ec2-user # then start a new SSH session

Creating a Dockerfile

You're going to create a Dockerfile for the bird.ai application. Let's review the steps we took to get bird.ai up and running.

• Installed system dependencies for building the application
• Installed Python 3.14.2
• Unzipped and copied over the application files (make sure your bird.ai application files are in your working directory and not a sub-directory)
• Created a virtual environment
• Installed application dependencies into the virtual environment
• Collected static assets (python manage.py collectstatic)
• Migrated the application database (python manage.py migrate)
• Created a super user
• Started the application web server (python manage.py runserver 0.0.0.0:8000)

For your Dockerfile, use an official Python base image that has Python 3.14.2. I would use the "slim" distribution of Python for the base image. Slim is based on Debian and ships glibc, a highly used C standard library. The machine learning (ML) libraries in our application distribute binaries pre-built for glibc. Another common base image for Python, alpine, uses musl. Musl is 10x smaller than glibc, but less commonly used, so it may force you to re-compile certain system dependencies during the docker build, causing it to take longer. There are more differences, feel free to explore on your own!

Tag the image with "bird.ai:latest". You'll have to build the image so it targets the ARM platform, that's the architecture of our EC2 instance. You can test your image is working by running:

$ docker build -t bird.ai:latest --platform linux/arm64 .
$ docker run --rm -p 8000:8000 bird.ai:latest # "--rm" cleans up the container

And visiting http://localhost:8000 in a web browser.

$ cid="$(docker ps -q --filter ancestor=bird.ai:latest)"
$ net="$(docker inspect --format '{{json .NetworkSettings}}' $cid)"
$ echo "$net" | python3 -m json.tool

Make sure to install Docker Desktop on your personal computer if you haven't already. If you need help writing a Dockerfile, review Chapter 6 Section 11 in the course textbook.

Once your Docker container is working, we're going to deploy it to EC2 server vm-ca2.

First, create a tar archive of the final image, then copy it over to your EC2 instance.

$ docker save -o bird.ai.tar bird.ai:latest
$ scp -i keypair.pem bird.ai.tar ec2-user@${INSTANCE_PUBLIC_IP}:~

SSH into vm-ca2 then use the following commands to run your container image. When you submit, the autograder will check that a container is running and your application is accessible over the internet, so make sure to update the security group to allow inbound TCP traffic to port 8000 (if you don't remember how, refer to Cloud Assignment 1).

$ ssh -i keypair.pem ec2-user@${INSTANCE_PUBLIC_IP}
$ docker load -i bird.ai.tar
$ docker run --rm -d -p 8000:8000 bird.ai:latest # "-d" runs it in background

You now have a containerized application running on your web server!

Surviving a reboot

Our business model depends on our users being able to access our website. If something happens and our servers go down, we're going to need to reboot and come back online fast. Our SaaS business loses money for every second of downtime.

But is our EC2 instance ready to reboot? Have we configured the virtual machine so that it can bring up our application without manual intervention?

Let's perform an experiment. We're going to let the autograder reboot our EC2 instance and rerun the previous tests so we can see which test fails. This will tell us what part of our application architecture will fail when a server reboots.

First, SSH onto vm-ca2 and create a file in the home directory that will indicate to the autograder we want it to run the reboot test.

$ ssh -i keypair.pem ec2-user@${INSTANCE_PUBLIC_IP}
$ touch .reboot-ready # creates an empty file in the home directory

Submit your credentials to the autograder on Gradescope. Wait to see what happens!

Uh oh, now some tests are failing. Let's make our application deployment robust.

First, we'll make sure our swap file is enabled at boot time. SSH into vm-ca2 and open up the file /etc/fstab with your preferred text editor. Add your swapfile at the end:

#
UUID=c1486bb3-de8e-4c78-a3ae-f5d5cbfb8912     /           xfs    defaults,noatime  1   1
UUID=6B1D-8531        /boot/efi       vfat    defaults,noatime,uid=0,gid=0,umask=0077,shortname=winnt,x-systemd.automount 0 2
+ /swapfile swap swap defaults 0 0

Test your change by running the following command and verifying there are no errors

$ sudo swapon -a

Now that swap is taken care of, it's time to start the Docker daemon so it runs at boot.

$ sudo systemctl enable docker

It's that easy. systemctl is a command that controls systemd. Systemd is a centralized initialization system for Linux. It performs a lot of responsibilites, and we just informed it to enable the "docker" service at boot. So what's a service? A service is just a file that systemd reads to understand how to run a particular program. Doesn't this sound familiar? We're tip-toeing around Dockerfile territory. They're both declarative specifications. Where a Dockerfile describes how to build a piece of software, a systemd service defines how that software should be run by an operating system.

Let's take a look at the service definition file for docker.

$ systemctl cat docker
# /usr/lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service time-set.target
Wants=network-online.target containerd.service
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
EnvironmentFile=-/etc/sysconfig/docker
EnvironmentFile=-/etc/sysconfig/docker-storage
EnvironmentFile=-/run/docker/runtimes.env
ExecStartPre=/bin/mkdir -p /run/docker
ExecStartPre=/usr/libexec/docker/docker-setup-runtimes.sh
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock $OPTIONS $DOCKER_STORAG>
ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=infinity
TimeoutStartSec=0
RestartSec=2
Restart=always
...

The service definition contains sequencing rules during boot and includes instructions for how to start and monitor the process. Here, for example, it tells systemd that it should be started after the network is online and the containerd service has started, and that it requires a Unix domain socket file docker.socket to be available before starting.

We're going to make a systemd service definition for our bird.ai application container, and instruct systemd to start it at boot.

On the EC2 instance, create a file /etc/systemd/system/bird-ai.service.

[Unit]
Description=bird.ai container
After=docker.service
Requires=docker.service

[Service]
Restart=always
# Clean up existing container
ExecStartPre=-/usr/bin/docker stop %n
ExecStartPre=-/usr/bin/docker rm %n

# The main command to start the container
# --rm: Clean up the container when it exits
# --name %n: Uses the service name (bird-ai) as the container name
ExecStart=/usr/bin/docker run --rm --name %n -p 8000:8000 bird.ai:latest
ExecStop=/usr/bin/docker stop %n

[Install]
WantedBy=multi-user.target

Now run:

$ sudo systemctl daemon-reload # force systemd to find new service definition
$ sudo systemctl enable --now bird-ai.service # enable the service at boot
$ sudo systemctl status bird-ai.service # check the status
$ sudo journalctl -u bird-ai.service -f # view logs

We've taken big steps towards creating a robust application deployment. Why don't you submit to autograder now and see what tests are passing?

The next piece to fix now is the database. We're going to create a docker volume that persists the database between reboots so our users can still log in after we recover from a server crash or re-deploy an updated application.

$ docker volume create bird-ai-data

We've just created a named volume. Now, you're going to update the systemd service definition for the bird.ai application so when it runs the container, it attaches the volume into the container filesystem at the path the application expects the database to be.

[Unit]
Description=bird.ai container
After=docker.service
Requires=docker.service

[Service]
Restart=always
# Clean up existing container (ignore errors with '-')
ExecStartPre=-/usr/bin/docker stop %n
ExecStartPre=-/usr/bin/docker rm %n

# The main command to start the container
# --rm: Clean up the container when it exits
# --name %n: Uses the service name (bird-ai) as the container name
- ExecStart=/usr/bin/docker run --rm --name %n -p 8000:8000 bird.ai:latest
+ ExecStart=/usr/bin/docker run --rm --name %n -p 8000:8000 -v bird-ai-data:/app/data bird.ai:latest
ExecStop=/usr/bin/docker stop %n

[Install]
WantedBy=multi-user.target

Even though the container is recreated every time, the volume won't be. New containers will re-use it, which means our SQLite database has gone from stateless to stateful across container lifetimes. Restart the application with our new volume attached.

$ sudo systemctl daemon-reload
$ sudo systemctl restart bird-ai.service
$ sudo systemctl status bird-ai.service

And submit to the autograder.

$ docker volume inspect bird-ai-data
[
  {
      "CreatedAt": "2026-02-10T07:17:55Z",
      "Driver": "local",
      "Labels": null,
      "Mountpoint": "/var/lib/docker/volumes/bird-ai-data/_data",
      "Name": "bird-ai-data",
      "Options": null,
      "Scope": "local"
  }
]
$ sudo ls /var/lib/docker/volumes/bird-ai-data/_data
db.sqlite3

Feature: Detection History

Now that we have a robust application deployment, we can start iterating on our application feature. This is the DevOps methodology: tightening the loop between design, development, testing, then release. Why are we developing software in the first place? Well, it's to make our customers' lives easier and give them capabilities they didn't have before, whether those customers are other engineers or non-technical consumers in the marketplace. Welcome to the wonderful world of tech entrepreneurship! We don't know if our application adequately addresses customer needs if we don't put it in front of them and receive feedback as they use it. Does a falling tree in an empty forest make a sound? Is Justin Timberlake still famous if no one listened to his last album? Do we even exist if no one has used the software we've written? Yes of course we do, but you get the idea.

For our development process, we work on our application with Python and Docker. We can test our application releases by submitting to the autograder. And we can deploy relatively quickly by creating a container image, copying it to the EC2 instance, loading it into the Docker daemon, then restarting the service using systemd. Customers will be able to use the newly released application by visiting our EC2 instance's public IP at port 8000. Now we can focus on the design for our latest feature, and push it out to customers using the DevOps flow we just discussed.

Model update

Returning to what we learned from our customer calls, let's design a history page for our web application.

http://localhost:8000/history/

When a user submits a photo, that photo and the detection result will now be saved to disk, and associated with the user. You will be implementing the Django model logic that makes that association.

sequenceDiagram
  autonumber
  participant App as Python Runtime<br/>(Views/Logic)
  participant ORM as Django ORM<br/>(Manager & Compiler)
  participant DB as SQL Database<br/>(PostgreSQL/MySQL)

  Note over App, DB: Phase 1: The Request (Python to SQL)

  App->>ORM: User.objects.filter(active=True)
  Note right of App: Python Method Call

  ORM->>ORM: Construct QuerySet
  ORM->>ORM: SQLCompiler.as_sql()
  Note right of ORM: Translates Python syntax<br/>to SQL string dialect

  ORM->>DB: SELECT * FROM app_user WHERE active = 1;
  Note right of ORM: Transmits raw SQL over socket

  Note over App, DB: Phase 2: The Response (SQL to Python)

  DB->>DB: Execute Query Plan
  DB-->>ORM: Returns Raw Rows (Tuples)
  Note left of DB: e.g., (1, "Connor", 1)

  ORM->>ORM: Model.from_db()
  Note right of ORM: "Hydration"<br/>Maps columns to attributes

  ORM-->>App: Returns QuerySet [User(id=1), ...]
  Note left of ORM: Iterable Python Objects

You will be implementing a Python class "Detection". Refer to Django's tutorial section "Creating models" for what to look for.

Your model will have have seven fields:

• "user": foreign key on Django's built-in user model.
• "original_image": image field
• "result_image": image field that can be null or blank.
• "detections": JSON field
• "found: boolean field
• "elapsed_time": float field
• "created_at": datetime field

Write your model definition into bird.ai/app/models.py, there is a stub class waiting to be implemented. You can see how it's used in bird.ai/app/views.py, which may help you implement it.

Run your application locally to test if your model works.

$ source .venv/bin/activate
(.venv) $ python manage.py runserver

When the history page is working, deploy it to your production server vm-ca2.

$ docker system prune
$ ssh -i keypair.pem ec2-user@$INSTANCE_PUBLIC_IP "docker system prune -f"

$ python manage.py makemigrations
$ python manage.py migrate

Two birds one hash

Now that we're storing files to disk storage, we risk running out of disk space. We started with 30GB. Let's say after our instance initialization and container deployment we have 20GB left. Mobile phones can take pictures that are 4MB in size. Doing the math: 20GB / 4MB = only 5000 photos for all our customers! That's not enough for all the bird selfies.

To solve this problem, you are going to implement data de-duplication based on a content hash. When the application recieves an image upload, it will hash the file and compare that hash against our database of past detections. If it finds a match, instead of saving the photo and running the YOLO model on it, it will delete the file, skip the inference run, and serve the old file and old inference result instead, saving time, space, and money.

Open up bird.ai/app/models.py again. You're going to add another field to your "Detection" model.

• "image_hash": char field

You'll then implement a class method called "find_duplicate". Here's the type hint.

@classmethod
def find_duplicate(cls, image_bytes: bytes) -> tuple[str, "Detection | None"]:

Your method will calculate a hash based on image_bytes, then .filter the Detection model to find a matching detection. If it doesn't find one, it will return None, and the controller will treat it like a new image. Take a look at bird.ai/app/views.py to see how "find_duplicate" is used.

Remember, try to develop this locally, and when you're happy with the result, send it off to production and submit your credentials to the autograder.

PUT-ing objects in their place

We've made some progress reducing disk usage on our servers, but can we take it further? Instead of trying to pack as many images as we can into a small space, can we try to pack as few as possible into an infinite space? Introducing S3, Amazon's Simple Storage Service.

You are going to be creating an S3 bucket to upload images to.

• Navigate to S3 in the AWS Console.
• Click on "Create bucket", select type "General purpose", and name it with a name containing "bkt-ca2" (e.g., "bkt-ca2-yourname"). S3 bucket names must be globally unique.
• Keep all other settings at their default values and click "Create Bucket" at the bottom.

Navigate to Cloudfront in the AWS Console.

• Click "Create distribution"
• Select the free plan. Click "Next".
• Name the distribution "cdn-ca2". Click "Next".
• Select "Amazon S3" as the origin type.
• Under "Origin", click "Browse S3" and select the bucket we created.
• Click "Next", then "Next" again until you are at "Review and create".
• Click "Create distribution".

Now navigate to IAM in the AWS Console.

• Click on "Policies" and "Create Policy".
• In the Policy editor, select "S3". You will have a large list of permission options to choose from.
• From the "List" dropdown, select "ListBucket".
• From the "Read" dropdown, select "GetObject".
• From the "Write" dropdown, select "PutObject".
• Click the "Resources" dropdown and next to "bucket" select "Add ARNs".
• Type in the name of the bucket we just created, and click "Add ARNs".
• In the "Resources" dropdown next to "object" select "Add ARNs".
• Type in the name of the bucket we just created under "Resource bucket name"
• Check "Any object name" next to "Resource object name". Click "Add ARNs".
• Now you can click "Next"
• Name the Policy "get-and-put-bkt-ca2"
• Click "Create policy"

We've just created a minimal set of permissions that will enable a service to put files into our bucket, and get files out of the bucket, nothing else (Remember the principle of least privilege?). We're going to assign the permission set to a specific role, and then you'll see how our application will use that role in our instance, securely.

Navigate to IAM in the AWS Console.

• Click on "Roles" and "Create Role".
• Select "AWS service" under "Trusted entity type".
• Select "EC2" for both options under "Use case".
• Search for the policy we just created, and select it.
• Click "Next"
• Name the role "bird.ai-app-prod"
• Click "Create role"

Now navigate to EC2 in the AWS Console.

• Click the checkbox next to "vm-ca2".
• Click the "Actions" dropdown menu.
• Click "Security" then "Modify IAM role".
• Add the IAM role we just created.

AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...

$ set -a; source .env; set +a # "-a" is "allexport"
$ python manage.py runserver

Push it to the edge

Now that all our infrastructure is in place, you'll be integrating with the Content Delivery Network (CDN) called AWS Cloudfront. Companies use CDNs to reduce latency and costs. S3 has to make a lot of trade-offs in order to provide you with durable storage for any type of object. Cloudfront just serves files, and fast. To put objects into, or get objects out of S3, you have 100GB of free bandwidth. Cloudfront will give you 1TB for free, and not charge you for pulling data from S3 origin servers. Lastly, S3 buckets are tied to a specific AWS region. Cloudfront's servers are a combination of regional edge caches, points of presence, and collaborations with Internet Service Providers (ISP), connected through a backbone network. That means they're closer to you, and closer means faster in computer networks.

You will implement a class method called "upload_to_s3". Here's the type hint.

@classmethod
def upload_to_s3(cls, image_bytes: bytes, object_key: str) -> None:

Take a look at the documentation for boto3, it's the Python SDK for the AWS API. You will import it in that function and create an "s3" client with it. You will then put those bytes in our bucket we created at the key specified by object_key. If you have any questions, look at bird.ai/app/views.py to see how "upload_to_s3" is used. Remember to set the ContentType to "image/jpeg".

You must open up bird.ai/core/settings.py and uncomment the following lines. Replace <your-distribution-name> with the domain name from your CloudFront distribution (visible on the CloudFront distributions page in the AWS Console).

- # S3_BUCKET_NAME = '<your-bucket-name>'
- # MEDIA_URL = 'https://<your-distribution-name>.cloudfront.net/'
+ S3_BUCKET_NAME = '<your-bucket-name>'
+ MEDIA_URL = 'https://<your-distribution-name>.cloudfront.net/'

Re-deploy your solution and you've completed the assignment!

Estimating Assignment Cost

Coming soon!

Teardown

The resources we created this assignment are

• EC2: instance "vm-ca2" (remember to terminate)
• S3: your "bkt-ca2" bucket (You will have to empty the bucket before deleting it)
• Cloudfront: distribution "cdn-ca2" (you have to disable it, wait a few minutes, then delete it)
• IAM: policy "get-and-put-bkt-ca2", role "bird.ai-app-prod"

https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#Instances: