Yleisradio enhances digital services with Amazon EKS and IPv6 Adoption

Yleisradio is a Finnish broadcasting company running most of its online and mobile services – which roughly 2.1 million Finns use every day – on AWS.

Like many organizations, they use IP Address Management (IPAM) systems to allocate IP addresses across their AWS environment to make sure routing works, even between AWS and their on-premises network. Although a /16 IPv4 CIDR range includes over 65,000 addresses, it was quickly consumed when allocating subnets for AWS Regions, teams, and environments. Combined with containerized workloads consisting of many small services and agents, each requiring an IP address, they faced a shortage of routable IPv4 addresses.

Yleisradio also needed to simplify the management of address allocations and to make traffic flows easier to follow and monitor. They wanted the cognitive load caused by understanding the system to be as low as possible, allowing their engineers to focus on the problems that they’re trying to solve.

This post details how using IPv6 for container workloads simplified network management, eased debugging, and empowered their engineers to focus on innovation.

Yleisradio’s setup

Yleisradio uses Amazon VPC IP Address Manager (IPAM) to make sure that the documentation and monitoring of IP address usage is up-to-date all the time. This also frees them from writing their own logic on efficient subnet allocations, as some VPCs demand bigger allocations than others. They also use an Egress VPC for better egress control and workload VPCs are peered back to on-premises through AWS Transit Gateway, as shown in the following figure.

Figure 1: Diagram of the AWS network and connectivity to the on-premises network

Each development team has one VPC on their account (Figure 1: workload VPCs), where they can deploy applications on top of Amazon Elastic Kubernetes Service (Amazon EKS) clusters. For those clusters, Yleisradio explored various networking options, such as overlay networks and concealing their EKS cluster VPCs behind Network Address Translation (NAT) gateways to prevent overlapping CIDR blocks. However, they ultimately decided to adopt IPv6 to simplify their Amazon EKS networking setup and eliminate the need for NAT gateways, gaining a transparent view of traffic flow patterns within their Kubernetes clusters.

Amazon VPC

When enabling their networks for IPv6, Yleisradio followed the best practices for designing dual-stack networks on AWS, for example using Egress-only Internet Gateways (IGWs) to allow IPv6 traffic from Amazon Virtual Private Cloud (Amazon VPC) to the internet.

Yleisradio still uses IPv4 for resources with no direct internet access requirement, such as databases, application servers, and internal services. IPv4 traffic is routed through a Transit Gateway to a dedicated egress VPC with NAT gateways to optimize costs, as shown in the following figure.

Figure 2: Diagram of the AWS network routing

IPv6 allocation

Although using AWS IPAM makes it easier to keep track of CIDR block allocation asking for contiguous IPv6 allocation from AWS simplified routing rules definition for VPCs and subnets.

Amazon EKS

Before adopting IPv6, managing an IPv4-only Amazon EKS was cumbersome. In particular, IPv4 exhaustion led Yleisradio to adopt an overlay network, which added complexity and limited visibility through VPC Flow logs. Additionally, the overlay network setup prevented them from using Karpenter, a tool ideal for scaling their dynamic workloads.

With Amazon EKS IPv6 clusters, these challenges were eliminated. The vast address space of IPv6 removes the challenge of exhaustion, allowing them to get rid of the complex overlay network and adopt Amazon VPC CNI. For a deep dive into how Amazon EKS with IPv6 works, refer to this three-part series [Part 1, Part 2, and Part 3].

In the next section, we focus on Yleisradio’s approach to external connectivity from their EKS cluster.

Connectivity to outside of Amazon EKS

Although with Amazon EKS the pod-to-pod communication within a cluster is always IPv6, some pods need to connect to legacy IPv4 endpoints outside the cluster. DNS64 translates the IPv4 addresses to IPv6 addresses with the prefix 64:ff9b::/96 as per RFC6052. This prefix is configured to point toward an egress VPC with NAT gateways that perform the NAT64 translation and forward the traffic to the correct address.

In particular, this is the traffic flow to connect to on-premises IPv4 endpoints, which is also shown in the following figure:

1. The IPv6 Pod makes a DNS query to resolve an internal address.
2. DNS64 resolver returns an adress with a 64:ff9b::/96 prefix since the address is IPv4 only. This behavior is explained in detail in another AWS post, Let your IPv6-only workloads connect to IPv4 services.
3. This 64:ff9b::/96 prefixed address routes to the NAT64, so the connection is sent to the NAT gateway.
4. The NAT64 (NAT gateway) translates the 64:ff9b::/96 address to an IPv4 address and forwards the request
5 and 6. The response travels back through the NAT gateway to the originating IPv6 Pod.

Figure 3: Diagram of the route from an Amazon EKS pod query to an on-premises IPv4 endpoint

Amazon EKS offers a built-in feature that enables IPv6 for clusters. With this feature, the node can perform NAT on its own when an A-record is resolved. Although this simplifies the overall setup process for users, it can pose some challenges when it becomes crucial to have visibility over the packet flow. Therefore, Yleisradio configured each container to resolve AAAA-records so that then NAT64 takes over and translates from IPv6 to IPv4. Yleisradio has added this to their documentation for the development teams.

Conclusion

In this post, we showed how using automation for both IP address management and VPC creation streamlines network management and reduces the chances for human error. This, along with the adoption of a large IPv6 address space, empowers you to fully use container-based solutions without complicated overlay networks. The benefits include:

• Easier traffic tracing
• Reduced debugging complexity
• Freed-up time for platform engineers to focus on innovation
• Simplified network setup through native AWS integrations
• Increased reliability through robust VPCs

Overall, embracing IPv6 has simplified Yleisradio’s daily operations, minimized system maintenance, and allowed them to use pre-built solutions more effectively.

We’re excited to share these learnings with the wider community through this post, and to support other organizations that are looking for easier day-to-day operations. As part of their experience, the Yleisradio team highly recommends modernizing network stack with IPv6 to better operate, scale, and observe containerised workloads on Amazon EKS.

Things they are looking forward to

As Yleisradio continues their Amazon EKS and IPv6 implementation and exploring potential challenges, they are enthusiastic about collaborating with Amazon’s skilled teams to jointly overcome obstacles that may arise. They also have seen how this already actually works in production and they haven’t had any problems running it this far.

For more information on how IPv6 on Amazon EKS works, you can have a look at this three-part series: [Part 1, Part 2, and Part 3].