High Availability for Non-Azure AMA

Question

High Availability for Non-Azure AMA

JC 40

Can non-Azure AMA supports LB in round-robin? Or, active-passive is more recommended?

Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-20T02:55:43.66+00:00

Hello Janel, AMA (the Azure Monitor Agent) wasn’t really built for you to stand up your own load-balanced front-end in front of the agent; it’s designed to talk directly to Azure’s highly-available ingestion endpoints and automatically fall over if one endpoint is unhealthy. In practice that means:

• There is no supported “round-robin” load-balancer you can put in front of AMA to distribute traffic.

• The agent itself has built-in retries and fail-over against Azure’s back-end, so you don’t need to run active-passive pairs just to protect the agent’s connectivity.

• If you’re doing Linux Syslog collection you can stand up your own syslog aggregator farm (e.g. rsyslog or syslog-ng cluster) behind a load-balancer, then install AMA on each aggregator. In that scenario –

– UDP‐based traffic tolerates simple round-robin (since it’s connectionless)

– TCP or persistent streams really ought to be active-passive (or at least sticky) to avoid breaking sessions

But again, those patterns apply to your syslog or event-forwarder tier – not to AMA itself. For pure AMA on non-Azure servers, just install the agent and point it at the Log Analytics workspace: the agent will automatically handle high availability on Azure’s side.

Hope that helps!

—Reference docs—

• Azure Monitor Agent troubleshooting & connectors

• Syslog-based connector guidance

• Azure Monitor Data Collection Rules overview

If the provided answer was helpful, please click Accept the Answer and upvote if the above was helpful.

Thanks
JC 40 Reputation points

2026-04-20T19:56:10.51+00:00

Hi,

Apologies for the confusion, I'm referring to HA setup when it's about to receive logs from the source.

E.g. from ZPA LSS Servers to 2 Syslog servers going to Sentinel
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-24T01:57:31.7433333+00:00

I just wanted to kindly follow up to check, If the provided answer is helpful, it would be great if you could accept the answer and up-vote. This helps other community members who might face the same issue. Thanks

Answer accepted by question author

1 additional answer

Your answer

Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-20T02:55:43.66+00:00

Hello Janel, AMA (the Azure Monitor Agent) wasn’t really built for you to stand up your own load-balanced front-end in front of the agent; it’s designed to talk directly to Azure’s highly-available ingestion endpoints and automatically fall over if one endpoint is unhealthy. In practice that means:

• There is no supported “round-robin” load-balancer you can put in front of AMA to distribute traffic.

• The agent itself has built-in retries and fail-over against Azure’s back-end, so you don’t need to run active-passive pairs just to protect the agent’s connectivity.

• If you’re doing Linux Syslog collection you can stand up your own syslog aggregator farm (e.g. rsyslog or syslog-ng cluster) behind a load-balancer, then install AMA on each aggregator. In that scenario –

– UDP‐based traffic tolerates simple round-robin (since it’s connectionless)

– TCP or persistent streams really ought to be active-passive (or at least sticky) to avoid breaking sessions

But again, those patterns apply to your syslog or event-forwarder tier – not to AMA itself. For pure AMA on non-Azure servers, just install the agent and point it at the Log Analytics workspace: the agent will automatically handle high availability on Azure’s side.

Hope that helps!

—Reference docs—

• Azure Monitor Agent troubleshooting & connectors

• Syslog-based connector guidance

• Azure Monitor Data Collection Rules overview

If the provided answer was helpful, please click Accept the Answer and upvote if the above was helpful.

Thanks
JC 40 Reputation points

2026-04-20T19:56:10.51+00:00

Hi,

Apologies for the confusion, I'm referring to HA setup when it's about to receive logs from the source.

E.g. from ZPA LSS Servers to 2 Syslog servers going to Sentinel
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-24T01:57:31.7433333+00:00

I just wanted to kindly follow up to check, If the provided answer is helpful, it would be great if you could accept the answer and up-vote. This helps other community members who might face the same issue. Thanks

Answer 1

Thanks for the update, you don’t need to put the Azure Monitor Agent (AMA) itself behind a fancy load-balancer AMA will automatically talk to Azure’s highly available ingestion endpoints and fail over if one goes unhealthy. Your HA concern is really at the syslog-aggregator tier, not the agent.

Here’s what you can do for "ZPA LSS > 2 Syslog servers > Sentinel":

Deploy two syslog aggregator servers (rsyslog/syslog-ng), install AMA on each, and point both at your Log Analytics workspace.
Front those two servers with a VIP/LB or virtual IP: • If ZPA LSS sends logs over UDP, you can safely use a round-robin LB. UDP is connectionless, so you won’t break sessions. • If it uses TCP or any persistent session, use either: – An active-passive design (e.g. keepalived + VRRP), or – A layer-4 LB with session-affinity (“sticky”) so you don’t tear down open connections.
On the backend, each AMA instance will independently forward to Azure and handle its own retries/fail-over against Azure ingestion endpoints—you don’t need an active-passive pair just for the agent.

Reference:

JC 40 Reputation points

2026-04-24T14:43:29.5866667+00:00

Thanks, this is what we are trying to clarify -- HA on syslog-aggregator tier, not the agent.

Answer 2

For non-Azure deployments, Microsoft guidance across similar high-availability scenarios generally favors active/active (round-robin or equivalent) when the platform and workload support it, and active/passive when the goal is only failover and not scale-out.

From the provided high-availability patterns:

With IIS Application Request Routing (ARR) and Network Load Balancing (NLB), both modes are supported:
- Active/passive: NLB is configured so that only one node receives traffic; the other is a standby for failover. This achieves high availability but not scalability, because capacity is limited to a single active node.
- Active/active: NLB is configured in multiple-host mode so that all ARR servers receive traffic concurrently. This achieves both high availability and scalability. The recommendation in this pattern is to set NLB affinity to none for more even load distribution, while ARR itself maintains affinity via cookies.
Similar guidance appears in other architectures (for example, multiregion deployments with Traffic Manager, ExpressRoute circuits, and SAP workloads):
- Active/active is recommended when the objective is both resilience and better utilization of capacity.
- Active/passive (hot or cold standby) is used when simplicity or cost is more important than using all nodes concurrently.

Applied to non-Azure AMA load balancing:

If the environment supports stateless or cookie-based affinity and the goal includes scale-out and better resource utilization, a round-robin (active/active) load-balancing pattern is generally more aligned with Microsoft’s high-availability and scalability guidance.
If the primary goal is only failover with minimal complexity, and there is no need to use all nodes concurrently, an active-passive design is acceptable but will not improve throughput.

In short, round-robin (active/active) is typically preferred when supported and when both high availability and scalability are desired; active-passive is more of a failover-only pattern.

References:

Share via

High Availability for Non-Azure AMA

1 additional answer

Your answer