Deploy EKS Clusters with CDK Blueprints (2026)

CDK Blueprints let you define your EKS cluster infrastructure as code, but they’re not just glorified CloudFormation templates; they’re opinionated, reusable, and composable stacks that bake in best practices from the start.

Let’s see what a minimal EKS cluster defined with CDK Blueprints looks like:

from aws_cdk import (
    Stack,
    aws_eks as eks,
    aws_iam as iam,
    aws_ec2 as ec2,
)
from constructs import Construct

class MinimalEksClusterStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # Define a VPC (or import an existing one)
        vpc = ec2.Vpc(self, "MyVpc", max_azs=2)

        # Define the EKS cluster
        cluster = eks.Cluster(
            self, "MyEksCluster",
            vpc=vpc,
            version="1.29",  # Specify Kubernetes version
            default_capacity=0, # No managed node groups by default
        )

        # Add a managed node group
        cluster.add_nodegroup_capacity(
            "my-nodegroup",
            instance_types=[ec2.InstanceType("t3.medium")],
            desired_size=2,
        )

        # Output the cluster endpoint
        self.cluster_endpoint = cluster.cluster_endpoint

This code snippet defines a basic EKS cluster. It starts by creating a Virtual Private Cloud (VPC) with two Availability Zones. Then, it instantiates an eks.Cluster resource, specifying the VPC and the desired Kubernetes version (1.29 in this case). default_capacity=0 is crucial here; it tells CDK not to create any default managed node groups, giving us explicit control. Finally, add_nodegroup_capacity provisions a managed node group with t3.medium instances, set to initially have 2 desired nodes. The cluster’s endpoint is then exposed as an output.

CDK Blueprints go further than this by providing pre-built, configurable patterns for common EKS setups. Think of them as higher-level abstractions that encapsulate complex configurations for networking, security, observability, and more. For instance, you might use a blueprint for a secure, production-ready cluster that automatically sets up Istio, Prometheus, and specific IAM roles.

The problem that CDK Blueprints solve is the inherent complexity and repetitive nature of setting up a robust EKS cluster from scratch using raw CloudFormation or even the basic CDK eks.Cluster construct. Manually configuring VPC CNI, IAM roles for service accounts, node group security, Kubernetes version upgrades, and add-on installations (like metrics-server or cert-manager) is tedious, error-prone, and hard to maintain consistently across multiple environments. Blueprints abstract this away, allowing you to define your cluster’s intent (e.g., "I need a production cluster with logging and monitoring") rather than its implementation details.

Internally, these blueprints are still generating CloudFormation resources, but they’re doing so through a structured, composable set of constructs. A blueprint might be composed of multiple CDK stacks: one for the EKS control plane, another for the VPC and networking, a third for IAM roles, and yet another for deploying common Kubernetes add-ons via eks.CfnAddon or Helm charts. When you instantiate a blueprint, it orchestrates the creation and linking of all these underlying resources according to its predefined patterns.

The exact levers you control depend on the specific blueprint library you’re using (e.g., aws-cdk-lib/aws-eks or third-party blueprints). Generally, you configure parameters like Kubernetes version, instance types for node groups, desired scaling parameters (min/max size, desired size), networking CIDRs, and options for enabling specific features like Fargate profiles or custom networking. You can often pass in existing VPCs and subnets if you don’t want the blueprint to manage networking.

One critical aspect often overlooked is how CDK Blueprints manage the lifecycle of Kubernetes add-ons. While the eks.Cluster construct has add_addon for certain core add-ons like vpc-cni or kube-proxy, more advanced blueprints might deploy a wider range of applications (e.g., Istio, cert-manager, external-dns, Prometheus). These are typically deployed using eks.CfnAddon for AWS-managed add-ons or by leveraging the cluster.add_helm_chart method. The blueprint’s power lies in its ability to define which add-ons are installed, their versions, and their configurations, all within the same CDK deployment. This ensures that your Kubernetes environment and its essential tooling are managed consistently alongside your cluster infrastructure.

The next conceptual hurdle you’ll face is managing the lifecycle of applications deployed onto your EKS cluster, which is a separate concern from the cluster infrastructure itself.