Terraform adds EKS to the infrastructure dependency graph

A new managed service creates an awkward interval for infrastructure automation if provisioning support arrives later. The first deployment may require a separate procedure that the eventual configuration then has to absorb. HashiCorp's June 5 announcement avoids that interval for EKS. Terraform's AWS provider supports the service on its launch day, so the cluster can enter the same configuration workflow as its AWS dependencies.

The AWS provider 1.22.0 changelog, also dated June 5, adds both an aws_eks_cluster resource and a data source of the same name. Those are distinct capabilities. A resource manages a cluster's lifecycle, while a data source provides a way to refer to a cluster without declaring ownership of that lifecycle. Day-zero support therefore includes more than a command that submits a creation request.

I value this extension of Terraform's API abstraction because a managed cluster still belongs to an infrastructure system. Its identity and network references need to agree with the rest of the configuration. Keeping those relationships expressible in Terraform reduces the need for a separate provisioning procedure around a newly available service.

A cluster declaration has external prerequisites

The resource documentation shipped in 1.22.0 requires a name, an IAM role ARN, and VPC configuration. This role permits the Kubernetes control plane to call AWS APIs on the user's behalf. Subnet configuration identifies where EKS creates cross-account network interfaces for communication with worker nodes.

The documentation requires subnets in at least two availability zones. Optional security group identifiers apply to those network interfaces. A minimal declaration can use existing infrastructure, provided those external prerequisites already satisfy the EKS requirements.

variable "cluster_role_arn" {}

variable "cluster_subnets" {
  type = "list"
}

resource "aws_eks_cluster" "example" {
  name     = "example"
  role_arn = "${var.cluster_role_arn}"

  vpc_config {
    subnet_ids = ["${var.cluster_subnets}"]
  }
}

This is an excerpt for a configuration supplied with an existing authorized role and suitable subnet IDs. It does not create worker capacity or install an application. The declaration's small size describes the management interface of the cluster resource, not the total amount of infrastructure required to use Kubernetes.

That distinction is useful when reading a launch announcement. A dedicated resource makes the control plane manageable through Terraform. It does not make the responsibilities around network connectivity and client authentication disappear. The resource's inputs identify several of those responsibilities explicitly.

Role existence and role readiness differ

HashiCorp's launch walkthrough creates an IAM role and attaches AmazonEKSClusterPolicy and AmazonEKSServicePolicy. Its cluster declaration uses explicit dependencies on both policy attachments. Merely referring to the role ARN would establish a dependency on the role, but would not express that the attachments must also be complete before cluster creation.

This is a concrete limit of dependencies inferred from attribute references. An identifier can exist before every related permission is in place. If readiness depends on resources not directly referenced by an argument, those resources need their own dependency relationship. The walkthrough's depends_on entries document that relationship in the configuration.

The provider implementation handles a second issue after ordering. Creation retries selected IAM-related errors for up to one minute. The recognized cases include a role reported as missing, an incorrect trusted entity, missing EKS managed policies, and missing required actions in the role policy.

Dependency ordering and these retries solve different problems. Ordering prevents Terraform from knowingly issuing the cluster request before the relevant attachment operations complete. Retrying allows the AWS creation interface time to observe recent IAM changes. A completed dependency in Terraform's graph does not establish immediate visibility through every remote service.

I find this an appropriate division of responsibility. The configuration expresses which operations have to precede cluster creation. The provider handles the specific remote errors it recognizes as temporarily inconsistent. Neither mechanism needs to pretend that distributed API updates become visible everywhere at the same instant.

Creation waits for an active control plane

After AWS accepts cluster creation, the provider records the cluster name as the Terraform identifier and waits for its status to move from creating to active. Both creation and deletion have documented default timeouts of fifteen minutes. The creation request returning successfully is therefore an intermediate result in the resource lifecycle.

The subsequent read stores the endpoint and certificate-authority data, along with the observed Kubernetes version and VPC information. Configuration can expose the endpoint and certificate data through outputs. Those values support client configuration, but a certificate authority authenticates the server and does not, by itself, supply the client's identity.

The launch walkthrough uses an executable client-authentication entry invoking heptio-authenticator-aws. That is a separate concern from the IAM role supplied to the cluster resource. The role authorizes control-plane actions against AWS, while the client configuration determines how a caller authenticates to the Kubernetes API. Their appearance in the same setup does not make them interchangeable.

The initial schema defines what changes mean

The launch implementation marks the cluster name, role ARN, Kubernetes version, and VPC configuration as ForceNew. Changes to these configured fields therefore request replacement through this version of the provider. It has create, read, and delete handlers, with no update handler. This is a significant part of the initial support contract for an operator considering changes after creation.

The optional version argument uses the latest available version when omitted, according to the release's resource documentation. That describes creation-time selection. It should not be read as a promise that this provider can perform later upgrades in place, particularly given the schema's replacement behavior. A configuration review therefore needs to distinguish the version reported after creation from the consequences of changing an explicitly configured version.

The practical gain on launch day is a cluster lifecycle represented in Terraform alongside its dependencies and observable outputs. The exact limits remain in the resource contract. Creation includes IAM readiness handling and a wait for an active control plane, while the initial schema treats changes to its main inputs as replacement operations.