- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Google Cloud, Azure, OCI, and Private Kubernetes
- On Azure
Coverage by target cloud
How the targets compare
Each row compares a capability of EventBridge with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
On Google Cloud
Via Pub/Sub
Bus, rules and destinations
The target design maps an EventBridge bus to a Pub/Sub topic and PutEvents to topic publication. Rules use Pub/Sub subscription attribute filters. A delivery worker pulls matched messages and forwards them to each rule’s configured target through the target service’s selected adapter. Pub/Sub attribute filtering cannot directly evaluate nested EventBridge detail objects. Review each event pattern before selecting this target. Rules that depend on nested content need the PostgreSQL-backed matcher or a deliberate change to the event and filter design; similar field names do not make the filter languages equivalent.Delivery, scheduling and operations
Google operates Pub/Sub storage and subscription redelivery. The adapter handles the EventBridge API and destination delivery. Broker acceptance, filter matching and target success are distinct stages: test all three and make target side effects safe to repeat after duplicate delivery. Scheduled rules use Google Cloud Scheduler rather than a Pub/Sub filter. Provision the schedule, topic, subscription and destination together, with the required identities and network access. Archive/replay, Pipes and the schema registry are outside this mapping. Switch producers after the rules and destinations are ready. Existing AWS history is not copied into the target. Size and validate the deployment with the customer’s event sizes, rule count and destination behavior.On Google Cloud, Azure, OCI, and Private Kubernetes
Via CloudNativePG
Accepting and matching an event
The Tensor9 adapter serves EventBridge requests using PostgreSQL for buses, rules, targets, events and pending deliveries. For each event, it evaluates enabled event-pattern rules on the destination bus. It commits the event and delivery records for matched rule-target pairs in one database transaction. This transaction is per event; do not treat a PutEvents batch as one application transaction. The adapter evaluates patterns in code instead of translating them to a broker’s attribute filter. Nested objects are matched recursively. Fields in an object must all match, while a field’s candidate values are alternatives. This supports rules over nested detail data as well as the envelope. The matcher supports prefix, suffix, ASCII case-insensitive equality, numeric comparisons, exists, * wildcards and the documented anything-but forms. CIDR matching is outside this matcher scope. Test matching and nonmatching examples for each operator used by the application, including combinations of operators.Delivering matched events
A worker claims pending deliveries with a temporary lease and sends each to its resolved target. The delivered body is the EventBridge envelope, or the target’s static Input when supplied. The envelope includes id, source, detail-type, time, region, account, resources and detail. Input transformation is a separate feature and must be checked against the profile’s limits. A delivery accepted by the target can be repeated if the worker fails before recording success. Targets must tolerate duplicates. Temporary failures are retried with increasing delay and an attempt cap; permanent failures and exhausted attempts become terminal. Removing a target also makes its remaining deliveries terminal. Monitor backlog and terminal failures independently of PutEvents success.Rules, targets and migration
Provision buses, rules and targets before switching producers, then test representative matching and nonmatching events. Confirm each target’s selected service adapter and network access. A matching rule is not enough if its destination cannot accept the delivered event. Scheduled rules need the scheduler described by the deployment, separately from event-pattern evaluation. Existing AWS event history is not copied into the database. Archive/replay, Pipes and the schema registry remain outside this mapping. A stored event used for pending delivery is not an EventBridge archive or an application-facing replay facility.On Azure
Via Azure Event Grid
How it works
A Tensor9 adapter in the customer environment accepts your application’s EventBridgePutEvents calls. Each event bus maps to an Event Grid topic; events are published in the CloudEvents format, and Event Grid advanced filters match the rules. Event handlers deliver matches to each target’s replacement service, such as the SQS or SNS adapter.
Microsoft operates Event Grid’s storage, delivery, retry and dead-lettering. The adapter uses the appliance’s workload identity to authenticate without a stored key.
Filter support and the PostgreSQL alternative
Event Grid advanced filters support numeric ranges, string containment and nested keys, but cover only part of EventBridge’s filter syntax. Limits on filter count and nesting can prevent a rule from being translated. Check the event patterns your application uses before choosing this target. With Event Grid, Microsoft operates event matching and delivery. The PostgreSQL target evaluates nested detail fields and its supported pattern operators in the adapter. Compare those operators with your rules when Event Grid cannot express them; it does not cover every EventBridge pattern form. The customer also operates the PostgreSQL database used for event and delivery state.Scheduled rules use Container Apps
Event Grid has no scheduler. Scheduled EventBridge rules use a Container Apps Job that scales to zero between runs. A stack containing both event-pattern rules and scheduled rules therefore provisions both Event Grid and Container Apps resources. Check the Container Apps section for its schedule and target restrictions.Limitations
△ Event Grid limitations- Content filtering is capped below EventBridge’s grammar. Advanced filters cover numeric ranges, string containment and nested keys, with limits on filter count and nesting. Check each required pattern against Event Grid and the PostgreSQL adapter’s supported operators before selecting a target.
- Archive and replay are out of scope. EventBridge can archive events and replay them later. Nothing here reproduces that, so a recovery or backfill procedure built on replay does not port and needs another design.
- Pipes and the schema registry are out of scope. EventBridge Pipes and the schema registry are unsupported by this target.
- Scheduled rules use Container Apps Jobs. Event Grid has no scheduler, so a cron or rate rule is served by a Container Apps Job instead. Expect a mixed stack to provision both, and review the scheduled-rule section for its constraints.
Other considerations
- Allow pending AWS deliveries to finish. Provision topics, filters and handlers before switching producers. Pending EventBridge deliveries and retries are not copied to Event Grid. Keep the old destinations available while those deliveries finish, and handle duplicate events during cutover.
- Review Event Grid retry limits. Retry and dead-lettering are Event Grid’s, with its own caps on delivery attempts and event time-to-live, and dead-lettered events land in Storage. If your operational runbooks assume EventBridge’s retry behaviour, those numbers are the ones to re-read.
- Targets resolve to their own equivalents. An SQS target sends a message through the SQS adapter selected for this appliance. Review each target service’s support and limitations alongside the EventBridge rules.
Via Container Apps
How it works
A scheduled EventBridge rule maps to a Container Apps Job with a schedule trigger. The job scales to zero between runs. Each run sends the scheduled event to the rule’s SQS target throughSendMessage, using the SQS adapter selected for the appliance.
Cron translation
AWS cron expressions have six fields; standard cron has five and uses a different day-of-week convention. Tensor9 translates expressions that preserve the schedule. If an expression cannot be represented, deployment fails with an error identifying it. Revise that schedule before deployment.Supported rules and targets
This target supports scheduled rules with SQS destinations. Deployment rejects event-pattern rules because the job provides neither an event bus norPutEvents. Use Event Grid for pattern rules, or compare the PostgreSQL adapter’s supported operators when your rules need nested detail matching that Event Grid cannot express.
Non-SQS destinations are also rejected. A scheduled rule that invokes a function or sends to another service needs a different implementation.
Limitations
△ Scheduled-rule limitations- Only scheduled rules are served here. Deployment rejects event-pattern rules for this target. Use Event Grid or the PostgreSQL adapter after checking its supported pattern operators.
- Only SQS targets are served here. The job delivers through the SQS adapter. Other target types are rejected at deploy, so a scheduled rule that invokes a function or posts to an API needs that gap closed before this target works for it.
- Some AWS cron expressions cannot be expressed at all. AWS’s six-field cron is more expressive than standard cron in places. An untranslatable expression is a deploy-time error, which means a rule you rely on may need its schedule restated in a form standard cron can express.
- Allow for job startup time. The job starts a new instance on each trigger. Measure the delay before processing begins if your application has a deadline after the scheduled time.
Other considerations
- Estimate cost from job runs. Job compute is billed while the job runs. Estimate it from the schedule frequency, run duration and resources required.
- Check cron translation before deployment. The translation is decided at deploy, so the fastest way to find an untranslatable expression is to look at your rules’ schedules first. Six-field expressions and unusual day-of-week forms are where the refusals land.
- A mixed stack provisions both mechanisms. If some rules are scheduled and others match patterns, expect Container Apps resources alongside Event Grid ones. On AWS they were entries on one bus; here they are two different services, and both appear in the plan.