Every Lambda function you write is code you have to maintain. Every intermediary service is latency you have to manage. Every additional component is complexity that calcifies you architectrure, burdens you team and slows them down.
Those are problems BREX (Binary Range Expression) can help solve. It's a Domain Specific Language we developed to enable dynamic AWS service integrations directly from binary data streams, without requiring Lambda functions as intermediaries. The result: simpler more flexible architectures, faster innovation cycles, and lower operational overhead.
According to AWS's guidance, Lambda functions should transform data and not orchestrate. Consider a
scenario that results from following their advice: you're ingesting UDP telemetry from IoT devices, and you
need to route each device's data to its own SQS FIFO queue GroupId for ordered processing. The
traditional
architecture looks like
this:
UDP Packets → UDP Gateway → Lambda → Extract Device ID → Send to SQS Queue with GroupId
The Lambda function is simple, perhaps less than 20 lines of code. It reads the device ID from the packet, formats it, and sends it to SQS with the appropriate message group ID. Easy, an in-line with AWS guidance, right?
But now you're maintaining:
Multiply this by dozens of data flows, and the operational burden compounds. Each Lambda function is another component to version, deploy, monitor, and troubleshoot. Your architecture diagram looks impressive, but your velocity suffers.
BREX eliminates the Lambda intermediary by allowing you to express data extraction operations declaratively in your destination configuration:
{
"DestinationArn": "arn:aws:sqs:us-east-1:123456789012:device-data.fifo",
"Arguments": {
"MessageGroupIdExpression": "[5:7]",
"MessageGroupIdFormatter": "hex"
}
}
This single configuration extracts bytes 5-7 from each UDP packet and uses them as the SQS message group ID, formatted as hexadecimal. No Lambda function. No custom code. No deployment pipeline for glue logic.
The new architecture:
UDP Packets → UDP Gateway (with BREX) → SQS Queue
One less service. One less deployment. One less runtime to maintain. One less thing to break. But the same functionality and more flexibility than before.
We recently added FIFO queue support with BREX-based configuration, enabling dynamic message group IDs and deduplication identifiers extracted directly from packet payloads. Teams that previously required Lambda intermediaries can now configure ordered, exactly-once processing declaratively.
Before (with Lambda):
After (with BREX):
The operational savings compound across teams. A lead customer behind the improvement reported eliminating dozens of Lambda functions when adopting BREX-based Destination configuration, reducing their infrastructure code and full-stack deployment time by almost a third.
The IoT Core Data destination demonstrates BREX's power for protocol bridging. Instead of writing Lambda functions to parse device protocols and route to appropriate MQTT topics, you express the routing logic declaratively:
{
"DestinationArn": "arn:aws:iot:us-east-1:123456789012:topic/devices",
"DynamicTopicSuffix": true,
"TopicSuffixExpression": "[2:6]",
"TopicSuffixFormatter": "hex"
}
This approach publishes each packet to a unique topic based on bytes 2-6 of the payload. The result is allowing lightweight UDP protocols used by devices at the edge to integrate seamlessly with AWS IoT Core's MQTT infrastructure.
For teams managing fleets of IoT devices, this can eliminates entire classes of integration code and/or IoT Rules executions. In migrating a large fleet of devices from an VM-based architecture to UDP Gateway with BREX-based routing, our customer improved spike tolerance and scalability while eliminating unused, pre-provisioned capacity and reducing operational cost.
BREX is a Domain Specific Language designed specifically for binary data manipulation. It supports:
[0:4] extracts bytes 0-4, [10:] extracts
from byte 10 to endu16le[0:] reads a 16-bit little-endian unsigned integer
[20:, [0]==31] | [2:] finds TLV type 31, returns
value partu8[0] == 1 ? [4:8] : [8:12] for protocol variants[u8[0] * 4] for computed offsetsThe syntax is concise but powerful. Common patterns like TLV (Type-Length-Value) record parsing become one-liners instead of dozens of lines of procedural code.
Full syntax reference and examples are available in the BREX documentation.
The elimination of intermediaries has cascading architectural benefits:
Fewer services means fewer things that can fail. No Lambda timeouts. No memory limits. No concurrency throttling. No EC2 scaling instance issues. No container crashes. The data path is shorter and more predictable, making incident response faster and root cause analysis simpler.
Every hop adds latency. Removing a Lambda from the critical path eliminates 50-200ms (best case cold start) or 5-20ms (warm invocation) from each request. For latency-sensitive applications this difference is material.
Lambda invocations, CloudWatch Logs, and associated data transfer all have costs. BREX-based routing is evaluated in-process with zero additional charges. For high-volume data streams, the savings are substantial.
Perhaps most important for teams under pressure, configuration changes deploy faster than code changes. Modifying a BREX expression is a CloudFormation stack update that takes seconds (no new deployment packages, quick code reviews for trivial changes, no testing pipeline for glue logic). Teams iterate faster when the feedback loop is tighter.
BREX isn't a replacement for all intermediaries. Complex business logic, external API calls, database lookups, and stateful processing still require custom code. BREX excels only at what it was designed for: extracting and routing data based on packet structure.
It's similar to pattern matching and data extraction, not general-purpose computation. If your logic is "extract these bytes and use them as an identifier," BREX may be ideal. If your logic is "look up this device in DynamoDB and apply business rules," you very likely still need an intermediary.
The sweet spot is eliminating simple Lambda functions that only perform data extraction, formatting, and routing—tasks that BREX handles declaratively with less overhead.
BREX is now available for SQS and IoT Data destinations, with more services planned. We're exploring:
Each new integration expands the range of Lambda functions you can eliminate, further simplifying your architecture and accelerating your team's velocity.
If you're currently using Lambda functions to parse and route UDP data, consider whether BREX could simplify your architecture. Start with the BREX syntax reference to understand the expression language, then explore the destination-specific documentation for SQS and IoT Data to see BREX in action.
For teams prioritizing velocity and cost efficiency, eliminating unnecessary intermediaries is a force multiplier. BREX makes that elimination practical, maintainable, and fast.
Get started with Proxylity UDP Gateway and BREX today. No upfront costs ‐ pay only for what you use.
Buy with AWS Try the Examples Explore BREX Syntax