DEV Community: Mads Quist

AWS Elastic IP failover with Keepalived: how we keep self-managed loadbalancers redundant

Mads Quist — Mon, 11 May 2026 16:28:24 +0000

Originally published on 10 May 2026 on the All Quiet Tech Blog.

At All Quiet we build incident management: alerting, on-call rotations, escalation, status pages, and integrations with the monitoring stacks teams already run. A meaningful slice of my job is keeping the boring edges boring, especially ingress, when something breaks.

In parts of our stack we run loadbalancers ourselves on EC2 instead of putting every path behind an AWS-managed balancer. We do that in part to avoid leaning too hard on higher-level AWS abstractions for those tiers: we still rely on EC2 for reliable virtual machines, and we keep the design close to portable building blocks so we could run the same pattern in another data center or provider without a ground-up redesign. Once we made that choice, we still had a plain high availability (HA) problem for the active-passive pair: keep the public edge redundant.

For those tiers we use a small pattern: a stable Elastic IP (EIP), the address we publish in DNS and the stand-in for a floating IP on a traditional network; Keepalived running Virtual Router Redundancy Protocol (VRRP) between peers; and the EC2 API, mainly AssignPrivateIpAddresses and AssociateAddress, to move that EIP when mastership changes. We wire this with Ansible and the AWS Cloud Development Kit (CDK) in our infrastructure repo.

The problem in AWS terms

I grew up with patterns where a “floating IP” moves at layer 2 (L2) with gratuitous Address Resolution Protocol (ARP). Amazon Virtual Private Cloud (VPC) doesn’t work like your favorite rack fabric: public routing for Elastic IPs is enforced by AWS’s control plane, tied to a specific Elastic Network Interface (ENI) and private address on an instance.

So we split responsibilities deliberately:

Between our servers, we use Keepalived / VRRP, almost always unicast, to decide which node is primary.
Against AWS, we run a script on notify_master that calls the command-line interface (CLI) or API so the EIP actually attaches to the winner.

If we did only VRRP virtual-address tricks without AssociateAddress, we would not fix customer-visible public routing for that EIP. If we did only API moves without Keepalived, we’d lack a clean distributed agreement story on the pair. We need both layers.

Architecture at a glance

                    Elastic IP (stable in DNS)
                              │
                              ▼
              ┌───────────────────────────────┐
              │  EC2: EIP associated here     │
              │  (AssociateAddress, etc.)     │
              └───────────────────────────────┘
                              │
                  Our LB tier (e.g. HAProxy / nginx)
                              │
                           backends

On both nodes we run Keepalived with unicast peers, priorities, and a vrrp_script that reflects whether our LB process is actually alive (systemctl, curl to localhost, or whatever probe matches reality). When a node becomes MASTER, notify_master runs our failover shell script: ensure a secondary private IP, then associate the allocation.

Implementation sketch

Kernel: we often enable ip_forward / ip_nonlocal_bind where our HAProxy or nginx layout needs it. We validate per role, not globally.

Security groups: protocol 112 (Virtual Router Redundancy Protocol, VRRP) allowed between peers, not the open internet.

Keepalived: notify_master logs to a rotated file; credentials via an Identity and Access Management (IAM) instance profile where we can.

Instance identity: in production we fetch instance metadata using Instance Metadata Service version 2 (IMDSv2).

Example Keepalived skeleton (placeholders only, not a drop-in):

global_defs {
    enable_script_security
    script_user root
    vrrp_startup_delay 1
}

vrrp_script check_service {
    script "/usr/bin/systemctl is-active --quiet nginx"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    unicast_src_ip 10.0.0.10
    unicast_peer {
        10.0.0.11
    }
    virtual_router_id 51
    priority 200
    advert_int 1
    track_script {
        check_service
    }
    notify_master "/etc/keepalived/aws-failover.sh >> /var/log/keepalived/aws-failover.log"
}

Example failover script shape (replace IDs and IPs; use IMDSv2 in production):

#!/usr/bin/env bash
set -euo pipefail

ALLOCATION_ID="eipalloc-REPLACE_ME"
PRIVATE_IP_SECONDARY="10.0.0.50"
INTERFACE="eth0"

INSTANCE_ID="$(curl -sf http://169.254.169.254/latest/meta-data/instance-id)"

ip addr add "${PRIVATE_IP_SECONDARY}/32" dev "${INTERFACE}" || true

NI_ID="$(aws ec2 describe-instances \
  --instance-ids "${INSTANCE_ID}" \
  --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' \
  --output text)"

aws ec2 assign-private-ip-addresses \
  --network-interface-id "${NI_ID}" \
  --private-ip-addresses "${PRIVATE_IP_SECONDARY}"

aws ec2 associate-address \
  --allocation-id "${ALLOCATION_ID}" \
  --instance-id "${INSTANCE_ID}" \
  --private-ip-address "${PRIVATE_IP_SECONDARY}"

Tradeoffs of managing the edge ourselves

When we self-manage load balancer tiers instead of defaulting to AWS-managed front doors, we still need to evaluate the usual architectures: application or network load balancers, DNS failover, Kubernetes ingress, or the Elastic IP + Keepalived pattern this post describes.

Application Load Balancer (ALB)

Pros / cons (for anyone choosing ALB):

Upside: AWS-managed HA, health checks, Transport Layer Security (TLS) with AWS Certificate Manager (ACM), AWS Web Application Firewall (WAF), and a clear scaling story for HTTP.

Downside: cost at scale, less hands-on control over every packet and knob than raw EC2.

At All Quiet: we rely on managed load balancing for paths where we want AWS to own HA end-to-end, including customer-facing HTTP. We treat ALB-class tooling as the default when we do not want to operate the edge ourselves.

Network Load Balancer (NLB)

Pros / cons (for anyone choosing NLB):

Upside: TCP/UDP transparency, static IPs per Availability Zone (AZ), low listener overhead compared to full layer 7 (L7).

Downside: fewer HTTP-specific features than ALB; still another billable and operated AWS component.

At All Quiet: when we need AWS-managed HA but not full layer 7 (L7) termination at the edge, NLB-style fits better than ALB; we don’t replace every self-managed tier with NLB, but it’s on the same “managed edge” side of the spectrum as ALB.

DNS failover (Route 53)

Pros / cons (for anyone using DNS failover):

Upside: no instance-side EIP choreography; health-checked routing policies let AWS steer names.

Downside: DNS time to live (TTL) and caching stretch failover and failback; client stacks behave inconsistently; not a drop-in substitute for “one stable IP, instant swing.”

At All Quiet: DNS steering can complement other designs; we don’t rely on it alone when our mental model is exactly one Elastic IP jumping between two known EC2 nodes. That is what Keepalived plus the API covers.

Kubernetes / gateways (e.g. Amazon EKS)

Pros / cons (for anyone on Kubernetes):

Upside: HA via Services, Ingress / Gateway API, and cloud LB integration, which gives different primitives than a bare-metal pair.

Downside: cluster operational tax; not every workload belongs there.

At All Quiet: this article describes a pair pattern centered on virtual machines (VMs) because we still run meaningful tiers that way; where we use Amazon Elastic Kubernetes Service (EKS) or similar, ingress HA follows Kubernetes, not Keepalived on two fixed hosts.

Elastic IP + Keepalived + EC2 API (this post)

Pros / cons (for anyone building like this):

Upside: one stable public address in DNS; relatively few moving AWS objects; full control over timers and failover scripts.

Downside: you own IAM, idempotent scripts, logging, monitoring, and ambiguous states deserve runbooks and checks such as DescribeAddresses. Compared with a managed load balancer, cutover is not instantaneous on abrupt failure: traffic follows wherever the EIP is still associated until VRRP agrees on a new master, your health logic runs, and notify_master finishes calling AWS. The gap depends on advert_int, vrrp_script intervals, preempt settings, and API behavior. Those knobs trade sensitivity against stability; sub‑millisecond failover is not what this pattern promises.

At All Quiet: this is what we actually implemented for specific self-managed loadbalancer tiers: Ansible-deployed Keepalived, scripts on notify_master, AWS Cloud Development Kit (CDK) and infrastructure as code (IaC) for the EIP and IAM. That is the same stack this article walks through at a pattern level.

How we pick among them

Internally we ask: does this path’s service level objective (SLO) and budget justify a managed LB? Do we need layer 7 (L7) features only ALB gives us? Does scripted EIP failover fit this path’s resilience expectations (see the EIP downside above)? If not, we promote the tier (ALB/NLB or another design); we don’t stretch EIP+Keepalived past where it fits.

Takeaways

We run self-managed LBs in some slices of our infra; we needed explicit public HA there, and EIP + Keepalived + EC2 API is our compact answer.
VRRP decides who leads; AssociateAddress decides where the EIP points.
Managed ALB/NLB remain strong defaults when we want AWS to own HA at that layer.

Closing

We touch incident paths every day; when ingress misbehaves, people notice fast. If you operate similar edges, use this framing to decide when the pattern fits and when to promote that tier to managed load balancing instead.

Running our test environment fully on Nanos

Mads Quist — Thu, 18 Sep 2025 16:19:15 +0000

We've probably all had this dream of waking up in the morning and finding ourselves with 10,000 new users on our platform. (At least as a Co-Founder & CTO, that's the dream) 😁

So we asked ourselves: can we run a dedicated environment of our platform entirely on nanos?

Spoiler: it worked, and it taught us a lot about where our real inefficiencies were hiding.

Here are some of these learnings:

The Reality of Scaling:

When your startup does grow and you start scaling your infrastructure, what really happens? Often it turns out that:

Important indexes are missing, leading to CPU spikes.
Query results are loaded into memory without paging, causing out-of-memory errors.
Other inefficiencies appear that raw cloud scaling alone cannot solve.

The result is often not a sleek, hyper-scalable system but an extremely expensive piece of cloud infrastructure.

The best part about scaling: Downsizing

What's great about the cloud is not just that it scales up. It also lets you scale down.

Recently, we ran a load test we called nano testing. The idea was simple: take our infrastructure and run it on AWS EC2 nano instances. That is as small as it gets on AWS.

A nano instance has 512MB RAM and 2 virtual CPUs. That reminds me of my gaming PC from the year 2000. For comparison, your smartphone today probably has 10–20 times more RAM. We then dumped in about four times the amount of test data we normally process.

Can It Run on Nanos?

The fun begins when you try to make your platform run decently on nanos. It does not have to be blazing fast. The key question is: does it run at all?

If some API queries take a few seconds, or some asynchronous jobs and emails are processed with a bit of lag, that is perfectly fine. If your system can handle this, it means you have built something resilient.

Running on nanos lets you pinpoint weaknesses in your platform very clearly. Fixes are often low-hanging fruit:

Add batch processing here.
Add an index there.
Add throttling in another place.

Our Approach at All Quiet

At All Quiet, we now run a dedicated testing environment entirely on nanos. This allows us to observe scaling issues early and fix them before they turn into real problems.

Why We Built a MongoDB-Message Queue and Reinvented the Wheel

Mads Quist — Thu, 04 Jul 2024 04:33:19 +0000

Hey👋

I'm Mads Quist, founder of All Quiet . We've implemented a home-grown message queue based on MongoDB and I'm here to talk about:

Why we re-invented the wheel
How we re-invented the wheel

1. Why we re-invented the wheel

Why do we need message queuing?

All Quiet is a modern incident management platform, similar to PagerDuty. Our platform requires features like:

Sending a double-opt-in email asynchronously after a user registers
Sending a reminder email 24 hours after registration
Sending push notifications with Firebase Cloud Messaging (FCM), which can fail due to network or load problems. As push notifications are crucial to our app, we need to retry sending them if there's an issue.
Accepting emails from outside our integration and processing them into incidents. This process can fail, so we wanted to decouple it and process each email payload on a queue.

Our tech stack

To understand our specific requirements, it's important to get some insights into our tech stack:

We run a monolithic web application based on .NET Core 7. The .NET Core application runs in a Docker container.
We run multiple containers in parallel.
An HAProxy instance distributes HTTP requests equally to each container, ensuring a highly available setup.
We use MongoDB as our underlying database, replicated across availability zones.
All of the above components are hosted by AWS on generic EC2 VMs.

Why we re-invented the wheel

We desired a simple queuing mechanism that could run in multiple processes simultaneously while guaranteeing that each message was processed only once.
We didn't need a pub/sub pattern.
We didn't aim for a complex distributed system based on CQRS / event sourcing because, you know, the first rule of distributed systems is to not distribute.
We wanted to keep things as simple as possible, following the philosophy of choosing "boring technology".

Ultimately, it's about minimizing the number of moving parts in your infrastructure. We aim to build fantastic features for our excellent customers, and it's imperative to maintain our services reliably. Managing a single database system to achieve more than five nines of uptime is challenging enough. So why burden yourself with managing an additional HA RabbitMQ cluster?

Why not just use AWS SQS?

Yeah… cloud solutions like AWS SQS, Google Cloud Tasks, or Azure Queue Storage are fantastic! However, they would have resulted in vendor lock-in. We simply aspire to be independent and cost-effective while still providing a scalable service to our clients.

2. How we re-invented the wheel

What is a message queue?

A message queue is a system that stores messages. Producers of messages store these in the queue, which are later dequeued by consumers for processing. This is incredibly beneficial for decoupling components, especially when processing messages is a resource-intensive task.

What characteristics should our queue show?

Utilizing MongoDB as our data storage
Guaranteeing that each message is consumed only once
Allowing multiple consumers to process messages simultaneously
Ensuring that if message processing fails, retries are possible
Enabling scheduling of message consumption for the future
Not needing guaranteed ordering
Ensuring high availability
Ensuring messages and their states are durable and can withstand restarts or extended downtimes

MongoDB has significantly evolved over the years and can meet the criteria listed above.

Implementation

In the sections that follow, I'll guide you through the MongoDB-specific implementation of our message queue. While you'll need a client library suitable for your preferred programming language, such as NodeJS, Go, or C# in the case of All Quiet, the concepts I'll share are platform agnostic.

Queues

Each queue you want to utilize is represented as a dedicated collection in your MongoDB database.
Message Model

Here's an example of a processed message:

{
    "_id" : NumberLong(638269014234217933),
    "Statuses" : [
        {
            "Status" : "Processed",
            "Timestamp" : ISODate("2023-08-06T06:50:23.753+0000"),
            "NextReevaluation" : null
        },
        {
            "Status" : "Processing",
            "Timestamp" : ISODate("2023-08-06T06:50:23.572+0000"),
            "NextReevaluation" : null
        },
        {
            "Status" : "Enqueued",
            "Timestamp" : ISODate("2023-08-06T06:50:23.421+0000"),
            "NextReevaluation" : null
        }
    ],
    "Payload" : {
        "YourData" : "abc123"
    }
}

Let’s look at each property of the message.

_id

The _id field is the canonical unique identifier property of MongoDB. Here, it contains a NumberLong, not an ObjectId . We need NumberLong instead of ObjectId because:

While ObjectId values should increase over time, they are not necessarily monotonic. This is because they:

Only contain one second of temporal resolution, so ObjectId values created within the same second do not have a guaranteed ordering, and are generated by clients, which may have differing system clocks.

In our C# implementation, we generate an Id with millisecond precision and guaranteed ordering based on insertion time. Although we don't require strict processing order in a multi-consumer environment (similar to RabbitMQ), it's essential to maintain FIFO order when operating with just one consumer. Achieving this with ObjectId is not feasible. If this isn't crucial for you, you can still use ObjectId.

Statuses

The Statuses property consists of an array containing the message processing history. At index 0, you'll find the current status, which is crucial for indexing.

The status object itself contains three properties:

Status: Can be "Enqueued", "Processing", "Processed", or "Failed".
Timestamp: This captures the current timestamp.
NextReevaluation: Records when the next evaluation should occur, which is essential for both retries and future scheduled executions.

Payload

This property contains the specific payload of your message.

Enqueuing a message

Adding a message is a straightforward insert operation into the collection with the status set to "Enqueued".

For immediate processing, set NextReevaluation to null.
For future processing, set NextReevaluation to a timestamp in the future, when you want your message to be processed.

db.yourQueueCollection.insert({
    "_id" : NumberLong(638269014234217933),
    "Statuses" : [
        {
            "Status" : "Enqueued",
            "Timestamp" : ISODate("2023-08-06T06:50:23.421+0000"),
            "NextReevaluation" : null
        }
    ],
    "Payload" : {
        "YourData" : "abc123"
    }
});

Dequeuing a message

Dequeuing is slightly more complex but still relatively straightforward. It heavily relies on the concurrent atomic read and update capabilities of MongoDB.

This essential feature of MongoDB ensures:

Each message is processed only once.
Multiple consumers can safely process messages simultaneously.

db.yourQueueCollection.findAndModify({
   "query": {
      "$and": [
         {
            "Statuses.0.Status": "Enqueued"
         },
         {
            "Statuses.0.NextReevaluation": null
         }
      ]
   },
   "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Processing",
                  "Timestamp": ISODate("2023-08-06T06:50:23.800+0000"),
                  "NextReevaluation": null
               }
            ],
            "$position": 0
         }
      }
   }
});

So we are reading one message that is in state “Enqueued” and at the same time modify it by setting the status “Processing” at position 0. Since this operation is atomic it will guarantee that the message will not be picked up by another consumer.

Marking a message as processed

Once the processing of the message is complete, it's a simple matter of updating the message status to "Processed" using the message’s id.

db.yourQueueCollection.findAndModify({
   "query": {
     "_id": NumberLong(638269014234217933)
   },
   "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Processed",
                  "Timestamp": ISODate("2023-08-06T06:50:24.100+0000"),
                  "NextReevaluation": null
               }
            ],
            "$position": 0
         }
      }
   }
});

Marking a message as failed

If processing fails, we need to mark the message accordingly. Often, you might want to retry processing the message. This can be achieved by re-enqueuing the message. In many scenarios, it makes sense to reprocess the message after a specific delay, such as 10 seconds, depending on the nature of the processing failure.

db.yourQueueCollection.findAndModify({
   "query": {
     "_id": NumberLong(638269014234217933)
   },
   "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Failed",
                  "Timestamp": ISODate("2023-08-06T06:50:24.100+0000"),
                  "NextReevaluation": ISODate("2023-08-06T07:00:24.100+0000")
               }
            ],
            "$position": 0
         }
      }
   }
});

The dequeuing loop

We've established how we can easily enqueue and dequeue items from our "queue," which is, in fact, simply a MongoDB collection. We can even "schedule" messages for the future by leveraging the NextReevaluation field.

What's missing is how we will dequeue regularly. Consumers need to execute the findAndModify command in some kind of loop. A straightforward approach would be to create an endless loop in which we dequeue and process a message. This method is straightforward and effective. However, it will exert considerable pressure on the database and the network.

An alternative would be to introduce a delay, e.g., 100ms, between loop iterations. This will significantly reduce the load but will also decrease the speed of dequeuing.

The solution to the problem is what MongoDB refers to as a change stream.

MongoDB Change Streams

What are change streams? I can’t explain it better than the guys at MongoDB:

Change streams allow applications to access real-time data changes […]. Applications can use change streams to subscribe to all data changes on a single collection […] and immediately react to them.

Great! What we can do is listen to newly created documents in our queue collection, which effectively means listening to newly enqueued messages

This is dead simple:

const changeStream = db.yourQueueCollection.watch();
changeStream.on('insert', changeEvent => {
  // Dequeue the message
  db.yourQueueCollection.findAndModify({
    "query": changeEvent.documentKey._id,
    "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Processing",
                  "Timestamp": ISODate("2023-08-06T06:50:24.100+0000"),
                  "NextReevaluation": null
               }
            ],
            "$position": 0
         }
      }
   }
});

Scheduled and Orphaned Messages

The change stream approach, however, does not work for both scheduled and orphaned messages because there is obviously no change that we can listen to.

Scheduled messages simply sit in the collection with the status "Enqueued" and a "NextReevaluation" field set to the future.
Orphaned messages are those that were in the "Processing" status when their consumer process died. They remain in the collection with the status "Processing" but no consumer will ever change their status to "Processed" or "Failed".

For these use cases, we need to revert to our simple loop. However, we can use a rather generous delay between iterations.

Wrapping it up

"Traditional" databases, like MySQL, PostgreSQL, or MongoDB (which I also view as traditional), are incredibly powerful today. If used correctly (ensure your indexes are optimized!), they are swift, scale impressively, and are cost-effective on traditional hosting platforms.

Many use cases can be addressed using just a database and your preferred programming language. It's not always necessary to have the "right tool for the right job," meaning maintaining a diverse set of tools like Redis, Elasticsearch, RabbitMQ, etc. Often, the maintenance overhead isn't worth it.

While the solution proposed might not match the performance of, for instance, RabbitMQ, it's usually sufficient and can scale to a point that would mark significant success for your startup.

Software engineering is about navigating trade-offs. Choose yours wisely.