Multi-Region Disaster Recovery for NXLog Platform on AWS

When an AWS Region becomes unavailable, organizations typically focus first on restoring business-critical applications. However, the availability of the log management platform is equally important.

If your log management infrastructure goes offline, you can lose access to security telemetry, audit records, operational data, and compliance evidence. Every minute that log ingestion is unavailable can create a visibility gap that may be difficult to reconstruct later.

For organizations running NXLog Platform on AWS, a multi-region disaster recovery (DR) strategy can provide a practical way to maintain continuity. Using AWS Elastic Disaster Recovery (AWS DRS), you can continuously replicate the complete NXLog Platform deployment to a secondary AWS Region and recover it when required.

This approach is described in the NXLog Multi-Region DR Guide for AWS and is based on block-level replication rather than maintaining a second fully operational NXLog environment.

Why NXLog Platform is well suited to block-level disaster recovery

NXLog Platform is a containerized, multi-component platform that runs on Linux using Podman. Its architecture includes:

• ClickHouse for log storage and analytics
• PostgreSQL for metadata
• HashiCorp Vault for secrets management
• Persistent configuration, certificates, and application data stored on disk

When deployed on AWS, the persistent data used by NXLog Platform can reside on Amazon EBS volumes. This makes block-level replication a practical DR strategy. Instead of rebuilding the platform in another Region, AWS DRS continuously replicates the blocks written to the source instance's storage to a staging environment in the recovery Region.

During recovery, the replicated volumes are used to launch an instance containing the state of the original deployment. This means you do not need to:

• reinstall NXLog Platform;
• recreate containers manually;
• restore configuration files separately;
• reconfigure certificates and secrets;
• rebuild the underlying operating system.

The recovery environment is based on the replicated state of the original server.

Setting up continuous replication with AWS DRS

The core configuration requires an AWS DRS replication agent installed on the EC2 instance running NXLog Platform. The high-level process is:

1. Open the AWS DRS console in your primary Region.
2. Generate the installation command for the AWS DRS agent.
3. Run the command on the NXLog Platform EC2 instance with root privileges.
4. Allow the initial synchronization to complete.
5. Confirm that the server appears as Ready for recovery with a Healthy replication status.

After the initial synchronization, AWS DRS continuously replicates changes from the source server to the recovery Region. Before deploying the replication agent, verify that your environment allows the required outbound connectivity, including:

• TCP 1500 for replication data transfer
• TCP 443 for the AWS DRS control plane

You should also confirm that all persistent NXLog Platform container volumes are backed by Amazon EBS.

Configure the recovery environment for NXLog Platform

A generic AWS DRS deployment is not enough by itself. The recovery instance must also have the network connectivity required for NXLog Platform to operate normally after failover. In particular, configure the recovery instance's security group in advance.

Required inbound traffic

The recovery environment should allow:

• TCP 443 — NXLog Platform HTTPS web interface
• TCP 5514 — log ingestion from NXLog agents
• TCP 5515 — NXLog agent management

Required outbound traffic

The instance also needs access to services required for normal operation, including:

• DNS: TCP/UDP 53
• SMTP: TCP 25, 465, or 587 for email notifications
• TCP 443 to the NXLog Customer Portal for subscription validation and configuration template updates

Preparing these rules before a disaster occurs is critical. During an actual regional outage, the recovery process should be as close to a predefined procedure as possible.

Test your disaster recovery plan before you need it

A disaster recovery strategy that has never been tested is only an assumption. AWS DRS supports recovery drills, allowing you to launch temporary recovery instances without disrupting the production environment. Regular DR exercises should verify that the recovered NXLog Platform instance is operational.

At a minimum, validate:

1. NXLog Platform containers

 On the recovered instance, verify that the expected containers are running: sudo podman ps All required NXLog Platform containers should be present and running.

2. Web interface

Verify that:

• the NXLog Platform web interface is accessible over HTTPS;
• administrators can authenticate successfully;
• the platform is operational in the recovery environment.

Regular drills also help measure the actual recovery time and identify network, DNS, firewall, or access-control issues before they become critical.

Recovering NXLog Platform after a Region outage

If the primary AWS Region becomes unavailable, the recovery procedure can be performed using AWS DRS. A typical failover sequence is:

1. Open the AWS DRS console in the recovery Region.
2. Select the replicated NXLog Platform source server.
3. Start a recovery job.
4. Select the appropriate recovery point.
5. Launch the recovery instance.
6. Validate the NXLog Platform containers and web interface.
7. Update DNS to redirect the ingestion endpoint to the recovered instance.

Choosing the right recovery point

The latest recovery point is normally appropriate for infrastructure failures such as a regional outage. However, disaster recovery can also involve security incidents. If the original environment has been compromised by ransomware or another destructive attack, recovering from an earlier known-good recovery point may be preferable to restoring the most recent state. This makes point-in-time recovery useful not only for regional availability failures but also for certain cybersecurity recovery scenarios.

Failback after the primary Region is restored

Disaster recovery does not end when the primary Region becomes available again. Once the original infrastructure is stable, AWS DRS supports reverse replication, allowing changes made in the recovery environment to be synchronized back toward the primary Region.

A typical failback process involves:

1. Stabilizing the original environment.
2. Initiating reverse replication.
3. Launching the failback instance.
4. Validating NXLog Platform.
5. Redirecting DNS back to the primary environment.

This approach helps ensure that logs collected while operating from the recovery Region are not simply left behind.

Why this approach matters for security and compliance

Log management infrastructure is part of the organization's security and compliance architecture. A regional outage that interrupts log collection can create gaps in:

• security monitoring;
• incident investigation;
• audit trails;
• compliance reporting;
• operational troubleshooting.

Maintaining a second fully operational log management environment can be expensive and operationally complex. With block-level replication, the recovery environment can remain in a lower-cost staging state until it is actually required. The result is a DR architecture that protects the complete NXLog Platform deployment without requiring organizations to permanently operate two full production environments.

Key considerations for implementation

Before deploying the architecture in production, organizations should define:

• RPO (Recovery Point Objective): how much recent log data the organization can afford to lose;
• RTO (Recovery Time Objective): how quickly log collection and access must be restored;
• DNS failover procedures;
• required firewall and security group rules;
• recovery-point selection procedures;
• administrator access to the recovery Region;
• regular DR testing schedules;
• failback procedures.

The technical replication mechanism is only one part of disaster recovery. Operational procedures need to be documented and tested as well.

The takeaway

Log data remains valuable only if it is available when you need it most. For organizations running NXLog Platform on AWS, AWS Elastic Disaster Recovery provides a practical foundation for multi-region resilience. By replicating the NXLog Platform instance at the block level, organizations can maintain a recoverable copy of their log management environment without deploying a second fully operational production cluster.

The resulting architecture is simple:

Replicate → Recover → Validate → Redirect → Fail back.

For organizations with strict security, audit, or availability requirements, this approach can help protect the continuity of security telemetry while keeping the operational and infrastructure overhead of disaster recovery under control. Softprom, as an official NXLog distributor, can help organizations evaluate NXLog Platform deployment options and design a log management architecture aligned with their security, compliance, and disaster recovery requirements.