Overview
This is the AWS info for our my IT capstone project at UW-Whitewater.
The goal of this project (and the class as a whole) was to build a Serverless Order Processing System entirely in AWS. The site files, backend infrastructure, databases, and any other functions were entirely in the cloud. The focus of our website was a mock refurbished cell phone storefront.
Our team's GitHub repository was specifically for CI/CD deployment to our static website. Any lambda functions, databases, etc. have all since been deleted, as this documentation was written about 6 months following the completion of the class. For the assistance of future students, though, I've explained how our infrastructure was set up.
- As per the recommendation of the professor for this course much of the website has been AI generated by Claude.AI Pro. Given the time constraints and extremely limited lack of guidance it would not have been possible to do without AI assistance.
- Regardless of this, though, I still learned much about many AWS tools and the ways in which they interact with eachother.
Website
The static website was publicly hosted in an AWS S3 bucket. It would update from our GitHub Repo using a GitHub action that would upload the files in the repository to the S3 bucket using an AWS access key for a IAM service account each time there was a commit.
User Information Database
User and Order information was saved in a mySQL database hosted on Amazon RDS. This had two tables, one for customer information (Customer ID [primary/foreign key], Email, Shipping Address, etc) and another for order information (Order ID, Products Ordered, Product Info [color, size, etc], Customer who ordered them)
Users couldn't log in but their orders were saved when placed. This was done through an API gateway that would trigger lambda functions to send the information to the mySQL database, while also sending information to the receipt system detailed below.
Inventory Database
This was probably the easiest part to set up. The inventory was managed through a DynamoDB database. When placing orders on the website, it would check if the item was in stock and if so then allow you to check out. The database was just one table with different fields (ex. iPhone128gb, Pixel64gb, etc.) that all had different values for the amount of fake "inventory" that was available. Like almost everything in this project it was updated and connected to the website using an API gateway with lambda functions.
Notification System
When users placed their orders, it would trigger through a lambda function and send an email receipt to the customer. This was done using Amazon SES to send to the persons email confirming their order, order ID, products bought, address, etc.
IAM roles
Provisioning IAM roles wasn't as big of a focus on this project as we only needed a handful. We set up IAM accounts for three primary reasons:
- Allowing team members to access our AWS infrastructure.
- Service accounts for Github code deployment.
- Designated roles for AWS functions to operate with the correct permissions.
For example, a DynamoDB role was made and assigned to allow different tools such as lambda functions to edit the DynamoDB database.
Other things to note:
This was all done and deleted about 6 months before I typed this ReadME documentation, so some details have been omitted due to either them being the focus of my teammates, or lack of clarity on our implementation. One example is lambda functions, I would need to use the AWS console again and work through problems in order to remember each of the exact lambda functions utilized.