Should You Run NATS on AWS Fargate? EC2, EBS, and EFS Guidance

Yes, NATS can run on AWS. For production JetStream workloads, the safest default is usually EC2 with block storage such as EBS. Be cautious with Fargate-style deployments and EFS-style network file systems, especially when JetStream persistence is required.

This guidance comes from a recurring NATS community question: whether NATS servers should be hosted on AWS, and which compute and storage choices make sense for production.

Short answer: should I run NATS on AWS Fargate?

For NATS Core-only use cases, Fargate-style deployment can be workable if your architecture accepts ephemeral placement and you do not need durable server-side stream storage.

For JetStream, Fargate is usually not the simplest default. JetStream makes NATS stateful, so you need predictable server identity, persistent storage lifecycle, restart behavior, disk latency, and failure recovery. EC2 with EBS, or Kubernetes with StatefulSets and persistent volumes, is typically easier to reason about for durable NATS storage.

How should I choose between NATS Core and JetStream on AWS?

Start by separating NATS Core from JetStream. The right AWS deployment model depends heavily on whether the server is stateless or stateful.

• NATS Core provides publish-subscribe, request-reply, queue groups, and related messaging patterns without durable server-side stream storage.
• JetStream adds persistence, streams, consumers, acknowledgements, replay, and durable state.

That distinction matters because JetStream turns the server into a stateful system. Once durable data is involved, placement, disk latency, filesystem behavior, restart behavior, and failure recovery become much more important.

For NATS Core-only use cases, more ephemeral container placement can be workable if your architecture tolerates the operational tradeoffs. For JetStream, treat the NATS server like other stateful infrastructure: closer to a database or log storage system than a stateless service.

What is the safest AWS baseline for JetStream?

For JetStream deployments on AWS, EC2 with EBS is often the simplest model to reason about:

• the NATS server runs on a known instance,
• storage is block storage rather than a shared network filesystem,
• disk characteristics can be provisioned and tuned,
• operational patterns such as backups, monitoring, replacement, and instance sizing are familiar.

As a practical starting point, some production deployments use EBS provisioned around 3000 IOPS for reasonably performant environments. That number is not a universal sizing rule. JetStream performance depends on message size, publish rate, acknowledgement patterns, retention, replication, consumer behavior, filesystem, instance type, and storage configuration.

The safest approach is to benchmark your actual workload and validate end-to-end behavior under failure and recovery, not just steady-state publish throughput.

Should I use EBS or EFS for JetStream storage?

Prefer EBS-style block storage for JetStream persistence unless you have tested and accepted the tradeoffs of another storage layer.

NATS is not tightly coupled to one specific filesystem provider, but JetStream persistence is sensitive to storage behavior. For durable messaging, prefer storage with predictable latency and filesystem semantics appropriate for stateful systems.

On AWS, that usually means favoring EBS-style block storage over EFS-style network file storage for JetStream.

Network file systems can be attractive because they simplify sharing and attachment, but they are generally a poor default for databases, messaging systems, and transactional state. They may introduce latency, consistency, locking, or failure-mode behaviors that are not what you want underneath a durable messaging layer.

If you are considering EFS, NFS, or another network filesystem anyway, treat it as an explicit risk decision. Test crash recovery, leader changes, disk stalls, latency spikes, and sustained write behavior before depending on it.

Why is Fargate risky for stateful NATS deployments?

Fargate-style platforms are useful for running containers without managing instances directly. That abstraction is often a good fit for stateless services. It is less natural for core stateful assets such as databases, durable message brokers, and systems with transactional storage.

For JetStream, the operational concerns include:

• stable server identity,
• predictable placement,
• persistent storage lifecycle,
• restart and rescheduling behavior,
• disk performance and latency,
• failure recovery,
• observability during storage or placement events.

If the platform can move or replace tasks in ways that make state ownership harder to reason about, you may end up rebuilding many of the stateful scheduling guarantees yourself. That work can outweigh the simplicity you hoped to gain from the serverless container model.

A Fargate-style deployment may be acceptable for NATS Core-only use cases where the servers are intentionally treated as ephemeral and no JetStream data is stored locally. For JetStream, EC2 with EBS, or a Kubernetes deployment using StatefulSets and persistent volumes, is usually easier to operate predictably.

When does Kubernetes make sense for NATS on AWS?

If your organization wants container orchestration for NATS, Kubernetes is often a better fit for stateful deployments than a purely ephemeral task runner.

Kubernetes StatefulSets are designed around concepts that matter for JetStream:

• stable network identity,
• ordered rollout behavior,
• persistent volume claims,
• predictable replacement semantics,
• clearer mapping between a server and its storage.

But Kubernetes gives you primitives that map more naturally to operating a replicated stateful service.

What AWS deployment path should I choose?

Use this conservative decision path for a production-oriented AWS deployment:

1. Decide whether JetStream is required. If yes, design for state from the beginning.
2. Use EC2 plus EBS as the default baseline unless you have a strong reason to choose another platform.
3. Avoid EFS or NFS as the default JetStream storage layer. Use block storage unless you have tested and accepted the tradeoffs.
4. Be skeptical of Fargate for JetStream. It may shift operational complexity into placement, identity, and persistent storage handling.
5. Benchmark with your workload. Include message size, retention, replication, consumers, acknowledgements, and recovery scenarios.
6. Test failures deliberately. Restart servers, detach or impair storage in a safe environment, and observe cluster recovery.

FAQ

Can NATS run on AWS?

Yes. NATS is commonly run on AWS. The important decision is not whether NATS can run there, but whether your deployment model matches your use of NATS Core, JetStream, and persistent storage.

Is EC2 with EBS required for JetStream?

No single AWS pattern is required in all cases, but EC2 with EBS is a practical and well-understood baseline for JetStream because it provides block storage and familiar stateful operational controls.

Is EFS a good default for JetStream?

No. EFS and other network file systems should not be the default choice for JetStream persistence. If you use one, treat it as an explicit risk decision and test failure and recovery behavior carefully.

Is Fargate acceptable for NATS Core?

It can be, if the NATS servers are treated as ephemeral and your architecture does not depend on durable server-side JetStream state. For JetStream, prefer deployment models that provide clearer stateful behavior.

What should I benchmark before production?

Benchmark your actual workload, including message size, publish rate, acknowledgement patterns, retention policy, replication, consumer behavior, filesystem choice, instance type, storage configuration, and recovery scenarios.

Bottom line

NATS can run well on AWS, but JetStream should be treated as stateful infrastructure. EC2 with EBS is a practical and commonly used starting point. Fargate-style placement and network file systems can be useful in other contexts, but they are not the safest default for durable NATS storage. If you need orchestration, prefer platforms and storage models that provide clear stateful behavior.

---

Want help from the NATS experts? Meet with our architects to get help tailored to your use case and environment.