Home / Projects
AE · 05In progress

AWS Cloud Foundations

A static site on S3 serving AE-01's dbt docs, and an EC2 instance running a Streamlit dashboard that reads AE-01's market mart through a least-privilege IAM role, instead of a public bucket and an admin user.

Data sourceAE-01's warehouse.duckdb: a read-only export of fct_daily_prices joined to dim_tickers (5,010 rows), plus AE-01's regenerated dbt docs site.
Architecturedbt docs → S3 (public static website) · market CSV → S3 (private) → EC2 (IAM role) → Streamlit
InfrastructureTerraform: S3 ×2, EC2 t3.micro, IAM instance role, security group, AWS Budgets alert
StackTerraform AWS S3 AWS EC2 IAM Streamlit dbt docs
StatusIn progress: built and verified locally, real AWS deploy pending (see Results)

Context

This project rebuilds an AWS fundamentals exercise from a cloud bootcamp (account setup, IAM, S3 static hosting, an EC2 instance serving a Streamlit app reading a CSV from S3). Instead of a placeholder page and a tutorial dataset, though, both deployments serve a real artifact from this portfolio's own AE-01: its dbt documentation site, and its dimensional-model market data.

Business Problem

How do you put an Analytics Engineering deliverable, whether that's dbt's auto-generated documentation or a dbt mart itself, in front of someone who won't clone a repo and run dbt docs serve locally? Static hosting and a small serving layer, provisioned as code and secured with least-privilege access, is the minimum real answer.

Architecture

AE-01 warehouse.duckdb dbt docs generate S3 (public website)
AE-01 warehouse.duckdb export_marts_to_csv.py S3 (private) EC2 + IAM role Streamlit

Two independent paths out of the same source project, each demonstrating a different AWS serving pattern: a fully static site behind S3 website hosting, and a private data object served only through an application with a scoped IAM role, never a public HTTP GET.

Data

Methodology

  1. Export (read-only): scripts/export_marts_to_csv.py opens AE-01's DuckDB warehouse in read_only mode.
  2. Infrastructure as code: Terraform defines every resource: two S3 buckets, one EC2 instance behind a security group open only on 22 (single trusted CIDR) and 80, one IAM role, one AWS Budgets alert.
  3. Billing alert first: budgets.tf has no dependency on any other resource, so it applies, and must apply, alone, before anything that can incur cost.
  4. App code tested independently of AWS: the Streamlit app reads its data source from an environment variable, a local CSV path today, an s3:// URI in production, same code either way.

Design Decisions

Results

In progress. The application code, data export, and infrastructure code are built and verified locally. The actual AWS deploy, meaning terraform apply and the live URLs, is a documented handoff: this environment has no working AWS credentials for a personal account.

What's verified without AWS:

Streamlit dashboard running locally, showing AAPL close price and volume charts built from AE-01's real market data dbt docs static site, regenerated from AE-01 and served locally, showing the project overview page

Tech Stack

CategoryTool
IaCTerraform (AWS provider)
ComputeEC2 (Amazon Linux 2023, t3.micro)
StorageS3 (static website + private bucket)
IAMLeast-privilege instance role
Cost controlAWS Budgets
AppStreamlit, pandas, boto3/s3fs
← Previous
LLM Token Gateway + AI FinOps