Kubernetes consulting: EKS and AKS, in the right place and for the right reasons

The real question: do you need Kubernetes?

Kubernetes is worth adopting only if its benefits outweigh a real operational burden. It has become the standard for container orchestration, and its ecosystem is vast. It also demands regular version upgrades, add-ons to maintain (ingress, DNS, certificates, autoscaling, storage), cluster security and scarce skills. We see teams adopt Kubernetes for a few applications and spend more time operating the platform than shipping their product.

Our first job is therefore to help you decide, without bias. Kubernetes has a place in your architecture if several of these conditions are met:

• a large number of containerised services, deployed often, by several teams;
• a need for portability across clouds or with on-premises hosting;
• needs the Kubernetes ecosystem covers well: operators, batch processing, GPU workloads, an internal developer platform;
• a team, in-house or supported, ready to operate the platform over the long term.

Otherwise, simpler container services often do the job better.

Kubernetes or alternatives: compare before you choose

Option	Strengths	Limitations	Typical use case
Amazon EKS	Standard Kubernetes, full ecosystem, AWS IAM and network integration	Demanding operations, upgrades to plan	Microservices estate, internal platform on AWS
Azure AKS	Standard Kubernetes, Entra ID and Azure network integration	Same operational demands	Microservices estate on Azure
Amazon ECS (with or without Fargate)	Simple to operate, tightly integrated with AWS	AWS-specific, smaller ecosystem	A few to several dozen services on AWS
Azure Container Apps	Serverless, automatic scaling, little to operate	Less fine-grained control	Web applications and APIs on Azure

The choice is not final, but it is a commitment: tooling, skills and operating costs depend on it. We document the decision and its criteria so it can be revisited.

What we build on EKS and AKS

Reproducible clusters

Clusters, node groups, networking and add-ons are described in Terraform and Infrastructure as Code, versioned and deployed through a pipeline. A cluster must be rebuildable, which also makes version upgrades easier: you can test on a fresh cluster before switching over.

GitOps deployment

Application manifests or Helm charts live in Git; Argo CD or Flux keeps the cluster in sync with the repository. Teams deploy through merge requests, Git history becomes the change log, and manual changes in the cluster are detected and corrected.

Observability

Metrics, logs and traces are centralised: Prometheus and Grafana, OpenTelemetry, or the native services (Amazon CloudWatch Container Insights, Azure Monitor), depending on what you already use. We define the useful dashboards and alerts with you: node saturation, crash loops, latency and errors per service, rather than a flood of ignored alerts.

Security

• Cluster access through cloud identities (IAM, Entra ID), Kubernetes roles on least privilege.
• Workload identities so pods can reach cloud services without stored secrets (EKS Pod Identity or IRSA, Workload Identity on AKS).
• Pod Security Standards, network policies, admission controllers (Kyverno or OPA Gatekeeper) to reject unapproved images or privileged containers.
• Image scanning in CI and a private registry.

These rules fit into your overall cloud security and governance.

Costs

Resource requests and limits calibrated on observed usage, pod and node autoscaling (Karpenter or Cluster Autoscaler on AWS, the cluster autoscaler on AKS), Spot Instances for tolerant workloads, cost allocation by namespace and team. This ties in with our FinOps practice.

Concrete deliverables

• Decision note on Kubernetes or an alternative, with criteria and operating costs estimated from your context.
• EKS or AKS clusters as code, with core add-ons and a version upgrade procedure.
• GitOps toolchain and an application repository model.
• Observability foundation with dashboards and alerts.
• Cluster security policies, documented.
• Runbooks: version upgrade, onboarding an application, node incident, restore.

Common pitfalls

• Adopting Kubernetes because it is fashionable for a handful of applications.
• Postponing version upgrades until you fall out of support, with several versions to catch up on.
• Ignoring resource requests: without them, neither scheduling nor autoscaling works properly.
• Installing dozens of add-ons with no owner: each one is a component to maintain.
• Giving every developer cluster administrator access.

How we work with your teams

Scope: real need, platform choice, target architecture. Build: clusters, GitOps, observability, security. Industrialise: gradual migration of applications, upgrade procedures, guardrails. Improve: cost reviews, version upgrades, platform evolution.

We work with your development and operations teams and transfer the practice as we go: your engineers must be able to upgrade and troubleshoot the cluster without us.

Who it is for, and when to call us

Companies unsure whether to adopt Kubernetes, teams with an EKS or AKS cluster that has become hard to maintain, or cloud migration projects involving containerised applications. We work on AWS and Azure, from Villeneuve-d’Ascq in the Lille metropolitan area (northern France), on site or remotely.

[ YOUR QUESTIONS ]

Frequently asked questions

Is Kubernetes right for a small or mid-sized company?

It is when you run many containerised services, with portability, extensibility or tooling needs that simpler container services do not cover, and a team able to operate it. For a handful of applications, ECS or Azure Container Apps are often enough, with far less operational effort.

Do I need Kubernetes to run containers on AWS?

No. ECS is simpler to operate and tightly integrated with AWS. EKS brings the standard Kubernetes ecosystem and portability, at the cost of more demanding operations: version upgrades, add-ons, cluster security. The choice depends on your application estate, your skills and your multicloud strategy.

What is GitOps?

GitOps is a way of deploying in which the desired state of the cluster is described in a Git repository, and a tool such as Argo CD or Flux continuously synchronises the cluster with it. Every change goes through review in Git, the history serves as a log, and the cluster can be rebuilt from the repository.

How do I keep Kubernetes cluster costs under control?

By sizing pod resource requests correctly, automatically adjusting the number and type of nodes, using Spot Instances for tolerant workloads, and allocating costs by namespace or team. Without reliable requests, autoscaling oversizes the cluster.

Can a Kubernetes consultant take over an existing cluster?

Yes. We start with an assessment: version and upgrade schedule, security, deployment, observability, costs. From it we draw up a prioritised remediation plan, then carry it out with your team.