eks-workshop-v2: hands-on Amazon EKS labs you can run in your own account

What the workshop repository is for and who it is aimed at

The repository holds two things at once: the source for the workshop website and the infrastructure-as-code that sets up a lab environment in a reader's own AWS account. The site is at eksworkshop.com, and the preview build of the `main` branch is published separately at preview.eksworkshop.com.

The stated goal is to help users learn about Amazon EKS features and their integrations with popular open-source projects. The content is abstracted into high-level learning modules, with Networking, Security and DevOps Automation named explicitly, and those modules are then split into standalone labs that each focus on a particular feature, tool or use case.

That structure sets the audience. The workshop says it covers some Kubernetes basics, but its stated priority is familiarising the user with concepts directly related to Amazon EKS. A reader who wants to learn Kubernetes from first principles will find the EKS-specific framing narrow, while an engineer who already runs Kubernetes and wants to see how EKS wiring differs will find the labs directly on point. The repository is published under the aws-samples organisation, licensed Apache-2.0, with a NOTICE file and a CODE_OF_CONDUCT.md at the top level.

One retail sample application across every module

The workshop states four tenets, and the second of them does most of the work for a learner. Every module uses the same sample retail store application, the AWS Containers Retail Sample, so a reader who has deployed it in the Networking module recognises the workload in the Security module instead of learning a new application each time.

The other tenets are modular, continuous testing, and EKS focus. Modular means the standalone modules can be completed individually, so you can start at any module and switch between them. The EKS focus explains why some generic Kubernetes content is present but limited.

The continuous testing tenet is the one that distinguishes this from a static tutorial. The repository states that the infrastructure provisioning and CLI steps in the workshop are tested automatically, which is what allows the content to track the latest versions of Amazon EKS. In practice that testing is visible in the repository layout: there are `testing/`, `hack/`, `cluster/`, `lab/` and `manifests/` directories at the top level, and the `lab/` and `manifests/` trees are where per-module content and its configuration live.

One consequence worth naming: the same structure that keeps the sample app consistent also means the workshop is a single coherent course of a particular shape. It is not a grab bag of independent recipes you can lift one at a time.

How a lab becomes infrastructure: website, terraform and the learner environment

The workshop content is a Docusaurus site, and all of it is written in Markdown under the `website` directory. The infrastructure that the content depends on, meaning EKS cluster configuration, VPC networking and components such as Helm charts, is defined as Terraform configuration in the `terraform` directory.

The Makefile shows that the terraform root layout is unusual. There is no root `terraform/` directory, as its comment states. Cluster level configuration lives in `cluster/terraform`, and per-module lab configuration lives under `manifests/`, in a `.workshop/terraform` directory inside each module. The variable that drives that discovery is a plain list.

terraform_dirs=cluster/terraform manifests

That detail matters if you write your own automation around the repository, because a glob over `terraform` at the root finds nothing.

The third piece is the learner environment. Tools such as `kubectl` must be installed before a participant can complete the labs, and the `environment` directory holds scripts and other artifacts that set this up automatically, including scripts to install all prerequisite tools and container images that recreate a consistent environment. The point of the container images is reproducibility of the client side, so a lab does not fail because of a version mismatch in the participant's own tooling.

Building and previewing the workshop site locally

The site is a Yarn monorepo. The root `package.json` declares two workspaces, the website itself and a releaser package, and pins the package manager.

  "workspaces": [
    "website",
    "releaser"
  ],

  "packageManager": "[email protected]"

The scripts in the root manifest set an environment variable on every site command, so the local build matches the published one.

  "scripts": {
    "build": "LAB_TIMES_ENABLED=true yarn workspace website build",
    "serve": "LAB_TIMES_ENABLED=true yarn workspace website serve",
    "start": "LAB_TIMES_ENABLED=true yarn workspace website start",
  },

The Makefile wraps the same steps with an install step that runs first, so the shortest path for a contributor is to run `make install` and then `make build`, or to invoke the Yarn scripts directly if you prefer to see the underlying commands. The `build` and `serve` targets both depend on `install`, so a missing dependency install is not something you have to remember.

There is no `deploy` script in the manifest, which is consistent with the repository stating that the site source is here while the site itself is published at eksworkshop.com. Publishing is handled by the release tooling, not by a local command you would run yourself.

The lint pipeline is the real quality gate for content

Content in this repository is prose, and prose fails in ways code does not, so the checks are extensive. The root manifest defines a single lint command that chains four checks together.

    "lint": "yarn links:check && yarn format:check && yarn markdown:check && yarn spelling:check",

The four components each have a dedicated script: `links:check` runs `markdown-link-check` with the repository's `link-check-config.json`, `format:check` runs `prettier -c .`, `markdown:check` runs `markdownlint-cli2` over the Markdown files under `website/docs`, and `spelling:check` runs `cspell` over the same documentation glob. A `lint:staged` variant runs the same chain through `lint-staged` with `--concurrent false --no-stash`, so staged files are checked one at a time without hiding the stash.

The supporting configuration at the top level tells you what the project expects. There is a `.markdownlint.json`, a `.prettierrc` with a `.prettierignore`, a `.prettier-plugin-sh` dependency for shell script formatting, a `cspell.config.yaml` and a `.spelling` file, plus a `link-check-config.json` and an `i18n/` directory for translated content.

The practical consequence for a reader who wants to contribute is that a pull request that only adds Markdown still has to pass link checking and spelling, and the same rules apply to translated copies of the content.

The Makefile stamps ECR public logins instead of repeating them

The Makefile carries one piece of non-obvious logic, and it exists because of a credential lifetime. The comment explains that ECR Public authorization tokens last 12 hours, so logging in on every invocation is wasted work. The Makefile records the last login in a stamp file and skips the login while that stamp is current, and the stamp is per container CLI because `docker` and `finch` keep their credentials in separate config files.

CONTAINER_CLI ?= docker

ecr_login_stamp=.make/ecr-login-$(CONTAINER_CLI)
ecr_login_ttl_mins=660

The TTL of 660 minutes is shorter than the 12 hour token life, and the stamp is keyed on the container CLI variable, so switching to `finch` produces a separate stamp file and a separate login.

The login itself authenticates to the public ECR registry rather than to a private one, using the AWS CLI for the token and piping it into the container CLI with `--password-stdin`.

	  aws ecr-public get-login-password --region us-east-1 | $(CONTAINER_CLI) login --username AWS --password-stdin public.ecr.aws; \

The stamp only tracks elapsed time, not whether the stored credential still works, so the Makefile exposes an `ecr-login` target that removes the stamp and forces a fresh login. That is the target to run after you log out or switch accounts, and the `SKIP_CREDENTIALS` environment variable skips the public ECR login entirely when it is set.

Maintenance, releases and the cases where this is the wrong tool

The last push was on 2026-10-21, and the repository publishes monthly release snapshots: release-snapshot-1b0f95ab for Release 26/09 on 2026-10-05, release-snapshot-b8d8d27e for Release 26/08 on 2026-08-25, and release-snapshot-d8f1b254 for Release 26/07 on 2026-07-30. The snapshot naming means a workshop attendee can be pointed at a known good cut of the content rather than at a moving branch, which matters when a lab takes an hour to run and fails on the last step.

Maintenance is not left to memory. There is a `renovate.json` for dependency updates, a `.mergify.yml` for merge automation, a `.pre-commit-config.yaml` for local checks, and a `devenv.nix` with a `devenv.lock` and a `direnvrc` for a reproducible developer environment. Governance is documented in `governance/steering.md`, `governance/model.md` and `governance/tenets.md`, and security issue reporting is described in CONTRIBUTING.md.

The wrong-tool cases are clear enough. This is not a Kubernetes curriculum, because the EKS focus is deliberate. It is not a production infrastructure template, because the Terraform exists to create disposable lab environments for learning, with the ECR public registry and a retail sample app baked in. And it is not free: every lab provisions AWS resources in your own account, and the workshop does not describe a teardown path for them in the README, so cost control is yours to arrange. For a team that only needs one EKS cluster, a single module and the matching Terraform under `cluster/terraform` is usually the sensible subset, and the workshop works well as a structured path rather than as a pattern to copy wholesale.

Editorial conclusion

Adopt eks-workshop-v2 if you want to rehearse EKS networking, security and automation work against a disposable cluster in your own account and value labs whose Terraform and CLI steps are automatically tested. Do not adopt it as a Kubernetes reference, as a production IaC template, or for a team that cannot afford to create and delete AWS resources, because every lab provisions real infrastructure in a real account. Verify first that the module you intend to run still matches the EKS version you operate, and read the release snapshot notes for the most recent monthly cut, release 26/09 published on 2026-10-05, before you copy any Terraform into a production path.

Frequently asked questions

Official sources

1. aws-samples/eks-workshop-v2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases