Speaking with TFiR, Julian Fischer of anynines defined why AWS “all-in” strategies still leave enterprises without a workable solution for Kubernetes data service orchestration at scale — and how a9s Hub for AWS fills that gap.

WHAT IS THE AWS MULTI-ACCOUNT KUBERNETES PROBLEM?

Fischer opens with a direct observation: Kubernetes does not have tight integration with AWS data services. Network integration and RDS instances are available — but creating those RDS instances declaratively, allowing developers on-demand self-service by simply applying a Kubernetes YAML, is not something AWS provides natively.

Teams have reached for Crossplane to fill this gap, installing it locally on EKS clusters to address RDS. For small environments, this works. But for larger enterprises where platform teams are building developer experiences across hundreds or thousands of Kubernetes clusters, the model collapses. A central control plane becomes necessary — and lightweight extensions are needed in each application cluster to expose data service automation. That is precisely the problem Klutch is built to solve.

THE WELL-ARCHITECTED FRAMEWORK AS ARCHITECTURAL FOUNDATION

a9s Hub for AWS is built around a recurring pattern Fischer’s team observed across large enterprises: the AWS Well-Architected Framework’s guidance on account separation. The pattern is consistent — EKS clusters live in one type of AWS account, and data service instances (RDS, S3, and others) live in dedicated service accounts. That pairing repeats per tenant, producing hundreds of AWS accounts at scale.

“You’re looking at hundreds of AWS accounts, and people would love to create RDS instances from those Kubernetes clusters spanning those AWS accounts — while the platform team needs to maintain an overview on where has been used what.”

AWS billing handles governance adequately when all services are native AWS resources. But the moment internally developed services or third-party enterprise databases enter the mix, central policy and governance breaks down.

THE KLUTCH TENANT MODEL: HOW CROSS-ACCOUNT PROVISIONING WORKS

The anynines solution introduces a tenant model into the latest version of Klutch and a9s Hub. Each tenant is declared with its associated AWS accounts. When a developer on an EKS cluster provisions a service, Klutch identifies the tenant, delegates the request, assumes the appropriate IAM role for that tenant’s account, and creates the service instance in the correct location — automatically.

The architecture: one Klutch control plane per region, lightweight extensions deployed to each application cluster. Platform teams retain full central visibility and can query which application clusters are running and which data service instances each cluster is using. Developers interact only with the lightweight extension, provisioning services exactly as they would in Cloud Foundry.

“You install Klutch, then install your application cluster plugin from Klutch, and you can right away create service instances as if you were on Cloud Foundry—just natively with Kubernetes.”

Current automation integrations cover RDS and S3, with more to follow. The framework is modular: AWS-native services, anynines-managed data services, and internally developed backends can all be added to the same unified layer.

BROADER CONTEXT: THE FULL a9s HUB PICTURE

This clip is part of a longer conversation covering the complete a9s Hub architecture. In the full interview, Fischer explains how the same Klutch foundation powers the on-prem scenario (OpenStack/VMware environments under digital sovereignty pressure), how the Klutch Service Broker extends coverage to Cloud Foundry from a single integration, and how anynines sees Cloud Foundry and Kubernetes together as the correct runtime layer for stateful AI workloads.

Watch the TFiR interview with Julian Fischer here