Proxylity releases AWS CDK construct library for serverless UDP gateways

Proxylity has shipped @proxylity/cdk-udp-gateway, an open-source AWS CDK construct library that wraps its serverless UDP gateway service in typed, reusable building blocks. A dev.to post published on 19 October 2026 walks through how the library was designed, and the process it describes — deliberate layering plus a verification harness that catches IAM mistakes before deployment — is arguably as interesting as the release itself.

The boilerplate it replaces

The AWS Cloud Development Kit lets developers define infrastructure in languages such as TypeScript, Python, Java, C# and Go instead of hand-writing CloudFormation JSON or YAML. As the post explains, most of the ergonomic value sits at the L2 level: opinionated wrappers that add sensible defaults, typed references and automatically derived IAM on top of a mechanical L1 mirror of the underlying resource.

Proxylity UDP Gateway provides a managed listener endpoint — UDP, WireGuard or DTLS — and delivers inbound datagrams to AWS destinations including Lambda, SQS, Kinesis, Firehose, S3 and Step Functions as batched events, with no servers to run, patch or scale. Until now, provisioning a listener meant authoring CloudFormation custom resources by hand: resolving account and region configuration mappings, wiring service tokens and API keys into every resource, and hand-building a least-privilege IAM role for each destination. According to the post, every destination amounted to a research exercise into which API actions a delivery actually performs and how they are scoped; get it subtly wrong and the stack deploys cleanly, then fails at runtime.

L1 first, and kept

The team deliberately built a faithful L1 layer before any convenience API, and kept it permanently beneath L2. L1 exposes whatever the underlying custom resources accept and invents nothing, which makes it both the foundation — L2 is assembled entirely from L1 constructs and never emits raw CloudFormation — and a permanent escape hatch when L2's opinions don't fit a particular use case. The post acknowledges this costs some duplication, in exchange for a library that is both easy and transparent.

Verification as the backbone

The discipline the author most wants other teams to copy is treating the deployed service's actual behaviour as the single source of authority, ahead of documentation, example templates or anyone's mental model. Two practices made this concrete. First, a golden synth-diff: for each known-good example template the service ships, an equivalent stack is written with the constructs, synthesised, and asserted to match the proven template property for property, so any drift turns a test red. Second, a review rule under which an IAM grant or behavioural claim not grounded in verified behaviour counts as a defect; the post says this repeatedly caught plausible-looking permissions that would otherwise have been accepted at deploy time and failed silently later, and notes that per-service least-privilege IAM across AWS partitions such as GovCloud and China is genuinely subtle. Discrepancies between assumptions, documentation and reality were logged with the observed behaviour and the decision taken, rather than quietly resolved. The author's conclusion: the quality came from the verification, not from cleverness.

One listener, four protocols

The main API design question was how to model protocol-specific settings — WireGuard has peers, DTLS has pre-shared keys and early-data windows, WebRTC has a signalling mode — when a listener speaks exactly one protocol but is fundamentally a single resource with one endpoint and one shared set of destinations. Rather than four separate classes or an inheritance hierarchy, the library offers a single Listener construct with a sealed protocol factory: ListenerProtocol.udp(), .wireGuard(), .dtls() and .webRtc(), each surfacing only its own relevant options. The post says a second design question also shaped the API, but the text available in the feed cuts off before describing it.

Why it matters

Infrastructure patterns that previously lived as copy-pasted custom-resource boilerplate become packaged, typed and testable abstractions — and the failure mode that matters most here, mis-scoped IAM that passes deployment and fails at runtime, moves from production incidents to design review. The methodology is also transferable: the L1-under-L2 layering and the golden-template synth-diff apply to any team wrapping an existing service in CDK, which is why the post reads as much as an engineering playbook as a release note.