JustReadIt AWS portfolio project

Last updated: 2026-07-29 (a day ago)
JustReadIt is a fictional e-book marketplace I used to demonstrate AWS architecture, Terraform infrastructure, CI/CD, and cloud account review skills.The goal is not to present a giant production application. It is to show how I reason through a realistic cloud workload: business constraints, service choices, network boundaries, cost drivers, operational risks, and the path from design to deployable infrastructure.
Stack
AWSTerraformECS FargateALBRDS PostgreSQLS3CloudFrontIAMGitHub Actions
RoleCloud architecture, infrastructure as code, CI/CD, and operational review.
ScopeReference SaaS architecture plus a deployable pre-production AWS implementation.
StatusPortfolio case study with working infrastructure path and documented production gaps.
FocusReliability, security, private networking, cost control, and maintainability.

What this project includes

This portfolio page is the short version. The repository contains the detailed artifacts:
  • a cost-conscious AWS SaaS architecture case study;
  • a deployable pre-production reference implementation written with Terraform;
  • a small .NET API and Preact frontend used to validate the infrastructure path;
  • GitHub Actions workflows for image build, ECR push, and ECS deployment;
  • a synthetic AWS account review report focused on reliability, security, observability, and cost.

Architecture snapshot

The target architecture uses CloudFront as the public entry point. Static frontend assets are served from private S3 through CloudFront, while API traffic is forwarded to an Application Load Balancer and then to ECS Fargate tasks running in private subnets.The backend communicates privately with RDS PostgreSQL, S3, Secrets Manager, and CloudWatch. E-books and other user uploads stay in a separate private bucket, with protected downloads handled through backend-generated presigned URLs.
JustReadIt AWS SaaS architectureHigh-level AWS architecture for the JustReadIt SaaS workload.

What this proves

The project is scoped to show cloud engineering judgement, not just a list of AWS services.
I can translate business constraints into AWS service choices and explicit tradeoffs.
I can design private networking, container hosting, relational storage, object storage, and CDN delivery as one coherent system.
I can turn architecture decisions into Terraform modules and deployment workflows.
I can review my own infrastructure for launch gaps and explain the reliability, security, observability, and cost implications.

Implementation highlights

The Terraform demo is intentionally pre-production, but it exercises the core infrastructure path end to end.
  • ECS Fargate runs a containerized backend behind an ALB, with images stored in ECR.
  • RDS PostgreSQL lives in private subnets and communicates only with the backend security group.
  • S3 and CloudFront serve frontend assets and user-uploaded content through separate buckets/distributions.
  • GitHub Actions use AWS OIDC to deploy without long-lived access keys.

Production readiness review

I also wrote an account-review report that treats the project like a pre-launch workload and names the gaps clearly.
  • P1: run at least two ECS tasks for better service availability.
  • P1: harden RDS production settings, including deletion protection, backups, sizing, and storage class.
  • P2: add HTTPS between CloudFront and the ALB origin.
  • P2: add CloudWatch alarms for health, latency, CPU, memory, database, and deployment signals.
  • P3: configure AWS Budgets and more granular cost tags.
  • P3: enable ALB access logs and extend log retention for incident review.

Repository references