Aws Sns Laravel Package

Product Decisions This Supports

• Vendor consolidation: is AWS good enough to replace our SMS/push provider? The channel turns SNS into a first-class Laravel via() target, so "could we drop Twilio/FCM and send through AWS instead?" becomes a cheap spike rather than a quarter-long migration project. Frame the experiment with explicit pass/fail criteria up front — per-message cost at our volume, delivery observability, segment/payload limits, and country coverage — and accept that a negative answer still has value: we've de-risked a vendor decision for the price of a Composer dependency.

• Build vs. buy on notification plumbing — buy the glue, own the judgment. What we're outsourcing is small and boring: topic/endpoint/phone addressing, AWS credential and region resolution, message attributes, Laravel's routing conventions. Engineering effort saved is modest; the real trade is maintenance risk transfer — from "we maintain glue code" to "a 56-star, single-maintainer package could go quiet." Because it's MIT and deliberately thin, the fallback (vendor the channel, swap the SnsClient wrapper) is roughly a day of work, not a project. The PM decision is whether that residual risk belongs in a customer-facing send path — say yes for internal/ops alerts, be more careful for revenue-touching transactional messages.

• Roadmap sequencing: this is a rider on the framework upgrade, not a standalone initiative. v2.0.0 hard-requires Laravel ≥ 12.11.0 (it delegates NotificationFailed dispatch to the framework) with no shim. Planning these as two separate workstreams is the most likely scheduling mistake. Scope the Laravel bump on its own merits — it has value independent of this package — and attach SNS as a dependent line item, not a parallel track.

• Delivery reliability as a product capability, not an infra detail. The 2.0.0 behavior change (stop swallowing exceptions; stop firing the package's own failure event; rely on Laravel's canonical NotificationFailed) is the strongest product-facing argument for upgrading. One normalized failure signal across all channels is what lets us build once — a delivery-status view, a support-facing "did the customer actually receive this?" lookup, alerting on send failures — instead of a per-channel special case each time.

• A support-facing error taxonomy. The new named exception classes let us split "invalid recipient" (don't retry; prompt the user to fix their number) from "provider/transport failure" (retry with backoff; show "try again shortly"). Without that split, every failure renders as the same unhelpful error and default-routes to engineering. This is a directly user-visible quality improvement we can spec and test.

• Cost governance on retries. SNS SMS is billable per message and per segment, and failures now propagate instead of being absorbed — meaning retries and failed_jobs become a spend vector, not just an availability one. Set explicit $tries/backoff() policy, require idempotency keys wherever a duplicate text is worse than a missed one, and put "watch SNS spend through the first full billing cycle post-deploy" on the launch checklist as an owner-assigned item.

• New reach surfaces, cheaply. Because topic ARNs, endpoint ARNs, and direct phone numbers are the same message class with different addressing, the same integration covers broadcast use cases we may not have budgeted for: ops/on-call pages, audience-segment announcements, and push to registered device endpoints. Worth a line in the PRD even if v1 only ships transactional SMS.

When to Consider This Package

Good fit when:

• You are on, or already committed to, Laravel 12.11.0+ — treat the framework floor as a gate, not a detail.
• Your use cases sit inside SNS's model: plain SMS, topic broadcast, endpoint push. No rich push payload composition, no template management.
• AWS is already your vendor (especially if SES handles email — SNS + SES + IAM is a coherent single-vendor story with one credential/audit surface).
• You have, or will build, a listener on the framework's NotificationFailed event. Adopting the channel without a failure hook is adopting a silent-failure path.
• Your team accepts thin observability, or has budgeted separately for CloudWatch delivery-status parsing.

Proceed deliberately (not "neutral default") when:

• You are below Laravel 12.11.0 and would pin to ^1.0. Document that as dated technical debt with an exit criterion — you're forking behavior permanently, including the old failure semantics.
• You have existing try/catch blocks around Notification::send(), imports of the package's prior exception classes, or listeners on its old failure event. Those don't error on upgrade, they just stop matching. Grep them into an acceptance checklist before bumping; this is the highest-risk defect class in the whole change, because it fails open and silent.

Look elsewhere when:

• The product needs delivery receipts, templated/managed messages, per-message analytics, or precise cost forecasting out of the box — SNS gives you none of that through this channel.
• You need one notification abstraction spanning older Laravel versions across multiple apps.
• You require an actively maintained, multi-maintainer dependency in a regulated or revenue-critical path.
• Push notifications are the primary use case rather than SMS — the rich-payload story is better served by a dedicated push channel.

Non-negotiable pre-launch checks to write into the plan: SNS SMS sandbox status and spending quota lifted (a staging send to your own phone proves nothing); phone numbers stored in E.164 at the source; IAM roles over static keys wherever possible so config:cache doesn't freeze credential rotation; and region/ARN consistency asserted, since mismatch presents as a misleading permissions error.

How to Pitch It (Stakeholders)

To executives: We can add SMS and broadcast messaging to the product through our existing AWS agreement using a small, MIT-licensed glue package rather than building notification infrastructure ourselves or signing a new vendor. The cost is one dependency plus a Laravel framework upgrade we already want; the strategic upside is a live test of whether AWS can replace part of our messaging vendor spend, answered with a two-week spike instead of a migration program. The main risk is dependency on an unmaintained community package — mitigated by its small size and permissive license, which make it cheap to own outright if needed. The upgrade also standardizes how all channels report delivery failure, which is the foundation for the customer-facing "did they get my message?" capability support keeps asking for.

To engineering: This is a thin driver over the AWS SDK that plugs into Laravel's notification pipeline — you write via() and toSns(), you don't write SDK calls. It's ~a day to integrate and ~a day to fork if it dies. The real work isn't integration, it's the migration: v2.0.0 requires Laravel 12.11.0+ and flips failure handling from swallowed-and-re-emitted to propagated-and-framework-handled. That is a silent breaking change for any existing try/catch or custom failure listener — so budget time for an audit, not just a composer update. Expect previously "successful" queued notifications to start landing in failed_jobs; set $tries, backoff(), and uniqueness constraints deliberately, since SNS retries are billable. Test against Notification::fake() and assert on the message object; only stub the SNS client when proving the failure path. Wrap the Aws\Sns\SnsClient and bind your own instance if you need logging or metrics — don't fork for that.