When a cloud region goes down, most teams think about their applications first. But if your log management platform goes dark, you lose more than a dashboard — you lose your audit trail, your security telemetry, and in many industries, your compliance posture. Every minute your ingestion endpoint is unreachable is a minute of blind spots you can’t get back.
The good news: if you run NXLog Platform on AWS, building a multi-region disaster recovery (DR) setup is more straightforward than you might expect. In this post, we walk through the approach described in our new Multi-Region DR Guide, which uses AWS Elastic Disaster Recovery (AWS DRS) to keep a warm copy of your entire deployment in a second region ready to launch in minutes.
Why NXLog Platform is a natural fit for block-level replication
NXLog Platform is a containerized, multi-component system that runs on Linux using Podman. Under the hood, it includes a ClickHouse database for log storage and analytics, PostgreSQL for metadata, and HashiCorp Vault for secrets management. All of its persistent state — databases, configurations, certificates — lives on EBS volumes.
That architecture matters for DR. Because everything NXLog Platform needs is on disk, AWS DRS can replicate the entire deployment at the block level, continuously, from your primary region to a low-cost staging area in your recovery region. When you fail over, AWS DRS restores the exact state of the disk. There is nothing to reinstall, no containers to rebuild, and no configuration to reapply. ClickHouse and PostgreSQL recover to a crash-consistent point-in-time snapshot, and even your host firewall rules come along for the ride.
Setting it up: one replication agent, continuous replication
The core of the setup is refreshingly simple:
-
Generate the AWS DRS agent installation command in the console of your primary region.
-
Run it on your NXLog Platform EC2 instance with root privileges.
-
Wait for the initial sync to complete. The console will show Ready for recovery with a Healthy replication status.
From that point on, AWS DRS continuously replicates every block written to your root and data volumes to the recovery region.
Before you install the agent, make sure your environment allows outbound TCP 1500 (replication data transfer) and TCP 443 (the AWS DRS control plane), and that all persistent container volumes are backed by EBS.
Don’t forget the NXLog Platform-specific configuration
The one place where a generic AWS DRS tutorial won’t help you is the recovery instance’s security group. For NXLog Platform to be fully functional after failover, it needs:
Inbound:
-
TCP 443 — the HTTPS web interface
-
TCP 5514 — log ingestion from your agents
-
TCP 5515 — agent management
Outbound:
-
DNS (TCP/UDP 53)
-
SMTP (TCP 25, 465, or 587) for email notifications
-
TCP 443 to the NXLog Customer Portal, used to validate your subscription and fetch the latest configuration templates
Configure this ahead of time in your launch settings, so failover day involves zero improvisation.
Practice before you need it: DR drills
A DR plan you’ve never tested is a hypothesis, not a plan. AWS DRS lets you launch temporary drill instances in the recovery region without touching production. Run a drill regularly and validate two things on the drill instance:
-
Containers:
sudo podman psshows all NXLog Platform containers running. -
Web interface: you can reach the UI over HTTPS and log in.
That’s the whole checklist, a testament to how much the block-level approach preserves.
When disaster strikes: failover in five steps
If your primary region goes down:
-
Open the AWS DRS console in the recovery region and select your source server.
-
Initiate a recovery job.
-
Choose your snapshot — the latest data for an infrastructure failure, or an earlier point in time if you’re recovering from ransomware.
-
Run the validation checklist on the launched instance.
-
Update your DNS records to point your ingestion domain at the recovery instance.
That last point deserves emphasis: the ability to roll back to a pre-infection snapshot makes this setup valuable not just for regional outages, but for ransomware recovery, an increasingly common reason organizations invoke their DR plans.
Coming home: failback
Once your primary region is stable again, AWS DRS supports reversed replication. AWS DRS syncs the logs you ingested during the outage back to the primary region. You launch a failback instance, run the same validation checks, and redirect DNS. No data ingested during the incident is left behind.
The takeaway
Log data is only valuable if it’s still flowing when everything else is on fire. With NXLog Platform’s disk-backed, containerized architecture and AWS Elastic Disaster Recovery, a full multi-region DR capability comes down to installing a replication agent, opening a handful of ports, and scheduling regular drills.
On the other hand, if you’re researching a solution, resilience doesn’t have to mean complexity or a bigger bill. Because NXLog Platform is a self-contained, disk-backed deployment, multi-region DR doesn’t require duplicating an entire pipeline of ingestion nodes, brokers, and worker fleets across regions. You replicate one instance, open a handful of ports, and schedule regular drills. Your DR footprint costs what an AWS DRS staging area costs and not a second production cluster.
