CampusAI — Serverless AI Support Assistant

Aug 2026 – Aug 2026

What Was Built

CampusAI is a 24/7 serverless student support platform built entirely on AWS, designed to eliminate the overhead of fixed compute while delivering instant, context-aware answers to academic, administrative, and financial inquiries. The system is powered by the Groq inference engine running Llama 3.3 70B—one of the fastest open-weight LLMs available—enabling sub-second response times at scale. The platform features a microservice backend architecture composed of four Python 3.12 Lambda microservices orchestrated behind Amazon API Gateway. Every protected route is secured with Amazon Cognito JWT authorization, enforcing strict access controls for authenticated student actions. User conversations are persisted to Amazon DynamoDB with full multi-turn chat thread reconstruction, allowing students to resume sessions seamlessly across different devices. A dedicated, unauthenticated public FAQ endpoint serves pre-configured campus information to lower latency for common administrative questions. The entire infrastructure is declared as code using the AWS Serverless Application Model (AWS SAM) and managed via CloudFormation, supporting drift detection and automated stack rollbacks. Deployments are managed through a zero-trust CI/CD pipeline via GitHub Actions using OpenID Connect (OIDC) identity federation, eliminating the need for long-lived AWS access keys in version control. Sensitive credentials, such as the Groq API key, are injected using CloudFormation NoEcho parameter masks, ensuring secrets never leak into build logs or repository trees. The frontend is a responsive web application hosted on Amazon S3 and distributed globally through Amazon CloudFront with Origin Access Control (OAC), ensuring the raw S3 bucket remains private while AWS Certificate Manager (ACM) provisions SSL certificates to enforce end-to-end HTTPS encryption. The result is a platform designed to scale dynamically from zero to thousands of concurrent student requests with zero baseline infrastructure operating expenses.

Why Was It Built

Traditional campus support channels face major operational bottlenecks, including high staff overhead, slow response times outside business hours, and expensive server infrastructure that incurs costs even during idle periods. CampusAI was developed to solve these challenges by introducing an automated, always-on AI assistant capable of handling multi-turn conversational inquiries for student support. By leveraging a fully serverless cloud framework, the system eliminates baseline compute costs while providing scalable, sub-second academic assistance. The project was also executed as a milestone for a cloud computing program, serving as a real-world showcase for implementing production-ready DevOps patterns, cloud-native infrastructure as code, zero-trust OIDC deployments, and secure AI integrations.

How It Works

Client requests originate at the browser level through a lightweight single-page interface fetched from Amazon CloudFront edge locations, which securely routes requests from S3 via OAC. When a student interacts with the application, HTTPS requests hit Amazon API Gateway. For protected operations, API Gateway validates the incoming JSON Web Token (JWT) against the Amazon Cognito User Pool before passing the payload downstream. Once authorized, API Gateway routes the event to the designated Python 3.12 AWS Lambda microservice. For conversational queries, the Lambda function fetches historical chat context associated with the user's session from Amazon DynamoDB, reconstructs the message history payload, and issues an API call to the Groq inference engine running Llama 3.3 70B. Once Groq returns the generated response, the Lambda microservice concurrently appends the new exchange to the DynamoDB thread and streams the response back through API Gateway to the student's interface. The deployment lifecycle operates entirely through automation. When developer updates are pushed to the GitHub repository, a GitHub Actions workflow authenticates directly to AWS via an OIDC role assumption. The pipeline runs sam build to compile the Python runtimes and sam deploy to execute CloudFormation changes, dynamically managing stacks, environment parameters, and API Gateway route mappings without manual server management.

What Broke and How Did I Fix It

During development and pipeline integration, several critical architectural and operational blockers emerged. Early CI/CD pipeline runs failed during deployment due to invalid GitHub Actions OIDC trust relationship configurations where the IAM role assumed by GitHub Actions lacked the exact repository subject claims needed for federated access. This was fixed by scoping the IAM trust policy strictly to the repository's GitHub OIDC provider string, granting temporary, least-privilege credentials for CloudFormation deployments. Initial multi-turn prompt tests resulted in loss of conversation history across API calls due to unindexed session query patterns in DynamoDB, which was resolved by restructuring the DynamoDB table schema with a composite primary key using the user identity as the partition key and adjusting the Lambda query logic to retrieve ordered session arrays prior to invoking Groq. Deploying the static frontend generated HTTP 403 Forbidden errors when accessing pages through CloudFront because of legacy S3 bucket policies attempting to use Origin Access Identity instead of OAC. This was resolved by migrating the distribution configuration to Origin Access Control, updating the S3 bucket policy to explicitly grant access only to the CloudFront Service Principal, and completely blocking public access to the bucket. Finally, early AWS SAM template deployments risked printing raw API keys inside CloudFormation stack traces, which was secured by refactoring deployment templates to mark sensitive inputs with NoEcho flags and passing keys securely via GitHub Secrets during execution.