Amazon EKS Blueprints for CDK

Amazon EKS Blueprints is an Infrastructure as Code (IaC) framework used to compose and manage complete Amazon EKS clusters. It allows you to describe the desired state of your EKS environment—including the control plane, worker nodes, and Kubernetes add-ons—as a blueprint.

Once configured, these blueprints can be used to deploy consistent environments across multiple AWS accounts and Regions using continuous deployment automation. It is designed to bootstrap clusters with both Amazon EKS add-ons and popular open-source software such as:

• Observability: Prometheus, Fluent Bit
• Scaling & Networking: Karpenter, Nginx, Traefik, AWS Load Balancer Controller
• Workload Management: Keda, ArgoCD

It also provides mechanisms to implement security controls for multi-team workload operations within a single cluster.

EKS Capabilities are fully managed cluster features where AWS handles installation, upgrades, scaling, and security patching. This is the AWS-managed equivalent of self-managed addons.

Important: Conflict Prevention The blueprints framework automatically detects conflicts between Capabilities and Addons. If you attempt to add both a capability and its corresponding addon (for example, AckCapability and AckAddOn), the build will fail with a conflict error.

By default, the addon sends both Fluent Bit application logs and Kubernetes metadata to CloudWatch. To reduce log volume and costs, you can:

1. Stop one or both data sources from being sent to CloudWatch.
2. Apply filters to the logs.

For detailed guidance on reducing volume, refer to the Amazon CloudWatch documentation on Reducing log volume from Fluent Bit. You can also inspect the aws-for-fluent-bit chart filter section to find specific ways to apply filters.

The Ingress NGINX Add-on provides the following capabilities:

• Installs the Ingress NGINX controller.
• Integrates with the AWS Load Balancer Controller to leverage a Network Load Balancer (NLB) for the load balancer.
• Integrates with the External DNS add-on for automatic integration with Amazon Route 53.
• Supports configuring TLS termination at the load balancer provisioned by the add-on.
• Supports standard Helm configuration options.

By default, mounted Kubernetes secrets inherit the name of their corresponding AWS Secret or SSM Parameter. If the AWS name contains slashes (/ or \), the CSI Driver replaces them with underscores. To maintain a specific filename when mounting the secret to a pod, use the secretAlias option.

Note: secretAlias is only applicable to secrets that are mounted to a pod. In these scenarios, secretName should match the name of the Secret or Parameter in AWS.

{
    secretProvider: new blueprints.LookupSsmSecretByAttrs('/path/to/my/parameter', 1),
    kubernetesSecret: {
        secretName: 'my_parameter', // Should match the AWS name
        secretAlias: 'my_parameter', // The filename used when mounted in the pod
    }
}

OPA Gatekeeper uses a hierarchical approach to policy enforcement via Kubernetes Custom Resource Definitions (CRDs):

1. Constraint Template: A template that defines the logic for a new type of constraint using the Rego query language. It acts as the blueprint for how a specific policy should be evaluated.
2. Constraint: A specific declaration of a requirement. It uses a ConstraintTemplate to define what must be met. Constraints are evaluated as a logical AND; if any single Constraint is not satisfied, the entire request is rejected.
3. Target: A set of objects (like Pods or Namespaces) that are selected for validation based on a common identification or selection scheme.
4. Enforcement Point: The location where the check happens. In Gatekeeper, this is typically the Kubernetes Admission Controller, which intercepts requests to create, update, or delete objects.

The BedrockTeam is an extension of ApplicationTeam designed to manage the namespace for generative AI workloads. It automates the creation of an IAM Role for Service Accounts (IRSA), which allows pods running in a specific namespace to access Amazon Bedrock services.

Important: BedrockTeam MUST be used in conjunction with the Bedrock Builder.

import * as cdk from 'aws-cdk-lib';
import * as blueprints from '@aws-quickstart/eks-blueprints';

const app = new cdk.App();
      
const bedrockTeamProps: blueprints.BedrockTeamProps = {
  namespace: 'bedrock',
  createNamespace: true,
  serviceAccountName: 'bedrock-service-account',
};

const blueprint = blueprints.EksBlueprint.builder()
  .version("auto")
  .teams(new blueprints.BedrockTeam(bedrockTeamProps))
  .build(app, 'my-stack-name');

Teams define logical groupings of IAM identities and the access permissions they have within your EKS clusters. The framework supports two primary team types:

• ApplicationTeam: Members are granted access to specific Kubernetes namespaces.
• PlatformTeam: Members are granted administrative access to the clusters.

This allows you to manage multi-tenant environments by isolating workloads and administrative duties.