4 Reasons to Use Talos Linux In AWS

Justin Garrison
June 5, 2024

Don’t ever let a company tell you what is best for you. Even Sidero Labs. You need to make the best decisions for what you need, and you should know why and when it makes sense to re-evaluate past decisions.

We’re not going to tell you Omni is the best and easiest Kubernetes management platform, or that Talos Linux is only distro you don’t have to think about. We’ll let our customers tell you at Taloscon.

Amazon EKS is a great option if you’re all in on AWS. But the world has moved past a single cloud vendor. Kubernetes was designed to be an infrastructure agnostic cloud and on-prem management platform and cloud providers have turned it into a proprietary product.

Here are 4 reasons you may want to consider Talos Linux even if you’re all in on AWS:

Avoid forced upgrade cycles
Kubernetes consistency
No proprietary services
Manage abstractions, not automation

Avoid forced upgrade cyles

Upgrades have been a concern for a long time. Kubernetes is a complex system that multiple teams—and maybe customers—have an interest in keeping stable. Performing a potentially disruptive upgrade is not easy. I’ve written about upgrade strategies before but none of them make it easier.

EKS announced “extended support” that let you delay your upgrades for a year while Amazon collects 6x the price of a standard supported cluster. This was so nice of them. Your single cluster just went from $877 to $5260 per year. All without having to do a thing. If you have 10 clusters you just went from $8770 to $52,600 on the final year.

Once your extended support ends Amazon will force your EKS API to upgrade, which can break your workloads. Thanks Amazon.

If you create an EKS cluster on the day they launch a new version all the way until they force your cluster to upgrade to the next version (26 months) you will pay $6282 for the control plane. That doesn’t include running any worker nodes, storage, or network traffic.

With Kubernetes clusters running on Talos Linux you are never forced to upgrade. You can upgrade your Kubernetes API and operating system on your own time. You own the Kubernetes API and can decide which version and upgrade cycle is right for you. Talos Linux is completely free (speech and beer). You don’t have to sign an agreement, no pay walls, just Linux as it should be.

If you want to use Omni to manage your Kubernetes clusters in AWS then there will be a flat rate cost depending on your SLA and cluster size needs. Omni doesn’t provide the compute resources (BYO EC2). A “hobby” tier cluster is only $10/mo for up to 6 nodes. A 10 node startup tier Omni cluster is $250/mo and that includes the Kubernetes control plane and worker nodes.

An Omni startup cluster over the same 26 months will cost $6500. This will work in any cloud environment or on-prem. You can have 10, 1 node clusters if that’s what you need.

If you have lots of EKS clusters you also should be aware that Omni is more than twice as fast as EKS for cluster creation, upgrades, and deletions.

Kubernetes consistency

Speaking of using Omni clusters anywhere, Talos Linux works on everything from a Raspberry Pi to a “metal” cloud instance. You get to use the same API driven Linux distribution consistently everywhere. You don’t even have to use Packer to customize it with factory.talos.dev.

Talos works the same way everywhere.

Amazon recently had to extend the End of Life support for Amazon Linux 2 from 2023 to 2025 because Amazon wasn’t ready. EKS wasn’t even ready. And there’s still a bunch of things in AL2023 that they aren’t bringing over from AL2.

If you want to run Amazon Linux outside of AWS you can’t. You’ll need to band a general purpose Linux distro to your needs or go with a cross cloud and on-prem distro to begin with. Amazon even removed support for Bottlerocket from their own on-prem Kubernetes offering EKS Anywhere.

No proprietary services

People often choose Kubernetes because it’s open source. There’s minimal “vendor lock-in” and you can own layers of your infrastructure that are important to you. People don’t pick Amazon ECS or Lambda for their portability. They’re proprietary services you can only run in AWS.

EKS is not open source. It never has been and never will be. It is run with proprietary code that you cannot see, use, modify, or audit. EKS Anywhere is a completely different open source product designed around Kubernetes Cluster API, but EKS Anywhere doesn’t actually run “anywhere.” It only runs on-prem on providers that are not competitors to AWS.

To more tightly integrate EKS into AWS they have started building user facing proprietary features into the EKS control plane. Features like AWS Fargate and EKS Pod Identity are not Kubernetes features. They’re proprietary extensions that were built using Kubernetes extension mechanisms that you will not be able to replicate outside of an EKS control plane.

The reason those extensions exist is because there was no other way to integrate an open source, cross cloud product into the proprietary AWS back end with different ways of managing resources and access (e.g. K8s RBAC vs AWS ABAC).

Talos Linux is open source and MPL licensed on GitHub. Omni, our hosted Kubernetes management platform, is also available on GitHub. It is Business Source Licensed (BSL) and we welcome contributions. We can’t license rug pull you when we are up front with the license.

As a matter of fact, the BSL license is exactly the opposite of a rug pull. The current code will automatically change to Mozilla Public License on Feb 22, 2028. You can start building on it today and know that it’s only going to get more open as time goes on.

Manage abstractions, not automation

Before CI/CD we would deploy applications with runbooks. A wiki page or physical notebook that documented all the commands you had to run to deploy a new version of your application. CI/CD took most of the runbooks and automated the steps with bash.

Containers came out and made deployments more reliable, but still automated. Kubernetes took the last part of the automation and abstracted it. We don’t run a command 10 times, we declare “replicas: 10”. This has been a big win for stabilizing application deployments: your infrastructure should be treated the same way.

Did you know when you run an Amazon Linux 2 node in EKS it relies on a 650 line bash script to provision the machine? That script depends on cloud-init (python mixed with bash) to execute systemd (10k+ lines of C code) services to make a general purpose Linux distro run the Kubelet. This sounds like runbooks from 15 years ago.

Talos Linux has no bash and no systemd. It’s not a general purpose Linux distribution. It does one thing, run Kubernetes. It manages everything from your hardware to your Kubernetes API with minimal code, limited surface area, and 0 scripts.

This drastically reduces the complexity of a system which in turn can increase reliability. Complex systems take more work to debug and are difficult to maintain. If you’re reading this then you probably already know that with Kubernetes.

As powerful as systems can be, making them really good at one thing is better than partially good at lots of things. You wouldn’t use a swiss army knife to cut down a tree even though it has a saw blade. Use a single purpose tool for a single purpose job.

Talos Linux has been built only for Kubernetes. We build in operational knowledge to provision a Kubernetes API, perform upgrades, and run applications with native Kubernetes requirements. It’s not an automation tool, it’s an abstraction.

With a single purpose operating systems it makes normal tasks like upgrades extremely fast and simplified with minimal automation.