Cloud Infrastructure
& Platform Engineering

Two Platforms, One Infrastructure Codebase

The infrastructure work spans two distinct platforms, both fully managed with Terraform and deployed on AWS. The first is a Kubernetes-native microservice platform — the Microservice stack — running on EKS with a full GitOps deployment model. The second is a Saleor-based e-commerce checkout platform running on ECS Fargate, with CloudFront CDN, multi-service Redis, and a RDS PostgreSQL backend shared across three application tiers.

Every AWS resource across both platforms — networking, compute, databases, caching, CDN, secrets, IAM, DNS — is declared in Terraform using a reusable module library. Environments (dev, stage, prod) are separate root configurations that share modules but define their own variable bindings. State lives in S3 with environment-isolated prefixes. There is no console-clicking in production.

Full platform architecture — VPC layout across two AZs, EKS node groups, RDS PostgreSQL, ElastiCache Redis, and VPC endpoints for S3 and ECR

Terraform Module Library

Rather than writing environment-specific code, all infrastructure is composed from typed, parameterized modules. The module library covers every layer of the stack:

VPC Design

Both platforms follow an identical network architecture pattern: a single VPC per environment, three private subnets and three public subnets across us-east-1a/b/c, one NAT gateway per public subnet, and an Internet Gateway for public egress. All workloads — EKS nodes, ECS tasks, RDS instances, ElastiCache clusters — live in private subnets. The ALBs and bastion host are the only resources in public subnets.

VPC Endpoints for Cost and Security

EKS nodes and ECS tasks pull container images from ECR and write to S3 in the critical path of every deployment and file upload. Without VPC endpoints, this traffic would exit via NAT gateways, incurring both latency and NAT data-processing costs at scale. Both platforms have S3 gateway endpoints (free, route-table-based) and ECR.dkr interface endpoints (private DNS enabled, eliminating NAT for image pulls entirely).

VPC layout — public subnets (ALB + Bastion EC2), private subnets (EKS pods, RDS, ElastiCache), NAT gateways per AZ, VPC endpoints for S3 and ECR

DNS and TLS

Route53 zones are managed at an account level and referenced via Terraform remote state in environment configs. Each environment creates ALIAS records pointing to its ALB (evaluate-target-health enabled for failover), with ACM certificates provisioned per environment. The checkout platform runs dual-stack (IPv4 + IPv6) ALBs with HTTP-to-HTTPS redirect on port 80.

EKS Platform — Kubernetes Orchestration

The Microservice microservice platform runs on EKS v1.32. Two clusters are provisioned: infra-stage (handles both dev and staging workloads) and infra-prod. Each cluster has managed node groups on t2.large instances with autoscaling (min 2, max 10, desired 2 per group). The EBS CSI driver addon is installed via Terraform for persistent volume support.

Service routing is handled by Traefik IngressRoute CRDs. Kubernetes manifests for each service live in the deploy/ directory, namespaced by service and environment. Services deployed to the platform include: payflow, brandkit, prospector, listing-sync-service, billing-sub, microfund, and standalone.

EKS cluster — Traefik IngressRoute dispatching to service namespaces, SOPS-encrypted secrets per namespace, OIDC-authenticated GitOps pipeline with ECR image pulls

ECS Fargate — Checkout Platform

The Saleor e-commerce checkout stack runs on ECS Fargate — no EC2 nodes to manage, no AMI patching, and precise per-task CPU/memory billing. The platform runs four primary service groups:

CloudFront CDN — Cache Behavior Architecture

Two CloudFront distributions per environment (Saleor + Storefront) sit in front of the ALBs and S3 origins. The cache behavior rules are the most critical part of the CDN config — different paths have radically different caching requirements and the wrong default would either serve stale API responses or miss static asset caching entirely.

CloudFront cache behavior routing — per-path policies, S3 static/media origins with OAC, ALB API origin with caching disabled for GraphQL and JWKS

S3 origin access is enforced with Origin Access Control (OAC) using SigV4 signing, replacing the legacy OAI pattern. Bucket policies reject all direct S3 requests and only allow the CloudFront service principal. TLS minimum: TLSv1.2_2021. HTTP versions: HTTP/2 and HTTP/3.

Data Layer

PostgreSQL 16 runs on RDS with parameter groups that enable query logging and set max_connections = 1000. ElastiCache Redis serves multiple logical databases per cluster: DBs 0–5 are partitioned across Saleor cache, Celery broker, FundGate, and Storefront to avoid key namespace collisions while sharing a single node in staging. The EKS platform uses Redis 6.x; the ECS checkout platform uses Redis 7.1 with dual-stack networking. RabbitMQ (AWS MQ, mq.m7g.medium) handles async messaging for event-driven services.

Bastion Host Architecture

Private cluster resources — RDS, Redis, EKS API, RabbitMQ — are not reachable from the public internet. The access pattern uses a bastion host in each environment's public subnet as the sole ingress point. There are two usage modes depending on whether you need full network routing or just proxy access:

Bastion access — sshuttle routing 10.0.0.0/8 through the EC2 bastion for transparent VPC access (top), and SOCKS5 proxy mode for kubectl-only traffic (bottom)

SOPS + KMS Encrypted Secrets

All Kubernetes secrets — database DSNs, API keys, payment credentials, JWT secrets — are stored as SOPS-encrypted ConfigMaps in Git. A customer-managed KMS key provisioned by Terraform handles encryption, with grants managed via IAM. The GitHub Actions deploy workflow decrypts manifests at deploy time using the KMS key vended via OIDC — no plaintext secrets ever appear in the repo or CI logs. The secrets Terraform module provisions Secrets Manager secrets for ECS workloads using the same IAM-controlled access pattern.

GitHub Actions OIDC — Keyless CI/CD

There are no long-lived AWS access keys in GitHub Actions. The github-oidc Terraform module provisions an AWS IAM OIDC identity provider bound to token.actions.githubusercontent.com and creates a federated IAM role that GitHub Actions can assume for specific repositories (acme-platform/*). The role has least-privilege policies: ECR describe/push, EKS describe, KMS decrypt for SOPS. Credentials are valid only for the duration of the workflow run and are scoped to the specific repo and branch.

EKS RBAC — aws-auth ConfigMap

Kubernetes RBAC is managed via the aws-auth ConfigMap, also version-controlled in the repo. Ten IAM users are mapped to the system:masters group, granting cluster-admin access. Node roles are mapped to system:bootstrappers and system:nodes for kubelet registration. Any RBAC change goes through code review — there is no ad-hoc kubectl edit configmap aws-auth pattern in production.

GitOps Deployment Pipeline

The deployment model is declarative and Git-driven. Kubernetes manifests live in deploy/<service>/<env>/ with a standard structure: namespace.yaml, deployment.yaml, service.yaml, env-config.sops.yaml. On merge to main, GitHub Actions runs kubectl apply against the target cluster — decrypting SOPS secrets at runtime using the OIDC-vended KMS key. There is no manual kubectl apply in the deployment lifecycle.

GitOps pipeline — git push triggers Docker Buildx → ECR push in parallel with SOPS KMS decryption, both feeding into EKS kubectl apply and ECS update-service with zero-downtime rolling update

Terraform State and Environment Promotion

Terraform state is stored in S3 (terraform-state-platform bucket, us-east-1) with environment-isolated key prefixes. Each environment (infra-stage/, infra-prod/, dev, stage, prod checkout) has its own state file, preventing cross-environment blast radius from a failed apply. Remote state outputs are consumed across configurations using terraform_remote_state data sources — for example, the checkout environment reads the Route53 zone ID and ACM certificate ARN from the account-level state without duplicating the resource.

What I Would Do Differently

The Terraform state backend has no explicit DynamoDB locking table, which means concurrent terraform apply runs are technically possible. In practice, the team was small enough that this was managed by convention, but at any reasonable team size a DynamoDB lock table should be standard.

Redis logical database partitioning (DB 0–5 on a single node) works in staging but is operationally fragile — a cache flush on one DB index can inadvertently affect another app's broker queue. The correct production pattern is separate ElastiCache clusters per application, or at minimum Redis 7 keyspace isolation with ACLs.

The EKS node group uses t2.large instances. Under sustained CPU credit exhaustion (the t2 burstable model), nodes can degrade unpredictably. m5.large or m6i.large instances with consistent CPU delivery would be more appropriate for production Kubernetes worker nodes handling latency-sensitive workloads.