AWS Builder Center

Builder Center

Platform Engineering at Scale: Building Reusable EKS Blueprints with KRO and ACK

Platform Engineering at Scale: Building Reusable EKS Blueprints with KRO and ACK

EKS Capabilities transforms platform engineering by enabling reusable blueprints that work across many clusters. This technical guide demonstrates the pattern through a observability implementation deploying AMP, ADOT collectors, and GitOps automation using KRO and ACK. Learn how to hide AWS and Kubernetes complexity behind simple YAML abstractions. This solution pattern can be applied across many use cases. Define once, deploy everywhere, scale without operational overhead.

Singhal, Samar

Platform engineering teams face a common challenge: how do you deliver consistent, repeatable infrastructure patterns across dozens or hundreds of clusters without creating operational bottlenecks? Whether it's observability, security, onboarding, or multi-tenancy, the traditional approach of manual configuration, Terraform templates, or custom scripts creates the same problems: configuration drift, operational overhead that scales linearly with cluster count, and complexity that requires deep expertise from every engineer. The solution? Reusable platform blueprints that transform complex infrastructure into simple, declarative patterns.
EKS Capabilities, introduced in late 2025, provides a fundamentally different approach to platform engineering. By delivering managed AWS Controllers for Kubernetes (ACK) and Kubernetes Resource Orchestrator (KRO) as native EKS features, it enables platform teams to define high-level patterns that expand into complete, properly configured infrastructure stacks. Instead of maintaining separate toolchains Terraform for AWS resources and kubectl for Kubernetes configurations, you define reusable ResourceGraphDefinitions that generate both AWS and Kubernetes resources from simple YAML declarations.
This post demonstrates this platform engineering pattern through a concrete, production-ready example: building a multi-cluster observability blueprint—a reusable pattern you can adapt for security, team onboarding, databases, and multi-tenancy. Managing observability across multiple Amazon Elastic Kubernetes Service (EKS) clusters presents the exact challenges that make it an ideal showcase for EKS Capabilities. Platform teams must provision Amazon Managed Service for Prometheus (AMP) workspaces, configure IAM roles and policies, deploy AWS Distro for OpenTelemetry (ADOT) collectors, and maintain consistent monitoring configurations across development, staging, and production environments. The manual, cluster-by-cluster approach creates configuration drift, operational overhead, and fragmented visibility.
Using EKS Capabilities, we'll build an observability blueprint where:
  • Platform teams define monitoring patterns once as KRO ResourceGraphDefinitions
  • Development teams deploy complete monitoring stacks with a single kubectl apply command
  • ArgoCD automates GitOps-driven deployment across all clusters
  • All metrics flow to a shared AMP workspace with unified visibility
  • Adding the twentieth cluster takes the same five minutes as the second cluster
By the end of this post, you'll have step-by-step implementation guidance for deploying this observability blueprint in your environment. More importantly, you'll understand the underlying pattern that can be applied to security, onboarding, multi-tenancy, and other platform engineering challenges turning complex, repetitive infrastructure work into simple, declarative abstractions.

The Multi-Cluster Observability Challenge

Traditional approaches to multi-cluster observability create operational overhead that scales with cluster count. Each cluster requires individual setup of monitoring infrastructure: creating an AMP workspace, configuring IAM roles and policies, deploying ADOT collectors with appropriate Kubernetes RBAC permissions, and establishing Grafana dashboards. This manual process typically takes 2-3 hours per cluster for experienced engineers.
As organizations scale to dozens of clusters, several critical challenges emerge. Configuration drift occurs when different engineers implement monitoring at different times and make different decisions. Early clusters might use IRSA for IAM authentication while newer ones use Pod Identity. Some clusters scrape metrics every 30 seconds while others use 60-second intervals based on different tradeoffs between granularity and cost. Recording rules and alert thresholds evolve over time, creating inconsistencies that make it difficult to confidently compare metrics between supposedly identical environments.
The operational overhead of maintaining this fragmented infrastructure becomes a significant burden. Rolling out a new recording rule or adjusting ADOT collector settings requires updating each cluster's configuration individually, testing changes to avoid disrupting existing metrics collection. What should be a single update to a shared configuration template becomes hours of repetitive work across dozens of clusters.
Visibility suffers when each cluster has its own AMP workspace and Grafana dashboards. Answering basic questions about overall platform health like total resource consumption or which clusters are approaching capacity requires querying multiple data sources and manually correlating results. Cross-cluster analysis becomes difficult or impossible without building custom tooling. The complexity of correctly configuring IAM policies, ADOT collectors, Prometheus scrape configs, and RBAC permissions typically limits this work to senior engineers, creating bottlenecks that slow down cluster onboarding and limit team scalability.

Solution Overview: Kubernetes-Native AWS Resource Management

EKS Capabilities provides two key features that enable a different approach to multi-cluster observability:

Managed AWS Controllers for Kubernetes (ACK): ACK controllers allow you to define AWS resources as Kubernetes custom resources. Instead of using the AWS CLI, CloudFormation, or Terraform to create an AMP workspace, you define a Workspace custom resource in Kubernetes and apply it with kubectl. The ACK controller watches for these resources and reconciles them with actual AWS infrastructure through AWS APIs. With EKS Capabilities, these controllers are built directly into EKS, no Helm charts to install, no operator upgrades to manage.
Managed Kubernetes Resource Orchestrator (KRO): KRO enables you to define ResourceGraphDefinitions, which are high-level abstractions that expand into multiple related Kubernetes resources. A ResourceGraphDefinitions functions as a reusable template that accepts parameters and generates a graph of interconnected resources. For observability, you can define a ResourceGraphDefinitions that takes five parameters (cluster name, region, workspace ID, endpoint URL, account ID) and generates eight Kubernetes resources (ServiceAccount, IAM Policy, IAM Role, PodIdentityAssociation, ClusterRole, ClusterRoleBinding, OpenTelemetryCollector).
Like ACK, KRO is built into EKS as a managed capability, no operator to deploy or maintain.
The combination of ACK and KRO creates a powerful pattern: define ResourceGraphDefinitions that expand into ACK custom resources, which then create actual AWS infrastructure. This enables you to build platform abstractions that hide complexity while providing consistent, repeatable deployments across any number of clusters.

Solution Architecture

The observability solution blueprint consists of two ResourceGraphDefinitions definitions that separate shared platform infrastructure from per-cluster monitoring resources.


ObservabilityPlatform ResourceGraphDefinitions

The ObservabilityPlatform ResourceGraphDefinitions defines shared infrastructure deployed once by the platform team:
Input parameters:
  •  workspaceName : Name for the AMP workspace
  •  region : AWS region for deployment
Generated resources - AMP Workspace: A single workspace where all clusters send metrics, enabling unified querying, reducing costs through shared infrastructur, Cross-cluster recording**** rules**** and Platform alert rules
The platform team deploys this ResourceGraphDefinitions once. All clusters subsequently reference the created AMP workspace. Updates to recording or alert rules propagate automatically to all clusters by updating this single ResourceGraphDefinitions.

ObservabilityCluster ResourceGraphDefinitions

The ObservabilityCluster ResourceGraphDefinitions defines monitoring infrastructure deployed per cluster:
Input parameters:
  •  clusterName : EKS cluster name
  •  region : AWS region
  •  ampWorkspaceID : Workspace ID from the platform deployment
  •  ampRemoteWriteEndpoint : AMP remote write URL
  •  accountID : AWS account ID
Generated resources:
  • ServiceAccount:  adot-collector  ServiceAccount for running collectors
  • IAM Policy: Grants  aps:RemoteWrite  and related permissions for AMP
  • IAM Role: With trust policy for  pods.eks.amazonaws.com  service principal
  • PodIdentityAssociation: Links ServiceAccount to IAM role for authentication
  • EKS Addon (ADOT operator)
  • ClusterRole and ClusterRoleBinding: RBAC permissions for service discovery and metric scraping
  • OpenTelemetryCollector: Configures ADOT collectors with Prometheus receivers, processors, and exporters
Metrics collection configuration: The OpenTelemetryCollector resource includes complete Prometheus scrape configurations. It collects control plane health metrics from kubernetes-apiservers, node-level kubelet metrics from kubernetes-nodes, application metrics from kubernetes-pods (for pods with the  prometheus.io/scrape: "true"  annotation), and container resource usage metrics from kubernetes-cadvisor. All metrics receive a  cluster_name  label identifying their source cluster, enabling multi-cluster queries in the shared AMP workspace.
Authentication: Pod Identity provides credentials to ADOT collectors automatically. The IAM role has a trust policy allowing the  pods.eks.amazonaws.com  service principal. When collector pods start, AWS SDKs detect Pod Identity and retrieve temporary credentials without requiring IRSA annotations or OIDC configuration.
Architecture benefits: Separating platform and per-cluster ResourceGraphDefinitions provides clear ownership boundaries. Platform teams control shared infrastructure (workspace, cross-cluster rules) while cluster teams control cluster-specific configuration. Both use the same declarative pattern and GitOps workflows.

How It Works: From YAML to AWS Infrastructure

The solution transforms simple YAML configurations into complete observability infrastructure through three layers:
plaintext
Platform Setup (One-Time):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ObservabilityPlatform YAML (2 parameters)
    ↓
KRO expands → 3 ACK Resources
    ↓
AWS creates → AMP Workspace + Rules + Alerts

Per-Cluster Setup (Repeatable):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ObservabilityCluster YAML (5 parameters)
    ↓
KRO expands → 8 Kubernetes Resources
    ↓
ACK creates → IAM + Pod Identity
ADOT operator → Deploys collectors (DaemonSet)
    ↓
Metrics flow → Amazon Managed Prometheus
Behind the scenes: When you apply an ObservabilityPlatform resource, the Kubernetes API server stores it and the KRO controller reads the observability-platform ResourceGraphDefinitions definition. KRO substitutes your parameters into the template and creates multiple Kubernetes resources: one Workspace resource, one RuleGroupsNamespace for recording rules, and another for alert rules. The ACK Prometheus controller notices these new resources and calls AWS APIs to create the actual AMP workspace and configure the rules.
When you apply an ObservabilityCluster resource, KRO expands it into eight different Kubernetes resources: ServiceAccount, IAM Policy, IAM Role, PodIdentityAssociation, ClusterRole, ClusterRoleBinding, and an OpenTelemetryCollector resource. The ACK controllers create the AWS resources (IAM policy, role, Pod Identity association) while the ADOT operator deploys collector pods as a DaemonSet. Within few seconds of the collectors starting, metrics begin flowing to AMP with correct cluster_name labels.

Metrics Collection Flow

plaintext
EKS Cluster Metrics Sources:                                                    
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
API Server │ kubelet │ Application Pods
  :443     │ :10250  │ /metrics endpoint
           │         │
           └────┬────┘
                ↓
        ADOT Collector (DaemonSet)
        • Scrapes every 30s
        • Adds cluster_name label
        • Authenticates via Pod Identity
                ↓
                │ HTTPS + SigV4
                ↓
    Amazon Managed Prometheus
    • Stores metrics with labels
    • Runs recording rules
    • Evaluates alert rules
                ↓
                │ PromQL queries
                ↓
    Amazon Managed Grafana
    • Cross-cluster dashboards
    • Filter by cluster_name

Prerequisites and Environment Setup

Before starting the implementation, ensure your environment meets the prerequisites.
EKS Cluster version 1.28 or later with EKS Capabilities (ACK, KRO, ArgoCD) enabled
Amazon Managed Grafana workspace created manually via AWS Console or CLI (one-time setup, no ACK controller available for AMG)
AWS permissions to create AMP workspaces/rules, IAM roles/policies, Pod Identity associations, and manage EKS addons
Local tools: AWS CLI, kubectl, Git

Implementation Walkthrough

The following walks through the implementation step by step.

Step 1: Create the Observability Namespace

Create a dedicated Kubernetes namespace for all observability infrastructure:
Bash
kubectl create namespace observability-system

Step 2: Deploy ResourceGraphDefinitions Definitions

Get the ResourceGraphDefinitions definitions into your cluster:
Bash
# Clone the repository
git clone <your-repository-url>
cd <repository-directory>

# Apply the platform ResourceGraphDefinitions
kubectl apply -f kro-resourcegroups/observability-platform.yaml

# Apply the cluster ResourceGraphDefinitions
kubectl apply -f kro-resourcegroups/observability-cluster.yaml
These commands register two new custom resource types in your cluster. After running them,  kubectl api-resources  will show new entries for ObservabilityPlatform and ObservabilityCluster.

Step 3: Deploy the Shared Platform Infrastructure

Deploy the actual shared platform infrastructure:
Bash
# Set environment variables
export AWS_REGION=us-east-1
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# Create the platform configuration file (company-observability.yaml)
cat <<EOF > company-observability.yaml
apiVersion: observability.company.com/v1alpha1
kind: ObservabilityPlatform
metadata:
  name: company-observability
spec:
  workspaceName: company-amp-workspace
  region: us-east-1
EOF

# Apply the platform configuration
kubectl apply -f company-observability.yaml

# Watch the deployment progress
kubectl get observabilityplatform company-observability -w
Within 3-4 minutes, the status should change to ACTIVE with READY true.

Step 4: Add Observability to Your First Cluster

Add observability to an actual cluster:
Bash
# Get the workspace ID
export WORKSPACE_ID=$(kubectl get workspace -n observability-system -o jsonpath='{.items[0].status.workspaceID}')

# Construct the remote write endpoint
export AMP_ENDPOINT="https://aps-workspaces.${AWS_REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/remote_write"

# Create the cluster configuration file (production-cluster.yaml)
cat <<EOF > production-cluster.yaml
apiVersion: observability.company.com/v1alpha1
kind: ObservabilityCluster
metadata:
  name: production-cluster
spec:
  clusterName: production-cluster
  region: us-east-1
  ampWorkspaceID: ${WORKSPACE_ID}
  ampRemoteWriteEndpoint: ${AMP_ENDPOINT}
  accountID: ${AWS_ACCOUNT_ID}
EOF

# Apply the cluster configuration
kubectl apply -f production-cluster.yaml

# Watch the deployment
kubectl get observabilitycluster production-cluster -w

Step 5: Configure Grafana Visualization

Configure Amazon Managed Grafana to visualize metrics:
  1. Log into your AMG workspace through the AWS Console
  1. Navigate to Configuration → Data sources → Add data source
  1. Select Prometheus and configure:
  • URL:  https://aps-workspaces.${AWS_REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}/ 
  • Auth: Enable SigV4 auth
  • SigV4 Auth Details: Select your workspace IAM role
  • Default region: Your AWS region (e.g.,  us-east-1 )
  1. Click Save & Test to verify connectivity

Validating Your Deployment

After deployment, verify all components are working correctly.

Platform Infrastructure Validation

Bash
# Check platform status (should show ACTIVE/READY)
kubectl get observabilityplatform -A
# Expected: company-observability   ACTIVE   True

# Get the workspace ID
kubectl get workspace -n observability-system -o jsonpath='{.items[0].status.workspaceID}'

# Verify in AWS
aws amp list-workspaces --region us-east-1
The ACK Prometheus controller creates the AMP workspace with status ACTIVE.

Per-Cluster Validation

Bash
# Check cluster status (should show ACTIVE/READY)
kubectl get observabilitycluster -A
# Expected: production-cluster   ACTIVE   True

# Verify ADOT collectors running (should see one per node)
kubectl get pods -n observability-system
# Expected: adot-collector-xxxxx   1/1   Running

# View collector logs to confirm metrics are being sent
kubectl logs -n observability-system -l app.kubernetes.io/component=opentelemetry-collector

Metrics Flow Verification

Bash
# Query AMP for metrics from your cluster
aws amp query \
  --workspace-id $WORKSPACE_ID \
  --query-string 'up{cluster_name="production-cluster"}' \
  --region $AWS_REGION
You should see results showing scrape targets like  kubernetes-apiservers  and  kubernetes-nodes  with values of 1, confirming successful metric collection.

Using Grafana

In Grafana's Explore view, test these queries:
  •  up{cluster_name="production-cluster"}  - verify connectivity
  • Build dashboards showing cluster health, resource utilization, and application performance

GitOps Automation with ArgoCD

ArgoCD automates observability rollout across clusters, watching Git and automatically applying changes:
plaintext
Git Repository (Single Source of Truth)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
kro-resourcegroups/          examples/clusters/
• platform.yaml              • production/
• cluster.yaml               • staging/
                             • development/
        │
        │ git push
        ↓
    ArgoCD (Running in EKS)
    • Application: observability-platform
    • ApplicationSet: auto-discovers cluster dirs
    • Automated sync + self-heal
        │
        │ kubectl apply (automated)
        ↓
    ┌─────────┬─────────┬─────────┐
    │         │         │         │
Production  Staging  Development  ...
    │         │         │
    └─────────┴─────────┘
            │
            ↓
    Amazon Managed Prometheus
    (Unified workspace)
Why ArgoCD matters: With ArgoCD's ApplicationSet, adding a new cluster is as simple as creating a directory in  examples/clusters/my-new-cluster/  with the cluster YAML. ArgoCD automatically detects the new directory, creates an Application, and deploys the full monitoring stack, no manual intervention required.

Setting Up ArgoCD ApplicationSet

The repository includes ArgoCD configurations:
Bash
# Deploy platform Application (syncs examples/platform/)
kubectl apply -f argocd/platform-app.yaml

# Deploy cluster ApplicationSet (auto-discovers examples/clusters/*/)
kubectl apply -f argocd/clusters-appset.yaml
The ApplicationSet watches the Git repository structure. When you commit a new cluster directory, ArgoCD automatically creates and syncs an Application for it.

Scaling to Additional Clusters

Adding additional clusters is straightforward and takes the same amount of time whether it's your second or twentieth cluster.

Manual Deployment Process

To add another cluster manually:
  1. Copy an existing ObservabilityCluster configuration file
  1. Update three values:
  •  metadata.name  - unique identifier
  •  spec.clusterName  - your actual EKS cluster name
  •  spec.region  - if deploying to a different region
  1. Apply the configuration:  kubectl apply -f new-cluster.yaml 
Everything else remains unchanged because you're using the same shared AMP workspace, the same remote write endpoint pattern, and the same AWS account. Within minutes, metrics from the new cluster start appearing in your shared AMP workspace with the correct cluster_name label.

GitOps Deployment Process

With ArgoCD configured:
  1. Create  examples/clusters/new-cluster/cluster.yaml 
  1. Commit and push to Git
  1. ArgoCD automatically discovers and deploys
No manual kubectl commands required.
Because deployment is declarative and collectors start sending metrics immediately, migration typically requires zero downtime, no maintenance windows needed.

Operational Benefits and Cost Efficiency

This approach provides concrete operational advantages that compound as your infrastructure scales.

Repeatability and Consistency

Adding monitoring to a new cluster requires copying an ObservabilityCluster YAML file, updating five parameters (cluster name, region, workspace ID, endpoint, account ID), and running kubectl apply. The process is identical whether you're adding your second or your twentieth cluster. The effort doesn't scale with cluster count.
Every cluster deploys from the same ResourceGraphDefinitions definition, ensuring all clusters scrape the same metrics at the same intervals with the same labels. This eliminates the configuration drift that plagues manually configured environments where each cluster potentially has slightly different monitoring setups.

Centralized Management

Updates to monitoring configuration happen centrally through the ResourceGraphDefinitions definitions. When you need to add new recording rules, adjust scrape intervals, or update alert thresholds, you modify the ResourceGraphDefinitions once and re-apply cluster configurations. Changes propagate consistently across all clusters in minutes rather than requiring hours of manual per-cluster updates.
Platform teams manage two ResourceGraphDefinitions definitions instead of maintaining separate monitoring configurations for each cluster. This centralization dramatically reduces operational overhead.

GitOps Integration

Both ResourceGraphDefinitions definitions and cluster instance files can be managed in Git repositories, enabling standard development practices like code review, version control, and automated deployment through ArgoCD. Monitoring infrastructure becomes code that follows the same change management processes as your applications.

Reduced Expertise Requirements

Platform abstractions significantly reduce the expertise required to deploy monitoring. The complexity of IAM policies, ADOT configurations, Prometheus scrape configs, and RBAC permissions is hidden behind simple ResourceGraphDefinitions parameters. Engineers who can edit YAML files and run kubectl commands can deploy monitoring without needing deep expertise in each underlying component. This democratization reduces bottlenecks and improves team velocity.

Unified Visibility

The shared AMP workspace architecture provides unified visibility across all clusters. The cluster_name label on every metric enables dashboards that span your entire infrastructure. Cross-cluster queries and aggregations work natively without requiring federation or custom tooling. Questions about overall platform health that previously required manual correlation across multiple data sources now work through standard PromQL queries.

Beyond Observability: A Pattern for Platform Engineering

The observability solution demonstrated in this post is just one example of how EKS Capabilities can simplify complex operational patterns. The combination of managed ACK, managed KRO, and GitOps automation provides a powerful foundation for building reusable platform patterns.
Observability is the beginning, not the end. The same architectural approach—defining simple, high-level abstractions that expand into properly configured AWS and Kubernetes resources—applies to many other platform engineering challenges:
Security patterns: Imagine an  ApplicationSecurity  ResourceGraphDefinitions that deploys AWS WAF rules, network policies, pod security policies, and AWS Config rules with a single YAML file. Security teams define the pattern once, application teams consume it without deep security expertise.
Onboarding patterns: Consider a  TeamOnboarding  ResourceGraphDefinitions that provisions namespaces, RBAC roles, resource quotas, network policies, service accounts, and cost allocation tags. New teams get production-ready environments in minutes instead of days.
Multi-tenancy patterns: Envision a  Tenant  ResourceGraphDefinitions that creates isolated namespaces, dedicated IAM roles, separate S3 buckets, RDS instances, and Kafka topics with proper security boundaries. Multi-tenant platforms become manageable at scale.
Notice the pattern: just like ObservabilityPlatform (2 parameters) + ObservabilityCluster (5 parameters), each of these follows the same structure. TeamOnboarding would have TeamPlatform (shared quotas, cost center setup) + TeamWorkspace (per-team namespace, RBAC, resources). ApplicationSecurity would have SecurityPlatform (shared WAF, Config rules) + ApplicationSecurityProfile (per-app policies, network rules). The two-tier model—shared platform infrastructure plus per-instance configuration—is the blueprint pattern that scales.
These blueprints share common characteristics: they hide complexity behind simple interfaces, ensure consistency through declarative configuration, enable self-service for development teams, and maintain central control for platform teams.

Conclusion

EKS Capabilities transforms how platform teams manage infrastructure across multiple clusters. By providing managed ACK, KRO and ArgoCD as built-in EKS features, AWS enables Kubernetes-native management of AWS resources without additional operational overhead.
The observability solution demonstrated in this post serves as a concrete example of this transformation. We've shown how to address the core challenges of multi-cluster management configuration drift, operational overhead, and fragmented visibility through declarative ResourceGraphDefinitions that hide complexity while ensuring consistency. Platform teams define monitoring patterns once, development teams deploy with a single kubectl apply, and ArgoCD automates the entire lifecycle.
But the real value extends far beyond observability. The same pattern high-level abstractions that expand into properly configured AWS and Kubernetes resources applies to security enforcement, team onboarding, multi-tenancy isolation, disaster recovery, and countless other platform engineering challenges. Each follows the same model: define the pattern once, consume it anywhere, maintain centrally, deploy consistently.
This is platform engineering at its best: building reusable blueprints that make complex operations simple and consistent, enabling self-service without sacrificing control, and scaling your platform team's impact far beyond what manual approaches allow. The observability blueprint provides a proven pattern you can replicate for security, onboarding, databases, multi-tenancy, and other platform engineering challenges.

Additional Resources

The complete implementation including ResourceGraphDefinitions definitions, cluster examples, and validation scripts is available in this repository.
For deeper learning:
Update: This observability pattern has been expanded into a complete enterprise platform covering security, team onboarding, compute, backup, certificates, and cost visibility. Read the full guide:  Beyond Observability: Building a Complete Self-Service EKS Platform with KRO and ACK 

About the Author

Samar 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 
# amazon-eks# monitoring-observability
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