fix(sns-subscriptions): use regionalized service principal for opt-in regions - #38339
Open
xkjjx wants to merge 5 commits into
Open
fix(sns-subscriptions): use regionalized service principal for opt-in regions#38339xkjjx wants to merge 5 commits into
xkjjx wants to merge 5 commits into
Conversation
…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.
aws-cdk-automation
previously requested changes
Jul 17, 2026
… 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
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
temporarily deployed
to
automation
July 21, 2026 04:13 — with
GitHub Actions
Inactive
aws-cdk-automation
temporarily deployed
to
automation
July 21, 2026 04:13 — with
GitHub Actions
Inactive
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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,
SqsSubscriptionandLambdaSubscriptiongenerate policies with the globalsns.amazonaws.comservice 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 inaws-sns-subscriptions/lib/private/util.tsthat determines the correct SNS service principal based on the topic and subscriber regions:sns.<subscriber-region>.amazonaws.comsns.<topic-region>.amazonaws.comsns.<subscriber-region>.amazonaws.comsns.amazonaws.com(unchanged)sns.amazonaws.com(safe default)The helper uses
RegionInfo.get(region).isOptInRegionto determine whether regionalization is needed, andServicePrincipal.fromStaticServicePrincipleName()to construct the regionalized principal directly. We usefromStaticServicePrincipleNamerather thannew ServicePrincipal('sns.amazonaws.com', { region })because the standardServicePrincipalregion 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), sincestack.region === opts.regioncauses it to skip regionalization. Using the static method bypasses this entirely and makes the behavior deterministic.Updated both
SqsSubscription.bind()andLambdaSubscription.bind()to use this helper.Description of how you validated changes
Added unit tests covering all scenarios:
Added integration test (
integ.sns-sqs-cross-opt-in-region.ts) with snapshot verifying that a topic inap-southeast-4(opt-in) subscribing to a queue inus-east-1produces 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