All work
Case 01·Capgemini·Nov 2021 to Present

Containerizing Sitecore onto AWS, where most deployments don't go

Sitecore workloads are built for Azure by convention. Running one on AWS instead meant no well-trodden path for the container topology, and disaster recovery that could not depend on Azure-native tooling.

Containerized the Sitecore IaaS applications onto AWS EKS behind an ALB, fronted by CloudFront and WAF for caching and edge protection, with CloudWatch for monitoring and alerting. Built a CI/CD pipeline with an AI governance layer that reviews release notes and approves zero-click deployments, backed by automated health checks and rollback, and implemented Velero-based disaster recovery across AWS regions.

Architected and led the migration end to end, including raising the platform gap directly with AWS.

Considered AWS ECS/Fargate as a more fully managed alternative to EKS, but Windows container support was still early-stage industry-wide at the time, and Fargate had no Windows container support at all. EKS also gave finer-grained control over logging, monitoring, alerting, and image customization for the Sitecore deployment that Fargate didn't allow.

~$30,000/month (~20%) in infrastructure savings, and Velero-based disaster recovery across AWS regions with an RTO under 2 hours.

20-40% faster page loads (CloudFront)~$30K/mo (~20%) infrastructure cost cut~60% less deployment support effort~30% faster releasesRTO under 2 hours (cross-region DR)~40% fewer incidents (CloudWatch + autoscaling)Zero-click, AI-governed deployments
A Windows worker node support gap surfaced along the way in EKS/Container Insights. Raised as a feature request, it was implemented and publicly announced by AWS in April 2024.
AWS EKSALBCloudFrontWAFCloudWatchVeleroSitecore XPSitecore XM CloudAI Governance
Release Engineering · AI-governed