Add IVS enhanced logging via EventBridge

[SethSharp]

Hey, I made a thing! 🥳

Great! Now please answer the following questions to help out your assigned reviewer:

What problems are you solving?

• IVS events aren't being logged anywhere, making it hard to debug live stream issues
• Sets up EventBridge rules + CloudWatch Logs so all IVS events (stream start/stop/failure, recording state, health, etc.) are captured automatically

Is there anything the reviewer needs to know to deploy this?

• This is fully opt-in — users need to add aws.logging.ivs: true to their yolo.yml to enable it
• Can also be run standalone via yolo sync:logging <environment>
• Optional aws.logging.ivs.log-retention-days config (defaults to 14 days)
• No impact on existing deployments — all steps return SKIPPED when IVS is not enabled
• Guard uses Manifest::get() (truthiness check) so ivs: false correctly disables the feature

Config example:

environments:
  production:
    aws:
      logging:
        ivs:
          log-retention-days: 14  # optional, defaults to 14

Or minimal:

environments:
  production:
    aws:
      logging:
        ivs: true

What does it provision?

1. CloudWatch Log Group (/aws/ivs/{keyed-name}) with configurable retention
2. CloudWatch resource policy granting events.amazonaws.com write access
3. EventBridge rule matching all aws.ivs events
4. EventBridge target wiring the rule to the log group

Architecture:

• New sync:logging command (follows Network/Storage/Compute/IAM pattern)
• Steps live in Steps/Logging/ with Ivs prefix (e.g. SyncIvsCloudWatchLogGroupStep)
• New UsesCloudWatchLogs and UsesEventBridge concerns for resource lookups

Coauthor Jarvis 🤖

🤖 Generated with Claude Code

[stevethomas]

Review Summary

Verdict: ❌ Changes Requested

Risk Assessment

Category	Status
Data Integrity	✅
Security	⚠️
Breaking Changes	✅
Operational	❌
Test Coverage	⚠️

Findings

❌ Blockers

src/Steps/Ivs/SyncCloudWatchLogGroupStep.php:59 — Missing CloudWatch Logs resource policy. EventBridge requires a resource-based policy on the log group granting logs:CreateLogStream and logs:PutLogEvents to events.amazonaws.com. Without this, putTargets succeeds but events silently fail to deliver — the entire IVS logging pipeline will appear configured but produce zero logs.

In src/Steps/Ivs/SyncCloudWatchLogGroupStep.php, after creating the
log group and setting its retention policy, add a
putResourcePolicy call granting events.amazonaws.com permission
to write to the log group. Apply on both create AND sync paths.
See EventBridge → CloudWatch Logs target docs.

⚠️ Warnings

src/Steps/Ivs/SyncEventBridgeTargetStep.php:34 — Target drift: if the target exists but the ARN has changed (e.g. log group rename), the step returns SYNCED without updating. Events would route to a stale log group.

In SyncEventBridgeTargetStep, instead of just checking the target
ID, also verify the ARN matches. If the ID exists but ARN differs,
fall through to putTargets to update it.

src/Steps/Ivs/SyncCloudWatchLogGroupStep.php — No unit tests for the 3 new IVS steps. Consistent with repo patterns (only arch tests exist), but these steps have real branching logic that would benefit from coverage. Not blocking since it's a repo-wide gap.

---

🤖 Reviewed by Claude Code

[stevethomas]

Review Summary

Verdict: ✅ Approved (with warnings)

Context

Found and fixed the Manifest::has vs Manifest::get bug during review — ivs: false would have bypassed the guard and provisioned resources. Fix pushed in dde6e2f.

Risk Assessment

Category	Status
Data Integrity	⚠️
Security	✅
Breaking Changes	✅
Operational	⚠️
Test Coverage	⚠️

Findings

⚠️ Warnings

src/Steps/Logging/SyncIvsEventBridgeTargetStep.php:41 — catch (EventBridgeException) swallows ALL errors (throttling, auth, network), not just "rule not found". A permissions error gets silently ignored and putTargets fails with a misleading error instead.

In SyncIvsEventBridgeTargetStep.php line 41, check
$e->getAwsErrorCode() for ResourceNotFoundException
specifically and re-throw anything else.

src/Steps/Logging/SyncIvsCloudWatchLogGroupStep.php:82 — CloudWatch Logs has a hard limit of 10 resource policies per region per account. Each YOLO app creates its own policy via keyedResourceName. Multiple apps with IVS in the same account will exhaust this. Consider a shared policy name or read-then-merge approach.

Check whether the per-app policyName in putResourcePolicy()
will scale within the 10-per-account CloudWatch Logs resource
policy limit. Consider a shared policy that merges log group ARNs.

src/Steps/Logging/SyncIvsCloudWatchLogGroupStep.php:89 — Resource policy lacks aws:SourceAccount condition — any EventBridge rule in any account could write to the log group.

Add Condition => StringEquals => aws:SourceAccount to the
resource policy to prevent cross-account confused deputy.

📝 Notes

• describeLogGroups uses prefix matching without pagination — if 50+ log groups share the prefix, exact match on page 2+ would be missed. Low risk with /aws/ivs/ prefix but worth noting for the generic trait.
• putResourcePolicy and putRule are called on every sync even when nothing changed — idempotent but noisy.
• putRule call is duplicated between try/catch branches in SyncIvsEventBridgeRuleStep — could extract to reduce duplication.
• No unit tests for the 3 new step classes. The has/get bug demonstrates the kind of issue tests would catch. Project convention is arch tests only for steps, but consider adding coverage for the branching logic.

---

🤖 Reviewed by Claude Code

[stevethomas]

Finding: catch (EventBridgeException) swallows ALL EventBridge errors — throttling, auth, network — not just "rule not found". A permissions error would be silently ignored, and putTargets below would fail with a confusing error instead of surfacing the real cause.
_{Severity: WARNING}

Suggested Fix

Check $e->getAwsErrorCode() for ResourceNotFoundException specifically and re-throw anything else so real errors (throttling, permissions) surface immediately.

Prompt

In src/Steps/Logging/SyncIvsEventBridgeTargetStep.php line 41,
the catch block catches all EventBridgeException types. Change
it to check $e->getAwsErrorCode() === 'ResourceNotFoundException'
and re-throw any other exception type so throttling, auth, and
network errors surface with their real error message.