Sydney, NSW

Jessamy Huang

Cloud & DevOps Engineer

I build useful tools and cloud solutions, from idea to deployment.

View Projects
Portrait of Jessamy Huang

About

I have hands-on experience in AWS cloud infrastructure, Terraform, CI/CD, and containerised applications. I enjoy understanding problems, designing practical solutions, and building tools that make everyday work easier. My interests extend beyond cloud engineering to automation, data analytics, and AI applications, with a focus on reliability and continuous improvement.

Hobbies

  • Singing
  • Piano
  • Dance
  • Badminton
  • Mahjong

Projects

Things I've built, from cloud infrastructure and automation to personal applications and creative projects.

Professional Projects

AWS architecture: Route 53 to an ALB with an ACM certificate in public subnets, a NAT gateway and internet gateway for outbound traffic, ECS Fargate tasks with auto scaling in two private subnets using Secrets Manager, RDS SQL Server primary and standby in database subnets, CloudWatch logs and metrics, and a Bitbucket Pipelines CI/CD workflow using OIDC, ECR and Terraform with remote state in S3

AWS Microservices Deployment Platform

AWS-based microservices platform running on ECS Fargate, with Terraform-managed infrastructure and automated CI/CD workflows focused on reliable, consistent deployments across environments.

  • ECS Fargate
  • RDS
  • Terraform
  • Docker
  • ECR
  • ALB
  • Bitbucket Pipelines
  • SonarQube

AWS Microservices Deployment Platform

Problem
  • Every change triggered a full rebuild of all services, slowing deployments.
  • Multiple ECS services ran database migrations on startup, risking conflicts.
  • Legacy SonarQube issues blocked new releases even when new code was clean.
Architecture
Route 53 → ALB → ECS Fargate → RDS SQL Server
Engineering approach
Managed infrastructure with Terraform and automated delivery through Bitbucket Pipelines, with linting, testing, quality gates and post-deployment health checks.
Key engineering decisions
  • Layered Terraform: Split networking, platform and service layers so changes stay isolated and modules are reusable.
  • Selective builds: Detected changed services and built only those.
  • Single migration task: Ran migrations once in a dedicated ECS task before rollout, instead of in every service.
  • New-code quality gates: Gated on critical issues and new code, so legacy debt didn’t block releases.
Result
  • Cut pipeline time from ~20 to ~5 min for single-service changes.
  • Eliminated migration conflicts between services.
  • Legacy issues no longer blocked deployments, while new code still passed quality gates.
AWS cost analytics architecture: the previous Cost Explorer API approach provided aggregated data with limited granularity, so AWS Billing CUR 2.0 data flows to S3, Glue and Athena into Amazon QuickSight, where the CID KPI Dashboard validates the pipeline and a generated AWS Cloud Cost Management analysis provides AI-assisted cost insights; AWS Cloud Intelligence Dashboards are deployed with Terraform

AWS Cost Analytics & Generative BI

A CUR-based AWS cost analytics pipeline, extended beyond the standard Cloud Intelligence Dashboards with QuickSight-generated analysis and AI-assisted cost insights.

  • CUR 2.0
  • Athena
  • QuickSight
  • Generative BI
  • Terraform
  • FinOps

AWS Cost Analytics & Generative BI

Problem
  • Cost Explorer API reporting lacked the granularity needed for deeper resource-, tag-, and SKU-level analysis.
  • A more flexible approach was needed to analyse detailed AWS billing data and identify cost optimisation opportunities.
Architecture
CUR 2.0 → S3 → Glue → Athena → QuickSight
Engineering approach
  • Deployed AWS CID with Terraform and validated the end-to-end CUR 2.0 analytics pipeline using the official KPI Dashboard.
  • Reused the Athena dataset to generate an AWS Cloud Cost Management analysis tailored to the available billing data.
  • Evaluated QuickSight AI capabilities for cost investigation and optimisation insights.
Key engineering decisions
  • Data granularity: Chose CUR 2.0 over Cost Explorer API for more detailed cost analysis.
  • Architecture reuse: Retained the validated CUR/Athena data layer while adapting the analytics layer.
  • Cost optimisation: Removed unnecessary QuickSight users and AI features to reduce recurring costs.
Result
  • Delivered a reusable AWS cost analytics pipeline with tailored QuickSight analysis and AI-assisted insights.
  • Reduced unnecessary QuickSight and Amazon Q recurring costs through configuration cleanup.

Personal Projects

JH TaskOps: Cloud platform for JH Task Tracker, my personal productivity app. Screenshots of the Daily List, Weekly Report and Focus Timer views

JH TaskOps

A personal productivity app I built and brought to AWS, with Terraform-managed infrastructure, CI/CD automation and secure deployments.

  • JavaScript
  • S3
  • CloudFront
  • Terraform
  • GitHub Actions
  • OIDC
GitHub Live Demo

JH TaskOps — AWS Deployment & CI/CD

Problem
  • The app ran only locally, with no public access or deployment process.
  • Existing AWS resources were created manually, making changes hard to track and repeat.
Architecture
JH TaskOps architecture: GitHub Actions deploys a static app from private S3 through CloudFront; Terraform manages AWS through GitHub OIDC; app data stays in browser LocalStorage with optional Gist sync and Claude API integration
Engineering approach
  • Imported existing AWS resources into Terraform and verified a clean initial plan with no drift.
  • Ran Terraform validation and plan on every pull request.
  • On merge to main, applied infrastructure changes, deployed the frontend, and invalidated the CloudFront cache.
Key engineering decisions
  • Security: Kept S3 private behind CloudFront OAC, serving over HTTPS only.
  • Authentication: Used GitHub OIDC instead of long-lived AWS credentials.
  • Access control: Separated Plan and Apply roles, restricting Apply to main.
  • Custom domain: Managed Cloudflare DNS and the ACM certificate (us-east-1) in Terraform alongside AWS resources.
Result
Live at taskops.jessamyh.com, with every infrastructure and frontend change shipped through a reviewed, automated pipeline and no manual console changes.
JH AI Observatory: Your AI, in perspective. Claude Code and Codex usage in one dashboard, with screenshots of the overview, usage by model and usage by project

JH AI Observatory

An AI usage analytics dashboard that tracks Claude Code and Codex activity across models, projects, and time, including token consumption, estimated API costs, and AI-powered insights.

  • Node.js
  • Usage Analytics
  • AI Integration
GitHub

JH AI Observatory

Problem
  • Wanted to understand Claude Code and Codex usage across projects and models.
  • Local usage logs were difficult to analyse, particularly for token consumption, caching, and estimated API costs.
Architecture
JH AI Observatory architecture: Claude Code and Codex logs on the local machine are ingested incrementally into a JSON store, which feeds a CLI and a dashboard served on 127.0.0.1; the dashboard optionally calls the Claude API over HTTPS for AI insights, while raw logs, the store and config never leave the machine
Engineering approach
  • Built a Node.js application to process local usage logs and visualise activity across models, projects, and time.
  • Implemented token tracking, cache analysis, and API cost estimation using configurable pricing.
  • Added automatic refresh, CLI summaries, and AI-powered insights based on usage data.
Key engineering decisions
  • Data accuracy: Distinguished missing token data and unknown model pricing from actual zero values.
  • Cost transparency: Separated estimated API costs from actual billing.
  • Incremental processing: Used file fingerprinting to process only changed logs.
  • Privacy: Kept raw logs and usage data local, with no external database.
Result
Delivered a zero-dependency, locally hosted analytics dashboard with automated updates, cost estimates, and AI-assisted usage insights.
JH Gallery home page: the collection title and the featured work framed on a warm dark wall

JH Gallery

A personal gallery of music performances, films, and photos, designed like a museum where each year represents a room.

  • S3
  • CloudFront
  • Terraform
  • Python
  • Automation
GitHub Live Demo

JH Gallery

Problem
  • Years of performances, films, and photos were scattered across folders, making them difficult to browse and share.
  • Needed a public gallery while keeping original media and personal information private.
Architecture
Local Archive → Python Build → Optimised Media → Private S3 → CloudFront (HTTPS) → gallery.jessamyh.com
Engineering approach
  • Built a Python pipeline to resize photos, strip EXIF/GPS data, compress videos with FFmpeg, and generate thumbnails.
  • Processed media incrementally, skipping unchanged files.
  • Automated publishing to S3 with selective uploads, cache headers, and CloudFront invalidation.
  • Managed S3, CloudFront, ACM and Cloudflare DNS in Terraform.
Key engineering decisions
  • Privacy: Kept original media and personal metadata out of the public repository and stripped location data before upload.
  • Security: Served from private S3 via CloudFront OAC, with security headers.
  • Discoverability: Added noindex so the gallery is shareable by link but not indexed.
Result
Live at gallery.jessamyh.com: new media goes from local folder to published site with one command, with Terraform-managed infrastructure.

Experience

  1. Jun 2026 – Sep 2026 Sydney, NSW

    Cloud Solutions Engineer · Contractor

    Jedi Hill TaaS

    Delivered AWS cloud engineering across infrastructure, cost analytics, and automation. Worked with customers to understand technical requirements and develop practical solutions and recommendations.

  2. Sep 2025 – May 2026 Sydney, NSW

    DevOps Engineer · Intern

    Liu & Woodland Law Firm

    Built and supported AWS infrastructure, CI/CD pipelines, and containerised applications. Used Terraform to manage infrastructure and improved deployment workflows through automation, quality checks, and monitoring.

  3. Apr 2021 – Sep 2022 Beijing, China

    Project Engineer · Full-time

    Digital China Cloud Technology Ltd

    Supported AWS and Azure cloud operations for enterprise clients, focusing on billing analysis, cost reporting, access management, and Python scripting to automate repetitive tasks.

  4. May 2019 – Mar 2021 Beijing, China

    Project Coordinator · Full-time

    Futurus

    Coordinated HUD product development across optical, hardware and software teams, supporting Agile planning and milestone tracking.

Skills

Cloud → AWS
  • EC2
  • VPC
  • IAM
  • S3
  • ECS Fargate
  • ECR
  • ALB
  • RDS
  • Lambda
  • SQS
  • Route 53
  • CloudFront
  • Glue
  • Athena
  • QuickSight
DevOps & Infrastructure
  • Terraform
  • Docker
  • CI/CD
  • Bitbucket Pipelines
  • GitHub Actions
  • Azure DevOps
  • SonarQube
  • Linux
  • Git
Observability & Operations
  • CloudWatch
  • Grafana
  • Monitoring
  • Logging
  • Troubleshooting
Programming & Scripting
  • Python
  • Bash
  • SQL
Networking
  • TCP/IP
  • HTTP/HTTPS
  • DNS
  • NAT

Certifications

Education

  1. Feb 2024 – Jan 2026 Sydney, NSW

    Master of Engineering (Information Technology)

    University of New South Wales

  2. Sep 2015 – Jun 2019 Beijing, China

    Bachelor of Engineering (Electronic and Information Engineering)

    Capital Normal University

Contact