> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # EventBridge > AWS EventBridge, an event bus that matches JSON events against rules and delivers them to targets such as Lambda, SQS and Step Functions. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Max adaptation](#max-adaptation) * [On Google Cloud](#on-google-cloud) * [Via Pub/Sub](#via-pub/sub) * [On Google Cloud, Azure, OCI, and Private Kubernetes](#on-google-cloud-azure-oci-and-private-kubernetes) * [Via CloudNativePG](#via-cloudnativepg) * [On Azure](#on-azure) * [Via Azure Event Grid](#via-azure-event-grid) * [Via Container Apps](#via-container-apps) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | ✓ | | Private Kubernetes | ✓ | ## 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 | Capability | EventBridge | Google Cloud · Pub/Sub | Google Cloud, Azure, OCI, and Private Kubernetes · CloudNativePG | Azure · Azure Event Grid | Azure · Container Apps | | ----------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Event bus + PutEvents | native | EventBridge bus and publish API served by the adapter | EventBridge bus and publish API served by the adapter | EventBridge bus and publish API served by the adapter | - | | Event-pattern matching | Yes | Partial - Pub/Sub subscription attribute filter, a subset (no nested detail matching) | Yes - EventBridge content filtering in the adapter, including nested detail matching; validate the application's operators | Partial - Event Grid advanced filters, the closest native match, still a subset (filter count/nesting limits) | - | | Scheduled rules · cron / rate | native | translated to a standard scheduler (inexpressible crons are rejected at deploy) | translated to a standard scheduler (inexpressible crons are rejected at deploy) | translated to a standard scheduler (inexpressible crons are rejected at deploy) | a Container Apps Job schedule trigger (translated cron; inexpressible crons are rejected at deploy) | | Rule targets · fan-out | SQS / SNS / Lambda / … | a pull-bridge re-emits to each target's own equivalent | a durable outbox row per target, re-delivered to each target's own equivalent (at-least-once) | event handlers re-emit to each target's own equivalent | - | | Target DLQ + retry | Yes | Partial - Pub/Sub dead-letter topic + maxDeliveryAttempts (attempt-count only; the age cap maps only to Pub/Sub's coarse min-10-min message retention) | Yes - durable outbox retry honoring maximum\_retry\_attempts + maximum\_event\_age\_in\_seconds, then a DLQ table (Tensor9-owned) | Yes - Event Grid dead-lettering to Storage + native retry (both caps: maxDeliveryAttempts + eventTimeToLive) | - | | API coverage | full | high | high | high | high | | Event-pattern rules | Yes | - | - | - | No - this target supports scheduled rules only; use the Event Grid or Postgres tier for event-pattern rules | | Rule target · delivery | SQS / SNS / Lambda / … | - | - | - | delivered to the target's own equivalent (SQS target → SendMessage) | ## On Google Cloud ### Via Pub/Sub | Operation | Area | Support | Depth | Notes | | --------------------------------------------------- | --------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cross-account / cross-region buses | Bus | Out of scope | Full surface | a bus spans one deployment; cross-account and cross-region event routing is out of scope | | Event bus (default + custom) | Bus | Supported | Common | each bus is provisioned at apply-time; a custom bus is its own topic (or partition of the events store) | | Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | a bus-level customer-managed KMS key is not supported; encryption at rest follows the backing store's own model (target-managed), not a per-bus customer key | | Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | the schema registry and Pipes (source → filter → enrich → target) are distinct products, out of scope | | PutEvents | Publish | Supported | Common | a custom event is published to the bus with its source and detail-type; on the durable tier it is committed before the call returns | | Archive + replay | Replay | Out of scope | Full surface | event archive and time-range replay have no analog here (out of scope for this equivalence) | | Rule: event pattern (JSON matcher) | Rules | Partial | Common | the event pattern maps to a Pub/Sub subscription attribute filter: source and detail-type are promoted to attributes and matched natively, but deep nested-detail matching is a subset of EventBridge's grammar | | Rule: scheduled (cron / rate) | Rules | Supported | Most usage | AWS 6-field cron and rate schedules are translated for the target scheduler; deployment rejects a schedule that cannot be represented | | DLQ + retry policy on targets | Targets | Partial | Most usage | a target DLQ maps to a Pub/Sub dead-letter topic; the attempt cap (maximum\_retry\_attempts) maps to the dead-letter policy's maxDeliveryAttempts (the cloud's own, range 5-100), but the age cap (maximum\_event\_age\_in\_seconds) has no equivalent setting; Pub/Sub bounds redelivery only by the subscription's message retention (min 10 min), too coarse to honor it | | Target input (constant / input\_path / transformer) | Targets | Partial | Full surface | delivery supports constant input unchanged, an input\_path JSONPath selection, or an input transformer using input\_paths + input\_template. Only a subset of transformer template syntax is supported | | Targets (fan a rule to N targets) | Targets | Supported | Common | a matched rule fans out to each of its targets (an SQS / SNS / Lambda target is delivered to that service's own equivalent) | #### 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 | Operation | Area | Support | Depth | Notes | | --------------------------------------------------- | --------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cross-account / cross-region buses | Bus | Out of scope | Full surface | a bus spans one deployment; cross-account and cross-region event routing is out of scope | | Event bus (default + custom) | Bus | Supported | Common | each bus is provisioned at apply-time; a custom bus is its own topic (or partition of the events store) | | Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | a bus-level customer-managed KMS key is not supported; encryption at rest follows the backing store's own model (target-managed), not a per-bus customer key | | Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | the schema registry and Pipes (source → filter → enrich → target) are distinct products, out of scope | | PutEvents | Publish | Supported | Common | a custom event is published to the bus with its source and detail-type; on the durable tier it is committed before the call returns | | Archive + replay | Replay | Out of scope | Full surface | event archive and time-range replay have no analog here (out of scope for this equivalence) | | Rule: event pattern (JSON matcher) | Rules | Supported | Common | The adapter stores and evaluates event patterns in code, including prefix, anything-but, numeric ranges, exists, alternatives and nested detail matching. Check the pattern operators used by the application. | | Rule: scheduled (cron / rate) | Rules | Supported | Most usage | AWS 6-field cron and rate schedules are translated for the target scheduler; deployment rejects a schedule that cannot be represented | | DLQ + retry policy on targets | Targets | Supported | Most usage | a failed target delivery retries from the durable outbox (Tensor9-owned), honoring the retry policy's maximum\_retry\_attempts (attempt cap) and maximum\_event\_age\_in\_seconds (age cap), then lands in a DLQ table; delivery is at-least-once | | Target input (constant / input\_path / transformer) | Targets | Partial | Full surface | delivery supports constant input unchanged, an input\_path JSONPath selection, or an input transformer using input\_paths + input\_template. Only a subset of transformer template syntax is supported | | Targets (fan a rule to N targets) | Targets | Supported | Common | a matched rule fans out to each of its targets (an SQS / SNS / Lambda target is delivered to that service's own equivalent) | #### 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 | Operation | Area | Support | Depth | Notes | | --------------------------------------------------- | --------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cross-account / cross-region buses | Bus | Out of scope | Full surface | a bus spans one deployment; cross-account and cross-region event routing is out of scope | | Event bus (default + custom) | Bus | Supported | Common | each bus is provisioned at apply-time; a custom bus is its own topic (or partition of the events store) | | Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | a bus-level customer-managed KMS key is not supported; encryption at rest follows the backing store's own model (target-managed), not a per-bus customer key | | Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | the schema registry and Pipes (source → filter → enrich → target) are distinct products, out of scope | | PutEvents | Publish | Supported | Common | a custom event is published to the bus with its source and detail-type; on the durable tier it is committed before the call returns | | Archive + replay | Replay | Out of scope | Full surface | event archive and time-range replay have no analog here (out of scope for this equivalence) | | Rule: event pattern (JSON matcher) | Rules | Partial | Common | the event pattern maps to Event Grid advanced filters, the closest native match to EventBridge content filtering (numeric ranges, string contains, nested keys), still capped below EventBridge's full grammar (filter count/nesting limits) | | Rule: scheduled (cron / rate) | Rules | Supported | Most usage | AWS 6-field cron and rate schedules are translated for the target scheduler; deployment rejects a schedule that cannot be represented | | DLQ + retry policy on targets | Targets | Supported | Most usage | a target DLQ maps to Event Grid dead-lettering to Storage, with both retry caps native: the attempt cap (maximum\_retry\_attempts) maps to Event Grid's maxDeliveryAttempts (1-30) and the age cap (maximum\_event\_age\_in\_seconds) to its eventTimeToLive (1-1440 min); both retry limits are applied by Event Grid | | Target input (constant / input\_path / transformer) | Targets | Partial | Full surface | delivery supports constant input unchanged, an input\_path JSONPath selection, or an input transformer using input\_paths + input\_template. Only a subset of transformer template syntax is supported | | Targets (fan a rule to N targets) | Targets | Supported | Common | a matched rule fans out to each of its targets (an SQS / SNS / Lambda target is delivered to that service's own equivalent) | #### How it works A Tensor9 adapter in the customer environment accepts your application's EventBridge `PutEvents` 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.
Before: on AWS a producer calls PutEvents on an EventBridge bus, rules match events by pattern and deliver to targets. After: on Azure the same PutEvents call is served by a Tensor9 adapter onto an Event Grid topic as CloudEvents, advanced filters match, and event handlers re-emit each matched event to the target's own equivalent. Before: on AWS a producer calls PutEvents on an EventBridge bus, rules match events by pattern and deliver to targets. After: on Azure the same PutEvents call is served by a Tensor9 adapter onto an Event Grid topic as CloudEvents, advanced filters match, and event handlers re-emit each matched event to the target's own equivalent.
#### 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 | Operation | Area | Support | Depth | Notes | | ---------------------------------------------------------- | --------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Event bus + PutEvents | Bus | Out of scope | Common | this target supports scheduled rules only; it provisions no event bus and no publish path. Use the Event Grid or the durable Postgres tier for a bus + PutEvents | | Archive + replay / Pipes / schema registry / cross-account | Ecosystem | Out of scope | Full surface | unsupported for scheduled jobs | | Rule: event pattern (JSON matcher) | Rules | Out of scope | Common | an event-pattern (bus-matching) rule is caught at deploy here; use Event Grid or the PostgreSQL adapter for event-pattern rules | | Rule: scheduled (cron / rate) | Rules | Supported | Common | a scheduled Container Apps Job runs the translated AWS 6-field cron or rate schedule and scales to zero between runs; deployment rejects schedules that cannot be represented | | DLQ + retry policy on targets | Targets | Partial | Most usage | delivery uses the selected SQS adapter; its storage and dead-letter behavior also apply here | | Target input (constant / input\_path / transformer) | Targets | Out of scope | Full surface | for scheduled jobs the job runs on its cron and receives the rule's scheduled event; a target input override (a constant Input, an input\_path selector, or an input\_transformer) is caught at deploy, so set the job's payload in the Container Apps Job definition instead | | Target: SNS / Lambda / non-SQS | Targets | Out of scope | Full surface | only SQS destinations are supported; deployment rejects other destination types | | Target: SQS | Targets | Supported | Common | each job run sends the scheduled event to the SQS target through SendMessage on its selected adapter | #### 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 through `SendMessage`, using the SQS adapter selected for the appliance.
Before: on AWS a scheduled EventBridge rule fires on a cron or rate schedule and delivers an event to its target. After: on Azure a Container Apps Job with a schedule trigger fires the translated cron, scales to zero between runs, and sends the scheduled event through the target SQS adapter. Before: on AWS a scheduled EventBridge rule fires on a cron or rate schedule and delivers an event to its target. After: on Azure a Container Apps Job with a schedule trigger fires the translated cron, scales to zero between runs, and sends the scheduled event through the target SQS adapter.
#### 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 nor `PutEvents`. 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. [Service Catalog](/service-adapters/catalog).