kubernetes

Artificial Intelligence, Cloud & Infrastructure, Engineering

Nvidia NIM and Triton Inference Server Explained: The Developer Tooling Layer Behind Nvidia’s AI Software Moat

Posted on November 3, 2026 by Filip Keser

Nvidia’s hardware moat gets most of the attention, but the software layer that sits between a trained model and a running production endpoint is just as deliberate a lock-in strategy. NIM (Nvidia Inference Microservices) and Triton Inference Server — now rebranding as Nvidia Dynamo-Triton — are the two pieces developers actually touch when deploying a model, distinct from the Blackwell GPUs and CUDA layer we covered in Nvidia’s Data Center AI Empire and the NVLink/InfiniBand networking stack we covered separately. Here’s what each one actually does, based on Nvidia’s own documentation.

At a Glance

	NVIDIA NIM	Triton Inference Server (→ Dynamo)
What it is	Pre-packaged, production-ready microservices for deploying specific foundation models	A general-purpose, open-source server for deploying models from any supported framework
Model scope	Nvidia’s curated catalog: LLMs, vision-language, speech, biology (AlphaFold2, Evo 2), climate (Earth-2), medical imaging, embedding/reranking, OCR, guardrails	Any model in TensorRT, PyTorch, ONNX, OpenVINO, Python, or RAPIDS FIL format
Deployment	Containers; NIM Operator for Kubernetes; GKE integration; WSL2 support	Linux containers via NGC; Windows/Jetson binaries on GitHub; Kubernetes with Prometheus monitoring
Licensing	Part of NVIDIA AI Enterprise	Open source (Apache-licensed on GitHub); also bundled in NVIDIA AI Enterprise for production support
Successor project	N/A	NVIDIA Dynamo — an open-source framework Nvidia calls “the successor to Triton Inference Server,” adding disaggregated prefill/decode serving

Short Verdict

NIM is the fastest path to a production endpoint if the model you need is already in Nvidia’s catalog — you get a hardened container with security updates, not a model you have to optimize and package yourself. Triton (and its emerging successor, Dynamo) is the right tool when you need to serve your own custom or fine-tuned model, or a model outside NIM’s catalog, with fine control over batching and multi-framework support. Both route through the same business reality: Nvidia bundles production support for either one inside NVIDIA AI Enterprise, a subscription Nvidia’s own CEO has publicly pegged at roughly $2,000 per GPU per year — the software half of Nvidia’s moat, sitting directly on top of the hardware half.

What NIM Actually Is

Nvidia describes NIM as “easy-to-use microservices for accelerating the deployment of foundation models on any cloud or data center.” In practice, a NIM is a pre-built, pre-optimized container for one specific model: Nvidia has already handled the inference engine selection, quantization, and performance tuning, and ships the result as a container with “production-grade runtimes” and ongoing security patching. The catalog is broad — large language models and vision-language models are the obvious entries, but it also covers speech (recognition, text-to-speech, translation), biology models like AlphaFold2, Evo 2, and RFdiffusion, Nvidia’s Earth-2 climate models, medical imaging, embedding and reranking models for retrieval-augmented generation, OCR, object detection, and safety guardrail models. Deployment tooling includes a NIM Operator for Kubernetes clusters, direct integration with Google Kubernetes Engine, and even a path to run NIMs inside WSL2 for local development. The trade-off for that convenience is scope: if the model you need isn’t in Nvidia’s catalog, NIM isn’t the tool — you fall back to Triton or another serving layer.

What Triton Does, and Why It’s Becoming Dynamo-Triton

Triton Inference Server is the general-purpose counterpart: an open-source server that deploys models from essentially any framework — TensorRT, PyTorch, ONNX, OpenVINO, Python, and RAPIDS FIL — on NVIDIA GPUs, non-NVIDIA accelerators, or plain x86/ARM CPUs, in the cloud or on-premises. Its core production features are dynamic batching (grouping incoming requests to use GPU capacity more efficiently), concurrent model execution, and support for real-time, batched, ensemble (multi-model pipeline), and streaming audio/video workloads. It integrates with Kubernetes for orchestration and Prometheus for monitoring, and Nvidia distributes Linux containers through NGC alongside Windows and Jetson binaries on GitHub.

Here’s the detail that’s easy to miss if you only know Triton by its old name: Nvidia’s own developer site now describes NVIDIA Dynamo as “the successor to NVIDIA Triton Inference Server.” Dynamo is an open-source, modular inference framework purpose-built for serving generative AI models across distributed, multi-GPU fleets, and it supports SGLang, TensorRT-LLM, and vLLM as backend engines. Its headline features go well beyond what Triton originally offered: disaggregated serving splits a request’s prefill and decode phases across different nodes so each can be scaled and optimized independently; a KV-aware router and KV Block Manager reduce redundant cache recomputation and offload cached attention state to cheaper memory tiers; and an SLO Planner adjusts allocated GPU resources to keep a deployment within a target latency budget. Nvidia cites independent benchmarks showing up to 50x higher throughput for mixture-of-experts models on its newest GB300 NVL72 systems running Dynamo compared with Hopper-generation hardware running older serving stacks — though as with any vendor-cited benchmark, treat the specific multiplier as directional rather than something every workload will replicate. Dynamo is available now as open source on GitHub, and Nvidia says NVIDIA AI Enterprise will add Dynamo for production inference support in a future release.

Licensing: What NVIDIA AI Enterprise Actually Costs

Triton itself is free and open source under an Apache license on GitHub — you can run it today with no Nvidia subscription. NIM and production support for Triton/Dynamo, however, are gated behind NVIDIA AI Enterprise, Nvidia’s commercial software subscription. Nvidia’s own licensing guide describes per-GPU licensing (every GPU in a server needs its own license), available as a subscription, a perpetual license with five years of support, or metered cloud consumption billed per GPU per hour on AWS, Google Cloud, Azure, or Oracle Cloud. The guide doesn’t publish a flat headline price and instead points to a separate pricing page — but Nvidia CEO Jensen Huang has publicly stated the company prices its AI Enterprise software at roughly $2,000 per GPU per year, a figure widely reported in coverage of Nvidia’s software strategy. Some data center GPUs (H100 PCIe/NVL, H200 NVL) ship with a bundled five-year AI Enterprise subscription already included, which is one reason the per-GPU economics of Nvidia’s platform are harder to compare directly against a GPU-only competitor’s sticker price.

Trade-offs vs. Alternatives

vLLM is the most common open-source alternative for LLM-specific serving: it’s free, widely adopted, and focused specifically on high-throughput language model inference with its own paged-attention memory management — notably, it’s also one of the backend engines Dynamo itself can orchestrate, so the two aren’t strictly competitors anymore. TensorFlow Serving is Google’s older, narrower serving system, built specifically around TensorFlow’s SavedModel format; it lacks Triton’s multi-framework flexibility and Dynamo’s distributed-serving features, but remains a simple, battle-tested choice for teams fully committed to the TensorFlow ecosystem. The general pattern: Nvidia’s stack (NIM/Triton/Dynamo) buys you tighter hardware-software co-optimization and enterprise support at the cost of a subscription and some platform lock-in; the open-source alternatives are free and portable but ask your team to own more of the integration and tuning work yourselves.

Pros and Cons

NVIDIA NIM

Pros: Fastest route to a production endpoint for catalog models; Nvidia handles optimization and security patching; broad catalog spanning far beyond LLMs.
Cons: Limited to Nvidia’s curated catalog; tied to NVIDIA AI Enterprise licensing; less control than rolling your own serving stack.

Triton / Dynamo-Triton

Pros: Open source and free to run; true multi-framework support; Dynamo’s disaggregated serving and KV-cache management are genuinely novel at large scale; works across NVIDIA and non-NVIDIA hardware.
Cons: You own the optimization and packaging work NIM would otherwise handle; production support still requires an AI Enterprise subscription; Dynamo’s most advanced features are newest and least battle-tested.

Who It’s a Good Fit For

Teams deploying a well-known foundation model with minimal customization — and who want Nvidia to own the optimization and patching burden — are the clearest fit for NIM. Teams serving their own fine-tuned or custom models, or running a genuinely multi-framework inference fleet, should look at Triton/Dynamo instead. Organizations operating at the scale of many GPUs across distributed nodes, where prefill/decode disaggregation and KV-cache offloading meaningfully change unit economics, are exactly who Dynamo was built for.

Who Should Look Elsewhere

If your workload is a single open-source LLM and you don’t need Nvidia’s broader catalog or enterprise support, vLLM alone is simpler and free. If you’re fully committed to TensorFlow and don’t need multi-framework flexibility, TensorFlow Serving avoids adopting a new toolchain entirely. And if avoiding per-GPU software licensing costs is a hard budget constraint, run Triton’s open-source build without an AI Enterprise subscription and accept community-support terms instead of Nvidia’s production SLA.

Bottom Line

NIM and Triton/Dynamo are the developer-facing half of Nvidia’s AI moat — the layer that converts raw GPU performance into something a team can actually deploy and operate. NIM trades flexibility for speed and support; Triton (and its new Dynamo successor) trades some convenience for openness and multi-framework reach. Both ultimately route spending back through NVIDIA AI Enterprise licensing, which is the real business model underneath “free and open source” software running on Nvidia hardware.

FAQ

Is Triton Inference Server being discontinued?
Not immediately, but Nvidia’s own developer site names NVIDIA Dynamo as its successor, with Dynamo-Triton as a transitional branding. Triton remains available and supported, but new investment is clearly going into Dynamo’s distributed-serving features.

Do I need NVIDIA AI Enterprise to use Triton?
No — Triton is open source and free to run on its own. AI Enterprise is only required if you want Nvidia’s production support, stable APIs, and long-term branch maintenance for it.

How much does NVIDIA AI Enterprise actually cost?
Nvidia’s official licensing guide doesn’t publish a flat per-GPU price and refers buyers to a separate pricing page, but CEO Jensen Huang has publicly cited roughly $2,000 per GPU per year as the company’s software pricing target — a figure widely reported, not an official list price guaranteed for every deal.

Can I use NIM with models that aren’t in Nvidia’s catalog?
Not directly — NIM is pre-built around specific catalog models. For custom or fine-tuned models outside that catalog, Triton or Dynamo is the appropriate serving layer instead.

How does Dynamo relate to vLLM?
They’re not strictly competitors — Dynamo is a distributed orchestration framework that can run vLLM (along with SGLang and TensorRT-LLM) as one of its backend inference engines, adding disaggregated serving and KV-cache management on top.

Sources

Cloud & Infrastructure

Policy-as-Code and Cloud Security Posture Management in 2026: Open Policy Agent (OPA) vs Kyverno vs AWS Config

Posted on November 3, 2026 by Filip Keser

“Policy as code” covers a wider range of tools than it first appears. Some enforce rules on who can do what inside an application; others enforce rules on how infrastructure is allowed to be configured in the first place. This piece is about the second kind — a different, complementary layer to the relationship-based authorization systems covered in our Zanzibar/ReBAC explainer. Open Policy Agent (OPA), Kyverno, and AWS Config all let teams encode infrastructure and configuration rules as version-controlled policy rather than tribal knowledge or manual review, but they enforce those rules at different points, for different scopes, and with meaningfully different deployment models. Here’s how each actually works.

At a Glance

Factor	Open Policy Agent (OPA)	Kyverno	AWS Config
Scope	General-purpose — Kubernetes, microservices, CI/CD, Terraform, CloudFormation, APIs	Kubernetes-native (usable outside clusters too)	AWS resource configuration only
Policy language	Rego (custom declarative language)	YAML + CEL, as native Kubernetes resources	Managed or custom rules (Guard DSL or Lambda)
Enforcement point	Decision engine queried by your software (sidecar, server, or library)	Kubernetes admission controller, CLI scanner, or runtime	Evaluates recorded resource configs; can auto-remediate
Learning curve	Higher — Rego is a new, Datalog-like language	Lower — “no new language to learn” per its own docs	Low for managed rules; higher for custom logic
Pricing model	Free, open source (CNCF graduated)	Free, open source (CNCF)	Metered: billed per configuration item and per rule evaluation
Governance body	CNCF (graduated)	CNCF	AWS proprietary service

Two Different Layers: Authorization vs Infrastructure Policy

It’s worth being precise about what these tools are not. Systems like Google Zanzibar, SpiceDB, and OpenFGA answer application-level authorization questions — “can this user view this document?” — by modeling relationships between users and resources. OPA, Kyverno, and AWS Config answer a different question entirely: “is this piece of infrastructure, Kubernetes manifest, or cloud resource configured the way our policy says it should be?” One layer governs who can do what inside your product; the other governs whether the systems your product runs on are compliant, secure, and consistent. A mature security posture typically uses both, and conflating them is a common mistake when teams first adopt policy-as-code.

Open Policy Agent (OPA): The General-Purpose Engine

OPA, a CNCF graduated project, describes itself in its own documentation as “a general-purpose policy engine that unifies policy enforcement across the stack.” Its design is deliberately decoupled from any one system: your application or infrastructure component sends OPA structured data (typically JSON) as input, and OPA evaluates that input against policies written in Rego, its purpose-built declarative language for reasoning over complex, hierarchical data, then returns a decision — which can be a simple allow/deny or arbitrary structured output.

That generality is OPA’s core trade-off. Its documentation lists an unusually wide integration surface: Kubernetes admission control, microservices and API gateways, Envoy and Istio service meshes, HTTP and GraphQL APIs, Kafka, Docker, SSH/sudo access control, Terraform plans, and AWS CloudFormation hooks. OPA typically runs as a standalone HTTP server (opa run --server, listening on localhost:8181 by default) that other systems query, or it can be embedded directly into Go programs via its rego package. The cost of that flexibility is Rego itself: it’s a genuinely new, Datalog-inspired language, and teams adopting OPA for the first time generally need to budget real ramp-up time for it, which is the single most common criticism leveled at OPA versus more narrowly scoped alternatives.

Kyverno: Kubernetes-Native, No New Language

Kyverno (also CNCF-hosted) was purpose-built for Kubernetes and has since expanded to work outside clusters as a more general policy tool, but its design center of gravity remains Kubernetes-native resource governance. Its own documentation leads with the contrast to Rego-based tools directly: policies are authored in YAML and CEL (Common Expression Language) as native Kubernetes resources managed the same way as any other manifest — with kubectl, Git, and kustomize — rather than in a separate policy language, which Kyverno’s docs frame as “no new language to learn.”

Functionally, Kyverno can validate, mutate, generate, or clean up Kubernetes resources, and it can verify container images and their metadata for supply-chain security — a feature set aimed squarely at platform engineering teams who need to enforce security and compliance baselines on application teams without those teams learning a new DSL. Deployment is correspondingly Kubernetes-centric: as an admission controller intercepting the API server, as a CLI-based scanner for CI pipelines, or evaluated at runtime, with results reported in the OpenReport format for integration with other tooling. Kyverno is the right fit when the governance problem is specifically “Kubernetes resources,” and the wrong fit when policy needs to span non-Kubernetes systems the way OPA can.

AWS Config: Cloud Resource Configuration, Metered

AWS Config is a different animal again: a managed AWS service, not an open source project, scoped specifically to AWS resource configuration rather than Kubernetes manifests or arbitrary application data. It continuously records the configuration of supported AWS resources and evaluates those recorded configurations against rules — either AWS-managed rules for common best practices or custom rules written against AWS’s own Guard policy DSL or backed by a Lambda function — flagging or, with remediation configured, automatically correcting non-compliant resources.

Unlike OPA and Kyverno, AWS Config is not free. According to AWS’s own pricing page (checked November 2026), the core charges are $0.003 per configuration item recorded with continuous recording (versus $0.012 per item under periodic recording), plus $0.001 per conformance pack evaluation and $0.001 per active Config rule evaluation for the first 100,000 evaluations in a region per month, with AWS’s documentation noting proactive evaluations from rules that support both proactive and detective modes are priced at $0 when run in combination. AWS states there is no free tier for this service and no minimum commitment — you pay purely for configuration items recorded and rule evaluations run, which means cost scales directly with both the size of your AWS footprint and the number of rules you turn on.

Choosing Between Them

Choose OPA when policy needs to span multiple, heterogeneous systems — Kubernetes admission control alongside API authorization, CI/CD gates, and Terraform plan checks — and your team can invest in learning Rego, or already has.
Choose Kyverno when the governance problem is specifically Kubernetes, your platform team wants policies that look like any other Kubernetes YAML manifest, and you want to avoid introducing a new policy language to application teams.
Choose AWS Config when you’re all-in on AWS and need continuous, automatic auditing of actual deployed resource configuration against compliance baselines (CIS benchmarks, internal standards), accepting its per-evaluation metered cost as the price of that continuous visibility.
Many mature AWS + Kubernetes shops run more than one: AWS Config for account- and resource-level compliance drift detection, plus Kyverno or OPA/Gatekeeper for admission-time enforcement inside the cluster — because Config audits after the fact, while Kyverno/OPA can block a non-compliant resource before it’s ever created.

Trade-offs Summary

OPA pros: broadest scope, CNCF-graduated maturity, works across Kubernetes and non-Kubernetes systems alike.
OPA cons: Rego’s learning curve is real and frequently cited as the main adoption barrier.
Kyverno pros: no new language, deeply Kubernetes-native, straightforward GitOps-style policy management.
Kyverno cons: scope is narrower than OPA’s outside the Kubernetes world.
AWS Config pros: deep, continuous AWS-native visibility and automatic remediation options, managed rule library for common compliance frameworks.
AWS Config cons: real metered cost that scales with resource count and rule evaluations, and it’s AWS-only — no multi-cloud coverage.

The Bottom Line

OPA, Kyverno, and AWS Config aren’t really competitors so much as three tools covering overlapping but distinct ground: general-purpose policy across many systems, Kubernetes-native governance without a new language, and AWS-specific continuous configuration auditing with a real metered bill attached. The practical pattern in 2026 is less “pick one” and more “pick the layer that matches the gap”: Kubernetes shops that want zero new languages lean Kyverno; teams with policy needs spanning multiple systems lean OPA; AWS-centric organizations layer Config on top of either for continuous drift detection, budgeting for its per-evaluation pricing as an operating cost rather than a one-time setup fee.

FAQ

Is this the same thing as Zanzibar/ReBAC authorization?
No. ReBAC systems like Zanzibar, SpiceDB, and OpenFGA govern application-level access decisions (who can see or edit what). OPA, Kyverno, and AWS Config govern infrastructure and resource configuration — a separate, complementary layer, not a substitute.

Does Kyverno replace OPA/Gatekeeper?
For Kubernetes-only use cases, many teams choose Kyverno specifically to avoid Rego. For policy needs spanning beyond Kubernetes, OPA’s broader integration surface still has no direct Kyverno equivalent.

How much does AWS Config actually cost for a mid-sized account?
It depends entirely on resource count and rules enabled, since pricing is per configuration item recorded plus per rule evaluation, with no free tier. AWS’s own pricing page is the authoritative source and should be checked directly, since the component rates ($0.003 per config item, $0.001 per rule evaluation for the first 100,000) can change.

Can OPA and AWS Config be used together?
Yes, and it’s a common pattern — OPA (often via Gatekeeper) enforcing policy at Kubernetes admission time inside a cluster, while AWS Config continuously audits the broader AWS account for drift and compliance across resources Kubernetes doesn’t touch.

Is Rego hard to learn?
It has a real learning curve — it’s a declarative, Datalog-style language unlike most imperative languages developers already know — which is why Kyverno’s YAML/CEL approach markets itself explicitly against that friction for Kubernetes-only use cases.

Sources

Cloud & Infrastructure

Container Orchestration in 2026: Kubernetes vs Amazon ECS vs HashiCorp Nomad

Posted on November 1, 2026 by Filip Keser

Running a handful of containers is easy. Running hundreds of them across dozens of servers, restarting the ones that crash, routing traffic to healthy instances, and rolling out updates without downtime is not — that’s the job of a container orchestrator. Three tools dominate this space in 2026: Kubernetes, the open-source standard; Amazon ECS, AWS’s own simpler alternative; and HashiCorp Nomad, the lightweight scheduler that handles containers and non-container workloads alike. They are not interchangeable, and the right pick depends heavily on how much operational complexity a team is willing to take on.

At a Glance

Tool	License / Cost Model	Control Plane Cost	Best For	Learning Curve
Kubernetes	Open source (self-hosted) or managed via a cloud provider	Free self-hosted; $0.10/cluster/hour on Amazon EKS (standard support)	Large, multi-cloud or portable workloads with complex scaling needs	Steep
Amazon ECS	AWS proprietary service	Free — no orchestration fee at all	Teams already committed to AWS who want less operational overhead	Low to moderate
HashiCorp Nomad	Business Source License 1.1 (not OSI-approved open source since 2023)	Free (Community edition); Enterprise is quote-based, not publicly priced	Mixed fleets running containers alongside VMs, batch jobs, or raw binaries	Low to moderate

Short Verdict

Kubernetes wins on ecosystem and portability but costs the most in engineering time to run well. Amazon ECS is the pragmatic choice if a team is AWS-only and wants orchestration without the Kubernetes tax — it genuinely has no control-plane fee. Nomad is the dark horse: a single lightweight binary that schedules containers, Java apps, and raw executables side by side, but it’s worth knowing upfront that it is no longer open source in the traditional sense, and its Enterprise pricing is not public.

What Each Tool Actually Is

Kubernetes is a Cloud Native Computing Foundation (CNCF) graduated project that automates deployment, scaling, and management of containerized applications. It’s cloud-agnostic by design — the same YAML manifests can, in principle, run on Amazon EKS, Google GKE, Azure AKS, or a self-managed cluster on bare metal. That portability comes with genuine operational weight: etcd, control-plane upgrades, networking plugins (CNI), and a sprawling ecosystem of add-ons that most teams end up needing (ingress controllers, service meshes, autoscalers).

Amazon ECS (Elastic Container Service) is AWS’s own orchestrator, tightly integrated with IAM, VPC networking, Application Load Balancer, and CloudWatch. It supports two launch types: the EC2 launch type, where you manage the underlying instances yourself, and Fargate, a serverless mode where AWS manages the servers and you simply specify how much vCPU and memory each task needs. ECS deliberately trades portability for simplicity — it only runs on AWS, but there’s no cluster software to patch or upgrade.

HashiCorp Nomad is a single-binary scheduler that treats containers as just one of several supported “task drivers” — it can also run raw executables, Java applications, QEMU virtual machines, and more, all from one tool. It has no etcd-equivalent dependency and is often praised for being easier to operate at small-to-mid scale than Kubernetes. Since August 2023, Nomad (along with most of HashiCorp’s products) has shipped under the Business Source License 1.1 rather than the Mozilla Public License it previously used — the source is visible on GitHub, but BUSL restricts competing commercial use, so it is not an OSI-approved open-source license. HashiCorp itself was acquired by IBM, which closed in 2025, and Nomad is now sold and supported as part of IBM’s HashiCorp product line.

Pricing Breakdown

Tool	What You Actually Pay
Kubernetes (self-hosted)	$0 in licensing; you pay only for the servers it runs on. Operational/engineering-time cost is the real expense.
Amazon EKS (managed Kubernetes)	$0.10 per cluster per hour under standard support (first ~14 months after a Kubernetes version’s release), rising to $0.60 per cluster per hour once that version enters extended support — plus the cost of the EC2/Fargate capacity the pods run on, per AWS’s EKS pricing page.
Amazon ECS	No orchestration fee on either launch type. EC2 launch type: standard EC2/EBS rates only. Fargate launch type: billed per second (one-minute minimum) at roughly $0.000011244 per vCPU-second and $0.000001235 per GB-second in US East (N. Virginia), per AWS’s ECS pricing page — AWS does not publish a simple flat hourly rate, only these per-second figures.
Nomad Community	Free, self-hosted, under BUSL-1.1.
Nomad Enterprise / HCP Nomad	Not publicly priced. HashiCorp’s and IBM’s own pricing pages list rates for Terraform, Vault, Packer, and Boundary but do not list a Nomad Enterprise figure — it is sold through a sales quote.

Pros and Cons

Pros: Enormous ecosystem (Helm, operators, service meshes); runs identically across any cloud or on-premises; the de facto industry standard, so hiring and documentation are easiest here.
Cons: Steep learning curve; managed control planes still cost money per cluster; teams frequently need a dedicated platform engineer just to keep it healthy.

Amazon ECS

Pros: Genuinely no orchestration fee; deep native integration with IAM, ALB, and CloudWatch; Fargate removes server management entirely.
Cons: AWS-only — no portability to other clouds; smaller ecosystem of third-party tooling than Kubernetes; less flexible for teams with complex, custom scheduling needs.

HashiCorp Nomad

Pros: Single lightweight binary, simple operational model; can schedule non-container workloads (VMs, batch jobs, raw binaries) alongside containers; lower overhead than Kubernetes at small-to-mid scale.
Cons: No longer OSI-approved open source (BUSL-1.1 since 2023); much smaller ecosystem and community than Kubernetes; Enterprise pricing is opaque and quote-only.

Who It’s a Good Fit For

Choose Kubernetes if the team needs multi-cloud portability, already has (or is building) platform-engineering expertise, or needs the breadth of the CNCF ecosystem. Choose Amazon ECS if the organization is AWS-only, wants orchestration with the least possible operational burden, and doesn’t need to run outside AWS. Choose Nomad if the workload mix includes more than just containers — batch jobs, VMs, or legacy binaries — and the team wants a simpler single-binary tool, while accepting that its licensing is more restrictive than classic open source and that enterprise support pricing isn’t public.

Who Should Look Elsewhere

Small teams running a handful of services should think twice before adopting full Kubernetes — the operational overhead often outweighs the benefit at that scale, and a simpler option (ECS Fargate, or even a PaaS) usually gets the job done faster. Teams that need a strictly open-source (OSI-approved) license with no commercial-use restrictions should be cautious with Nomad given its BUSL-1.1 terms, and should confirm current licensing directly with HashiCorp/IBM before committing.

Bottom Line

There’s no universally “best” orchestrator — only the one that matches a team’s cloud strategy and appetite for operational complexity. Kubernetes remains the safest long-term bet for portability and hiring; Amazon ECS is the lowest-friction choice for AWS-committed teams; and Nomad is worth a serious look for mixed workloads, as long as its current licensing terms are acceptable for the use case.

FAQ

Is Kubernetes free?
The Kubernetes software itself is free and open source (CNCF project). What costs money is either the servers you run it on yourself, or a managed control plane like Amazon EKS, which charges $0.10–$0.60 per cluster per hour depending on Kubernetes version support status.

Does Amazon ECS really have no extra fee?
Correct — AWS’s own ECS pricing page states there is no additional charge for ECS orchestration on either the EC2 or Fargate launch type. You only pay standard rates for the compute, storage, and networking resources the tasks use.

Is HashiCorp Nomad still open source?
Its source code is publicly visible on GitHub, but since August 2023 it has been licensed under the Business Source License 1.1, not the Mozilla Public License it used before. BUSL is not an OSI-approved open-source license because it restricts certain competing commercial uses, even though the Community edition remains free to use for most purposes.

Can Nomad really run things other than containers?
Yes — Nomad’s “task driver” model supports Docker containers, raw executables (exec driver), Java applications, and QEMU virtual machines, among others, all managed by the same scheduler.