Whats the difference between the EKS provider and the EKS module?

We’re wondering which is the best choice. What are the pros and cons of each of them? Does one of them use the other, or are they independant.


Thanks alot for your help,

Hi @ivans3,

In Terraform, a provider is a plugin (an executable program) that maps from Terraform’s plan/apply lifecycle to real API requests to some specific backend API. The AWS provider, then, is the adapter layer that allows Terraform to make requests to the various AWS service endpoints. Without the AWS provider Terraform cannot interact with AWS at all.

Terraform modules are a way to factor out parts of your Terraform code into reusable portions that can be called from many different configurations. A good Terraform module will generally introduce an additional level of abstraction over what a provider offers in order to more easily meet a common use-case.

I’m not personally familiar with that EKS module, but from a quick look at its documentation I think its purpose is to declare not only the EKS cluster itself but also various supporting infrastructure needed for a working EKS deployment, such as an EC2 autoscaling group for the worker nodes, VPC security group rules to allow the nodes and the cluster to communicate, etc.

Internally the EKS module uses the AWS provider. In the Terraform module registry you can see all of the resource types used by the EKS module; the ones whose names start with aws_ are from the AWS provider and correspond to object types in the AWS management APIs.

The Terraform registry entry for the AWS provider includes a link to its documentation, where you should be able to find details about all of the resource types that the EKS module is using. You’ll see there that the AWS provider resource types tend to be at a lower level of abstraction, mapping as directly as possible to the underlying AWS APIs and thus ensuring that all of the service details are exposed for your use.

The EKS module, on the other hand, is presumably designed to describe a common deployment pattern for EKS that might not use all of the detailed features of the system but in return allows you to write a smaller configuration yourself, as long as you agree with the design tradeoffs made by the module. If you have needs that the module doesn’t meet, you can either fork the existing module or write your own, while still using the official AWS provider as the final interface between Terraform and AWS.

Thanks apparentlymart for the detailed Answer. We Appreciate it!