Skip to content

fix(sns-subscriptions): use regionalized service principal for opt-in regions - #38339

Open
xkjjx wants to merge 5 commits into
aws:mainfrom
xkjjx:fix/sns-subscriptions-opt-in-region-principal
Open

fix(sns-subscriptions): use regionalized service principal for opt-in regions#38339
xkjjx wants to merge 5 commits into
aws:mainfrom
xkjjx:fix/sns-subscriptions-opt-in-region-principal

Conversation

@xkjjx

@xkjjx xkjjx commented Jul 17, 2026

Copy link
Copy Markdown

Issue # (if applicable)

Closes #32526.

Reason for this change

When subscribing an SQS queue or Lambda function to an SNS topic where one or both regions are opt-in regions, SqsSubscription and LambdaSubscription generate policies with the global sns.amazonaws.com service principal. Per the SNS cross-region delivery documentation, a regionalized service principal is required when opt-in regions are involved, otherwise messages are silently dropped.

Description of changes

Added a snsServicePrincipal() helper in aws-sns-subscriptions/lib/private/util.ts that determines the correct SNS service principal based on the topic and subscriber regions:

  • Default → opt-in region: uses sns.<subscriber-region>.amazonaws.com
  • Opt-in → default region: uses sns.<topic-region>.amazonaws.com
  • Opt-in → opt-in region: uses sns.<subscriber-region>.amazonaws.com
  • Default → default region: uses sns.amazonaws.com (unchanged)
  • Unresolved regions (tokens): falls back to sns.amazonaws.com (safe default)

The helper uses RegionInfo.get(region).isOptInRegion to determine whether regionalization is needed, and ServicePrincipal.fromStaticServicePrincipleName() to construct the regionalized principal directly. We use fromStaticServicePrincipleName rather than new ServicePrincipal('sns.amazonaws.com', { region }) because the standard ServicePrincipal region option relies on token resolution that compares the passed region against the stack's region at synth time — this fails when the policy lives in the same stack as the opt-in region (e.g., the subscriber is in the opt-in region), since stack.region === opts.region causes it to skip regionalization. Using the static method bypasses this entirely and makes the behavior deterministic.

Updated both SqsSubscription.bind() and LambdaSubscription.bind() to use this helper.

Description of how you validated changes

Added unit tests covering all scenarios:

  • Topic in opt-in region, queue in default region → regionalized principal
  • Queue in opt-in region, topic in default region → regionalized principal
  • Same region (both opt-in) → global principal
  • Cross-region default-to-default → global principal
  • Unresolved topic ARN → global principal (fallback)
  • Lambda subscription with topic in opt-in region → regionalized principal

Added integration test (integ.sns-sqs-cross-opt-in-region.ts) with snapshot verifying that a topic in ap-southeast-4 (opt-in) subscribing to a queue in us-east-1 produces the regionalized principal in the queue policy.

Checklist


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

…region subscriptions involving opt-in regions

When subscribing an SQS queue or Lambda function to an SNS topic where
one or both regions are opt-in regions, the generated policies now use
the correct regionalized service principal (e.g.,
sns.<region>.amazonaws.com) instead of always using the global
sns.amazonaws.com principal.

Per the SNS cross-region delivery documentation, the regionalized
principal is required when opt-in regions are involved:
- Default region to opt-in region: sns.<subscriber-region>.amazonaws.com
- Opt-in region to default region: sns.<topic-region>.amazonaws.com
- Opt-in region to opt-in region: sns.<subscriber-region>.amazonaws.com

Without this fix, cross-region SNS-to-SQS/Lambda delivery involving
opt-in regions silently fails with messages being dropped.

When regions cannot be determined at synth time (tokenized ARNs or
env-agnostic stacks), the behavior falls back to the global principal
to maintain backwards compatibility.

Closes aws#32526.
@github-actions github-actions Bot added bug This issue is a bug. effort/medium Medium work item – several days of effort beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK p2 labels Jul 17, 2026
@aws-cdk-automation
aws-cdk-automation requested a review from a team July 17, 2026 22:38

@aws-cdk-automation aws-cdk-automation left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This review is outdated)

… subscription

Adds an integration test that verifies the SQS queue policy uses a
regionalized service principal (sns.ap-southeast-4.amazonaws.com) when
the SNS topic is in an opt-in region and the queue is in a default
region.
@aws-cdk-automation
aws-cdk-automation dismissed their stale review July 17, 2026 22:47

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

…oth opt-in cases

Use the same explicit principal construction for both subscriber-opt-in
and topic-opt-in scenarios rather than mixing approaches. This avoids
relying on ServicePrincipalToken's resolve-time region comparison logic
and makes the behavior deterministic at construct time.
…le instead

Use the imported function name directly and rename the local variable
from snsServicePrincipal to principal to avoid the naming conflict.
@aws-cdk-automation aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK bug This issue is a bug. effort/medium Medium work item – several days of effort p2 pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

aws-sns-subscriptions: Adding SqsSubscription on SNS topic does not create correct queue policy for SQS when SNS topic is present in opt-in AWS regions

2 participants