Case Study

Automotive Finance Self-Serve Platform

A 7-service TypeScript microservices platform on ECS Fargate serving a UK-based automotive-finance and vehicle-leasing business. Zero-downtime rolling deployments, OIDC keyless CI/CD, PCI DSS-scoped infrastructure, and Claude AI automated code review as a mandatory PR quality gate on every service.

Production ECS Fargate TypeScript OIDC CI/CD PCI DSS

Project overview

The self-serve platform enables car leasing customers to configure, price, and submit leasing applications without manual agent involvement. The platform consists of seven independent microservices — an API gateway, order service, document service, integration service, sync service, core API, and React frontend — each deployed independently to AWS ECS Fargate.

As sole cloud and DevOps engineer on the engagement, I designed and operate the complete AWS infrastructure, CI/CD pipelines, security controls, and production deployment process for all seven services.

7
Microservices
3
Environments
0
Stored credentials
AI
PR review gate

Problem and constraints

The platform operates in a PCI DSS and ISO 27001 environment, which introduces several hard constraints on how infrastructure is built and operated:

  • No long-lived credentials: Access keys stored in CI/CD systems or developer machines are a compliance and security risk. Every service deployment must use ephemeral, scoped credentials.
  • Audit trail: Every infrastructure change, deployment event, and code review decision must be traceable.
  • Isolation between environments: Staging, release, and production must be isolated — a misconfiguration in one environment must not affect another.
  • Zero-downtime deployments: Customer-facing services cannot tolerate maintenance windows during deployments.
  • Code quality at scale: With seven services and multiple developers, maintaining consistent code quality without a dedicated QA function required systematic tooling.

My contribution

The platform was built by a team of application developers; my role was the AWS infrastructure, CI/CD pipelines, security architecture, and production operations. I also integrate AWS SDK usage directly into application code where service integrations require it, shipping those changes through the same peer-reviewed process as the rest of the codebase.

Specifically: I designed and implemented the ECS Fargate cluster configuration, VPC networking, RDS PostgreSQL setup, ALB routing, IAM roles, OIDC federation, GitHub Actions pipelines, and the Claude AI code review integration across all seven services.

Architecture

ECS Fargate — containerised microservices

Each service runs as an independent ECS Fargate service behind an ALB. Services are isolated by security group — inter-service communication is permitted only on the specific ports and protocols required, with no open ingress from outside the VPC except through the ALB.

Container images are built on every push to the deploy branch, tagged with the Git commit SHA (not latest), pushed to ECR, and the ECS task definition updated to reference the new image tag. This gives every running ECS task a traceable link to its exact source commit.

OIDC keyless CI/CD

All seven services use GitHub Actions OIDC federation to authenticate with AWS. There are no long-lived access keys stored anywhere — in GitHub secrets, developer machines, or .env files.

Each service has a dedicated IAM role with a trust policy scoped to:

  • The specific GitHub repository (not the whole organisation)
  • The specific branch permitted to deploy (typically main or the release branch)
  • Actions limited to what that service's deployment requires (ECR push, ECS update, SSM read)
Security design

A compromised GitHub Actions workflow for service A cannot use service B's deploy role — the OIDC trust condition names the exact repository. The iam:PassRole permission is restricted using iam:PassedToService conditions, preventing role escalation even if a workflow is modified.

Zero-downtime deployment pipeline

Each service deployment follows this sequence:

Step 1
Test gate: pytest suite must pass (with moto-backed AWS mocks for unit isolation). Deployment does not proceed on test failure.
Step 2
Build & push: Docker image built, tagged with commit SHA (:sha-abc1234), and pushed to ECR.
Step 3
Task definition update: New task definition revision registered with the updated ECR image URI.
Step 4
ECS rolling deploy: --force-new-deployment triggers ECS rolling update with minimum healthy percent = 100%.
Step 5
Stability wait: Pipeline polls ECS service events for up to 900 seconds. On failure, the last 15 service events are dumped for diagnosis.
Step 6
Health check: Post-deploy ALB health check confirms the new task is serving traffic before the pipeline completes.

RDS PostgreSQL — Multi-AZ production database

The production RDS instance is configured with Multi-AZ standby, deletion protection enabled, and automated backups with a 7-day retention window. Database credentials are stored in Secrets Manager and injected into ECS task definitions as environment variable references — they are never present in source code or CI/CD logs.

AI code review as a CI gate

Claude AI automated code review is integrated as a mandatory PR check across every service in the platform. A pull request cannot be merged until the AI review has completed and has not identified blocking issues.

The review runs via a dedicated claude-code-review.yml workflow that is present in each of the seven service repositories. It runs in parallel with the standard quality check (TypeScript type checking, ESLint) and the build validation — all three must pass.

This is complementary to, not a replacement for, human code review. The AI review catches common patterns quickly — missing error handling, inconsistent use of existing abstractions, security anti-patterns, and TypeScript type issues not caught by the compiler — freeing human reviewers to focus on architecture and business logic.

Security and compliance

The infrastructure is operated within a PCI DSS and ISO 27001 scope. Key controls include:

  • No long-lived credentials anywhere — OIDC for CI/CD, IAM roles for service-to-service, Secrets Manager for application secrets.
  • Least-privilege IAM roles — each ECS task role permits only the AWS API calls that the service makes.
  • KMS-encrypted SNS alerting — CloudWatch alarms route through a KMS-encrypted SNS topic with aws:SourceAccount conditions preventing confused-deputy attacks.
  • CloudTrail enabled — all API calls across the production account are logged to an S3 bucket with object-lock retention.
  • SSM Parameter Store — non-secret configuration is stored in SSM, keeping it out of source code and enabling auditability of configuration changes.

Outcome and lessons

The platform serves production traffic for a UK automotive-finance business. Seven independent microservices deploy independently with no downtime, no stored credentials, and a code quality gate that catches issues before they reach production.

The most significant operational improvement from this architecture was eliminating access key rotation as a maintenance concern. With OIDC, there are no keys to rotate, no rotation reminders to miss, and no risk of a leaked key persisting in a CI/CD system's secret store after it should have been revoked.

The AI code review gate pays for itself in review cycle time — issues that would typically require a back-and-forth comment thread are caught automatically, and human reviewers arrive at pull requests that have already been filtered for the most common categories of issues.