EKS Migration Guide

Enterprise EKS Auto Mode Migration Roadmap

From On-Premises to Fully Managed Kubernetes with EKS Auto Mode

A Comprehensive Guide by Ditah Kumbong, ZSoftly Technologies Inc.

December 2025

Notices

This document is provided for informational purposes only. It represents ZSoftly Technologies Inc.'s current product offerings and practices as of the date of publication, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of ZSoftly's services.

This document does not create any warranties, representations, contractual commitments, conditions, or assurances from ZSoftly Technologies Inc., its affiliates, suppliers, or licensors.

Trademarks

• Amazon Web Services, AWS, Amazon EKS, and related services are trademarks of Amazon.com, Inc. or its affiliates.
• Kubernetes is a registered trademark of The Linux Foundation.
• SigNoz, Falco, Trivy, and ArgoCD are open-source projects under their respective licenses.
• All other trademarks are the property of their respective owners.

Third-Party Content

This document references third-party open-source tools (SigNoz, Falco, Trivy, ArgoCD). ZSoftly Technologies Inc. is not responsible for the content, accuracy, or functionality of these third-party tools. Users should review the respective project documentation and licenses.

Table of Contents

1. Executive Summary
2. The Challenge
3. Solution Architecture Overview
4. Open-Source Technology Stack
5. Implementation Roadmap
   • Phase 1: AWS Foundation
   • Phase 2: EKS Auto Mode Clusters
   • Phase 3: GitOps with ArgoCD
   • Phase 4: Open-Source Observability
   • Phase 5: Open-Source Security
   • Phase 6: Metrics Server & HPA
   • Phase 7: CI/CD Pipeline
   • Phase 8: Application Migration
   • Phase 9: Disaster Recovery
   • Phase 10: Handover & Training
6. Investment Framework
7. Success Criteria
8. Why ZSoftly
9. Next Steps
10. Contact Us
11. Appendix: Compliance Control Mapping
12. Sources

Executive Summary

Organizations running Kubernetes on-premises face real challenges: aging infrastructure, scaling limitations, security compliance burdens, and the constant operational overhead of cluster management. This guide provides a proven roadmap for migrating to Amazon EKS Auto Mode. You get fully managed infrastructure, automated node provisioning, and production-ready security with open-source tooling.

Why EKS Auto Mode?

EKS Auto Mode changes how you manage Kubernetes. AWS now manages Karpenter, ALB Controller, and EBS CSI Driver off-cluster, removing the operational burden of maintaining these critical components. Combined with Bottlerocket OS and open-source observability and security tools, you get enterprise capabilities without vendor lock-in.

Key Benefits

Target Outcomes

• Infrastructure as Code: 100% coverage
• Deployment Frequency: Multiple deployments per day
• Change Failure Rate: < 5%
• Mean Time to Recovery: < 30 minutes
• Vendor Lock-in: Minimized with open-source tooling

Who Should Read This Guide

• CTOs & VP Engineering: Strategic business case and ROI framework
• Platform Engineers: Technical architecture and implementation details
• DevOps Teams: GitOps workflows and operational procedures
• Security Teams: Open-source security stack and compliance

The Challenge

On-Premises Limitations

Organizations operating Kubernetes on-premises commonly face:

Infrastructure Constraints

• Hardware refresh cycles creating technical debt
• Limited capacity for sudden scaling demands
• High capital expenditure for peak capacity planning
• Data center operational overhead

Operational Burden

• Kubernetes version upgrades requiring significant planning
• Node patching and security remediation delays
• Managing Karpenter, Ingress Controllers, CSI drivers
• Limited observability across distributed workloads

Vendor Lock-in Concerns

• Expensive proprietary APM tools (Dynatrace, Datadog)
• Costly runtime security solutions (CrowdStrike, Sysdig)
• Limited flexibility for multi-cloud strategies

Business Impact of Current State

Solution Architecture Overview

EKS Auto Mode: What AWS Manages

With EKS Auto Mode, critical Kubernetes components run off-cluster in the AWS control plane:

EKS Auto Mode Managed Components:

Understanding where components run is critical for capacity planning and troubleshooting:

EKS Capabilities (Opt-in Features):

EKS Capabilities are AWS-managed features that run within EKS rather than in your clusters—zero pods on your worker nodes. You explicitly enable these via aws eks create-capability or eksctl create capability.

Enable EKS Capabilities:

# AWS CLI
aws eks create-capability --cluster-name my-cluster --capability-name argo-cd
aws eks create-capability --cluster-name my-cluster --capability-name ack
aws eks create-capability --cluster-name my-cluster --capability-name kro

# eksctl
eksctl create capability --cluster my-cluster --capability argo-cd

Key Distinction:

• Off-cluster components consume no node resources—they run entirely in AWS infrastructure
• In-cluster components run as pods/DaemonSets—they consume CPU/memory on your nodes
• EKS Capabilities run within EKS (not in your cluster)—zero pods on worker nodes

Note: Amazon Managed Prometheus (AMP) and Amazon Managed Grafana are separate AWS services, not EKS Capabilities. They integrate with EKS but are provisioned independently.

Self-Managed Components (deploy via ArgoCD):

Data Persistence (Outside Cluster):

Multi-Account Strategy

Bottlerocket: Secure Node Operating System

EKS Auto Mode uses Bottlerocket exclusively. This purpose-built Linux OS for containers provides:

Built-in NodePools

EKS Auto Mode provides two built-in NodePools:

Open-Source Technology Stack

Observability: SigNoz

Why SigNoz over Datadog/Dynatrace?

SigNoz Architecture:

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#E85D04', 'lineColor': '#E85D04', 'background': '#fff'}}}%%
flowchart LR
    APP[Apps] -->|OTLP| COLL[Collectors]
    COLL --> DB[(ClickHouse)]
    DB --> UI[Dashboard]

    style APP fill:#fff,stroke:#E85D04,color:#1f2937
    style COLL fill:#E85D04,stroke:#9D4402,color:#fff
    style DB fill:#9D4402,stroke:#E85D04,color:#fff
    style UI fill:#E85D04,stroke:#9D4402,color:#fff

K8s-Infra Helm Chart Capabilities:

• Tails and parses container logs in real-time
• Gathers distributed traces from Kubernetes workloads
• Collects kubelet and host metrics
• Gathers cluster-level metrics from API server
• Out-of-the-box Kubernetes dashboards

Enterprise Alternatives:

For organizations requiring vendor-supported solutions:

• Datadog - Full-featured APM with strong dashboards, per-host licensing (~$30-50/host/mo)
• Dynatrace - AI-powered root cause analysis, per-host licensing (~$30-50/host/mo)

Security: Falco + Trivy

Why Falco over CrowdStrike?

Falco Runtime Security Architecture:

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#00BFA5', 'lineColor': '#00BFA5', 'background': '#fff'}}}%%
flowchart LR
    EBPF[eBPF] --> RULES[Rules]
    RULES --> ALERTS[Alerts]
    ALERTS --> OUT[SigNoz/Slack]

    style EBPF fill:#00BFA5,stroke:#00897B,color:#fff
    style RULES fill:#00BFA5,stroke:#00897B,color:#fff
    style ALERTS fill:#fff,stroke:#00BFA5,color:#1f2937
    style OUT fill:#fff,stroke:#00BFA5,color:#1f2937

Falco Detection Capabilities:

• Container escape attempts
• Privilege escalation
• Cryptomining detection
• Unexpected network connections
• File system tampering
• Kubernetes audit events

Trivy Security Scanning:

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#1A73E8', 'lineColor': '#1A73E8', 'background': '#fff'}}}%%
flowchart LR
    IMG[Images] --> SCAN[Scan]
    SCAN --> RPT[Reports]
    POD[Pods] --> ADM[Admit]
    ADM --> K8S[K8s]

    style IMG fill:#fff,stroke:#1A73E8,color:#1f2937
    style SCAN fill:#1A73E8,stroke:#0D47A1,color:#fff
    style RPT fill:#fff,stroke:#1A73E8,color:#1f2937
    style POD fill:#fff,stroke:#1A73E8,color:#1f2937
    style ADM fill:#1A73E8,stroke:#0D47A1,color:#fff
    style K8S fill:#0D47A1,stroke:#1A73E8,color:#fff

Enterprise Alternatives:

For organizations requiring vendor-supported security solutions:

• CrowdStrike Falcon - Industry-leading EDR/XDR with Kubernetes support, managed threat intelligence, 24/7 SOC (~$20-40/node/mo)
• Prisma Cloud - Palo Alto's CNAPP platform, image scanning + runtime protection
• Sysdig Secure - Kubernetes-native security with Falco compatibility

Secrets Management: External Secrets Operator

Why External Secrets Operator (ESO)?

Kubernetes Secrets stored in Git (even encrypted) create security and operational challenges. External Secrets Operator solves this by syncing secrets from AWS Secrets Manager directly into Kubernetes, keeping sensitive data out of your repositories.

ESO Architecture:

How It Works:

1. Store secrets in AWS Secrets Manager - Database credentials, API keys, certificates
2. Create ExternalSecret resources - Reference the secret path in Secrets Manager
3. ESO syncs automatically - Controller creates/updates Kubernetes Secrets
4. Pods consume normally - Mount as environment variables or volumes

Secret Organization Strategy:

Benefits:

• Zero secrets in Git - Only ExternalSecret manifests referencing paths
• Automatic rotation - Update Secrets Manager, ESO syncs within minutes
• Least-privilege access - Each cluster only accesses its environment's secrets
• Audit compliance - CloudTrail logs all secret access

Implementation Roadmap

Timeline (5-6 Months)

Base Duration: 20 weeks (5 months) for 5 applications. Additional apps add ~1-2 weeks each, extending to 24+ weeks for larger portfolios.

Phase 1: AWS Foundation (Weeks 1-2)

Objectives:

• Establish multi-account structure
• Configure networking foundation
• Set up IAM roles with least-privilege policies

Key Deliverables:

• AWS Organizations setup with Service Control Policies (SCPs)
• VPC per environment with proper CIDR planning
• VPC Endpoints for private AWS API access
• Cross-account IAM roles for deployments
• KMS keys for EBS encryption

Network Architecture:

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#232F3E', 'lineColor': '#232F3E', 'background': '#fff'}}}%%
flowchart LR
    IGW[Internet] --> PUB[Public]
    PUB --> PRIV[Private]
    PRIV --> EKS[EKS]
    VPCE[VPC Endpoints] --> AWS[AWS APIs]

    style IGW fill:#fff,stroke:#232F3E,color:#232F3E
    style PUB fill:#2563EB,stroke:#1E40AF,color:#fff
    style PRIV fill:#232F3E,stroke:#2563EB,color:#fff
    style EKS fill:#232F3E,stroke:#2563EB,color:#fff
    style VPCE fill:#fff,stroke:#232F3E,color:#232F3E
    style AWS fill:#2563EB,stroke:#1E40AF,color:#fff

Secure Access to Private Cluster:

The EKS cluster uses private endpoints only—the Kubernetes API server is not exposed to the public internet. Developers and CI/CD pipelines access the cluster through secure VPN connectivity.

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#232F3E', 'lineColor': '#232F3E', 'background': '#fff'}}}%%
flowchart LR
    DEV[Users] --> GW[WireGuard/Zscaler]
    GW --> EKS[EKS Private API]

    style DEV fill:#fff,stroke:#232F3E,color:#232F3E
    style GW fill:#2563EB,stroke:#1E40AF,color:#fff
    style EKS fill:#232F3E,stroke:#232F3E,color:#fff

VPN Options:

Open-Source Recommendation: WireGuard

• Kernel-level performance (faster than OpenVPN)
• Simple configuration with public key cryptography
• Deploy on EC2 instance or container in VPC
• No licensing costs

Enterprise Recommendation: Zscaler ZPA

• Zero trust network access (ZTNA)
• Identity-aware policies (Okta, Azure AD integration)
• No inbound firewall rules required
• Compliance-ready (SOC 2, HIPAA)

Phase 2: EKS Auto Mode Clusters (Weeks 3-4)

Objectives:

• Deploy EKS Auto Mode clusters
• Configure built-in NodePools
• Enable managed add-ons

What EKS Auto Mode Provides:

Cluster Configuration:

NodePool Configuration:

Custom NodePools can be created for specialized workloads such as GPU instances (g5.xlarge, g5.2xlarge, p4d.24xlarge) with on-demand capacity type, CPU limits of 1000, and consolidation policies.

Deliverables:

• EKS Auto Mode cluster per environment
• Custom NodePools for GPU/specialized workloads
• CloudWatch log groups configured
• EKS access entries for admin roles

Phase 3: GitOps with ArgoCD (Weeks 4-5)

Objectives:

• Deploy ArgoCD (managed or self-hosted)
• Implement app-of-apps pattern
• Configure environment-specific deployments

Option A: EKS Capability for ArgoCD (Recommended)

AWS manages ArgoCD in the control plane:

• No ArgoCD pods on worker nodes
• AWS handles Git/Helm registry access
• Automatic scaling and updates
• Native integration with AWS IAM Identity Center

Option B: Self-Hosted ArgoCD

Deploy via Helm for full customization control.

AWS IAM Identity Center (SSO) Integration

For organizations using AWS IAM Identity Center (formerly AWS SSO) for user and account management, the EKS ArgoCD Capability provides seamless authentication without additional configuration.

How It Works:

Benefits for Identity Center Customers:

• Zero additional IdP configuration - No need to set up OIDC providers or SAML connections
• Unified access management - Same groups/users manage AWS console, CLI, and ArgoCD
• Automatic provisioning - New Identity Center users inherit ArgoCD access via group membership
• Consistent MFA - Identity Center MFA policies apply to ArgoCD access
• Centralized offboarding - Disable user in Identity Center, ArgoCD access revoked immediately

RBAC Mapping Example:

Self-Hosted ArgoCD with Identity Center:

If you choose self-hosted ArgoCD (Option B), you can still integrate with Identity Center:

1. Configure Identity Center as an OIDC provider
2. Set up ArgoCD Dex connector for OIDC
3. Map Identity Center groups to ArgoCD RBAC policies

This requires additional configuration but provides the same SSO experience.

App-of-Apps Pattern:

Phase 4: Open-Source Observability (Weeks 5-6)

Objectives:

• Deploy SigNoz for unified observability
• Configure OpenTelemetry collectors
• Set up dashboards and alerting

SigNoz Deployment via ArgoCD:

SigNoz is deployed using the official Helm chart from charts.signoz.io with AWS cloud configuration, cluster name settings, and OpenTelemetry collector endpoint configuration. The deployment uses automated sync with prune and self-heal enabled.

K8s-Infra Collectors:

The K8s-Infra Helm chart is deployed alongside SigNoz to collect infrastructure metrics, logs, and traces from all Kubernetes workloads with AWS cloud configuration.

Included Capabilities:

• Pod-level CPU/memory usage, restarts, saturation
• P90/P99 latency, request throughput, error rates
• Unified correlation of logs, traces, and metrics
• Custom dashboards for EKS Auto Mode
• Real-time distributed tracing

Enterprise Alternatives:

For organizations requiring vendor-supported APM:

• Datadog - Deploy Datadog Agent DaemonSet via Helm
• Dynatrace - Deploy OneAgent Operator for auto-instrumentation

Phase 5: Open-Source Security (Weeks 6-7)

Objectives:

• Deploy Falco for runtime security
• Deploy Trivy for image scanning
• Configure admission control

Falco Deployment:

Falco is deployed via ArgoCD using the official Helm chart with modern eBPF driver, Falcosidekick for alert routing to SigNoz, and custom rules for detecting shell access in containers.

Trivy Operator Deployment:

Trivy Operator is deployed via ArgoCD to automatically scan all container images in the cluster, reporting CRITICAL and HIGH severity vulnerabilities with ConfigAudit scanning enabled.

Admission Controller (Optional):

Enable webhook-based admission control to block vulnerable images at deploy time with a Fail policy.

Phase 6: Metrics Server & HPA (Weeks 7-8)

Objectives:

• Deploy Metrics Server for resource metrics
• Configure Horizontal Pod Autoscaler (HPA) for data-driven scaling
• Establish scaling policies per application

Why Metrics Server + HPA:

EKS Auto Mode manages node scaling via Karpenter, but pod scaling requires Metrics Server and HPA for data-driven autoscaling based on your organization's actual traffic patterns.

Metrics Server Deployment:

Metrics Server is deployed via ArgoCD to collect CPU and memory metrics from kubelets, enabling HPA to make scaling decisions based on real-time resource utilization.

HPA Configuration per Application:

Each application Helm chart includes HPA configuration with:

• Min/max replica counts based on workload requirements
• CPU threshold (e.g., scale at 70% CPU utilization)
• Memory threshold (optional)
• Custom metrics from SigNoz (requests per second, latency)

Scaling Architecture:

Phase 7: CI/CD Pipeline (Weeks 8-9)

Objectives:

• Configure GitLab/GitHub Actions for infrastructure
• Implement promotion workflows
• Set up security scanning in pipeline
• Configure private ECR registry with cross-region replication

Pipeline Stages:

The CI/CD pipeline consists of four stages: validate (terraform fmt, validate, trivy scan), build (terraform plan), deploy (terraform apply), and security (trivy image scan).

GitOps Deployment Flow:

Private ECR Registry Setup

All container images are stored in AWS ECR private repositories, created and managed via Terraform. This ensures consistent image management, security scanning, and cross-region availability for disaster recovery.

ECR Infrastructure (Terraform):

ECR Cross-Region Replication (Prod):

For production, ECR replication is configured between ca-central-1 (primary) and ca-west-1 (DR). Images pushed to the primary region automatically replicate to the DR region, ensuring container images are available for failover.

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#232F3E', 'lineColor': '#232F3E', 'background': '#fff'}}}%%
flowchart LR
    CI[CI/CD] --> SCAN[Trivy Scan]
    SCAN --> ECR1[ECR ca-central-1]
    ECR1 -.-> ECR2[ECR ca-west-1]

    style CI fill:#fff,stroke:#232F3E,color:#232F3E
    style SCAN fill:#1A73E8,stroke:#0D47A1,color:#fff
    style ECR1 fill:#232F3E,stroke:#2563EB,color:#fff
    style ECR2 fill:#2563EB,stroke:#1E40AF,color:#fff

CI/CD Image Pipeline:

1. Build: Docker image built from Dockerfile
2. Scan: Trivy scans image for CRITICAL/HIGH vulnerabilities
3. Push: Image pushed to ECR ca-central-1 with semantic version tag
4. Replicate: ECR automatically replicates to ca-west-1 (prod only)
5. Deploy: ArgoCD detects new image tag, syncs to cluster

IAM Policies:

Lifecycle Policy:

ECR lifecycle policies automatically clean up untagged images and retain only the most recent tagged versions, reducing storage costs and maintaining a clean registry.

Phase 8: Application Migration (Weeks 9-16)

Objectives:

• Migrate 5 organization applications to EKS via Helm charts
• Implement data-driven autoscaling with HPA
• Deploy via GitOps with environment promotion

Scope: 5 Applications

This phase migrates 5 company applications. Timeline scales with application count:

Per-Application Helm Chart Includes:

• Deployment with resource requests/limits
• Service and Ingress configuration
• HPA with CPU/memory thresholds
• ConfigMaps and Secrets (via External Secrets Operator)
• Health checks (liveness, readiness, startup probes)
• OpenTelemetry auto-instrumentation for SigNoz
• Network policies

Migration Approach: Strangler Fig Pattern

1. Create Helm chart for application
2. Deploy to dev → validate with SigNoz metrics
3. Promote to qat → load testing, tune HPA thresholds
4. Promote to stg → production-like validation
5. Promote to prod → DNS cutover, monitor
6. Decommission on-prem instance

Per-Application Checklist:

• Containerize application (Dockerfile)
• Create Helm chart with values per environment
• Configure HPA with org-specific scaling thresholds
• Add OpenTelemetry instrumentation
• Validate in dev → qat → stg → prod
• DNS cutover and decommission legacy

Migration Pitfalls & Risk Mitigation

Common challenges encountered during Kubernetes migrations and how to avoid them:

Database Migration Timing:

StatefulSet Challenges:

• Persistent Volume migration - EBS volumes are AZ-specific; plan for data migration
• Pod identity - StatefulSets expect stable network identities; test DNS resolution
• Ordered scaling - Pods scale sequentially; factor into HPA response time

DNS & Traffic Cutover:

Rollback Strategy:

Every application migration should have a documented rollback procedure:

1. Pre-cutover: On-prem and EKS running in parallel
2. Cutover: DNS points to EKS, on-prem remains available
3. Validation: 24-48 hours monitoring in production
4. Decommission: Only after successful validation period
5. Emergency rollback: DNS revert to on-prem (< 5 min)

Resource Sizing Mistakes:

Security Oversights:

• Running as root - Use securityContext.runAsNonRoot: true
• Missing network policies - Default allow-all; implement deny-by-default
• Secrets in environment vars - Visible in pod describe; use volume mounts
• No pod security standards - Enable Pod Security Admission (restricted)

Phase 9: Disaster Recovery (Weeks 16-18)

Objectives:

• Prepare DR infrastructure as code
• Configure cross-region data replication
• Establish failover procedures

DR Strategy: Cold Standby

Only ca-central-1 runs at all times. The DR region (ca-west-1) uses cold standby—no running compute resources. Infrastructure is defined in Terraform and apps in ArgoCD, ready to deploy on demand. Only the EKS control plane runs continuously to enable rapid cluster bootstrapping during failover.

What's Pre-Configured (Git-Tracked):

Multi-Region Architecture (Prod Account):

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#232F3E', 'lineColor': '#232F3E', 'background': '#fff'}}}%%
flowchart LR
    GIT[(Git)] --> PRD[ca-central-1]
    GIT -.-> DR[ca-west-1]
    PRD --> DR

    style GIT fill:#fff,stroke:#232F3E,color:#232F3E
    style PRD fill:#232F3E,stroke:#232F3E,color:#fff
    style DR fill:#2563EB,stroke:#1E40AF,color:#fff

RTO: 30 Minutes

Failover procedure:

1. Detect ca-central-1 failure (Route53 health checks)
2. Run terraform apply to provision ca-west-1 compute nodes and networking (~10 min)
3. ArgoCD syncs app-of-apps from Git (~5 min)
4. Restore RDS from latest snapshot (~10 min)
5. Update Route53 to ca-west-1 endpoints
6. Verify application health

Note: EKS control plane already running in DR region enables rapid node provisioning.

RPO: 24 Hours (daily RDS snapshots, continuous ECR replication)

Phase 10: Handover & Training (Weeks 18-20)

Documentation Deliverables:

Training Topics:

• EKS Auto Mode cluster management
• HPA tuning and scaling policies
• SigNoz dashboards and alerting
• Falco rule customization
• Trivy vulnerability remediation
• ArgoCD GitOps workflows
• Incident response with open-source tools

Investment Framework

Infrastructure Costs (Monthly Estimate)

Assumptions:

• Region: ca-central-1 (primary), ca-west-1 (DR)
• 5 containerized applications
• On-Demand pricing (before Savings Plans)
• Prices as of December 2025

Compute - EC2 Node Pools

DR uses cold standby - no running compute until failover

EKS Control Plane

EKS Auto Mode: $0.10/hr per cluster ($0.10 × 730 hrs = $73/cluster/month)

Storage - EBS Volumes

Networking

DR uses cold standby - no ALB or NAT Gateway until failover. Only VPC Endpoints for ECR replication.

Observability & Monitoring

SigNoz storage included in EBS costs above

Cost Summary

Total Monthly: ~$2,697 (On-Demand pricing)

With Compute Savings Plans (1-year, no upfront): ~$1,750/mo (35% savings)

DR uses cold standby strategy - only EKS control plane ($73) and minimal VPC endpoints ($15) run continuously. Full DR infrastructure deploys on-demand during failover.

Open-Source vs. Proprietary Savings

Annual Savings: ~$53,000 with open-source tooling

Proprietary pricing based on typical enterprise contracts with full feature suites (December 2025). Actual costs vary by vendor negotiation and feature selection.

Cost Optimization Strategies

Beyond open-source tooling savings, EKS Auto Mode enables additional cost optimization through intelligent node management and AWS pricing models.

Spot Instances for Non-Production:

Karpenter Consolidation (Managed by EKS Auto Mode):

EKS Auto Mode's managed Karpenter automatically consolidates workloads to reduce node count:

• Bin packing - Efficiently schedules pods to maximize node utilization
• Node consolidation - Removes underutilized nodes during low-traffic periods
• Right-sizing - Selects optimal instance types based on workload requirements
• Spot interruption handling - Gracefully migrates pods before Spot termination

Reserved Capacity for Production:

For predictable production workloads, combine On-Demand with Savings Plans:

Cost Monitoring:

• AWS Cost Explorer - Tag-based cost allocation per environment/application
• Kubecost (open-source) - Kubernetes-native cost visibility per namespace/workload
• SigNoz dashboards - Correlate cost with performance metrics

Estimated Monthly Savings with Optimization:

Success Criteria

Why ZSoftly

Our Expertise

EKS Auto Mode Specialists

• Early adopters of EKS Auto Mode since GA (December 2024)
• Certified Kubernetes Administrators (CKA)
• AWS Container Services expertise

Open-Source Champions

• SigNoz deployment experience
• Falco rule customization experts
• OpenTelemetry implementation specialists

Canadian-Based Team

• Local presence for Canadian enterprises
• Understanding of Canadian compliance requirements
• Responsive support in your timezone

Our Services

Learn more: zsoftly.com/services/containers

Next Steps

1. Discovery Workshop

Schedule a discovery session to review your current architecture and migration requirements.

2. Assessment

Receive a detailed assessment of your EKS Auto Mode readiness and recommended approach.

3. Proof of Concept

Deploy a development cluster with SigNoz, Falco, and sample application.

4. Engagement

Finalize scope and begin your migration journey.

Contact Us

ZSoftly Technologies Inc.

Appendix: Compliance Control Mapping

This architecture supports common compliance frameworks. The table below maps key controls to specific components.

SOC 2 Type II Controls

PCI-DSS v4.0 Requirements

HIPAA Technical Safeguards

Shared Responsibility Note

Sources

• EKS Auto Mode Best Practices
• Under the Hood: Amazon EKS Auto Mode
• EKS Auto Mode Security Overview
• SigNoz Kubernetes Observability
• Falco Cloud Native Runtime Security
• Trivy Security Scanner
• EKS Blueprints with Auto Mode