Beyond Observability: Building a Complete Self-Service EKS Platform with KRO and ACK

EKS Capabilities transforms how platform teams deliver infrastructure at scale. This technical guide demonstrates how to build a complete enterprise platform observability, security governance, compute optimization, team onboarding, backup, certificates, and cost visibility, using reusable KRO ResourceGraphDefinitions and ACK. Three YAML files replace hours of manual configuration. Blueprints to cover the full platform lifecycle. Define your platform once, deploy it everywhere, onboard teams in seconds.
Singhal, Samar

Published Feb 19, 2026
Last modified Feb 19, 2026
Platform engineering teams face a compounding problem. The first EKS cluster goes well. An engineer spends a few days configuring observability with Amazon Managed Prometheus and ADOT collectors, setting up ExternalDNS for Route53 integration, tuning Karpenter node pools for cost optimization, creating team namespaces with proper RBAC and resource quotas, and establishing security baselines with pod security standards and network policies. The configuration lives across Terraform modules for AWS resources, Helm charts for Kubernetes components, Kustomize overlays for environment differences, and documentation that's already outdated.
The second cluster takes almost as long. By the tenth cluster, the platform team has become a bottleneck. Every new cluster requires the same hours of manual setup. Every team onboarding request sits in a queue. Every security audit reveals drift between clusters that were supposed to be identical. The operational overhead scales linearly with cluster count, and the platform team spends more time maintaining tooling than building platform capabilities.
A  previous post  demonstrated how EKS Capabilities can solve this for observability a single blueprint that deploys AMP workspaces, ADOT collectors, IAM roles, and Pod Identity with five parameters. This post takes that pattern and applies it across the entire platform stack. We'll build reusable blueprints organized into three tiers infrastructure foundation, security governance, and team self-service that together deliver a complete enterprise platform from a handful of YAML declarations.
By the end of this post, you'll have step-by-step implementation guidance for deploying the complete platform, concrete verification steps for every component, and a GitOps automation model that makes the next cluster setup as easy as the second.
The Enterprise Platform ChallengeBuilding an enterprise-grade EKS platform requires solving several interconnected problems simultaneously. Observability infrastructure must be consistent across clusters so that metrics are comparable and dashboards work uniformly. Security policies must be enforced everywhere but flexible enough to accommodate different environments. Team onboarding must be fast enough that it doesn't become a bottleneck but controlled enough that it doesn't create security gaps. Compute optimization must balance cost and performance across workload types. Secrets must flow securely from AWS Secrets Manager into pods. DNS records must be created automatically when services are exposed. Logs must be centralized for troubleshooting. Certificates must be provisioned and renewed automatically. Backups must run on schedule. Cost must be attributable to teams.
Each of these capabilities has its own configuration surface area, its own AWS resources, its own Kubernetes components, and its own operational lifecycle. In a traditional approach, each capability is managed by a different tool Terraform for IAM roles, Helm for ADOT collectors, kubectl for RBAC, AWS CLI for AMP workspaces creating a fragmented operational model where no single tool provides a complete picture of the platform state.
EKS Capabilities provides a unified approach. Managed KRO enables platform teams to define high-level ResourceGraphDefinitions that expand into complete infrastructure stacks. Managed ACK brings AWS resource management into the Kubernetes reconciliation loop. Managed ArgoCD automates GitOps-driven deployment. All three are built into EKS as native capabilities no operators to install, no Helm charts to maintain, no version upgrades to manage.
Solution ArchitectureThe following diagram shows how the platform transforms simple YAML declarations into complete infrastructure through KRO and ACK, all within an EKS Auto Mode cluster managed through GitOps.
﻿
The platform is organized into three tiers with clear ownership boundaries and deployment lifecycles.
plaintext
┌─────────────────────────────────────────────────────────┐                     
│  Tier 1: Platform Foundation                            │
│  Deploy once per cluster · 3 required parameters        │
│  Observability · DNS · Compute · Metrics                │
│  Secrets · Logging                                      │
│  Output: 30-50 AWS + Kubernetes resources               │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐                    
│  Tier 2: Platform Security                              │
│  Deploy once per cluster · 1 required parameter         │
│  Pod Security Standards · RBAC Baseline                 │
│  Network Policies · Image Security                      │
│  Resource Governance · Audit Logging                    │
│  Output: ConfigMap + ClusterRoles + NetworkPolicies     │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐                   
│  Tier 3: Team Services                                  │
│  Deploy per team · 4 required parameters                │
│  Namespace · RBAC · Quotas · Network Isolation          │
│  Backup · GitHub Runners                                │
│  Output: 10 Kubernetes resources per team               │
└─────────────────────────────────────────────────────────┘
Tier 1 is owned by the infrastructure team. It provisions everything a cluster needs to be operational: AMP-based observability with ADOT collectors, ExternalDNS for automatic Route53 record management, Karpenter NodePools optimized for EKS Auto Mode, Metrics Server for horizontal pod autoscaling, External Secrets Operator for AWS Secrets Manager integration, and centralized logging to CloudWatch. The EKSPlatformFoundation ResourceGraphDefinitions accepts three required parameters (cluster name, region, and account ID) and expands into child ResourceGraphDefinitions for each module, which in turn expand into native Kubernetes and ACK resources.
Tier 2 is owned by the security team. It establishes governance baselines that apply cluster-wide: pod security standards enforcement, RBAC roles for platform-wide viewer and audit access, default-deny network policies, image registry allowlists, required labels for cost allocation, and resource limit enforcement. The EKSPlatformSecurity ResourceGraphDefinitions accepts one required parameter cluster name and creates native Kubernetes resources that encode the security policy.
Tier 3 is consumed by development teams. The TeamNamespace ResourceGraphDefinitions creates a fully configured namespace with RBAC roles and bindings, resource quotas, limit ranges, network policies, and a workload service account. The BackupStrategy ResourceGraphDefinitions provisions Velero infrastructure with S3 storage, IAM roles, and Pod Identity. Teams consume these through self-service YAML declarations or GitOps pull requests.
How It Works: From YAML to InfrastructureThe transformation from a simple YAML declaration to a complete infrastructure stack happens through three layers of expansion.
plaintext
Platform Engineer Applies:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
EKSPlatformFoundation YAML (3 required parameters)
    ↓
KRO Expands into Child ResourceGraphDefinitions:
    ObservabilityCluster + ExternalDNSCluster + KarpenterNodePool (x4)
    + MetricsServer + ExternalSecretsOperator + CentralizedLogging
    ↓
Each Child Expands into Native Resources:
    ObservabilityCluster → ServiceAccount + IAM Policy + IAM Role
      + PodIdentityAssociation + ClusterRole + ClusterRoleBinding
      + OpenTelemetryCollector (DaemonSet)
    ↓
ACK Controllers Reconcile AWS Resources:
    IAM policies created via AWS APIs
    IAM roles created with Pod Identity trust
    Pod Identity associations configured
    AMP workspace receives metrics
    ↓
Result: Complete platform infrastructure from one declaration
When you apply a ResourceGraphDefinition to the cluster, KRO reads the schema and dynamically creates a Custom Resource Definition. The cluster now has a new API type EKSPlatformFoundation, EKSPlatformSecurity, TeamNamespace that any authorized user can create instances of. KRO watches for instances and expands them into the defined resource graph. This is fundamentally different from Helm or Kustomize, which generate static manifests applied once. KRO creates living APIs that continuously reconcile. If someone manually deletes a NetworkPolicy from a team namespace, KRO recreates it. The platform's intent is continuously enforced.
Prerequisites and Environment SetupThe implementation requires an EKS Auto Mode cluster with EKS Capabilities enabled. Auto Mode is recommended because it manages the Karpenter node lifecycle, load balancer controller, EBS CSI driver, and VPC CNI automatically, eliminating significant operational surface area from the platform team's responsibilities.
Required EKS Capabilities:
 kro  — Kubernetes Resource Orchestrator
 ack  — AWS Controllers for Kubernetes (IAM, EKS, Prometheus Service)
 argo-cd  — GitOps automation
Enable capabilities via the EKS console or CLI:
Bash
aws eks update-cluster-config --name <cluster> \
  --compute-config enabled=true \
  --kubernetes-network-config '{"elasticLoadBalancing":{"enabled":true}}' \
  --storage-config '{"blockStorage":{"enabled":true}}'
Local tools required: AWS CLI and kubectl configured for your cluster.
Implementation WalkthroughStep 1: Deploy Blueprint TemplatesClone the repository and run the bootstrap script:
Bash
git clone https://github.com/samar-singhal/eks-platform-blueprints.git
cd eks-platform-blueprints/bootstrap
./deploy-blueprints.sh
The bootstrap script configures KRO RBAC permissions, restarts the KRO controller, and applies all  ResourceGraphDefinitions. Within seconds, the cluster has new custom resource types.
Verify the blueprints are registered and ready:
Bash
kubectl get resourcegraphdefinition
Expected output:
plaintext
NAME                        KIND                      READY
backup-strategy             BackupStrategy            True
centralized-logging         CentralizedLogging        True
certificate-manager         CertificateManager        True
cost-visibility             CostVisibility            True
eks-platform-foundation     EKSPlatformFoundation     True
eks-platform-security       EKSPlatformSecurity       True
external-dns-cluster        ExternalDNSCluster        True
external-secrets-operator   ExternalSecretsOperator   True
karpenter-nodepool          KarpenterNodePool         True
metrics-server              MetricsServer             True
observability-cluster       ObservabilityCluster      True
observability-platform      ObservabilityPlatform     True
team-namespace              TeamNamespace             True
All blueprints showing  True  in the READY column confirms that KRO has validated the ResourceGraphDefinitions schemas, created the corresponding CRDs, and is ready to accept instances.
Step 2: Deploy Platform FoundationEdit the foundation example with your cluster-specific values:
Bash
vim platform/foundation/examples/full.yaml
The file requires three values: your cluster name, AWS region, and account ID. If you're enabling observability, provide your AMP workspace ID and remote write endpoint. If you're enabling DNS, provide your Route53 hosted zone ID and domain filter. All other parameters have production-tested defaults.
YAML
apiVersion: platform.company.com/v1alpha1
kind: EKSPlatformFoundation
metadata:
  name: full
spec:
  clusterName: my-production-cluster
  region: us-east-1
  accountID: "123456789012"
  profile: production
﻿
  modules:
    observability: true
    dns: true
    compute: true
    metrics: true
    secrets: true
    logging: true
﻿
  observability:
    ampWorkspaceID: ws-abc123def456
    ampRemoteWriteEndpoint: https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-abc123def456/api/v1/remote_write
﻿
  dns:
    hostedZoneID: Z1234567890ABC
    domainFilter: prod.example.com
﻿
  compute:
    spotEnabled: true
    consolidationPolicy: WhenEmptyOrUnderutilized
Apply the foundation:
Bash
kubectl apply -f platform/foundation/examples/full.yaml
Watch the deployment progress:
Bash
kubectl get eksplatformfoundation full -w
Within two minutes, the status should show  ACTIVE  with  READY True . KRO has expanded the single resource into child ResourceGraphDefinitions instances for each enabled module.
Verify the child resources were created:
Bash
kubectl get observabilitycluster,externaldnscluster,karpenternodepool,metricsserver,externalsecretsoperator,centralizedlogging
Each child resource triggers its own expansion chain. The ObservabilityCluster creates ServiceAccounts, IAM policies and roles via ACK, Pod Identity associations, RBAC resources, and an OpenTelemetryCollector that deploys ADOT as a DaemonSet. Verify the ADOT collectors are running:
Bash
kubectl get pods -n observability-system
# Expected: adot-collector pods running on each node
Verify metrics are flowing to AMP:
Bash
WORKSPACE_ID=$(kubectl get workspace -n observability-system -o jsonpath='{.items[0].status.workspaceID}')
aws amp query \
  --workspace-id $WORKSPACE_ID \
  --query-string 'up{cluster_name="my-production-cluster"}' \
  --region us-east-1
Step 3: Deploy Security BaselineBash
kubectl apply -f platform/security/examples/restricted.yaml
Verify the security resources:
Bash
# Check instance status
kubectl get eksplatformsecurity restricted
# Expected: ACTIVE   True
﻿
# Verify ConfigMap with security policy
kubectl get configmap platform-security-config -n kube-system -o jsonpath='{.data}' | python3 -m json.tool
# Expected: securityProfile=restricted, enforcementMode=deny, podSecurityLevel=restricted
﻿
# Verify ClusterRoles
kubectl get clusterrole platform-viewer platform-admin-audit
# Expected: Both created
﻿
# Verify default-deny NetworkPolicy
kubectl get networkpolicy -n default
# Expected: platform-default-deny-ingress
The ConfigMap contains keys encoding the complete security policy: security profile, enforcement mode, pod security level, image security settings, resource governance flags, required labels, and network policy configuration. This ConfigMap serves as the declarative record of the cluster's security posture. Policy engines like OPA Gatekeeper or Kyverno can consume these values to create enforcement constraints, extending the baseline without modifying the blueprint.
Step 4: Onboard TeamsBash
kubectl apply -f team-services/team-namespace/examples/backend-team.yaml
Verify the team namespace and all its resources:
Bash
# Check instance status
kubectl get teamnamespace backend-team
# Expected: ACTIVE   True
﻿
# Verify namespace with governance labels
kubectl get ns backend --show-labels
# Expected: team=backend, environment=production, rbac-profile=developer, managed-by=platform
﻿
# Verify all ten resources
kubectl get resourcequota,limitrange,networkpolicy,role,rolebinding,sa -n backend
# Expected:
# resourcequota/team-quota          (20 CPU, 40Gi memory)
# limitrange/team-limits            (default container limits)
# networkpolicy/deny-ingress-by-default
# networkpolicy/allow-dns
# role/team-admin
# role/team-developer
# rolebinding/team-admin-binding
# rolebinding/team-developer-binding
# serviceaccount/team-workload
The namespace labels are significant. The  team  and  environment  labels satisfy the required labels governance from the security tier. The  rbac-profile  label documents the access level. The  managed-by: platform  label identifies this namespace as platform-managed, distinguishing it from manually created namespaces that might not meet governance requirements.
Verify the resource quotas are enforced:
Bash
kubectl describe resourcequota team-quota -n backend
# Shows: requests.cpu 0/20, requests.memory 0/40Gi, pods 0/100
Verify network isolation:
Bash
kubectl get networkpolicy -n backend
# deny-ingress-by-default: blocks all inbound except same-namespace
# allow-dns: permits DNS resolution to kube-system
Step 5: Configure Cluster BackupEvery production platform needs backup. The BackupStrategy blueprint provisions the complete Velero infrastructure through ACK: an encrypted S3 bucket with versioning for backup storage, IAM policies scoped to that bucket, an IAM role with Pod Identity trust for secure credential delivery, and a ConfigMap encoding the backup schedule and retention policy.
YAML
apiVersion: platform.company.com/v1alpha1
kind: BackupStrategy
metadata:
  name: cluster-backup
spec:
  clusterName: my-production-cluster
  region: us-east-1
  accountID: "123456789012"
  s3BucketName: "my-production-cluster-velero-backups"
  scheduleExpression: "0 2 * * *"
  retentionDays: "30"
  snapshotVolumes: true
Bash
kubectl apply -f team-services/backup-strategy/examples/full.yaml
﻿
# Verify
kubectl get backupstrategy cluster-backup
# Expected: ACTIVE   True
﻿
kubectl get bucket -n velero
# Expected: S3 bucket created via ACK
﻿
kubectl get sa -n velero velero-server
# Expected: ServiceAccount with Pod Identity
The backup schedule runs daily at scheduled time with defined retention. The S3 bucket is created with server-side encryption and versioning enabled through ACK's S3 controller. The IAM role grants only the permissions Velero needs. S3 object operations on the specific backup bucket and EC2 snapshot operations for persistent volume backups following least-privilege principles without requiring manual IAM policy authoring.
Step 6: Configure Certificate ManagementAlmost every workload needs TLS. The CertificateManager blueprint configures cert-manager's AWS integration so that teams can request certificates through simple Kubernetes resources without understanding the underlying ACME protocol, DNS validation, or IAM configuration.
YAML
apiVersion: platform.company.com/v1alpha1
kind: CertificateManager
metadata:
  name: cluster-certs
spec:
  clusterName: my-production-cluster
  region: us-east-1
  accountID: "123456789012"
  email: "platform-team@example.com"
  hostedZoneID: Z1234567890ABC
Bash
kubectl apply -f modules/certificate-manager/examples/full.yaml
﻿
# Verify
kubectl get certificatemanager cluster-certs
# Expected: ACTIVE   True
﻿
kubectl get sa -n cert-manager cert-manager
# Expected: ServiceAccount with Pod Identity for Route53 access
The blueprint creates IAM policies granting Route53 permissions for DNS01 challenge validation, an IAM role with Pod Identity trust, and the Pod Identity association linking cert-manager's ServiceAccount to the role. Once deployed, any team can create a Certificate resource in their namespace and cert-manager handles the Let's Encrypt ACME flow, DNS validation, and automatic renewal without any AWS credential management.
Step 7: Enable Cost VisibilityPlatform teams are always asked the same question: how much does each team cost? The CostVisibility blueprint provisions the IAM infrastructure needed for split cost allocation, connecting Kubernetes namespace-level resource consumption to AWS billing data.
YAML
apiVersion: platform.company.com/v1alpha1
kind: CostVisibility
metadata:
  name: cluster-costs
spec:
  clusterName: my-production-cluster
  region: us-east-1
  accountID: "123456789012"
  enableSplitCostAllocation: true
  costAllocationTags: "team,environment,cost-center"
Bash
kubectl apply -f modules/cost-visibility/examples/full.yaml
﻿
# Verify
kubectl get costvisibility cluster-costs
# Expected: ACTIVE   True
﻿
kubectl get configmap cost-visibility-config -n cost-visibility -o jsonpath='{.data}'
# Expected: costAllocationTags=team,environment,cost-center
The cost allocation tags defined here align with the required labels enforced by the security tier. Because every team namespace carries  team ,  environment , and  cost-center  labels enforced by the EKSPlatformSecurity governance baseline. The cost visibility module can attribute resource consumption to teams without requiring any additional instrumentation from development teams. The IAM role grants read access to Cost Explorer and Pricing APIs, enabling cost dashboards that break down spend by team, environment, and cost center.
Step 8: Onboard Additional TeamsWith the full platform running, adding more teams follows the identical pattern:
Bash
kubectl apply -f team-services/team-namespace/examples/frontend-team.yaml
kubectl apply -f team-services/team-namespace/examples/data-team.yaml
Each team gets an isolated namespace with identical governance controls but team-specific quotas, RBAC bindings, and labels. The data team might get 50 CPU cores and 100Gi memory for data processing workloads. The frontend team might get 10 CPU cores and 20Gi. The platform enforces these boundaries consistently. Every team's cost is tracked through the labels enforced at onboarding, certificates are available on demand, and backups protect their workloads automatically.
GitOps Automation with ArgoCDManual kubectl commands work for initial setup and testing, but production platforms should be driven entirely through Git. The repository includes ArgoCD configurations that automate the complete lifecycle.
Plain text
Git Repository (Single Source of Truth)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
platform/foundation/examples/     platform/security/examples/
  full.yaml                         restricted.yaml
  standard.yaml                     standard.yaml
  minimal.yaml                      permissive.yaml
﻿
team-services/team-namespace/examples/
  backend-team.yaml
  frontend-team.yaml
  data-team.yaml
  (add new file → team auto-onboards)
        │
        │ git push
        ↓
    ArgoCD (Managed EKS Capability)
    ├── Wave 0: Register blueprint templates
    ├── Wave 1: Deploy foundation + security
    └── Wave 2: ApplicationSet auto-discovers team files
        │
        │ kubectl apply (automated)
        ↓
    KRO expands → ACK reconciles → Platform running
The ArgoCD setup uses sync waves to ensure correct ordering. Wave 0 registers all ResourceGraphDefinitions. Wave 1 deploys the platform foundation and security instances. Wave 2 uses an ApplicationSet that watches the  team-services/team-namespace/examples/  directory. When someone commits a new team YAML file and pushes to Git, ArgoCD automatically discovers it, creates an Application, and syncs the TeamNamespace resource to the cluster.
Deploy the GitOps automation:
Bash
# Update repoURL in ArgoCD files to your Git repository
find argocd -name "*.yaml" -exec sed -i 's|<YOUR_GIT_REPO_URL>|https://github.com/your-org/eks-platform-blueprints|g' {} \;
﻿
# Deploy the root app — everything else is automatic
kubectl apply -f argocd/root-app.yaml
From this point forward, all platform changes flow through Git. Adding a team is a pull request. Changing the security profile is a pull request. Enabling a new module is a pull request. Every change is reviewed, approved, audited, and automatically deployed.
Multi-Cluster DeploymentThe same blueprints serve different environments through profile-based configuration. The repository includes three example profiles for each tier.
For the foundation,  full.yaml  enables all modules with high availability settings.  standard.yaml  enables all modules with balanced cost and performance.  minimal.yaml  enables only essential modules with ARM Graviton instances for maximum cost savings.
For security,  restricted.yaml  enforces strict pod security, image allowlists, and mandatory resource limits.  standard.yaml  provides balanced enforcement suitable for staging.  permissive.yaml  uses warning mode for development environments where developers need flexibility.
Deploying the same platform to three clusters with different profiles:
Bash
# Production: full infrastructure, restricted security
kubectl apply -f platform/foundation/examples/full.yaml
kubectl apply -f platform/security/examples/restricted.yaml
﻿
# Staging: standard infrastructure, standard security
kubectl apply -f platform/foundation/examples/standard.yaml
kubectl apply -f platform/security/examples/standard.yaml
﻿
# Development: minimal infrastructure, permissive security
kubectl apply -f platform/foundation/examples/minimal.yaml
kubectl apply -f platform/security/examples/permissive.yaml
All three clusters share the same blueprint definitions. The differences are entirely in the instance parameters. When the platform team updates a blueprint adding a new Prometheus recording rule, adjusting the default network policy, or changing the Karpenter consolidation behavior the change propagates to all clusters on the next reconciliation cycle.
Operational BenefitsThe architecture produces concrete operational improvements that compound as infrastructure scales.
Adding monitoring, security, and team namespaces to a new cluster requires editing three YAML files with cluster-specific parameters and running three kubectl commands. The process is identical whether it's the second cluster or the twentieth. The effort does not scale with cluster count because every cluster deploys from the same ResourceGraphDefinitions.
Configuration drift is eliminated by design. KRO continuously reconciles instances against their ResourceGraphDefinitions. If someone manually modifies a resource deleting a NetworkPolicy, changing a ResourceQuota, altering an IAM policy KRO detects the drift and corrects it. The declared state in Git is the enforced state in the cluster.
Platform updates propagate centrally. When the security team decides to require image digests instead of tags, they change one field in the security blueprint ( requireDigests: true ), update the ResourceGraphDefinition, and reapply. Every cluster running that security profile picks up the change. What would require touching dozens of clusters individually in a Terraform-based approach happens through a single Git commit.
Team onboarding becomes self-service. With ArgoCD configured, development teams submit a pull request adding their team YAML file. The platform team reviews the resource quotas and RBAC configuration. Upon merge, ArgoCD deploys the namespace automatically. The team gets a production-ready environment with RBAC, quotas, network isolation, and governance labels in seconds. No tickets, no manual provisioning, no platform team bottleneck.
Expertise requirements drop significantly. The complexity of IAM policies, ADOT collector configurations, Prometheus scrape configs, Karpenter NodePool specifications, and RBAC permissions is hidden behind simple ResourceGraphDefinitions parameters. Engineers who can edit YAML files and submit pull requests can deploy and manage platform infrastructure without deep expertise in each underlying component.
ConclusionEKS Capabilities transforms how platform teams deliver infrastructure at scale. Blueprints organized into three tiers cover the full platform lifecycle from cluster infrastructure through security governance to team self-service through a single declarative model. Platform teams define patterns once. Development teams consume them through simple YAML. ArgoCD automates the lifecycle through Git. KRO and ACK handle the expansion from simple declarations to complete infrastructure.
But the platform stack demonstrated here is just the beginning. The same pattern ResourceGraphDefinitions that hide complexity behind simple schemas applies to far more ambitious infrastructure challenges. Consider the AI/ML stack: provisioning SageMaker training jobs, deploying inference endpoints with Karpenter GPU node pools, configuring Ray clusters for distributed training, managing model registries, and orchestrating ML pipelines all through the same  kubectl apply  workflow. An MLPlatform ResourceGraphDefinitions that provisions a complete AI/ML environment from a handful of parameters, with GPU-optimized compute, model serving infrastructure, experiment tracking, and data pipeline connectivity, is a natural extension of everything demonstrated in this post. Stay tuned.
Additional ResourcesThe complete implementation including all ResourceGraphDefinitions, example configurations, bootstrap scripts, and ArgoCD integration is available in the  EKS Platform Blueprints repository .
For deeper learning:
 EKS Capabilities documentation  — Comprehensive coverage of managed KRO, ACK, and ArgoCD
 Kubernetes Resource Orchestrator  — Documentation on ResourceGraphDefinitions syntax and patterns
 AWS Controllers for Kubernetes  — Community site with documentation on all available controllers
About the AuthorSamar Singhal is a Solution Architect at AWS specializing in Advanced AI Systems. With deep passion for Generative AI, Containers, and Kubernetes, Samar focuses on developing next-generation solutions that combine artificial intelligence with cloud-native technologies to solve complex enterprise challenges. Follow this project on  GitHub 
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article
Builder Center

Beyond Observability: Building a Complete Self-Service EKS Platform with KRO and ACK

Singhal, Samar

The Enterprise Platform Challenge

Solution Architecture

How It Works: From YAML to Infrastructure

Prerequisites and Environment Setup

Implementation Walkthrough

Step 1: Deploy Blueprint Templates

Step 2: Deploy Platform Foundation

Step 3: Deploy Security Baseline

Step 4: Onboard Teams

Step 5: Configure Cluster Backup

Step 6: Configure Certificate Management

Step 7: Enable Cost Visibility

Step 8: Onboard Additional Teams

GitOps Automation with ArgoCD

Multi-Cluster Deployment

Operational Benefits

Conclusion

Additional Resources

About the Author
