Cloud & AI Platform Engineering Portfolio

Yvonne Yao — Senior Platform Engineer — Cloud & AI

I design and build secure, governed, observable, and cost-aware cloud and platform foundations for AI workloads and AI-assisted engineering. This personal portfolio explores reusable, mock-first patterns for enterprise environments through AWS platform infrastructure, delivery automation, and controlled AI access.

LinkedIn · GitHub

Core technologies: AWS · Terraform · Kubernetes · EKS · Helm · Argo CD · GitHub Actions · TypeScript · Python · JSON Schema · AI governance patterns

Independent technical portfolio built using synthetic data and public-cloud patterns.

Architecture at a Glance

flowchart LR
  context["Enterprise outcomes<br/>and accountable<br/>ownership"]
  policy["Governance and<br/>data policy"]
  platform["Shared CloudAI Platform:<br/>secure foundations,<br/>governed access, delivery,<br/>and operations"]
  workloads["Business-domain AI<br/>workloads and integrations"]
  providers["AWS-first implementation<br/>with Azure and GCP<br/>future mappings"]
  capacity["Optional AI Factory<br/>and capacity extension"]

  context --> platform --> workloads --> providers
  policy -. "applies across" .-> platform
  policy -. "applies across" .-> workloads
  capacity -. "future extension" .-> platform

Loading

This is a reference architecture, not a deployed topology. Read the full architecture hierarchy for the enterprise capability map, CloudAI platform domains, lifecycle, evidence boundaries, and provider views.

Featured Solutions

Solution	Status	Focus
Governed AI Gateway	Implemented — mock-first	Controlled model access, request policy, metadata-only evidence, and an opt-in provider adapter boundary.
AI Release Engineering on EKS	Implemented — sandbox-validated	Terraform, Helm, GitOps, rollout, rollback, and teardown discipline for a synthetic workload.
Governed RAG Lifecycle	Implemented — local synthetic workflow	Provenance, source lifecycle, evaluation artifacts, and deterministic local quality checks.
Bounded Bedrock Sandbox	Implemented — bounded synthetic sandbox validation	Short-lived identity, least-privilege access, manual approval, and narrow synthetic Guardrail checks.
AgentCore Governed RAG POC	Implemented — sandbox-validated	Gateway-only Runtime access, synthetic Knowledge Base ingestion, citations-or-abstention behavior, and bounded CloudWatch evidence.
Bounded EKS GPU + Kueue POC	Implemented — source path; runtime pending	One-node, scale-to-zero Terraform and protected workflow path for a synthetic CUDA admission check.
Private EKS Enterprise AI target	Implemented — source path; runtime pending	Single network-state ownership, private workers, endpoint-first egress, protected VPC-connected delivery, and no-public-IP controls; GPU extension remains gated.

Read the featured-solution evidence and boundaries →

Evidence-Status Legend

• Implemented — mock-first: local code, contracts, and tests are present; no provider call is required by default.
• Implemented — local synthetic workflow: local, synthetic artifacts and deterministic checks demonstrate the workflow without a hosted runtime.
• Implemented — sandbox-validated: a manually approved personal sandbox validation exercised a synthetic workload; it is not a production platform.
• Implemented — bounded synthetic sandbox validation: a manually approved, least-privilege provider validation used synthetic inputs and sanitized evidence; it is not unconstrained provider access or production operation.
• Design / future reference: an architecture mapping or documented boundary without runtime implementation evidence.
• Implemented — source path; runtime pending: reviewed code, static controls, and local tests are present, but the associated cloud runtime has not been deployed or validated.

What This Portfolio Demonstrates

• Cloud platform foundations, infrastructure-as-code, and controlled delivery paths.
• Governed AI access, RAG lifecycle controls, safety boundaries, and evaluation evidence.
• Kubernetes packaging, GitOps, rollout and rollback patterns, and cost-aware sandbox discipline.
• Explicit separation between implemented, mock-first, sandbox-validated, and future work.

Architecture Library

Browse the complete Architecture Library →

Repository Boundaries

The Technical Reference below links to the implementation record and evidence boundaries. This repository does not claim production operation, customer-data use, autonomous agent execution, or a general-purpose AI application.

---

Technical Reference

The portfolio landing page above is deliberately concise. Use these paths for the supporting technical detail:

• Architecture library — complete curated document index, including AWS-first and future Azure/GCP mappings.
• Architecture hierarchy — enterprise ecosystem, capability layers, CloudAI domains, lifecycle, and evidence boundaries.
• Solution walkthrough — guided technical reading sequence and evidence progression.
• Current status — implementation record, bounded sandbox validation, deferred scope, and recommended next slice.
• Featured solutions — curated case studies with technical evidence, trade-offs, and explicit non-claims.

AWS is the first provider with bounded implementation and validation evidence; the synthetic AgentCore Gateway + Runtime + RAG sandbox is the current AWS flagship POC. Azure and GCP remain reference mappings, not provider-parity implementations. The private EKS Enterprise AI target now has a separate network, runner, and EKS Terraform state model plus a protected CI delivery contract, but its private worker/bootstrap runtime and GPU extension remain unvalidated. AI Factory and GPU capacity patterns remain future design scope beyond a bounded source path for a one-node EKS GPU + Kueue proof of concept; that source implementation is not a deployed GPU runtime. The AgentCore sandbox does not claim a production or autonomous agent platform. The AI Workload Operating Contract defines this as a future/design practice track within the portfolio: it does not add a scheduler, GPU cluster, or cloud runtime by default. It now also records applicability-led energy, water, land-use, location, supplier, and external-requirement evidence so future capacity decisions can respond to current procurement signals and planned infrastructure standards without claiming that those standards are already in force.

Run Locally in Mock Mode

The current P1 implementation runs locally in mock mode.

The P1 mock GenAI API uses local synthetic responses:

cd providers/aws/app/api
pnpm install
pnpm run build
pnpm test
pnpm run dev

The API exposes:

• GET /health
• POST /chat
• GET /rag/status
• GET /rag/artifacts
• POST /rag/query
• POST /guardrails/assess

The current mock scripts are simple placeholders:

# Optional, if a TypeScript runner is available in your local environment
tsx scripts/estimate-token-cost.ts
tsx scripts/ingest-sample-docs.ts

If you do not have a TypeScript runner installed, read the scripts as mock examples. No cloud account setup is needed for this path. For deferred scope, future work, and bounded validation evidence, read Current status.