One tunnel per site, three jobs per message
Each site's router opens a WireGuard tunnel to a Proxylity listener and sends ordinary UDP/514 syslog into it. Proxylity receives it at the edge and fans every message out to three destinations in your own AWS account. Parsing and fan-out happen in the gateway, so the parser, shippers, and transforms that would normally be your code are a property of the destination instead.
Site routers → WireGuard UDP/514 → Proxylity listener, then fanned out three ways:
archive → S3 Object Lock (immutable WORM evidence)
logs → CloudWatch Logs (live alarms, SIEM forwarding)
analytics → S3 Parquet → Athena (SQL over full retention)
Production controls ship with the stack
Encrypted multi-site ingress
Each site authenticates with its own WireGuard public key before syslog leaves the source network. There is no VPN appliance on your perimeter to patch or exploit.
Immutable WORM evidence
The archive bucket uses S3 Object Lock in GOVERNANCE or COMPLIANCE mode. In COMPLIANCE mode, retention can't be shortened or removed by anyone — including the account root.
Live operations and analytics
CloudWatch metric filters drive per-site silence, high-severity, and tunnel-down alarms to SNS. Parquet with Glue partition projection gives you Athena over the full retention period, with no crawlers.
Separation of duties
Two managed policies ship with the stack: an auditor can read and query evidence without altering it, and an operator can keep the pipeline healthy without reading log content.
Encryption everywhere, one key
WireGuard in transit, one customer-managed KMS key with rotation for every bucket and log group at rest, and TLS required on every bucket.
SIEM and DR, optional
Forward selectively to Splunk, Elastic, Datadog, or Sumo Logic so the SIEM only sees what's worth correlating. Replicate archive objects cross-region, retaining their lock settings.
Identity you can trust, labeled by trust
Every record carries an envelope: the site's WireGuard key is cryptographically authenticated, the public endpoint is network-observed, the device address is router-asserted, and the device hostname is self-reported. Sites can reuse the same private address ranges because every record carries the site's key, and an auditor can see exactly which claims are cryptographic and which are hearsay.
Add a site by editing a file
One config file is the single source of truth for your sites. Each entry simultaneously becomes a WireGuard peer, a dedicated silence alarm, and a dashboard series. Adding a site is: generate a key pair, add one object to the array, run cdk deploy. There is no step where you also provision a bigger collector, and a traffic spike is a line on a graph rather than a capacity exercise.
Deploy and verify the pipeline
The repository includes the CDK source, both config files, site-router recipes for Linux, OpenWrt and rsyslog, stack outputs, saved Athena queries, a compliance mapping (PCI DSS v4.0, NIST SP 800-92, ISO/IEC 27001 A.8.15, SOC 2), and a cost model with the levers to tune it. Site routers still need WireGuard and syslog-forwarding configuration; the AWS processing path itself requires no custom runtime code.
View source and deployment steps →
Read the architecture deep dive →
Related use cases
Modernize RADIUS | Inspect UDP protocols live | Apply policy to DNS