EKS Blueprints: Deployment and Best Practices

EKS Blueprints are a new approach to Kubernetes cluster development released by AWS to simplify how EKS administrators build and deploy cluster infrastructure while following best practices. Blueprints are provided as modules for the Cloud Development Kit (CDK) and Terraform, and they are capable of deploying Kubernetes addons, AWS infrastructure, EKS node groups, observability tools, and other useful resources. The modules enable administrators to quickly assemble building blocks to deploy their clusters and the surrounding infrastructure. 

This article will cover how Blueprints work, how administrators can deploy them, and what best practices they should follow.

Summary of key concepts

What are EKS Blueprints?

EKS Blueprints are predefined templates provided by AWS to help cluster administrators easily set up their cluster infrastructures. A Blueprint defines configurations for resources like the cluster control plane, node groups, networking resources, addons, and third-party project integrations. The goal of the feature is for administrators to have access to a well-tested library of predefined configurations following operational best practices. Blueprints enable administrators to reduce the operational overhead of developing solutions from scratch by leveraging existing templates as building blocks for their infrastructures.

EKS Blueprints are currently provided in two flavors: Terraform and CDK. Both tools offer an approach to deploying cloud resources via infrastructure as code (IaC), a modern approach to deploying resources that involves defining infrastructure requirements in configuration files. This enables developers to leverage version control for tracking configuration changes over time and allows infrastructure to be deployed in a consistent and deterministic manner.

Terraform and CDK are two IaC tools that allow developers to define their infrastructure configurations and deploy these resources to a cloud environment. EKS Blueprints are available as modules for Terraform and CDK, allowing cluster administrators to quickly develop their EKS cluster infrastructure without manually writing excessive code to define their resources.

An additional benefit of EKS Blueprints is that the default configurations will follow operational best practices. AWS configures security, high-availability, and scalability defaults to follow best practice recommendations, which helps ensure that administrators are building their clusters with appropriate settings.

For example, there is an EKS Blueprint for the AWS Load Balancer Controller. The Controller provisions Load Balancer resources for EKS clusters. Administrators need to take additional steps to enable an IAM Role specific to the Controller’s pod when installed manually. Without this additional step, the Controller pod will instead use the worker node’s IAM Role, which is a security risk: The node IAM Role will have excessive permissions, so it should not be utilized by pods.

Machine learning for Kubernetes sizing

Learn More

	Visualize Utilization Metrics	Set Resource Requests & Limits	Set Requests & Limits with Machine Learning	Identify mis-sized containers at a glance & automate resizing	Get Optimal Node Configuration Recommendations
Kubernetes
Kubernetes + Densify

The EKS Blueprint for the Load Balancer Controller will automate the Controller installation and perform the entire IAM Role setup. The pod-specific IAM Roles are attached with the IAM Roles for Service Accounts (IRSA) feature. The EKS Blueprint will automate the Controller’s configuration, including creating the IAM Role and IAM Policy and modifying the pod’s Annotations to enable IRSA.

import 'source-map-support/register';
import * as cdk from 'aws-cdk-lib';
import * as blueprints from '@aws-quickstart/eks-blueprints';
const app = new cdk.App();
const addOn = new blueprints.addons.AwsLoadBalancerControllerAddOn();
const blueprint = blueprints.EksBlueprint.builder()
   .addOns(addOn)
   .build(app, 'my-stack-name');

This Blueprint automation for the Load Balancer Controller will ensure that security best practices are being followed without any additional intervention by the administrator.

Overall, administrators benefit from reduced operational head and improving production readiness by leveraging EKS Blueprints to set up their EKS environments.

How are EKS Blueprints deployed?

EKS Blueprints can be deployed via either Terraform or CDK. Typically, administrators should select the tool that is suitable for managing all of their AWS infrastructure. This will ensure that a single IaC tool is used for both general AWS infrastructure and the EKS cluster resources.

Gather requirements

Administrators can begin planning for EKS Blueprints integration by determining their infrastructure requirements. Planning the desired EKS cluster architecture will help inform decisions about what EKS Blueprints will be helpful for fulfilling requirements. Details about the cluster’s desired functionality will need to be gathered, including:

• Workload requirements: Administrators need to understand what workloads will be deployed on their clusters. This will provide insight into security, scaling, availability, and cost needs and will inform the administrator’s cluster design decisions. Every operational aspect of the cluster will be impacted by what workloads are being deployed, and many EKS Blueprints can be leveraged for various operational requirements.
• Observability: Determining the observability approach is an essential aspect of designing any Kubernetes cluster. Administrators will benefit from planning what tools will be implemented for collecting observability data, like metrics, logs, and traces, to manage their clusters effectively. These design choices will impact which EKS Blueprints may be suitable for integration, such as Datadog, CloudWatch, New Relic, Dynatrace, Istio, Prometheus, and Grafana.
• Scalability: Cluster administrators can select from various scaling approaches for their EKS clusters. They may choose autoscaling tools like the Cluster Autoscaler or fixed-size clusters. Determining the suitable options based on workload scaling requirements can help determine whether EKS Blueprints for tools like the Cluster Autoscaler should be leveraged.
• High availability: Availability requirements determine what level of software and hardware failures are considered acceptable for a given environment. Deciding on availability requirements will impact Blueprint configuration details, like the replica count of addons and node group topology.
• External resource dependencies: It’s common for workloads on EKS clusters to utilize other AWS infrastructure like EBS and EFS volumes, load balancers, Route53, and CloudWatch. Blueprints are available to enable workloads to leverage external AWS resources, so gathering requirements on what resources are required will help inform Blueprint configuration decisions. For example, there is an EKS Blueprint for installing the EBS CSI addon, allowing workloads in the EKS cluster to provision EBS volumes via Persistent Volume objects.

In summary, administrators will benefit from carefully gathering requirements to effectively plan their EKS cluster setups and determine what Blueprints can be leveraged to simplify operational overhead.

Explore EKS Blueprint resources

Once the basic requirements have been gathered to determine the cluster’s design and operational needs, administrators can begin exploring what EKS Blueprints are available to fulfill their design requirements. This exploration will involve evaluating the CDK or Terraform Blueprint libraries available for use and what configuration parameters they allow.

The latter aspect is important for administrators to evaluate. When implementing Blueprints, some parameters will not be configurable, which will impose limitations on administrators. The administrator should consider which parameters are configurable and what parameters are restricted to determine if the Blueprint will still fit the requirements. Administrators who require maximum configuration flexibility may need to avoid using Blueprints and instead manually deploy their solutions. The benefit of Blueprints is a preconfigured packaged solution, but this also becomes a limitation on flexibility, depending on the use case.

There are a few key locations that administrators should research to gather information on implementing EKS Blueprints. Analyzing the available libraries and associated documentation will help administrators understand the Blueprint’s capabilities and how to begin testing them with their EKS clusters.

Quickstarts 

These resources contain tutorials for administrators to get started with deploying EKS Blueprints. The tutorials explain setting up a local development environment and deploying sample applications. Administrators should begin with these resources to gain familiarity with how Blueprints are used.

• Terraform: aws-ia.github.io/terraform-aws-eks-blueprints/getting-started/
• CDK: aws-quickstart.github.io/cdk-eks-blueprints/

GitHub

These repositories contain useful resources like code samples for administrators to leverage. The repositories are frequently updated with new resources, and administrators should keep an eye on newly released features that they can leverage in their own environments.

• Terraform: github.com/aws-ia/terraform-aws-eks-blueprints
• CDK: github.com/aws-quickstart/cdk-eks-blueprints

Testing and validation

Administrators should validate EKS Blueprint functionality in a development environment to gather information on the Blueprint’s usefulness. Testing Blueprints should be done in non-production environments due to the potential impact of the various AWS infrastructure changes being applied. 

Validation may include answering these questions:

• Are Blueprints available that meet the architecture requirements for the desired EKS cluster infrastructure?
• Are the selected Blueprints flexible enough in terms of the available configuration options to fit the desired use case?
• Is the development and deployment workflow for the Blueprints an improvement on the previous approaches used by the administrator?
• If there are limitations for the Blueprints—such as a particular addon not being available in the library—can the administrator work around the issue?

There are Blueprints available for Kubernetes addons as well as for AWS infrastructure. Testing both of these would be ideal for gathering the most data. Since every EKS cluster will require some node group infrastructure, trying to deploy a managed node group Blueprint would be a reasonable starting point to begin testing Blueprint capabilities:

const props: MngClusterProviderProps = {
    minSize: 1,
    maxSize: 10,
    instanceTypes: [new InstanceType('m5.large')],
    amiType: NodegroupAmiType.AL2_X86_64,
    nodeGroupCapacityType: CapacityType.ON_DEMAND,
    version: KubernetesVersion.V1_25,
    amiReleaseVersion: "1.25.7-20230509"
}
const clusterProvider = new blueprints.MngClusterProvider(props);
new blueprints.EksBlueprint(scope, { id: 'blueprint', [], [], clusterProvider });

Testing EKS Blueprints in a development environment will help administrators gain confidence about whether the libraries are helping their EKS journeys, meeting their requirements, and are a suitable option for long-term adoption. It is essential for thorough testing to be completed to ensure that administrators can make the right design decisions for their EKS environments.

How can GitOps be implemented with EKS Blueprints?

GitOps is a deployment model enabling users to define their Kubernetes workloads and infrastructure requirements in a version-controlled repository. It involves configuring a Kubernetes Controller like ArgoCD to watch for changes to the repository and automatically deploy manifests to the Kubernetes cluster. The benefit of this model is it allows both infrastructure and application workloads to be stored in a Git repository as a source of truth. Users can simply push new manifests to the repository and expect them to be automatically deployed to the cluster. This model goes beyond traditional CI/CD pipelines by leveraging Kubernetes principles like “Desired State,” “Continuous Reconciliation,” and “Pull-Based Deployment.”

EKS Blueprints can provide out-of-the-box GitOps functionality via the ArgoCD Blueprint. The EKS Blueprint for ArgoCD can install the ArgoCD Controller into the target EKS cluster during cluster creation and configure ArgoCD to point to a specified Git repository containing the Kubernetes manifests (YAML files, Helm Charts, Kustomize files, etc.). This functionality allows administrators to store Kubernetes resources in a Git repository and let ArgoCD synchronize and deploy the manifests into the cluster.

Here is a CDK Blueprint example demonstrating how ArgoCD integration can be added to an EKS cluster:

import 'source-map-support/register';
import * as cdk from 'aws-cdk-lib';
import * as blueprints from '@aws-quickstart/eks-blueprints';
                        
const app = new cdk.App();
                        
const addOn = new blueprints.addons.ArgoCDAddOn();
                        
const blueprint = blueprints.EksBlueprint.builder()
    .addOns(addOn)
    .build(app, 'my-stack-name');

The example can be extended to change the default admin password and point ArgoCD to an external Git repository to begin bootstrapping the cluster with additional Kubernetes workloads. When an administrator or developer commits new workload objects to the Git repository, ArgoCD will automatically download and deploy the Kubernetes objects into the EKS cluster without any additional steps required by the user.

EKS Blueprints best practices

Here are the key best practices to follow when implementing EKS Blueprints:

• Ensure that there is a clear plan for the desired EKS cluster architecture. It’s important to have a plan to help inform decisions about what Blueprints may be helpful and how the desired use case can be fulfilled.
• Validate the selected EKS Blueprints in a development environment to ensure that they can meet use case requirements.
• Check available configuration options for the selected Blueprints. Not all configuration options will be customizable, so administrators must validate if the chosen Blueprint is flexible enough for the desired use case.
• Use GitOps to deploy and bootstrap the EKS cluster. Leveraging the ArgoCD Blueprint will enable administrators to quickly bootstrap their clusters with Kubernetes workloads stored in a Git repository.
• Ensure that the default Blueprint settings follow your organization’s security requirements. Administrators should validate the default resource configuration values supplied with their selected EKS Blueprints to ensure that they are set appropriately. For example, deploying ArgoCD will cause a default “admin” user to be created with full administrative access to ArgoCD. A safer approach may be to create separate users in ArgoCD with more limited permissions to reduce the impact of a compromised user. Blueprints can also create IAM Roles and IAM Policies, which are sensitive resources. Administrators will benefit from verifying that all IAM changes comply with internal security requirements.
• Enable observability tools, like CloudWatch, Prometheus, Grafana, etc. A high-quality monitoring setup will be helpful for administrators to detect and action problems with the infrastructure. Monitoring the impact of Blueprints deployments will be easier when observability tools are enabled and will allow administrators to gain insight into the behavior and performance of their EKS clusters. Blueprints are available for deploying observability tools that can automatically help bootstrap clusters with relevant tooling.
• Be mindful of the limitations of EKS Blueprints based on thorough testing and validation. They will not cover every aspect of a cluster’s functionality, and some manual operational practices will still be necessary. For example, while node groups can be deployed via Blueprints, rightsizing the node groups with the appropriate instance types cannot be done with Blueprints. Using solutions from Densify will fulfill this use case by enabling automation for rightsizing node group instance types. Visit this page to learn more.

Conclusion

EKS Blueprints are a useful tool for administrators implementing Terraform or CDK to deploy their EKS cluster infrastructure. Blueprints enable administrators to quickly deploy prepackaged infrastructure components like node groups and Kubernetes addons using only a few lines of code, with best practices enabled by default.

Leveraging Blueprints to accelerate infrastructure development can reduce operational overhead and increase operational readiness. Administrators will still need to test and validate that the selected Blueprints provide sufficient functionality and flexibility to meet their use case requirements. When using IaC and GitOps, testing Blueprints in a development environment is relatively straightforward and will provide insight into the environment’s operational readiness. Overall, Blueprints are a worthwhile feature for EKS administrators to evaluate as part of their infrastructure development workflows.