Networking AWS

BGPalerter BGP and RPKI Monitoring on AWS User Guide

Last updated: 2026-07-22 | Product: BGPalerter

Overview

This guide covers the deployment and use of BGPalerter on AWS using cloudimg AWS Marketplace images. BGPalerter is a self hosted, open source BGP and RPKI monitoring and alerting daemon from NTT. It connects to the real time BGP stream and continuously watches your prefixes and autonomous systems for visibility loss, prefix hijacks, unexpected more specific announcements, RPKI invalid routes and ROA misconfiguration, so you learn about a routing incident affecting your network in minutes rather than hours. Alerts are delivered through simple reports to a rotating log file, email, Slack, syslog, HTTP webhooks, Kafka and more, all driven by plain YAML configuration.

The image installs the official BGPalerter binary at /usr/local/bin/bgpalerter, running as the bgpalerter service with its built in REST status API bound to loopback 127.0.0.1:8011, behind nginx on port 80. nginx is ready for your TLS certificate.

Secure by design, no default login. BGPalerter's status API ships with no authentication of its own. This image never exposes it unauthenticated. The daemon binds the API to loopback only and it is served through nginx: GET /health is an unauthenticated liveness endpoint for load balancer probes, while /status and every other path require HTTP Basic Auth (username cloudimg). A bgpalerter-firstboot.service oneshot generates a unique password on each instance's first boot, writes it to a root only file and to an nginx htpasswd, resolves the instance URL and writes a root only info note, then disables itself. No two instances share a password and none is baked into the image.

Always current. On first boot the appliance downloads the newest BGPalerter release binary (falling back to the baked version if the network is unavailable), so every launch runs current software rather than the version frozen at build time.

Note on the interface. BGPalerter is a headless daemon. It has no web UI; you drive it through its REST status API and its YAML configuration files (config.yml and prefixes.yml), and it emits alerts through the reports you enable. This guide uses curl against the status API and edits the YAML files directly.

What is included:

BGPalerter (verified at 2.0.1 at build) as the official self contained binary, refreshed to the latest release on first boot
bgpalerter.service with its REST status API bound to 127.0.0.1:8011
nginx reverse proxy on port 80: public /health, password protected /status
bgpalerter-firstboot.service for the first boot password, binary refresh and info note
A unique per instance status API password generated on first boot, in a root only 0600 file
Ubuntu 24.04 LTS base, fully patched, with unattended security upgrades enabled
24/7 cloudimg support, 24h response SLA

Connecting to your instance

Connect over SSH as the default user for the operating system variant you launched. BGPalerter is a headless daemon, so all interaction is over SSH and the status API.

OS variant	SSH login user	Example
Ubuntu 24.04 LTS	`ubuntu`	`ssh ubuntu@<instance-public-ip>`

Prerequisites

An active AWS account, an EC2 key pair, and a VPC with a subnet. BGPalerter is lightweight and CPU friendly. Recommended instance type: m5.large is comfortable for most networks; monitoring a very large number of prefixes benefits from more memory. BGPalerter needs outbound access to the RIPE RIS live stream (wss://ris-live.ripe.net) to receive BGP data, so allow outbound HTTPS/WSS from the instance. No inbound port is required for BGPalerter to monitor: it makes an outbound connection to the BGP data stream.

Step 1: Subscribe and launch from AWS Marketplace

Find BGPalerter on AWS Marketplace, subscribe, and launch an instance from the Ubuntu 24.04 delivery option. Choose your instance type and attach a security group that allows TCP 22 (SSH) from your management network and TCP 80 (the status API) from the networks that need to query it. Front port 80 with TLS in production (see the HTTPS section below).

Step 2: Launch from the AWS CLI

AMI_ID="<the-marketplace-ami-id>"        # from your Marketplace subscription
KEY_NAME="my-keypair"
SG_ID="sg-xxxxxxxx"                       # allows 22 from your mgmt CIDR and 80 as needed
SUBNET_ID="subnet-xxxxxxxx"
aws ec2 run-instances \
  --image-id "$AMI_ID" --instance-type m5.large \
  --key-name "$KEY_NAME" --security-group-ids "$SG_ID" --subnet-id "$SUBNET_ID" \
  --metadata-options 'HttpTokens=required' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=bgpalerter-01}]'

Step 3: Connect via SSH

ssh ubuntu@<public-ip>

Step 4: Verify the services are running

BGPalerter's status API listens on loopback 127.0.0.1:8011 and nginx fronts it on port 80. The health endpoint is public; the status API requires your password.

sudo systemctl is-active bgpalerter nginx
ss -tln | grep -E ':80 |127.0.0.1:8011'
curl -s http://127.0.0.1/health

You should see both services active, the two listening sockets (the status API bound to loopback, nginx on port 80), and ok from the public health endpoint.

Terminal showing the bgpalerter and nginx services active, the status API bound to loopback 8011 with nginx fronting port 80, and the public health endpoint returning ok

Step 5: Read your per instance status API password

The password was generated on this instance's first boot and stored in a root only file. Read it and keep it secret: it authenticates every status API request. Confirm that unauthenticated requests are rejected and that the info note and htpasswd are root readable only.

sudo cat /root/bgpalerter-info.txt
echo "unauthenticated /status -> HTTP $(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1/status)"
ls -l /root/bgpalerter-info.txt /etc/nginx/.bgpalerter_htpasswd

The info note holds STATUS_API_PASSWORD and the instance URLs, is owned root:root with mode 0600, and an unauthenticated call to /status returns 401 because nginx enforces authentication. The public /health endpoint stays 200 for load balancer probes.

Terminal showing the public health endpoint returning 200, an unauthenticated status API call rejected with HTTP 401 and an authenticated call returning 200, and the root only info note and htpasswd files

Step 6: Query the status API

Load the password into a shell variable and query the status API through nginx with HTTP Basic Auth. BGPalerter returns a JSON document describing the health of its components (the RIS connectors and the RPKI data). A healthy daemon returns HTTP 200 with connected: true for the RIS connector, which confirms it is attached to the live BGP stream and processing updates.

export BGP_PW=$(sudo grep '^STATUS_API_PASSWORD=' /root/bgpalerter-info.txt | cut -d= -f2-)
echo "authenticated /status -> HTTP $(curl -s -o /dev/null -w '%{http_code}' -u cloudimg:$BGP_PW http://127.0.0.1/status)"
curl -s -u cloudimg:$BGP_PW http://127.0.0.1/status | jq .

The authenticated call returns 200 and a JSON object reporting each connector and the RPKI status. This is the endpoint you point an external monitor or dashboard at (over HTTPS, with the password).

Terminal showing an authenticated request to the status API returning the component health JSON with the ConnectorRIS connector connected true and the RPKI data loaded

Step 7: Monitor your own network

Out of the box the appliance ships a placeholder prefixes.yml that monitors a documented example autonomous system so the daemon runs immediately. Replace it with your own prefixes and ASNs. BGPalerter can generate the watch list for you from an ASN: it discovers the prefixes that AS originates and writes them into prefixes.yml.

cd /var/lib/bgpalerter
sudo systemctl stop bgpalerter
sudo -u bgpalerter /usr/local/bin/bgpalerter generate -a <YOUR_ASN> -o prefixes.yml -i -m
sudo systemctl start bgpalerter

The -i flag includes RPKI/ROA monitoring for the generated prefixes and -m includes monitoring the ASN itself. Review the generated prefixes.yml, then restart the service. You can also edit prefixes.yml by hand to add or remove prefixes; each entry has a description, an asn and monitoring options.

Step 8: See detections and configure alerting

BGPalerter has a built in self test that injects fake BGP updates so you can confirm the full monitor and report pipeline before you rely on it. By default alerts are written to a rotating log file under /var/lib/bgpalerter/logs/; watch it to see detections as they are raised.

ls -1 /var/lib/bgpalerter/logs/
sudo tail -n 20 /var/lib/bgpalerter/logs/reports-$(date -u +%Y-%m-%d).log 2>/dev/null || echo "no alerts logged yet (this is normal on a quiet network)"

Each detection names the affected prefix, the peers that saw it and the AS path, so a more specific announcement of one of your prefixes from an unexpected origin AS stands out immediately. To deliver alerts to email, Slack, syslog, an HTTP webhook, Kafka and more, edit the reports: section of /var/lib/bgpalerter/config.yml and restart the service. Each report type has a template in the file.

sudo systemctl restart bgpalerter

Terminal showing BGPalerter connected to the live RIPE RIS stream and its self test detecting monitored prefixes in the update stream, including a more specific of a monitored prefix from an unexpected origin AS

Step 9: Enable HTTPS

nginx fronts the status API on port 80 and is ready for TLS. Point a DNS record at the instance, then obtain a certificate with certbot and let it configure nginx for port 443.

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

After issuance, restrict the security group so only 443 (and 22 from your management network) is reachable, and query the status API over https://your-domain.example.com/status with the password.

Persistence, first boot and updates

The configuration (config.yml, prefixes.yml) and the alert logs live on the OS disk under /var/lib/bgpalerter/ and are captured into the image, so an instance launched from this image is ready immediately. The first boot service generates the per instance status API password, refreshes the BGPalerter binary to the latest release, then disables itself so subsequent reboots are unaffected. The OS ships fully patched with unattended security upgrades enabled.

Support

Every cloudimg deployment includes 24/7 support with a 24 hour response SLA. Contact support@cloudimg.co.uk for help with deployment, configuration or scaling.

This is a repackaged open source software product with additional charges for cloudimg support services. BGPalerter is distributed under the BSD 3-Clause license. cloudimg is not affiliated with or endorsed by NTT or the BGPalerter project. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.