Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Amazon EKS Blueprints Streamline Bootstrapping Kubernetes Clusters

Amazon EKS Blueprints Streamline Bootstrapping Kubernetes Clusters

This item in japanese


AWS has released EKS Blueprints, a collection of infrastructure as code (IaC) modules to simplify configuring and deploying EKS clusters. EKS Blueprints are currently implemented in both HashiCorp Terraform and AWS Cloud Development Kit (CDK). The blueprints have support for a number of open-source add-ons including Prometheus, Nginx, and Argo CD.

The blueprints provide a fully bootstrapped, open-sourced approach to configuring EKS clusters. The bootstrapping takes care of configuring the appropriate IAM policies, roles, and service accounts as needed by the included add-ons. The blueprint can contain configuration for the state of the EKS cluster including the control plane and worker nodes. Once a blueprint is configured it can be used to deploy the same EKS environment across multiple regions or accounts.

EKS Blueprints can be used to configure and manage administrator teams and application teams. Administrator teams are able to access and administrer the cluster while application teams manage workloads running in cluster namespaces. A form of "soft multi-tenancy" can be used to allow multiple teams to run workloads within the same cluster. As described by Kevin Coleman, Apoorva Kulkarni, Mikhail Shapirove, and Vara Bonthu, "soft multi-tenancy leverages native Kubernetes constructs (for example, namespaces, roles, role bindings, and network policies) to create logical separation between tenants."

EKS Blueprints provides two sample Argo CD repositories showing how to manage workload configuration and add-on configuration. The following example shows how to set up an EKS cluster with Argo CD that includes two application resources leveraging the sample repositories:

module "kubernetes-addons" {

  enable_argocd         = true
  argocd_manage_add_ons = true # Indicates that Argo CD is responsible for managing/deploying Add-ons.
  addons = {
    path               = "chart"
    repo_url           = ""
    add_on_application = true
  workloads = {
    path               = "envs/dev"
    repo_url           = ""
    add_on_application = false

EKS Blueprints is able to provision both EKS and self-managed add-ons into an EKS cluster. Amazon EKS add-ons are curated and managed by Amazon. They include the latest security patches and bug fixes and have been validated by Amazon to work with EKS. For cases where an Amazon EKS add-on is available but a self-managed version is already in use, the Amazon version can be installed instead.

The add-on points to an open-source, upstream Helm repository. EKS Blueprints include default IAM roles for service accounts for each add-on that makes requests to the AWS APIs. These defaults can be overridden as needed.

The Amazon EKS managed configuration fields for Amazon EKS add-ons can be updated via the Amazon EKS API. Configuration fields not managed by EKS can be adjusted through the Kubernetes cluster once the add-on starts. These changes will not be overridden by Amazon EKS as they make use of the Kubernetes server-side apply feature. Amazon EKS add-ons can be used with any 1.18 or later Amazon EKS cluster.

The release also includes a number of partner add-ons from companies such as Datadog, HashiCorp, and Snyk. HashiCorp has released a Vault add-on that deploys Vault instances into Kubernetes. This simplifies accessing Vault in EKS by enabling Vault in the workflow as illustrated below:

module "eks_addons" {
 source = ""
 eks_cluster_id = module.eks_blueprints.eks_cluster_id
 enable_vault   = true

EKS Blueprints for both Terraform and CDK are available via GitHub. EKS Blueprints is free to use with costs only being incurred for the deployed resources.

About the Author

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • More complex examples?

    by Nico Coetzee,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great article and I think this will make life a lot easier.

    However, real life is usually a more complex and I was wondering if there are examples for EKS clusters in a private only deployment where you may only have access to a private Git repo (like GitLab) and how you would then go about injecting credentials and certificates after the ArgoCD deployment. Same goes for modifying any manifests to point to a private container image repo (like ECR) for all images. By the way, we have a process for only releasing vetted images into our private repos so no one can really deploy anything with a reference to a public container image.

    These more complex scenarios isn't really explained anywhere and for people like me it means we don't even bother trying since we just don't have the time to figure it out ourselves. We basically have to wait for the stackoverflow Q&A :-)

  • Re: More complex examples?

    by Matthew Campbell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great point Nico, the provided examples often don't cover more complex scenarios such as what you've described. I wasn't able to find any worked examples for GitLab, but ArgoCD is detailed here: I'm not sure how easily that can be adapted to work with GitLab.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p