EKS Blueprints: Deployment and Best Practices

EKS Best Practices
calendar August 18, 2023

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? Blueprints are preconfigured templates for CDK or Terraform to deploy components for an
EKS cluster. Their purpose is to provide
building blocks for cluster administrators to quickly develop EKS clusters and the
supporting infrastructure. 
How are EKS Blueprints deployed? EKS Blueprints are deployed via either the Terraform or CDK tools. The Blueprint
libraries are imported as modules imported into these IaC tools.
Gathering requirements Administrators need to determine their EKS infrastructure requirements to plan which
Blueprints could fulfill their use cases. Having a clear understanding of the target
architecture is important for effective planning.
Exploring EKS Blueprint resources There are several key resources for administrators to investigate, containing Blueprint
libraries, examples, and tutorials. Researching these resources will help administrators
understand what Blueprints are available and how they can be implemented.
Testing and validation Testing Blueprints in a development environment will enable administrators to validate
their Blueprints’ functionality and determine if they are meeting use case requirements.
How can GitOps be implemented with EKS Blueprints? The EKS Blueprint from ArgoCD
enables administrators to automatically bootstrap EKS clusters with workloads stored in
Git repositories. The modern GitOps model allows faster cluster setup and reduced
operational overhead.
EKS Blueprints best practices? To leverage Blueprints effectively, administrators will need to effectively plan their
architecture, determine appropriate Blueprints to implement, test their functionality,
validate their flexibility, and ensure that security best practices are being followed.
Conclusion EKS Blueprints can be a useful tool for administrators to quickly build EKS cluster
infrastructure via IaC and GitOps. Administrators can benefit from reduced operational
overhead and faster setup times. 

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.

Spend less time optimizing Kubernetes Resources. Rely on AI-powered Kubex - an automated Kubernetes optimization platform

Free 60-day Trial

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.

Spend less time optimizing Kubernetes Resources. Rely on AI-powered Kubex - an automated Kubernetes optimization platform

Free 60-day Trial

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.

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.

Spend less time optimizing Kubernetes Resources. Rely on AI-powered Kubex - an automated Kubernetes optimization platform

Free 60-day Trial

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.

Spend less time optimizing Kubernetes Resources. Rely on AI-powered Kubex - an automated Kubernetes optimization platform

Free 60-day Trial

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.

$100

Amazon Gift Card for Kubex Demo

If you are involved in a K8s environment with 500 or more containers, spend 20 minutes seeing a demo and we will send you $100.

Book it