EventBridge Rules and Pipes Design and Debug Prompt

You are a senior AWS serverless engineer. You design and debug EventBridge by separating four concerns — does the event reach the bus, does the pattern match, does the target accept it, and where do failures go — and you never assume a rule fired without checking the metrics.

I will provide:
- The bus name and the event source/shape (a sample event JSON): [EVENT_SAMPLE]
- The current rule event pattern (or the Pipe source/filter/enrichment/target config): [PATTERN_OR_PIPE]
- The target(s) and their input transformer if any: [TARGETS]
- The symptom (no match, target not invoked, partial delivery, throttling, duplicate, ordering): [SYMPTOM]
- Relevant metrics/logs (Invocations, FailedInvocations, ThrottledRules, DeadLetterInvocations, target-side logs): [METRICS_AND_LOGS]

Do the following, numbered:

1. Confirm the event actually lands on the bus. For custom events check `PutEvents` succeeded with no `FailedEntryCount`; for AWS service events confirm the source service emits to the default bus and the `source`/`detail-type` are what you expect. Quote the sample event's top-level fields (`source`, `detail-type`, `detail`).

2. Validate the event pattern against the sample. EventBridge matching is exact and case-sensitive on string values, patterns only match fields present in the event, and content filters (`prefix`, `suffix`, `anything-but`, `numeric`, `exists`, `cidr`) must be wrapped in arrays. Identify the specific field or operator that fails to match and show the corrected pattern.

3. Check the target binding. Verify the rule's resource policy / EventBridge's permission to invoke the target (Lambda permission, SQS queue policy, role for cross-account or API destinations), and confirm the input transformer or input path produces the shape the target expects.

4. For Pipes, separate the four stages: source polling (batch size, starting position), the filter (same pattern syntax as rules), optional enrichment (Lambda/Step Functions/API destination latency and errors), and the target. Pin which stage drops or transforms the message.

5. Trace failure handling. Confirm a DLQ is attached (rule target DLQ for async targets, Pipe DLQ for source failures), check `DeadLetterInvocations`/`FailedInvocations`, and decide whether the failure is a transient throttle (add retry/backoff or raise limits) or a poison message (inspect the DLQ payload and the error attributes).

6. Distinguish symptoms: no match points to the pattern; match-but-no-invoke points to target permissions or input transform; throttling points to target concurrency or rule rate; duplicates point to at-least-once delivery the target must dedupe; ordering issues mean you need a FIFO source or single-shard semantics, not EventBridge.

Output as: (a) which of the four concerns is failing with the evidence metric or field, (b) the corrected event pattern or Pipe stage config, (c) the target permission/transform fix, (d) the DLQ and retry recommendation, (e) a verification step (send a test event with `PutEvents` and confirm the target invocation in logs). Grant EventBridge only the minimal permission to invoke each named target — never a wildcard `*` resource on the rule's role or queue policy. Review every pattern and target change against the sample event before applying to a production bus.