EventBridge

This page describes how EventBridge maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of EventBridge with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway

​

CloudNativePG

​

Accepting and matching events

Tensor9 serves EventBridge APIs with PostgreSQL holding buses, rules, targets, accepted events and pending delivery work. Terraform declarations and authenticated API calls address the same records within an account. Configure the application client to use the EventBridge endpoint and credentials for the target environment. For each event on an existing bus, the adapter evaluates enabled rules on that bus and commits the event with one delivery record per matched rule and target. Two rules sharing a destination produce separate deliveries. Entries commit separately. A batch request can fail after earlier entries have committed, so retrying the batch can duplicate events. Destination delivery happens afterward. A nonexistent bus can return an event ID without storing or delivering the event. Confirm the bus exists before switching producers; an event ID alone does not establish durable work. The matcher evaluates nested objects, scalar and array values, the alternatives operator, prefix and suffix with their case-insensitive forms, equals-ignore-case, wildcard with escaped asterisks, numeric ranges, exists, IPv4 and IPv6 cidr, and anything-but with values, prefix, suffix, wildcard and case-insensitive forms. It runs in the adapter, so rules can inspect nested detail data without promoting it to broker attributes. Invalid patterns are refused with EventBridge’s reasons. Case-insensitive comparison covers ASCII letters only.

​

Destination calls and payloads

Workers claim delivery records and call the configured destination. SQS, SNS and Lambda calls use signed service requests. Each destination needs a reachable endpoint and permission for its operation: SendMessage, Publish or InvokeFunction. Do not assume an SQS delivery role also grants SNS or Lambda access. Direct HTTP targets receive an unsigned POST; EventBridge Connections and managed API Destinations are outside this mapping. By default, a target receives the EventBridge envelope, including id, source, detail-type, time, region, account, resources and detail. A target can instead use constant Input, an InputPath selection or an InputTransformer template. Selection modes are mutually exclusive. JSON paths support the root, dotted members and nonnegative array indices. Unsupported path syntax is refused when configuring targets. Template variables must be declared; do not assume all AWS reserved variables are available. As in EventBridge, an InputPath that selects nothing delivers an empty JSON object, and a template variable whose path selects nothing renders as an empty value. Lambda calls first request asynchronous invocation. A receiver that explicitly refuses it uses synchronous fallback. With that fallback, function errors follow the EventBridge target retry policy, and Lambda asynchronous failure destinations do not apply. Deliveries in a claimed batch are sent concurrently, so a slow function does not hold the others in its batch, though the slowest send, up to a per-send deadline, delays the next batch.

​

Recovery, retries and dead letters

Accepted delivery work survives a process restart. Work a stopped worker had claimed resumes when that claim expires, which can take up to about five minutes. A worker can retry after a lease expires, including when the destination accepted the preceding call but the worker failed before recording success. Delivery is at least once with no ordering guarantee. Use an application event key to make destination side effects safe to repeat. Each target can set its retry count and event-age limit. Age is measured from acceptance, rather than from the event’s supplied time. The default attempt budget differs from AWS. One target’s retry state is independent of another target’s success. Terminal dispatch failures with a configured SQS dead-letter queue record the failed delivery and pending dead-letter send in one database transaction. A separate worker sends the rendered target payload to that queue with EventBridge’s ERROR_CODE, ERROR_MESSAGE, RULE_ARN and TARGET_ARN message attributes, adding RETRY_ATTEMPTS and EXHAUSTED_RETRY_CONDITION when a retry or age limit ran out. Error codes other than permission, missing-resource and connection failures are reported as UNKNOWN. Dead-letter arrival is asynchronous and can also be duplicated after a crash. Queue failures retry separately, but exhausting that budget leaves work requiring operator attention. A configured dead-letter queue is therefore not a guarantee that every failed event arrives there.

​

Scheduled rules

A database-backed schedule driver creates the same durable work used for matched events. It supports rates and six-field UTC cron, including values, ranges that wrap, lists, steps, names, the question-mark day selector, and the L, L-n, LW, nW, nL and n#k calendar forms. PutRule validates expressions as EventBridge does and allows schedules only on the default bus. It also refuses a few forms EventBridge accepts whose firing times are undocumented: a step of zero, # on a range or on a day outside 1-7, W on a range, and L-n or a ranged L in the day-of-week field. A rate too long to schedule within the database’s calendar is accepted and never fires. Missed occurrences during downtime are not backfilled, and re-enabling a rule does not replay its disabled intervals. This mapping covers EventBridge scheduled rules; the separate EventBridge Scheduler service is outside its scope.

​

Limitations

PutTargets refuses per-target RoleArn and service-specific parameter objects, including FIFO SqsParameters, ECS and HTTP parameters. A request containing an unsupported target field fails as a whole. Review the operation table before migrating those declarations. Workers resolve queued deliveries against target configuration when claiming work. Updating a target can change where pending work goes; an already claimed delivery may still use the previous configuration. Disabling a rule stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and recreating a target with the same name. Event archives, replay, cross-account and cross-region routing, customer KMS keys per bus, Pipes and the schema registry are outside this mapping. Durable delivery records do not provide an application-facing event archive. Case-insensitive pattern matching covers ASCII letters only.

​

Other considerations

Tensor9 operates the service adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity follow the selected PostgreSQL deployment. Configure database access and destination permissions as part of the deployment, then check received payloads as well as successful PutEvents responses. Provision buses, rules and targets before switching producers. Existing AWS history and pending deliveries are not copied. Keep source destinations available while their pending work finishes. Monitor pending work, retries, terminal failures and failed dead-letter sends separately; a successful publish does not establish successful delivery.

​

On Azure

​

PostgreSQL Flexible Server

​

PostgreSQL hosting

Microsoft operates Azure Database for PostgreSQL Flexible Server. The Cloud Adapter deployment provisions one server, injected into the Cloud Adapter deployment’s virtual network with no public endpoint, and every connection uses TLS. The PostgreSQL major version is fixed when the Cloud Adapter deployment is set up; Microsoft applies maintenance in its own window, which restarts the server. Automated backups keep seven days of history with point-in-time restore inside that window; geo-redundant backup is off. The server runs in a single availability zone without a zone-redundant standby, so a restart for maintenance or failure makes PutEvents return errors and stops delivery until the server returns. Committed events and pending deliveries are still there afterwards. EventBridge state lives in one database on that server. The SQS and SNS adapters on the same Cloud Adapter deployment use the same database when they run on PostgreSQL, and the Cloud Adapter deployment’s own state store is a separate database on the same server. Because an event bus declares no database size, the server has a fixed default size; connections, storage and throughput are shared limits, so watch them alongside pending delivery work. When the Cloud Adapter deployment is set up, the administrator password is generated and the connection string is stored in the Cloud Adapter deployment’s Azure Key Vault; the adapter’s identity can read that one secret and nothing else in the vault, and the application never handles it. Removing the Cloud Adapter deployment removes the server and the EventBridge state on it, so drain pending work first. Buses start empty, and existing AWS history is not migrated.

​

Accepting and matching events

Tensor9 serves EventBridge APIs with PostgreSQL holding buses, rules, targets, accepted events and pending delivery work. Terraform declarations and authenticated API calls address the same records within an account. Configure the application client to use the EventBridge endpoint and credentials for the target environment. For each event on an existing bus, the adapter evaluates enabled rules on that bus and commits the event with one delivery record per matched rule and target. Two rules sharing a destination produce separate deliveries. Entries commit separately. A batch request can fail after earlier entries have committed, so retrying the batch can duplicate events. Destination delivery happens afterward. A nonexistent bus can return an event ID without storing or delivering the event. Confirm the bus exists before switching producers; an event ID alone does not establish durable work. The matcher evaluates nested objects, scalar and array values, the alternatives operator, prefix and suffix with their case-insensitive forms, equals-ignore-case, wildcard with escaped asterisks, numeric ranges, exists, IPv4 and IPv6 cidr, and anything-but with values, prefix, suffix, wildcard and case-insensitive forms. It runs in the adapter, so rules can inspect nested detail data without promoting it to broker attributes. Invalid patterns are refused with EventBridge’s reasons. Case-insensitive comparison covers ASCII letters only.

​

Destination calls and payloads

Workers claim delivery records and call the configured destination. SQS, SNS and Lambda calls use signed service requests. Each destination needs a reachable endpoint and permission for its operation: SendMessage, Publish or InvokeFunction. Do not assume an SQS delivery role also grants SNS or Lambda access. Direct HTTP targets receive an unsigned POST; EventBridge Connections and managed API Destinations are outside this mapping. By default, a target receives the EventBridge envelope, including id, source, detail-type, time, region, account, resources and detail. A target can instead use constant Input, an InputPath selection or an InputTransformer template. Selection modes are mutually exclusive. JSON paths support the root, dotted members and nonnegative array indices. Unsupported path syntax is refused when configuring targets. Template variables must be declared; do not assume all AWS reserved variables are available. As in EventBridge, an InputPath that selects nothing delivers an empty JSON object, and a template variable whose path selects nothing renders as an empty value. Lambda calls first request asynchronous invocation. A receiver that explicitly refuses it uses synchronous fallback. With that fallback, function errors follow the EventBridge target retry policy, and Lambda asynchronous failure destinations do not apply. Deliveries in a claimed batch are sent concurrently, so a slow function does not hold the others in its batch, though the slowest send, up to a per-send deadline, delays the next batch.

​

Recovery, retries and dead letters

Accepted delivery work survives a process restart. Work a stopped worker had claimed resumes when that claim expires, which can take up to about five minutes. A worker can retry after a lease expires, including when the destination accepted the preceding call but the worker failed before recording success. Delivery is at least once with no ordering guarantee. Use an application event key to make destination side effects safe to repeat. Each target can set its retry count and event-age limit. Age is measured from acceptance, rather than from the event’s supplied time. The default attempt budget differs from AWS. One target’s retry state is independent of another target’s success. Terminal dispatch failures with a configured SQS dead-letter queue record the failed delivery and pending dead-letter send in one database transaction. A separate worker sends the rendered target payload to that queue with EventBridge’s ERROR_CODE, ERROR_MESSAGE, RULE_ARN and TARGET_ARN message attributes, adding RETRY_ATTEMPTS and EXHAUSTED_RETRY_CONDITION when a retry or age limit ran out. Error codes other than permission, missing-resource and connection failures are reported as UNKNOWN. Dead-letter arrival is asynchronous and can also be duplicated after a crash. Queue failures retry separately, but exhausting that budget leaves work requiring operator attention. A configured dead-letter queue is therefore not a guarantee that every failed event arrives there.

​

Scheduled rules

A database-backed schedule driver creates the same durable work used for matched events. It supports rates and six-field UTC cron, including values, ranges that wrap, lists, steps, names, the question-mark day selector, and the L, L-n, LW, nW, nL and n#k calendar forms. PutRule validates expressions as EventBridge does and allows schedules only on the default bus. It also refuses a few forms EventBridge accepts whose firing times are undocumented: a step of zero, # on a range or on a day outside 1-7, W on a range, and L-n or a ranged L in the day-of-week field. A rate too long to schedule within the database’s calendar is accepted and never fires. Missed occurrences during downtime are not backfilled, and re-enabling a rule does not replay its disabled intervals. This mapping covers EventBridge scheduled rules; the separate EventBridge Scheduler service is outside its scope.

​

Limitations

PutTargets refuses per-target RoleArn and service-specific parameter objects, including FIFO SqsParameters, ECS and HTTP parameters. A request containing an unsupported target field fails as a whole. Review the operation table before migrating those declarations. Workers resolve queued deliveries against target configuration when claiming work. Updating a target can change where pending work goes; an already claimed delivery may still use the previous configuration. Disabling a rule stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and recreating a target with the same name. Event archives, replay, cross-account and cross-region routing, customer KMS keys per bus, Pipes and the schema registry are outside this mapping. Durable delivery records do not provide an application-facing event archive. Case-insensitive pattern matching covers ASCII letters only.

​

Other considerations

Tensor9 operates the service adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity follow the selected PostgreSQL deployment. Configure database access and destination permissions as part of the deployment, then check received payloads as well as successful PutEvents responses. Provision buses, rules and targets before switching producers. Existing AWS history and pending deliveries are not copied. Keep source destinations available while their pending work finishes. Monitor pending work, retries, terminal failures and failed dead-letter sends separately; a successful publish does not establish successful delivery.

​

Azure Event Grid

​

Scope of this relation

EventBridge delivery through Azure Event Grid is outside this profile’s offered contract. Use the PostgreSQL service adapter for EventBridge buses, rules and durable target delivery. This comparison explains the native Event Grid mechanisms and their differences.

​

Topics, filters and handlers

An Event Grid topic can represent events as CloudEvents. Event subscriptions apply advanced filters and deliver matches to handlers. Advanced filters support numeric and string conditions on supported fields, with syntax and limits that differ from EventBridge. A matching field name does not establish equivalent pattern behavior. An EventBridge mapping also needs an adapter for the EventBridge API and handlers that preserve target payload selection, destination permissions and delivery outcomes. Event Grid topic acceptance alone does not establish successful SQS, SNS or Lambda delivery.

​

Limitations

Event Grid topic subscriptions use their own retry and event-age policies. Dead letters can be written to Blob Storage, which differs from an EventBridge target’s SQS dead-letter queue. See Event Grid delivery and retry for the native contract. Scheduled rules need a separate scheduler and destination delivery mechanism. Container Apps job schedules alone do not provide those EventBridge semantics. Scheduled rules, target transformations, archives, replay, Pipes and the schema registry are outside this mapping.

​

Other considerations

Microsoft operates Event Grid topic storage and native delivery. Handlers still require authentication, network access and duplicate-safe processing. Review those responsibilities separately from the native broker’s retry policy when evaluating a migration.

​

Container Apps

​

Scheduled-job configuration

This infrastructure translation turns supported EventBridge scheduled-rule declarations into Azure Container Apps Jobs. It covers the job’s schedule configuration. It provides no EventBridge request endpoint, event bus or scheduled target delivery. Use the PostgreSQL service adapter when the application needs EventBridge matching, publication and delivery. A job schedule alone does not send the scheduled event to SQS.

​

Cron and rate translation

Container Apps scheduled jobs use five-field cron in UTC. The translation handles representable AWS six-field cron and rate expressions and rejects expressions it cannot preserve. Review the emitted schedule and allow for job startup time; a scheduled trigger does not guarantee immediate processing. See Container Apps jobs for the native scheduling and execution model.

​

Limitations

Deployment refuses event-pattern rules, non-SQS target declarations and target input overrides, including constant input, input paths and transformers. Accepting an SQS target declaration does not establish target delivery. EventBridge retry and dead-letter delivery are outside this mapping. Container Apps job retries and SQS queue redrive are separate policies. Archives, replay, Pipes, the schema registry and cross-account bus routing are also outside scope.

​

Other considerations

Microsoft operates job execution. Estimate compute use from schedule frequency, run duration and allocated resources. Application processing needs its own executable, destination credentials and network access; these responsibilities are separate from schedule translation.

​

On Google Cloud

​

Cloud SQL for PostgreSQL

​

PostgreSQL hosting

Google operates Cloud SQL for PostgreSQL. The Cloud Adapter deployment provisions one instance with no public IP address, reached only through a Private Service Connect endpoint inside the Cloud Adapter deployment’s network, and every connection uses TLS. The PostgreSQL major version is fixed when the Cloud Adapter deployment is set up; Google applies maintenance in its own window, which restarts the instance. Daily automated backups run with point-in-time recovery, keeping seven days of transaction logs and seven backups. The instance runs in a single zone without a regional standby, so a restart for maintenance or failure makes PutEvents return errors and stops delivery until the instance returns. Committed events and pending deliveries are still there afterwards. EventBridge state lives in one database on that instance. The SQS and SNS adapters on the same Cloud Adapter deployment use the same database when they run on PostgreSQL, and the Cloud Adapter deployment’s own state store is a separate database on the same instance. Because an event bus declares no database size, the instance has a fixed, shared-core default machine size; connections, storage and throughput are shared limits, so watch them alongside pending delivery work. When the Cloud Adapter deployment is set up, a dedicated database user and password are generated and the connection string is stored in the Cloud Adapter deployment’s Secret Manager, where the adapter resolves it; the application never handles it. Removing the Cloud Adapter deployment removes the instance and the EventBridge state on it, so drain pending work first. Buses start empty, and existing AWS history is not migrated.

​

Accepting and matching events

Tensor9 serves EventBridge APIs with PostgreSQL holding buses, rules, targets, accepted events and pending delivery work. Terraform declarations and authenticated API calls address the same records within an account. Configure the application client to use the EventBridge endpoint and credentials for the target environment. For each event on an existing bus, the adapter evaluates enabled rules on that bus and commits the event with one delivery record per matched rule and target. Two rules sharing a destination produce separate deliveries. Entries commit separately. A batch request can fail after earlier entries have committed, so retrying the batch can duplicate events. Destination delivery happens afterward. A nonexistent bus can return an event ID without storing or delivering the event. Confirm the bus exists before switching producers; an event ID alone does not establish durable work. The matcher evaluates nested objects, scalar and array values, the alternatives operator, prefix and suffix with their case-insensitive forms, equals-ignore-case, wildcard with escaped asterisks, numeric ranges, exists, IPv4 and IPv6 cidr, and anything-but with values, prefix, suffix, wildcard and case-insensitive forms. It runs in the adapter, so rules can inspect nested detail data without promoting it to broker attributes. Invalid patterns are refused with EventBridge’s reasons. Case-insensitive comparison covers ASCII letters only.

​

Destination calls and payloads

Workers claim delivery records and call the configured destination. SQS, SNS and Lambda calls use signed service requests. Each destination needs a reachable endpoint and permission for its operation: SendMessage, Publish or InvokeFunction. Do not assume an SQS delivery role also grants SNS or Lambda access. Direct HTTP targets receive an unsigned POST; EventBridge Connections and managed API Destinations are outside this mapping. By default, a target receives the EventBridge envelope, including id, source, detail-type, time, region, account, resources and detail. A target can instead use constant Input, an InputPath selection or an InputTransformer template. Selection modes are mutually exclusive. JSON paths support the root, dotted members and nonnegative array indices. Unsupported path syntax is refused when configuring targets. Template variables must be declared; do not assume all AWS reserved variables are available. As in EventBridge, an InputPath that selects nothing delivers an empty JSON object, and a template variable whose path selects nothing renders as an empty value. Lambda calls first request asynchronous invocation. A receiver that explicitly refuses it uses synchronous fallback. With that fallback, function errors follow the EventBridge target retry policy, and Lambda asynchronous failure destinations do not apply. Deliveries in a claimed batch are sent concurrently, so a slow function does not hold the others in its batch, though the slowest send, up to a per-send deadline, delays the next batch.

​

Recovery, retries and dead letters

Accepted delivery work survives a process restart. Work a stopped worker had claimed resumes when that claim expires, which can take up to about five minutes. A worker can retry after a lease expires, including when the destination accepted the preceding call but the worker failed before recording success. Delivery is at least once with no ordering guarantee. Use an application event key to make destination side effects safe to repeat. Each target can set its retry count and event-age limit. Age is measured from acceptance, rather than from the event’s supplied time. The default attempt budget differs from AWS. One target’s retry state is independent of another target’s success. Terminal dispatch failures with a configured SQS dead-letter queue record the failed delivery and pending dead-letter send in one database transaction. A separate worker sends the rendered target payload to that queue with EventBridge’s ERROR_CODE, ERROR_MESSAGE, RULE_ARN and TARGET_ARN message attributes, adding RETRY_ATTEMPTS and EXHAUSTED_RETRY_CONDITION when a retry or age limit ran out. Error codes other than permission, missing-resource and connection failures are reported as UNKNOWN. Dead-letter arrival is asynchronous and can also be duplicated after a crash. Queue failures retry separately, but exhausting that budget leaves work requiring operator attention. A configured dead-letter queue is therefore not a guarantee that every failed event arrives there.

​

Scheduled rules

A database-backed schedule driver creates the same durable work used for matched events. It supports rates and six-field UTC cron, including values, ranges that wrap, lists, steps, names, the question-mark day selector, and the L, L-n, LW, nW, nL and n#k calendar forms. PutRule validates expressions as EventBridge does and allows schedules only on the default bus. It also refuses a few forms EventBridge accepts whose firing times are undocumented: a step of zero, # on a range or on a day outside 1-7, W on a range, and L-n or a ranged L in the day-of-week field. A rate too long to schedule within the database’s calendar is accepted and never fires. Missed occurrences during downtime are not backfilled, and re-enabling a rule does not replay its disabled intervals. This mapping covers EventBridge scheduled rules; the separate EventBridge Scheduler service is outside its scope.

​

Limitations

PutTargets refuses per-target RoleArn and service-specific parameter objects, including FIFO SqsParameters, ECS and HTTP parameters. A request containing an unsupported target field fails as a whole. Review the operation table before migrating those declarations. Workers resolve queued deliveries against target configuration when claiming work. Updating a target can change where pending work goes; an already claimed delivery may still use the previous configuration. Disabling a rule stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and recreating a target with the same name. Event archives, replay, cross-account and cross-region routing, customer KMS keys per bus, Pipes and the schema registry are outside this mapping. Durable delivery records do not provide an application-facing event archive. Case-insensitive pattern matching covers ASCII letters only.

​

Other considerations

Tensor9 operates the service adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity follow the selected PostgreSQL deployment. Configure database access and destination permissions as part of the deployment, then check received payloads as well as successful PutEvents responses. Provision buses, rules and targets before switching producers. Existing AWS history and pending deliveries are not copied. Keep source destinations available while their pending work finishes. Monitor pending work, retries, terminal failures and failed dead-letter sends separately; a successful publish does not establish successful delivery.

​

Google Pub/Sub

​

Scope of this relation

EventBridge delivery through Google Cloud Pub/Sub is outside this profile’s offered contract. Use the PostgreSQL service adapter for EventBridge buses, rules and durable target delivery. This comparison explains the native Pub/Sub mechanisms and the differences that matter when evaluating an EventBridge mapping.

​

Topics, filters and destination delivery

A Pub/Sub topic is the natural counterpart of an event bus, with subscriptions selecting messages for consumers. Pub/Sub filters inspect message attributes, not the message body. Promoting source and detail-type to attributes can express simple conditions; nested EventBridge detail matching requires additional processing. See Pub/Sub message filtering. An EventBridge mapping also needs a service adapter to accept PutEvents and manage rules, plus workers that apply target input selection and call authorized destinations. A broker’s acknowledgment is distinct from completion of that destination call.

​

Limitations

Native subscription redelivery and dead-letter topics do not establish EventBridge per-target retry, event-age or SQS dead-letter semantics. A separate scheduler, such as Cloud Scheduler, would also need to preserve rule timing and destination behavior. These capabilities are outside this mapping, as are archives, replay, Pipes and the schema registry.

​

Other considerations

Google operates Pub/Sub storage and subscription redelivery. Application consumers still need authentication, network access and duplicate-safe processing. Evaluate native Pub/Sub with those responsibilities in view; its broker features alone do not establish EventBridge API compatibility or target delivery.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.