AWS and Kubernetes work I take on.

EKS & Kubernetes Platform Engineering

A multi-tenant EKS platform that one team can operate, instead of a cluster per team that nobody can upgrade.

Most Kubernetes estates I get called into have the same shape: a cluster per team, each on a different version, each with its own hand-rolled ingress and its own secret-management story. Upgrades stall because there are eleven of them. I collapse that into one cluster per region with namespace-level tenant isolation, IRSA scoping each pod's AWS permissions to its own namespace, and network policies that make cross-tenant traffic a deliberate act rather than the default.

Node capacity runs on Karpenter, so nodes are provisioned against real pending pods and consolidated when the load drops, not sized by a guess made at cluster creation. Deployments go through ArgoCD ApplicationSets. After the handover there is no path to change production that is not a Git commit, which is the part that makes the platform survivable when I leave.

Typical engagement is six to twelve weeks, ending with your team running an upgrade themselves while I watch.

What you get

• Terraform and Terragrunt modules for the cluster, node pools, and add-ons
• ArgoCD ApplicationSets plus the repository layout tenants deploy through
• Namespace, IRSA, and network-policy baseline per tenant
• Runbook for cluster upgrades, node rotation, and tenant onboarding

Proof: Enterprise Multi-Region EKS Multi-Tenant Platform and Fintech Buy-Now-Pay-Later AWS Platform

AWS Migration & Modernization

Moving a running business to AWS service by service, with traffic shifting behind DNS rather than a cutover weekend.

A big-bang migration weekend is a bet that nothing you did not know about will surface at 2am. I do not take that bet. Work starts with a dependency map of what actually talks to what, then services move one at a time behind Route 53 weighted records, with the old path kept warm until the new one has held real traffic.

The AWS side is landing zone first: an Organizations structure with Service Control Policies setting each team's ceiling, a Transit Gateway route domain instead of a peering mesh, and centralised logging before the first workload lands. That order matters. Retrofitting account boundaries onto thirty live VPCs costs multiples of what it costs to get them right on day one.

Legacy databases usually decide the schedule. I plan around the replication window rather than pretending it is not there.

What you get

• Dependency map and a per-service migration sequence with rollback points
• Landing zone: Organizations, SCPs, Transit Gateway, centralised logs
• Cutover runbooks with the DNS weights and the abort criteria written down
• Post-migration cost and right-sizing review

Proof: Enterprise Insurance AWS Migration Platform and Multi-Environment Rails AWS Infrastructure Deployment

Terraform & Infrastructure as Code

Every environment generated from the same modules, so staging stops disagreeing with production about settings nobody wrote down.

Config drift is rarely dramatic. It is a security group somebody widened during an incident, a parameter changed in the console, a staging instance two sizes smaller than production. Then a release behaves differently in each and the week goes to finding out why.

I rebuild the estate as Terraform modules with Terragrunt keeping the environment configurations DRY, wire plan-on-pull-request and apply-on-merge through Atlantis or GitHub Actions, and add drift detection that runs on a schedule and opens an issue rather than emailing someone who is on leave. Pre-commit hooks run fmt, tflint, Checkov, and tfsec before anything reaches CI, so the obvious misconfigurations never get as far as review.

Brownfield accounts are the normal case, not the exception. Existing resources get imported into state rather than recreated.

What you get

• Reusable Terraform modules plus the Terragrunt environment hierarchy
• PR-driven plan and apply pipeline with state locking and remote backends
• Static analysis in pre-commit and CI: fmt, tflint, Checkov, tfsec, Trivy
• Scheduled drift detection reporting into your issue tracker

Proof: AWS ECS Fargate Flagsmith Feature Flagging Application Deployment and NodeJS with Magento Container Platform

AWS Security & Compliance Hardening

Getting an AWS estate through PCI-DSS, SOC 2, or a FedRAMP-style review without freezing delivery while you do it.

Audit findings cluster in the same places every time: long-lived IAM users, database passwords in a wiki, encryption enabled on the primary but not the replica, and no answer to who read what. The fix is structural rather than a checklist run the month before the assessment.

I take human credentials out of the path entirely: IRSA and instance roles for workloads, SSO with permission sets for people, a database proxy so no engineer holds a production password. Encryption goes on with KMS keys the customer owns and can rotate. GuardDuty, Security Hub, Config, and CloudTrail feed one account rather than nine, with the noisy rules tuned so alerts still mean something six months later.

The evidence the assessor wants is generated from the environment, not assembled by hand the night before.

What you get

• IAM overhaul: SSO permission sets, IRSA, removal of long-lived keys
• KMS envelope encryption across storage, databases, backups, and snapshots
• GuardDuty, Security Hub, Config, and CloudTrail centralised and tuned
• Control-to-evidence mapping for your framework, generated from the account

Proof: Fintech Buy-Now-Pay-Later AWS Platform and NGO Global Data & Human Rights Platform

Cloud Cost Optimization & FinOps

Finding the spend that buys nothing, then making the savings stick after I am gone.

The first pass is the boring one and it usually pays for the engagement: unattached volumes, idle load balancers, oversized instances running at eight percent CPU, snapshots from a project that ended in 2023, and logs kept in standard storage for seven years because nobody set a lifecycle policy.

The second pass is architectural, and it is where the durable savings are. Karpenter consolidation and Spot for interruptible workloads. Storage tiering with compression on log archives. Scale-to-zero for the environments that only run during working hours. Commitment coverage sized against the floor of your usage rather than its peak, so you are not locked into capacity you stopped needing.

Then it stays fixed: tagging enforced through a tag policy, cost anomaly alerts routed to the team that owns the account, and a per-service spend view that engineers can see without opening a ticket.

What you get

• Costed inventory of waste with the effort and risk of removing each item
• Right-sizing, Spot, and commitment plan with the modelled saving per change
• Tag policy enforcement and per-team cost allocation
• Anomaly alerting and a dashboard your engineers actually get to read

Proof: Magento 2 Search & Analytics Platform and Real-Time Event Loop Platform

How an engagement starts

Send me the shape of the problem and whatever constraints are already fixed: the deadline, the audit, the account structure you cannot change. I will tell you whether I am the right person for it, and if I am not, I will usually know who is. Read-only access to the account before we start saves a week of guessing.