Back to work

Telco EKS

Amazon EKS Platform for CNF Workloads

Delivered an Amazon EKS platform using Terraform and GitHub Actions, supporting self-managed node groups, Multus-based secondary networking, SR-IOV, Whereabouts IPAM, and telco-style traffic separation patterns for CNF workloads.

Published: Dec 2025. Scope: CNF platform infrastructure. Stack: AWS, Amazon EKS, Terraform, GitHub Actions, Multus, SR-IOV, Whereabouts.

High-level Amazon EKS architecture for telco CNF workloads

Overview

This project involved deploying an Amazon EKS platform to host Containerized Network Function workloads. The platform required advanced Kubernetes networking, multiple self-managed node groups, and add-ons such as Multus, SR-IOV, and Whereabouts.

The project focused on standardizing Amazon EKS infrastructure for CNF workloads that needed more than a basic Kubernetes cluster. The platform had to support advanced networking, repeatable provisioning, and infrastructure changes that could be reviewed and applied through a controlled CI/CD workflow.

Terraform was used for Infrastructure-as-Code, while GitHub and GitHub Actions provided the source-control and pipeline workflow for planning and applying platform changes.

Requirement

The requirement was to provide an Amazon EKS platform that could support Containerized Network Function workloads with multiple worker node profiles, secondary pod networking, and add-ons used in telco-style Kubernetes deployments.

The platform also needed environment state separation, repeatable node group provisioning, and CI/CD controls around Terraform plan and apply operations.

My Contribution

  • Delivered EKS self-managed node group deployment using Terraform.
  • Supported multiple node group patterns for different CNF requirements.
  • Integrated advanced add-ons such as Multus, SR-IOV, and Whereabouts.
  • Embedded platform bootstrap configuration into Terraform user data scripting.
  • Supported GitHub Actions workflow for Terraform plan and apply.
  • Helped establish a repeatable deployment model for EKS platform changes.

Architecture

The high-level model connected Terraform code in GitHub to a GitHub Actions workflow, then used a runner to execute the IaC workflow against AWS.

High-level Amazon EKS platform architecture

Workflow

Engineers updated Terraform code, committed changes to GitHub, and used GitHub Actions to run formatting, validation, planning, review, approval, and apply stages.

Terraform delivery workflow for controlled EKS platform updates

Multiple Self-Managed Node Groups

Multiple self-managed node groups were needed because each CNF workload may have different bootstrap, scheduling, interface, and Multus requirements.

Terraform helped model those differences while keeping the deployment process repeatable and reviewable.

Multus, SR-IOV, and Whereabouts

Multus allows Kubernetes pods to attach multiple network interfaces instead of relying only on the default pod network. Whereabouts provides cluster-wide IPAM for secondary pod networks. SR-IOV related components support high-performance networking patterns.

Secondary pod networking view

Telco VRF Design Pattern

Multus and secondary pod interfaces can help extend telco-style traffic separation into the Kubernetes worker node and pod layer, while AWS networking constructs provide the cloud-side routing separation.

Multus does not equal VRF. It is one part of the Kubernetes networking layer that helps attach additional interfaces to pods.

Approach

The implementation centered on Terraform modules and environment configuration that could express EKS cluster settings, self-managed node groups, bootstrap scripting, remote state, and add-on installation patterns in a repeatable way.

Challenges

The main challenge was coordinating EKS cluster provisioning, self-managed node group bootstrap, add-on readiness, secondary interface behavior, and CNF networking expectations.

Lessons Learned

CNF-oriented EKS work benefits from treating node groups, bootstrap scripts, add-ons, and secondary networks as first-class platform components.

Outcome

The result was a repeatable Terraform-based delivery model for an Amazon EKS platform that supported multiple self-managed node group patterns, advanced Kubernetes networking add-ons, and GitHub Actions based infrastructure workflow controls.

References