Moving your Snowplow AWS account to a different AWS Organization

Overview

Moving your AWS account into a different AWS Organization is a common step during a merger or reorganization, and on its own it does not disrupt your Snowplow pipeline. The account keeps its ID, and the resources inside it are not destroyed or recreated. The area to watch is the governance layer that changes around the account, not the pipeline itself.

This article explains what carries over unaffected, the one change that can cause problems, and what we need from you to give you a clean assessment before the move.

What stays the same

When an account moves between Organizations, the account ID does not change. Because the account ID is preserved, the following are unaffected by the move on their own:

• All pipeline infrastructure in the account, including your collector, streams, processing, and storage resources.

• Cross-account IAM roles that grant access based on the account ID, including the roles used to operate and deploy the pipeline. These are account-to-account trusts, so they carry over.

• Data already in the pipeline and in storage. Nothing is destroyed or recreated by the move.

One thing to check on your side. If any IAM role trust policy or resource policy (for example on S3 buckets, KMS keys, SQS queues, or SNS topics) grants access based on the AWS Organization ID rather than the account ID, that access is keyed to the old Organization and will need updating for the new one. Scanning for aws:PrincipalOrgID, aws:PrincipalOrgPaths, and any direct reference to your current Organization ID across those policies is the fastest way to confirm whether this applies to you. If the scan comes back with no matches, this is not a concern.

Where the real risk sits: Service Control Policies

The one change that can affect a running pipeline is the set of Service Control Policies (SCPs) enforced by the destination Organization. When your account leaves its current Organizational Unit and joins the new one, it inherits whatever SCPs apply there.

If any of those policies deny an action, a Region, or a service that the pipeline relies on, resources can lose permissions even though nothing about them changed. This is the most common cause of disruption in an otherwise clean account move.

We cannot see the destination Organization's SCPs, so we cannot confirm compatibility from our side. A Region allowlist is the most visible kind of SCP, but restrictions often sit deeper in the policy rules than a Region check surfaces, so a clean Region check on its own is not enough to rule out a problem.

Why we ask you to validate the SCPs. Only your team, or the team managing the destination Organization, can see the full SCP set that will apply to the account after the move. Validating it against what the pipeline and its deployment tooling actually do is the single most useful thing you can do to de-risk the migration.

Planning the migration window

Once you have a date, let us know so we can agree a window with you.

Two things worth arranging ahead of the window:

• Someone who can adjust an SCP on the destination side should be available during and shortly after the window. If a policy turns out to block the pipeline, a quick turnaround lets us clear it.

• Treat the hours right after the move as a monitoring period rather than a hard sign-off. The move is most likely clean, but the only way to fully confirm SCP compatibility is to run and maintain the pipeline through the change and watch it.

During and after the move

With the window agreed, the account move itself proceeds on your side. After it completes, we recommend watching the pipeline for a period to confirm it continues to collect, process, and load as before, and that routine maintenance actions still succeed under the new SCPs.

If something does surface, it will almost always be a permission denied by a destination SCP rather than anything wrong with the pipeline resources. That is why having someone able to adjust the SCPs on hand makes the difference between a quick fix and a drawn-out one.

When to raise a ticket with us

You do not need to raise a ticket simply to move your account to a new Organization. The guidance above covers the standard case. Please do get in touch if:

• Your Organization-ID policy scan returns matches and you are not sure which access needs updating.

• The pipeline shows errors after the move that you suspect are permission related.

To reach us, open a ticket at support.snowplow.io and include your planned or completed migration window and the destination SCP set if you have it.