This is the stack I built for this personal project. It is not running right now. Scale-to-zero by default; scaled up on demand to prove the wiring still holds.

cluster at a glance

IRSA — how the cluster talks to AWS without static keys

IAM roles bound via the EKS OIDC provider, each scoped to one ServiceAccount. No long-lived IAM user, no secret stuffed in a ConfigMap.

# cost-at-24x7 estimate: EKS control plane ~$73/mo alone. Add t3.medium ×1, ALB, data transfer — call it ~$110–140/mo just to keep a blog warm. The static stack is under a dollar. Keeping it up 24/7 would be too expensive for a personal project. (Infra/prod/ also exists in Terraform but is not provisioned in the current account — legacy from a prior AWS account.)

lab-on / lab-off — scale-to-zero helpers

$ lab-on.sh      # EKS nodes: min=0, desired=0 → desired=1,  ArgoCD syncs workloads
$ lab-off.sh     # back to desired=0, $0 compute until next lab-on
      

Two pipelines, distinct triggers, distinct blast radii:

• application pipeline — app repo → app-ci.yaml builds image, pushes to ECR by digest, opens a PR on the GitOps repo bumping the dev Deployment to the new digest → ArgoCD picks it up.
• content pipeline — markdown push → content-ci.yaml syncs to the S3 content bucket under dev/, then dispatches content_validation on the GitOps repo.

application repo — .github/workflows/

gitops repo — .github/workflows/

content flow (markdown → dev → prod)

 content/*.md ──▶ content-ci.yaml ──▶ s3://.../dev/
                                           │
                                           ▼
                                 dispatch content_validation
                                           │
                             ┌─────────────┴─────────────┐
                             ▼                           ▼
                      smoke (curl /health)         ZAP baseline DAST
                             └─────────────┬─────────────┘
                                           ▼
                                   on success:
                              copy-content.yaml syncs
                               s3://.../dev/ → prod/
                                           ▼
                              prod-validation runs ZAP
                                    against prod
      

Delivery is pull-based. Nothing in CI runs kubectl apply. ArgoCD sits inside the cluster and reconciles desired state from devopsblog-gitops to what's actually running.

 devopsblog-application  ──┐
   (source + Dockerfile)   │
                           ▼
                   GHA: app-ci.yaml
                   ├─ build image
                   ├─ push to ECR (by digest)
                   └─ open PR on devopsblog-gitops
                           │
                           ▼
 devopsblog-gitops ──────── ArgoCD (in-cluster) ─────▶ dev namespace
   (k8s manifests,          │                          (Deployment, SA,
    one commit = one        │                           Service, Ingress)
    desired state)          └── automated sync, self-heal, prune
      

app-of-apps pattern

• argocd-apps-root-dev/ — the root Application, bootstrapped once into ArgoCD by hand.
• argocd-apps-dev/ — child Applications the root points at (currently: devopsblog-dev).
• dev/devopsblog-dev/ — the actual manifests: Deployment, Service, Ingress, ConfigMap, two ServiceAccounts (ALB + S3).
• dev-alb-controller/ — the AWS Load Balancer Controller install.

sync policy (every child Application)

• automated — ArgoCD applies new commits without a human clicking sync.
• self-heal — manual kubectl edit on a managed resource is reverted back to git.
• prune — resources deleted from git are deleted from the cluster.
• drift detection — every resource is either Synced or flagged OutOfSync with a diff against git.

why this over kubectl apply from CI

• Rollback is git revert. No CI-held credential with cluster-admin.
• Desired state has a review trail — every cluster change is a PR.
• The cluster pulls; CI never reaches in. Smaller attack surface.

GitHub App pattern — zero secrets in repo Variables/Secrets

Cross-repo writes (app repo → GitOps PR) need a token with more scope than the default GITHUB_TOKEN. Instead of stuffing a PAT into repo secrets, a GitHub App holds the permission; its private key lives in AWS Secrets Manager.

 GHA job starts
   │
   ├─ aws-actions/configure-aws-credentials  (OIDC → short-lived STS)
   ├─ aws-actions/aws-secretsmanager-get-secrets  (fetch App private key)
   └─ actions/create-github-app-token  (mint short-lived installation token)
                 │
                 └─▶ git push / gh pr create on devopsblog-gitops
      

• zero hardcoded secrets in either repo's Variables or Secrets.
• short-lived tokens at every hop — STS credential, then App installation token.
• scoped — the App is only installed on the two repos it needs, with the minimum permission set.

runtime env (when the Flask pod is actually running)

No origin server. No Kubernetes pod. No database. This page is a flat HTML file sitting in an S3 bucket, fronted by CloudFront. A Python process baked it once (Frozen-Flask) and then exited. What you are hitting is a CDN edge cache.

 you ──HTTPS──▶ CloudFront edge ──SigV4/OAC──▶ S3 (private)
                   │
                   ├─ ACM cert in us-east-1 (TLSv1.2_2021 min)
                   ├─ response_headers_policy: HSTS, CSP, XFO, nosniff, referrer
                   └─ caches baked HTML + static assets
      

security headers at the edge (CloudFront response-headers policy)

why static:

• cost — roughly $0.65/month. No compute, no NAT gateway, no control-plane fee.
• uptime — CloudFront+S3 availability is higher than any single-cluster EKS I'll ever run.
• blast radius — a bad commit ships HTML, not containers. Worst case: invalidate the CDN.
• tradeoff — no server-side dynamic behaviour. For a blog, that's a feature.