Cloud Assignment 3

Purdue University CS351 Spring 2026

Due Friday April 3rd 11:00PM

Introduction

During this assignment you will implement and deploy an application architecture designed for scaling web services. You'll become familiar with local development tools for managing multiple software services and open-source software commonly used in industry. You'll work with Infrastructure-as-Code approaches for controlling cloud infrastructure and performing automated deployments. You'll continue to improve and update the bird.ai application, gaining practical experience with MVC application frameworks and YOLO machine learning models. Finally, you'll gain insight into data privacy and ethical issues when working on Software-as-a-Service applications in the cloud.

Contents

1. Initial Setup
   1. Set AWS Budget
   2. Set AWS IAM Permissions
2. Update from bird.ai
3. Part 1: N-Tier Architecture
   1. Adding a reverse proxy
   2. Introducing Docker Compose
   3. Pushing to a container repository
   4. Automating our deploys
   5. From ClickOps to GitOps
   6. Importing existing infrastructure
   7. What about bird.ai?
   8. Choosing a domain name
4. Part 2: Squirrel-due University
   1. Turning cleartext into ciphertext
   2. Squirrel detection
   3. Mapping detections
   4. Gossip Squirrel
5. Estimating Cloud Cost
   1. Resource Rates (us-east-1, on-demand, no free tier)
   2. How Billing Works
   3. Estimated 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.

1. Navigate to IAM (Identity and Access Management) in your AWS account.
2. 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::949430458732: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

The detection history feature went viral. Funny bird photos captured with your application are all over BipBop and CrackerGraham. It proved to investors you’ve gained traction and found product-market fit (PMF). You just raised a Series A round of 10 million dollars from the investment firm Lion Local Management. Time to scale.

After signing the term sheet you find yourself in a lot more zoom meetings with phrases like due diligence, runway, and annual recurring revenue (ARR) thrown around. You've made a few more friends, and a lot more bosses. In the last board of directors meeting the lead series A investor demanded you find new sources of revenue. The investor is also on the board of a large financial company interested in purchasing your user data to feed into credit models they use to set interest rates for clients who love squirrels. A few months ago you would never have considered monetizing user data, but you're slowly realizing this 10 million dollar bag is pretty heavy.

While you're negotiating the stock purchase agreement and pretending it's the first time you heard the junior VC's story of how he won the spelling bee in middle school, your engineering team has been working around-the-clock on-call shifts putting out fires that pop up whenever another bird picture goes viral. Your lead engineer, Bark Iceberg, has teamed up with your head of product, Cherry Sandbar, to convince you to upgrade the website's infrastructure. Shocked at the sight of enemies uniting, you realize the scale of the problem.

Part 1: N-Tier Architecture

You're going to be implementing a N-Tier Web Architecture to accommodate the increasing load on the bird.ai application. This is a versatile system architecture that lets you scale individual components according to how your application's usage patterns evolve. Our initial minimum-viable product (MVP) had a strong benefit, simplicity, which allowed us to move quickly and develop a proof-of-concept on a single virtual machine. However, this virtual machine becomes a single point of failure.

Mark Zuckerberg gave a talk to a Harvard CS class in 2005, where he says "The first decision we had to make, was how to expand the architecture to go from a single school type setup that we had just at Harvard, to something that supported multiple schools", and that "one really important decision that's helped us scale really well, is how we decided to distribute the data." They were able to scale to 300,000 users and 400 million page views a day in 2005 using a N-tier web architecture!

This architecture continues to be relevant today, and we will enhance it by implementing automation that lets us manage it effectively with a small team.

Adding a reverse proxy

A reverse proxy is software that sits between a client initiating network requests and a server responding to them. It's a versatile middleman, and depending on the use case will perform load balancing, authorization, rate limiting, data transformation, and more. We're going to be using nginx today, a popular reverse proxy.

First, we'll create a Dockerfile.

FROM nginx:alpine

Now build it and run it.

$ docker build -t proxy:latest nginx/
$ docker run -p 8080:80 proxy

When you visit http://localhost:8080 in a web browser, you'll see the nginx welcome page. Check it out! It's famous, a kind of Hollywood sign for web developers.

You can also see that the web server is running from the command line. To do that, we'll use a tool called curl (or cURL).

$ curl -v http://localhost:8080
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.29.6
< Date: Thu, 19 Mar 2026 18:33:30 GMT
< Content-Type: text/html
< Content-Length: 896
< Last-Modified: Tue, 10 Mar 2026 16:28:44 GMT
< Connection: keep-alive
< ETag: "69b046bc-380"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

curl is a useful tool you should become familiar with. It's an ubiquitous command line HTTP client (and C HTTP library) that is feature rich and flexible. We just used the verbose flag "-v" to display the HTTP response and request content. Whenever you are debugging an API you are building, use curl -v to make requests to the endpoint.

Why did we use curl in the first place? We wanted to make sure that the nginx server was running and responding to requests. This type of action is called a healthcheck, and is used to monitor software services. This type of check is so common that it's a feature in Dockerfile through the HEALTHCHECK instruction.

Your task is to add a HEALTHCHECK instruction to the nginx Dockerfile definition you created, using curl to ping port 80 on all interfaces inside the container.

Once you've finished, move on to the next section.

Introducing Docker Compose

The premise of an N-Tier Architecture is that multiple software services work together to deliver a final user experience. You've already learned in class how that might look in a data center. You would have multiple servers in a rack, connected through a top of rack switch, with one or more services running on each server, responding to inbound north-south traffic from the internet. But our local development environment (your laptop) does not share that type of infrastructure set up. How then can we develop our application architecture with the confidence that if it works on our computer, it will work in production? A step in that direction builds on top of virtualization and standardization features that Dockerfile definitions for software gives us.

Docker Compose is a powerful tool that lets you define your container architecture in code. It's great for emulating a production environment on your local computer and playing around with different networking settings, container configurations, and more. We're going to create a basic Docker Compose file for our application, and add to it over the course of the assignment.

services:
  proxy:
    platform: linux/amd64 # to match our target EC2 instance architecture
    build: # TODO
    ports: # TODO

Your task is to fill out "build" and "ports" with the same values we used in the previous docker build and docker run commands. Once you've done that, run the following command.

$ docker compose up

The docker compose command by default looks for a file called "compose.yaml" in the current directory, reads the service definitions, and then starts the containers. Now you can re-visit http://localhost:8080 in the browser. Notice how we didn't have to pass any command line flags specifying port forwarding rules, or build the container image ahead of time. Compose reads the service definition, builds the container on-demand, and then configures runtime settings and starts the container for you automatically.

services:
  proxy:
    build: ./nginx
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 2G

When you have Docker Compose installed and the compose stack running, move on to the next section.

Pushing to a container repository

We have a working web service, an Nginx container, that we can run. We're not satisfied with just running it in our local development environment however, our goal is to deploy it so it's publicly available on the internet for anyone to access. In Cloud Assignment 2, we would build a container image locally, save it to a tar archive, copy the archive over to the remote server, and load it into Docker engine before starting it. That was a lot of repetitive work that had a risk of human error. In this assignment, we're going to set up a container registry that will store the container image for us, so we can push to it and pull from it on-demand. To "push" is to upload an image, to "pull" is to download an image. Don't worry, we'll step through how to do that in this section.

First things first, we'll need an AWS IAM user that has permission to push to an ECR repository in your account. Since we're iterating on new application features, we'll create a user that has "PowerUserAccess". We can downgrade the user's permissions later.

1. Visit IAM in the AWS Console after logging in.
2. In the left-hand menu under "Access Management" click "Users"
3. Click "Create User"
4. Write "ca3" as the user name.
5. Under "Permissions Options", select "Attach policies directly"
6. Under "Permissions Policies", filter by "AWS managed - job function" and select "PowerUserAccess". Then filter by "AWS managed" and select "IAMFullAccess".
7. Click "Next".
8. Click "Create user"
9. Select the "ca3" user.
10. Click tab "Security credentials" and click "Create Access key"
11. Under "Use case" select "Other" and click "Next"
12. Click "Create access key"
13. Store the access key and secret access key someplace temporary and click "Done"

And in the terminal, run:

$ aws configure --profile ca3
AWS Access Key ID [None]: <enter access key id>
AWS Secret Access Key [None]: <enter secret access key>
Default region name [None]: us-east-1
Default output format [None]
$ export AWS_PROFILE=ca3 # important! AWS CLI commands will now use ca3 by default

Now we can create a container registry and push to it. We're going to use the AWS Elastic Container Registry (ECR) and create a new repository.

1. Visit ECR in the AWS Console after logging in.
2. In the left-hand menu under "Public registry" click "Repositories"
3. In the "Public repositories" page click "Create repository"
4. Under "Repository name" write "ca3/proxy". "ca3" is the namespace and "proxy" is the repo-name.
5. Click "Create"

Now take the URI of the container repository, and update the docker compose file we created for local development. Your task is to add another field "image" to the proxy service definition, which includes a "latest" tag.

Once you've updated the docker compose file, it's time to build the image and push it to our remote repository.

First, authenticate with the remote repository. Select the "ca3/proxy" repository and click "View push commands". Follow the first instruction to authenticate your Docker client to the registry.

https://us-east-1.console.aws.amazon.com/ecr/public-registry/repositories?region=us-east-1

Now once you've authenticated, you'll use compose to build and push your image.

$ docker compose build # builds from ./nginx and tags with "image" value
$ docker compose push # pushes the image to ECR
$ docker compose up # runs the stack with the image stored in ECR

Automating our deploys

It's time to introduce you to a new tool called Ansible. It automates server setup, instead of SSHing in to an EC2 instance and running commands manually, you describe the desired final state of the server in a YAML file and Ansible takes it from there. Ansible is an example of Infrastructure as Code (IaC). You write what you want (e.g. "Docker should be installed and running"), Ansible figures out the how (through a pre-written module or a script you write), and if Ansible verifies the server is already in the desired state, it doesn't change anything. That last property is called idempotency, it's an important characteristic of Ansible. It means you can run an Ansible playbook multiple times against a server and it will always end up in the correct state (as long as your playbook is written correctly).

Inside your starter code you'll find a few files:

• Inventory (inventory.ini): lists the servers you want to configure, with their IPs/hostnames.
• Playbook (playbook.yml): the YAML file describing what tasks to run on which servers.
• Config (ansible.cfg): defaults, like which SSH key to use so you don't retype flags every run.

Using this information, Ansible SSHs into the instances defined in the inventory and runs all the commands in the playbook against them, bringing your server to your final desired state. Because Ansible runs over SSH, you don't need anything installed on your server for Ansible to work (you just need to install it on your personal computer, take a look at installing it generally or on a specific operating system).

Now, you have several tasks to perform to make your playbook ready to run:

1. Replace <YOUR_KEY_NAME> in ansible.cfg with the key pair you attached to your EC2 instance.
2. Replace <YOUR_PROXY_PUBLIC_IP> in inventory.ini with ca3-proxy's public IP address.
3. Replace <YOUR_ECR_URI> in playbook.yml with the URI of the ECR repository you created (omit any tag).

First, you'll have to create an EC2 instance, you should be pretty good at that by now. Create a c7i-flex.large running Amazon Linux with 8GB of disk space named "ca3-proxy". Add an inbound security group rule allowing all traffic to port 80.

When you've spun up the EC2 instance and replaced all the values in the Ansible files, run the following command.

$ cd ansible
$ ansible-playbook playbook.yml

Voila! Visit your EC2 instance's public IP and you'll see "Welcome to nginx!"

From ClickOps to GitOps

We've done well by automating part of our deploy process, but in order to do that, we've spent a lot of time navigating the AWS Console. This is valuable experience, some cloud computing features are only available through a user interface, but it can be tedious and non-reproducible. This method of operation is jokingly called ClickOps. So how can we improve? How can we introduce reproducibility and visibility into our cloud infrastructure?

The most common solution today is Terraform. Terraform revolutionized DevOps by moving the implicit infrastructure you provision by clicking around in a web console into explicit infrastructure described in a text file. The Terraform language consists primarily of Providers, which are modules that interact with cloud services like AWS, and Resources, which are infrastructure objects you create and manage using a provider. There are a few other types of "blocks" in Terraform code, and you'll become familiar with most of them as we transition our ClickOps-managed infrastructure into GitOps-style infrastructure in this section.

Terraform is structured so that you write a new resource block to a file, plan the change letting you review how the infrastructure will be mutated, then apply that change automatically from the command line. But how does Terraform keep track of what has changed? Terraform stores the state of your infrastructure in a file called terraform.tfstate. When you start a new Terraform project, that state will live in a file on your computer. But if you are going to collaborate with other engineers, you need some way to share that "source of truth" with them. This is called a backend. Let's step through setting up S3 as a Terraform backend.

First, visit S3 in the AWS Console and create an S3 bucket called "ca3-tfstate-<YOUR_ACCOUNT_ID>". You've done this before in Cloud Assignment 2, refer back to that assignment if you need help.

Next, locate the terraform/ directory in the Cloud Assignment 3 starter code. Fill in the values required by the terraform.tfvars file.

# --- Your Configuration ---
#
# Fill in these values before running terraform init.

account_id  = "<YOUR_ACCOUNT_ID>" # e.g. "123456789012"
region      = "us-east-1"
ami_id      = "<YOUR_AMI_ID>"      # e.g. "ami-0abcdef1234567890" (find in EC2 console)
key_name    = "<YOUR_KEY_NAME>"    # e.g. "my-keypair"
public_key  = "<YOUR_PUBLIC_KEY>"  # run: ssh-keygen -y -f ~/.ssh/<key>.pem

Now, initialize Terraform.

$ cd terraform # enter the terraform directory
$ terraform init # download and initialize providers

You now have a local Terraform state file! Take a look inside.

$ cat terraform.tfstate
{
"version": 4,
"terraform_version": "1.13.5",
"serial": 1,
"lineage": "29340e2f-6b8e-43f5-cb83-dc1712b9753f",
"outputs": {},
"resources": [
...

The next step is to have Terraform store the state file inside S3, securing the state file and making collaboration on infrastructure possible. Never share or store the state file in a public location, it contains sensitive credentials and details about your infrastructure an attacker can exploit.

Open backend.tf, delete the "local" backend, and uncomment the "s3" backend. Make sure to replace "<ACCOUNT_ID>" with your actual AWS Account ID (the backend block cannot use variables, it's the starting point for the rest of your terraform code).

Now run:

$ terraform init -migrate-state

If you visit the S3 bucket again in the AWS Console, you'll see it now has an item "ca3/terraform.tfstate" inside. Now you can clean up the local state files:

$ rm -f terraform.tfstate terraform.tfstate.backup

Importing existing infrastructure

Terraform isn't only used for new projects. Take this Cloud Assignment for example, we've already created quite a few AWS resources manually:

• IAM role "CS351-autograder"
• IAM user "ca3"
• IAM policy for "ca3" granting "PowerUserAccess"
• Public ECR Repo "ca3/proxy"
• EC2 instance "ca3-proxy"
• Security group for "ca3-proxy"
• Key pair for "ca3-proxy"
• S3 bucket for terraform state

We're going to use Terraform's import feature to bring our existing infrastructure under Terraform's control. The steps we work through will help you become more familiar with Terraform's CLI. Let's get started.

Look up the EC2 instance ID, security group ID, and key pair name for "ca3-proxy" in the AWS Console. Add the following import blocks to imports.tf:

import {
   to = aws_ecrpublic_repository.proxy
   id = "ca3/proxy"
 }

 import {
   to = aws_instance.ca3_proxy
   id = "<INSTANCE_ID>"
 }

 import {
   to = aws_security_group.ca3_proxy
   id = "<SECURITY_GROUP_ID>"
 }

 import {
   to = aws_key_pair.ca3
   id = "<KEY_PAIR_NAME>"
 }

Then run:

$ terraform plan
$ terraform apply

When the terraform apply succeeds, delete the imports.tf file.

Now when you run terraform plan again, you should see "No Changes":

$ terraform plan
aws_ecrpublic_repository.proxy: Refreshing state... [id=ca3/proxy]
data.aws_vpc.default: Reading...
aws_key_pair.ca3: Refreshing state... [id=ca3-keypair]
data.aws_vpc.default: Read complete after 0s [id=vpc-0ae3ae9dc53c75193]
data.aws_subnets.default: Reading...
aws_security_group.ca3_proxy: Refreshing state... [id=sg-04fe4f42d727e45a4]
data.aws_subnets.default: Read complete after 0s [id=us-east-1]
aws_instance.ca3_proxy: Refreshing state... [id=i-00beba6801cfed024]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

That wasn't too difficult, so you might not be impressed. But we've gained extraordinary capabilities. We're going to demonstrate what we've achieved using the autograder. You're going to run a new command terraform destroy, which will remove all the infrastructure we've spent time setting up in this assignment. Are you worried?

$ terraform destroy

Let's bring everything back with two commands:

$ cd terraform
$ terraform apply
$ cd ../ansible
$ ansible-playbook playbook.yml

What about bird.ai?

There's an easter egg hiding in the Ansible and Terraform code, have you spotted it already? Our architectural change moving bird.ai to an N-Tier architecture has already been mapped out for us.

Your penultimate task for Part 1 is to find the terraform.tfvars file and uncomment the "deploy_app" and "app_instance_type" section. Make sure to choose the instance architecture that matches your personal computer. When you're ready, run

$ cd terraform
$ terraform apply
$ cd ../ansible
$ ansible-playbook playbook.yml

It will take some time for the cloudfront distribution and RDS database to be provisioned. When it's finished, visit the public IP of the nginx instance. What do you see?

Choosing a domain name

It's not convenient or memorable to type in an IP address every single time you want to visit a website. That's why the Domain Name System (DNS) exists. It's a way to give a human-readable name to an address on the internet. Instead of "101 N Grant St, West Lafayette, IN 47906", you can say "Purdue Memorial Union". If you'd like to share bird.ai with your friends and family, let's make that easier for you.

Your final task for Part 1 is to make an HTTP request to an API endpoint to create a DNS A record for the EC2 instance running the reverse proxy. The instructional team for CS 351 has created an HTTP server that exposes a REST API endpoint that lets you submit a domain name. Here are the details of the API endpoint:

{
	"record": "mysite.ca3.cs351.cloud",
	"type": "A",
	"value": "3.14.15.92",
	"message": "DNS record updated. Changes propagate within 60 seconds"
}

You have a few different options to accomplish this using tools that have been introduced to you in the Cloud Assignment.

• Ansible uri module: add it as a task in the ansible playbook using Ansible variables to construct the request.
• cURL: construct the PUT request from the command line.
• Python requests module: construct the PUT request in a Python script.

There are strengths and weaknesses with each approach, pick the one that fits your workflow.

services:
 db:
   image: postgres:17-alpine
   environment:
     POSTGRES_DB: ca3
     POSTGRES_USER: ca3
     POSTGRES_PASSWORD: localdev
   volumes:
     - pgdata:/var/lib/postgresql/data
   healthcheck:
     test: ["CMD-SHELL", "pg_isready -U ca3"]
     interval: 3s
     timeout: 3s
     retries: 10

 app:
   build:
     context: .
     dockerfile: bird.ai/Dockerfile
   environment:
     DATABASE_URL: postgres://ca3:localdev@db:5432/ca3
     DEBUG: "true"
   volumes:
     - media:/app/data/media
   depends_on:
     db:
       condition: service_healthy

 proxy:
   image: nginx:alpine
   ports:
     - "8080:80"
   volumes:
     - ./nginx/default.conf.local:/etc/nginx/conf.d/default.conf:ro
     - media:/media:ro
   depends_on:
     - app

volumes:
 pgdata:
 media:

Part 2: Squirrel-due University

bird.ai has taken off and the $40 million in Series A funding has given you runway to grow, but venture capital comes with strings attached. Your investors expect returns, and they have ideas about how to get them.

You are being pushed by one of your investors to sell usage data that financial technology companies can use to build better credit models that set interest rates for customers that love squirrels. This is a familiar business model in tech, first you offer a free consumer product, then you monetize the data it generates. Meta makes money through targeted advertising powered by user behavior. Google gives away Search, Maps, and Gmail to power its ad platform. Even VPN providers that market themselves on privacy have been caught selling anonymized browsing data. The product is free because you are the product.

In order to win new fintech customers, bird.ai needs a couple upgrades. First, squirrel detection, birds are not enough in this competitive market. Second, geolocation, your customers need to know where your users are. Part 2 implements both of these features, along with the infrastructure to share detection data across the class through a gossip protocol.

But before any of that, we have a security problem to fix.

$ cp terraform/terraform.tfvars terraform/terraform.tfvars.bkp
$ cp terraform/backend.tf terraform/backend.tf.bkp
$ cp ansible/ansible.cfg ansible/ansible.cfg.bkp

$ unzip -o ca3.bird.ai.zip

$ cd terraform
$ terraform init
$ terraform plan # should show no unexpected changes

Turning cleartext into ciphertext

When you visit your application over the internet, you are using the HTTP protocol, sending HTTP requests back and forth. The original HTTP specification was very simple, and omitted one important feature: encryption. At the moment, every request between you and the bird.ai application travels in plaintext over HTTP, unencrypted. Anyone on the network path (your coffee shop Wi-Fi router, Internet Service Providers, or VPN) can read the whole thing. That means when you log in to bird.ai, you are sending your username and password unencrypted over the internet. It's like sending a letter through the mail to login, but instead of writing your password inside the envelope, you put it on the outside, next to the address.

We're going to implement HTTPS to solve this problem. HTTPS wraps HTTP requests in something called Transport Layer Security (TLS). TLS provides three guarantees:

1. Confidentiality: traffic is encrypted and eavesdroppers see ciphertext
2. Integrity: any tampering with the request itself can be detected
3. Authentication: the server you communicate with verifies its identity using a TLS certificate signed by a Certificate Authority (CA).

To enable HTTPS you need a TLS certificate issued for your domain. We'll use AWS Certificate Manager (ACM) to accomplish that. Instead of installing the certificate on Nginx, we'll place CloudFront in front of your proxy to terminate TLS at the edge.

This pattern is called TLS offloading, where compute-intensive encryption and decryption work happens on AWS's global edge network rather than on your EC2 instance.

Your first task is to uncomment the domain variable in your terraform.tfvars and replace it with the domain name you registered in Choosing a domain name

domain = "<your-subdomain>.ca3.cs351.cloud"

Now run

$ terraform apply

Terraform will run, but block at ACM certificate validation. That's expected, in order to validate the certificate, we need to update our DNS settings again. We'll do that with a similar API call as was used in the domain name section. First, interrupt the terraform apply when it becomes blocked. Then run

$ terraform apply 
random_password.rds[0]: Refreshing state... [id=none]
aws_ecrpublic_repository.proxy: Refreshing state... [id=ca3/proxy]
aws_cloudfront_origin_access_control.media[0]: Refreshing state... [id=E3DY32JLXZYQDA]
...
create Terraform will perform the following actions:
  # aws_acm_certificate.proxy_tls[0] will be created
  + resource "aws_acm_certificate" "proxy_tls" {
  + arn = (known after apply)
  + domain_name = "mysite.ca3.cs351.cloud"
...
Do you want to perform these actions?
  Terraform will perform the actions described above. Only 'yes' will be accepted to approve.
  Enter a value: yes

aws_acm_certificate.proxy_tls[0]: Creating...
aws_acm_certificate.proxy_tls[0]: Creation complete after 7s [id=arn:aws:acm:us-east-1:897729129333:certificate/bd093522-7646-481f-ae4f-cfdc6ddf6232]
aws_acm_certificate_validation.proxy_tls[0]: Creating...
aws_acm_certificate_validation.proxy_tls[0]: Still creating... [00m10s elapsed]
aws_acm_certificate_validation.proxy_tls[0]: Still creating... [00m20s elapsed]
aws_acm_certificate_validation.proxy_tls[0]: Still creating... [00m30s elapsed]
aws_acm_certificate_validation.proxy_tls[0]: Still creating... [00m40s elapsed]
aws_acm_certificate_validation.proxy_tls[0]: Still creating... [00m50s elapsed]
aws_acm_certificate_validation.proxy_tls[0]: Still creating... [01m00s elapsed]
^C
Interrupt received. 
Please wait for Terraform to exit or data loss may occur. 
Gracefully shutting down...

Stopping operation...
$ terraform output acm_validation_name
"_a0f0a86e85fac3db6512c9350cd21003.mysite.ca3.cs351.cloud."
$ terraform output acm_validation_value
"_55dfb05e47cd7afbff025c91a15c96f2.jkddzztszm.acm-validations.aws."

Now take those outputs and use them in another HTTP request to the instructional API. This time, you'll be submitting validation records that prove to AWS you control this domain name.

{
	"record": "_abc123.mysite.ca3.cs351.cloud",
	"type": "CNAME",
	"value": "_xyz.acm-validations.aws",
	"status": "PENDING",
	"message": "ACM validation CNAME created. Certificate validation typically completes within a few minutes."
}

Once you've successfully updated the DNS records, within a few minutes ACM will verify the CNAME record and issue your certificate. You can check the progress by visiting ACM in the AWS Console and looking at the "Status" column for the certificate you submitted. Once "Status" becomes "Issued", return to the terminal and run

$ terraform apply # wait for it to complete, may take 5-15 minutes
$ terraform output cloudfront_proxy_domain

Now take the cloudfront domain name and submit it to the PUT /dns endpoint as the new "value" for your "subdomain". Once that request is successful, return to the terminal and run

$ cd ../ansible
$ ansible-playbook playbook.yml # configure nginx to tell Django HTTPS is enabled

Once DNS changes propagate, if you visit your subdomain in a web browser again, you'll see that HTTPS is enabled! No more warning that you're visiting an HTTP-only site, and you can be confident your application credentials are encrypted.

Squirrel detection

It's time to implement squirrel detection using our YOLO model. Remember, we can only detect birds at the moment. The model is capable of detecting many objects, we just have to tell it what to look for. In this section, you'll modify the application code that controls this feature. This is your first time modifying bird.ai's code in this assignment, and afterwards you'll re-deploy to see your changes live.

The current model (yoloe-26n-seg.pt, 11MB) is the "nano" variant of YOLO-E. It's fast and small, but its text encoder doesn't produce strong enough embeddings to reliably detect squirrels. You'll upgrade to the "large" variant (yoloe-26l-seg.pt, 75 MB), which is more capable.

The first step is to download the larger model, it should be placed alongside the existing yoloe-26n-seg.pt file in the bird.ai/ directory.

$ cd bird.ai
$ curl -Lo yoloe-26l-seg.pt https://github.com/ultralytics/assets/releases/download/v8.4.0/yoloe-26l-seg.pt

The second step is to update the YOLO model configuration you find in bird.ai's controller code.

- model = YOLO('./yoloe-26n-seg.pt')
- model.set_classes(['bird'], model.get_text_pe(['bird']))
+ model = YOLO('./yoloe-26l-seg.pt')
+ model.set_classes(['bird', 'squirrel'], model.get_text_pe(['bird', 'squirrel']))

Finally, re-deploy the bird.ai application using Ansible (it will take longer because the model file size has increased). bird.ai works on mobile, I encourage you to go out on campus, log in, and start taking pictures of squirrels!

Mapping detections

Photos taken on smartphones contain metadata called EXIF (Exchangeable Image File Format). Among other data (camera model, exposure settings, timestamp), EXIF can include the GPS coordinates of where the photo was taken (if the user has location services enabled). In this section, you'll implement a function that extracts GPS coordinates from uploaded images and store them alongside the detection record. Once implemented, detections from geotagged photos will automatically appear as markers on the map page.

https://mysite.ca3.cs351.cloud/map/

Part of becoming a professional in cloud computing is understanding the implications of working with cloud services. One of the most important is that once data leaves your device, you don't own it anymore, and the service you're interacting with can and will pull a lot of information from even a small amount of data.

Open bird.ai/app/views.py and find the extract_location_from_exif() function. Currently, it returns (None, None).

def extract_location_from_exif(image_path):
  # TODO: implement EXIF GPS extraction
  # Hint: use Image.open(image_path).getexif().get_ifd(IFD.GPSInfo)
  # to access the GPS tags, then convert DMS to decimal degrees
  return None, None

Replace the body with your implementation. You'll need to:

1. Open the image with PIL.Image.open(image_path)
2. Get the EXIF data with .getexif()
3. Access the GPS sub-IFD with .get_ifd(IFD.GPSInfo) (import IFD from PIL.ExifTags)
4. Read GPS tags 1-4 (latitude ref, latitude DMS, longitude ref, longitude DMS)
5. Convert DMS to decimal degrees
6. Apply the hemisphere sign
7. Return (latitude, longitude) or (None, None) if no GPS data is present

Wrap everything in a try/except. Images without EXIF or without GPS tags should return (None, None), not crash.

Latitude: 40° 25' 25.32" N
Longitude: 86° 55' 16.32" W

decimal = degrees + minutes/60 + seconds/3600

When you want to verify your implementation, run the unit tests locally (If you haven't set up the full docker compose stack from the end of Part 1, do that first).

$ docker compose run --rm --entrypoint python app manage.py test app.tests.ExifExtractionTest

Once they're passing, deploy your updated application using Ansible, then upload an image with your phone and check the map page to see if a location marker appears.

Gossip Squirrel

Your bird.ai application is isolated to your AWS account and constrained to the N-Tier architecture we developed in Part 1. Any data your application stores was only generated by users registered with you. In this section, you'll connect your application to a gossip network that shares detection data across the entire class. When any student uploads a geotagged photo, every other student's map shows the detection.

The gossip API only stores metadata (location, image URL, domain name), while images stay on the CloudFront CDN they originated from. When another student's map shows your detection, their browser loads the image directly from your CloudFront distribution.

Your goal in this section is to implement the function share_detections_with_network(), which performs the POST /gossip request that publishes data to the API server.

The gossip sync runs inside the bird.ai container as a background loop (every 10 seconds). It needs three pieces of information: your domain name, AWS account ID, and external ID. These flow through a pipeline that starts in Terraform and ends inside the running container.

1. You define external_id and domain in terraform.tfvars
2. Terraform exposes them as outputs (along with account_id)
3. The Ansible playbook reads those outputs and passes them as variables to Play 3
4. Play 3 templates them into the systemd service file ca3-app.service.j2
5. The service file passes them as environment variables to the Docker container
6. Inside the container, sync_gossip.py reads them from os.environ

Steps 2-6 are already wired up in the starter code. Your task is step 1, uncomment and set external_id in terraform.tfvars

# Gossip protocol: set your external_id from your credentials file
external_id = "your-external-id"

Then run terraform apply to register the new output value.

...
ExecStart=/usr/bin/docker run --rm --name ca3-app \
  -p 8000:8000 \
  -e DATABASE_URL={{ database_url }} \
  -e AWS_STORAGE_BUCKET_NAME={{ s3_bucket }} \
  -e CLOUDFRONT_DOMAIN={{ cloudfront_domain }} \
  -e DOMAIN={{ domain | default('') }} \
  -e AWS_ACCOUNT_ID={{ account_id | default('') }} \
  -e AWS_EXTERNAL_ID={{ external_id | default('') }} \
  {{ app_image }}
  ...

The final step is to implement the share function. Open bird.ai/app/views.py and find share_detections_with_network. It currently is a stub.

def share_detections_with_network(detections_data, domain, account_id, external_id):
  # TODO: implement - make one HTTP POST request to
  # https://api.cs351.cloud/gossip
  pass

Replace the body with a single requests.post() call. Here's the format of the API call:

{
    "new": 1,
    "skipped": 0,
    "message": "Shared 1 new detection(s)."
}

To verify your implementation is correct, run the unit tests:

$ docker compose run --rm --entrypoint python app manage.py test app.tests.GossipPushTest

Once the unit tests are passing, deploy the application using Ansible.

Estimating Cloud Cost

Your N-Tier Architecture uses several AWS services billed by the hour or by the gigabyte. Because you built with Terraform, you can terraform destroy when you stop working and terraform apply when you start again — you only pay for hours your infrastructure is running.

Resource Rates (us-east-1, on-demand, no free tier)

Data transfer in is free. CloudFront egress is covered by the 1 TB/month free tier.

How Billing Works

• EC2 and RDS are billed per second while running. When you terraform destroy, the instances are terminated and billing stops. When you terraform apply, new instances start and billing resumes.
• EBS volumes are billed per GB-month for as long as they exist. They are created with the instance and destroyed with it — no separate lifecycle.
• RDS storage is billed per GB-month for the allocated size (20 GB), regardless of how much data is in the database.
• S3 is billed per GB-month for stored objects and per request (GET/PUT). At ~100 uploads the cost rounds to zero.
• CloudFront charges for data transfer out to viewers. The first 1 TB/month is free, which comfortably covers this assignment's gossip traffic and image serving.
• ECR Public and ACM are always free.

Estimated Cost

The largest cost driver is the proxy instance ($0.0848/hr). Storage and bandwidth are negligible.

Teardown

Step 1: Destroy Terraform-managed infrastructure

$ export AWS_PROFILE=ca3
$ cd terraform
$ terraform destroy

Step 2: Delete the state bucket

$ aws s3 rb s3://ca3-tfstate-<YOUR_ACCOUNT_ID> --force

Step 3: Visit IAM in the AWS console and delete the user "ca3"