AWS Architecture Blog

LeasePlan Sitecore Implementation with Amazon EKS

LeasePlan is one of the world’s leading car leasing companies, with 1.9 million vehicles in more than 30 countries. They manage the entire lifecycle of their fleet, from purchase and maintenance to the sale of returned lease cars.

Sitecore is a leading content management system in the enterprise market. It allows organizations to combine content authoring capabilities for enterprise-ready websites with marketing automation tools to develop and deliver a personalized web user experience.

Sitecore is critical to the LeasePlan ecosystem because it provides content for most of their websites. To serve LeasePlan’s millions of visitors per month, the Sitecore deployment setup must be robust, scalable, and highly available.

Sitecore on AWS

AWS, in collaboration with Sitecore, created Sitecore XP 9.3 on AWS. This Quick Start is intended for organizations that want to deploy a Sitecore Experience Platform (XP) 9.3 architecture on the AWS Cloud.

Sitecore Experience Platform (XP) 9.3 architecture

Figure 1. Sitecore Experience Platform (XP) 9.3 architecture

This Quick Start deploys a multirole architecture into individual AWS Auto Scaling groups to ensure recoverability when an instance fails. Database services are provided by Microsoft SQL Server through Amazon Relational Database Service (Amazon RDS), and caching is managed by Redis on Amazon ElastiCache. To control access, this deployment uses AWS Certificate Manager (ACM) and AWS Secrets Manager.

The AWS Quick Start for Sitecore 9.3 is a reference architecture. It can be customized by downloading the templates from the official Quick Start repository. This allows you to add/remove Sitecore application roles and add or change opt-in modules.

Containerizing Sitecore

Moving your solution to a containerized development workflow needs a careful analysis because it requires time, knowledge, and a shift in mindset. Before running Sitecore on infrastructure as a service (IaaS) setup on Amazon Elastic Compute Cloud (Amazon EC2) instances, consider the following:

  • Maintaining and scaling virtual machines requires substantial manual work. However, with containers, you will have this process automated and ensure the consistency of your environments. You can rebuild base Docker images to fetch the latest Windows security patches, so deploying them is a virtually seamless experience.
  • Setting up new environments (including local development environments) takes time. However, after moving to containerized deployments, onboarding a new developer and setting up their local development environment takes minimal effort.
  • Replicating a Production-like environment on local development machines for testing is difficult. However, with Docker, you can run the same version of the Production environment, including its dependencies, on a local machine to reproduce bugs.
  • Because a single virtual machine can host multiple Docker containers, resource utilization could be maximized with containerized environments.
  • Sitecore itself is moving to containers. Thus, containers are the recommended approach for deploying Sitecore.

Moving to containers also requires work and expertise, which requires you to understand and acknowledge the following:

  • You need an established in-house DevOps culture and the required expertise in the company to deploy and maintain Kubernetes workloads.
  • The learning curve for developers might be steep, so spend time on education early, because the development workflow will be heavily affected.
  • You might require a Sitecore upgrade, which, depending on your solution, might be a project on its own. For official container support, you need Sitecore 9.3; however, having Sitecore 10 is best because it provides official base Docker images, deployment templates, and guidelines.

LeasePlan’s Sitecore Architecture

Sitecore offers many ways to architect and implement your solution. You have a wide choice of presentation technologies: Sitecore MVC, Sitecore Experience Accelerator, or, for a headless approach, Sitecore JSS (JavaScript Services) or ASP.NET Core Rendering SDK.

By following a headless Sitecore architecture approach, LeasePlan could decouple content from presentation and business logic and parallelize front end and backend development. Business logic, content (Sitecore APIs), and presentation (React Frontend) are all decoupled and implemented by different teams independently.

LeasePlan has implemented a Sitecore XM topology with headless architecture by using Sitecore JSS acting as server-side rendering proxy with Node.js.

Headless architecture by using Sitecore JSS

Figure 2. LeasePlan Sitecore headless architecture

LeasePlan’s technology stack is composed as follows:

  • Amazon CloudFront quickly delivers content worldwide.
  • Amazon Elastic Kubernetes Service (Amazon EKS) hosts Sitecore 9.3 content delivery/management servers. Amazon EKS allows LeasePlan to automatically scale out the content delivery servers based on CPU/RAM load.
  • LeasePlan uses a publishing service hosted on Amazon EKS to publish content for 30+ countries.
  • LeasePlan uses Amazon RDS to host the Sitecore SQL Server databases with the content structure and data by using a fully managed service.
  • A microservices API layer is hosted on Amazon EKS. It handles business logic (such as car catalog APIs), decoupling them from Sitecore.
  • A front-end application layer serves as an orchestrator between Sitecore API operations and business logic API operations. It retrieves and aggregates required data to render the website.
  • JSS (React) is used for headless JSS topology with server-side rendering proxy. To enable Sitecore Experience Editing capabilities, LeasePlan uses a remote rendering host (or HTTP rendering engine), which performs server-side rendering for the Sitecore editor.

Figure 3. Sitecore remote rendering architecture

Figure 3. Sitecore remote rendering architecture

  • To facilitate website search, LeasePlan runs a Solr Cloud deployed on Amazon EKS.
  • Amazon Simple Storage Service (Amazon S3) stores static assets (such as distributions of JSS builds) behind the CloudFront distribution.

For building Docker containers, LeasePlan uses Sitecore community Docker images as a base. On top of these base images, they build application-specific images and push them to Amazon Elastic Container Registry (Amazon ECR). This process (including infrastructure provisioning) is fully automated. LeasePlan uses Ansible as a base for AWS Infrastructure as Code deployments, and they use GitLab CI as their build/deployment tool.

Figure 4. GitLab build/deployment tool

Figure 4. DevOps setup with GitLab CI and Amazon ECR

Operating any application at scale presents challenges. Implementing a centralized logging and application monitoring solution allows you to monitor your applications, detect incidents, and find performance bottlenecks. At LeasePlan, to achieve best performance and avoid network latency, all Sitecore logs and metrics are sent first to a Datadog sidecar service (agent) deployed within their Kubernetes cluster.

LeasePlan has set up distributed tracing across all their components: browser client application, Node.js server, Sitecore, and .NET backends and data storages. All AWS metrics are sent to the monitoring tool, which allows them to monitor and observe anomalies.

Best Practices

  1. Optimize Sitecore startup times and Docker image size. When scaling out pods, Kubernetes might take a while to pull your images from a registry and warm up Sitecore.
  2. Use CloudFront as the content delivery network for your Sitecore media library assets to offload Sitecore servers and improve performance.
  3. You can never have too much logging and tracing, especially in distributed environments. Capturing and correlating all the information helps you monitor and troubleshoot issues. Set up distributed tracing, and invest into a centralized logging and monitoring solution.
  4. Move your environment-specific configuration to environment variables. Your Docker images must be environment agnostic. To enable/disable certain features on specific environments (for example, Sitecore Live Mode and extended logging), use feature toggles configurable via environment variables.
  5. Configure liveness and readiness probes for your pods. Sitecore provides out-of-the-box /healthz/live and /healthz/ready endpoints. Make sure the readiness probe on your Sitecore Content Delivery pods does not depend on non-essential external resources (such as Solr). If those external services become unavailable, then your readiness endpoint would fail and Kubernetes will tear down/restart all the pods.


Deploying Sitecore on Kubernetes has many benefits and is officially supported and encouraged by Sitecore. Amazon EKS perfectly fits this purpose while providing all required infrastructure.

At LeasePlan, they have a dedicated DevOps team of engineers who are experienced with Kubernetes. This allows them to smoothly migrate from EC2 instances to containerized deployments in AWS. This way LeasePlan has become one of the first companies to host Sitecore on AWS using Amazon EKS.

Borja Prado Miguelez

Borja Prado Miguelez

Borja is a Senior Specialist Solutions Architect for Microsoft workloads at Amazon Web Services. He is passionate about web architectures and application modernization, helping customers to build scalable solutions with .NET and migrate their Windows workloads to AWS.

Vitalii Tylyk

Vitalii Tylyk

Vitalii is a Lead .NET developer and architect who is passionate about distributed application architecture and crafting high quality software for the business. Currently he works as a Sitecore Chapter Lead at LeasePlan and is awarded as multiple time Sitecore MVP for his contributions to the Sitecore community. Outside work, you will find Vitalii traveling the world or on a football field.