Standing Up a Governed AWS Foundation in Days, Not Quarters: A Post-Merger Integration Pattern for Financial Services

When two regulated banks merge, the cloud integration question is usually framed as a choice between two bad options: extend one institution’s existing landing zone and inherit its accumulated compromises or spend two quarters designing a new one before a single workload can move. This post describes a third path – a greenfield governed organization stood up within days of legal close – drawn from a recent U.S. bank merger. The customer is anonymized; the pattern, the sequence, and the measured outcomes are real.

The headline result: the combined team created a fully governed AWS organization four days after legal close, with a nine-service security baseline (Amazon GuardDuty, AWS Security Hub, Amazon Detective, AWS Config, AWS Firewall Manager, IAM Access Analyzer, Amazon Inspector, Amazon Macie, and AWS CloudTrail) live in under ten minutes, and the first workload accounts vended 42 days later. This was possible not because the build was rushed, but because the foundation work started before close and the governance was established before any workload landed.

In this post, you will learn how to sequence a post-merger cloud foundation so that governance is established before workloads land, and how pre-close design compresses the integration timeline from quarters to days.

The problem: two estates, one regulator, no time

A bank merger creates a specific cloud problem. Each institution arrives with its own AWS footprint (or none), its own identity provider, its own security tooling, and its own network addressing – frequently overlapping [IP_ADDRESS] space that cannot be routed together without NAT or re-addressing, stalling network integration for months. Meanwhile the regulator does not grant a grace period: from legal close, the combined entity is expected to demonstrate unified controls, complete audit logging, and defensible access governance.

This is not abstract: examination requirements such as SEC Rule 17a-4 and FINRA Rule 4511 mandate immutable records retention from the moment of legal close. Establishing an organization-wide audit trail while the organization is still empty is what makes these obligations satisfiable by design rather than by remediation.

The instinct is to consolidate onto whichever estate looks more mature. In this engagement the acquired institution had the stronger cloud practice – a full datacenter exit already codified in Terraform – so extending its environment was tempting. The team rejected it. A landing zone built by one bank for one bank encodes assumptions (account structure, guardrail scope, identity model) that do not survive the doubling of scale and the addition of a second regulator-facing entity. Instead, the team built new. Three things make this greenfield different from simply creating a new organizational unit (OU) within one estate. First, the entire organization is built as code through Account Factory for Terraform (AFT), so governance is inherited by every account at birth rather than applied after the fact. Second, pre-close planning means the design (OU structure, Service Control Policy (SCP) set, identity model, addressing plan) is complete before Day 0, so the build is execution of a plan rather than discovery under pressure. Third, greenfield addressing in [IP_ADDRESS] sidesteps the CIDR-overlap problem entirely, which extending either legacy estate would not.

The pattern: Discover → Stabilize → Consolidate → Modernize

The engagement followed a four-phase arc that generalizes to most regulated-industry M&A cloud integrations:

Discover (pre-close) – Establish the target operating model while regulatory review runs in parallel. Decide greenfield vs. extend, choose the account-vending mechanism, and model identity federation. This happens before legal close, using the announcement-to-close window that would otherwise be dead time.

Stabilize (Day 0 → ~Day 45) – Stand up the governed organization: landing zone, organizational units, Service Control Policies, delegated security administration, centralized logging and address management. The objective is to establish governance controls (logging, guardrails, identity, addressing) ahead of the first account vend, so that no workload ever operates in an ungoverned state.

Consolidate (~Month 2 → Month 6) – Vend workload accounts, migrate the priority applications, harden security to the full control set, and drive toward the core-system conversion event.

Modernize (Month 6+) – With the foundation proven, introduce higher-order workloads – analytics, then generative AI – on the same governed substrate, and decommission the legacy estate.

The rest of this post focuses on Stabilize, because that is where the 42-day result is won or lost, and where the reusable engineering lives.

Architecture: a greenfield governed organization

The diagram below shows the target-state governance model as deployed in this engagement:

Figure 1: The target-state governance model, established before any workload account is vended. Security tooling, logging, identity, and address management are delegated to purpose-specific accounts; workload accounts inherit governance at birth.

The organization is built on AWS Control Tower with Account Factory for Terraform (AFT) as the vending mechanism, structured into six organizational units (Core, Operations, Platform, Workloads, Sandbox, Deployments) with production/non-production separation under Workloads. Three design decisions carry most of the weight:

• Three-tier delegated administration: Rather than operate security from the management account, the team delegates by function: the Security Tooling account owns the nine security services (Amazon GuardDuty, AWS Security Hub, Amazon Detective, AWS Config, AWS Firewall Manager, IAM Access Analyzer, Amazon Inspector, Amazon Macie, and AWS CloudTrail); the operations-tooling account owns identity and observability; the network account owns connectivity and address management. This keeps the management account minimal – its only standing job is to enforce policy.
• Immutable, organization-wide logging from Day 0: An organization trail streams every API call to a segregated log-archive account from the outset – so there are no audit blind spots to backfill under examination.
• Centralized address management: VPC IP Address Manager (IPAM) is delegated to the network account and shared organization-wide through AWS Resource Access Manager (AWS RAM). A greenfield [IP_ADDRESS] pool deliberately avoids the [IP_ADDRESS] space both legacy estates already occupy, so hybrid connectivity via AWS Direct Connect routes cleanly from the first connection.

The timeline insight: the head start is pre-close

Figure 2: From announcement to operational readiness. Cloud foundation work (the pre-close bars) began roughly six weeks before legal close and ran in parallel with regulatory review, so the governed organization existed within days of Day 0 rather than months after it.

The single most transferable lesson is visible in the negative offsets on the timeline. The greenfield design workshop happened roughly six weeks before legal close; identity modeling and the MVP build plan followed, all while regulatory approval was still pending. Legal close is a hard gate for operating combined infrastructure – but it is not a gate for designing it. Teams that treat the announcement-to-close window as planning time, rather than waiting for Day 0 to start, convert months of post-close latency into days.

This is why “four days to a governed org” is not a heroic sprint. By Day 0 the team already knew the OU structure, the SCP set, the identity model, and the addressing plan. Day 0 to Day 4 was execution of a plan, not discovery.

The 42-day path is a dependency chain

The speed of the foundation build is often misread as parallelism – many teams working many tracks at once. It was the opposite. The path from legal close to first workload was a sequence, where each control was the precondition for the next, and skipping ahead was not an option.

This sequence is codified, not manual, which means each step is recoverable. If a security-service delegation fails, Config rules and Security Hub findings detect the drift before the next step proceeds. If pre-close design assumptions prove wrong post-close, the AFT pipeline catches errors before an account reaches production. The chain is not fragile because it is sequential; it is sequential because each control must be verifiable before the next one depends on it.

Security services cannot be delegated until the organization exists. Identity cannot federate until IAM Identity Center is delegated. Workload accounts cannot be vended until IPAM can hand each one a non-overlapping CIDR. What looks like a 42-day sprint is really a critical path: six governance milestones in strict order, each unlocking the next.

Reading the sequence this way reframes the metric. “42 days to first workload” is not a speed record to chase – it is the minimum length of the dependency chain once the pre-close design work is done.

The following diagram maps the dependency chain visually:

Figure 3: The governance establishment sequence. Each control unlocks the next: security delegation requires the organization to exist, identity federation requires Identity Center to be delegated, and workload vending requires IPAM to allocate non-overlapping CIDRs. The 42-day path is this dependency chain, not a set of independent tasks.

The sequence below is the critical path in prescriptive form. Each step names the service that does the work and the precondition it depends on:

1. Deploy the landing zone (Day 0). AWS Control Tower and AWS Organizations apply the baseline Service Control Policies. Precondition: none – this is the root action.

2. Delegate security and identity administration (Day 2). The nine security services are delegated to the Security Tooling account; IAM Identity Center is delegated separately to the operations-tooling account. Precondition: the organization must exist (step 1).

3. Turn on organization-wide logging (Day 4). An AWS CloudTrail organization trail streams to the log-archive account, and the SCP that protects it is enforced. Precondition: the Core OU and log-archive account (step 1).

4. Federate identity (Day 14). This step connects the two institutions’ directory services to IAM Identity Center as external identity sources (via SAML/SCIM) and maps permission sets to the organizational-unit structure, enabling both workforces to authenticate without account-level IAM users. Precondition: Identity Center delegation (step 2).

5. Delegate address management (Day 23). VPC IPAM moves to the network account and shares the [IP_ADDRESS] pool org-wide through AWS RAM. Precondition: the network account and org-wide RAM (step 1).

6. Vend the first workload accounts (Day 42). Account Factory for Terraform provisions the accounts; each inherits its organizational unit’s SCPs, enrolls in the delegated security services, and draws a non-overlapping CIDR from IPAM. Precondition: all of the above – this step consumes every prior control.

Step 6 is the payoff, and it is also the proof that the ordering is not optional: a workload account cannot be governed, logged, authenticated, or addressed unless steps 1 through 5 already exist. That is why the 42 days compress rather than parallelize.

Four anchor implementations

Of the sixteen Service Control Policies and the full landing-zone build, four pieces best illustrate the “governed before workloads” principle – two guardrails, one addressing control, and the account-vending mechanism that ties them together. Each is small enough to read in full, and each closes a gap that is expensive to remediate after workloads have already landed. They are shown complete here because the point is not that any one of them is complex, but that the vending step inherits them all automatically.

The first protects the audit trail; the second constrains the highest-risk accounts; the third guarantees non-overlapping addressing; the fourth vends accounts that are born governed. Together they show the failure modes a governed foundation has to prevent from day one – losing audit coverage, unbounded blast radius in experimental accounts, and painting the merged network into a corner it cannot route out of – and how automated vending makes “governed” the default rather than a manual checklist.

1. Protect the audit trail with a Service Control Policy

The first control applied – before the first account is created – prevents anyone, including administrators in member accounts, from disabling or tampering with the organization CloudTrail. This is the control examiners ask about first.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectOrgCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "cloudtrail:PutEventSelectors"
      ],
      "Resource": "arn:aws:cloudtrail:*:*:trail/org-trail"
    }
  ]
}

What the team accepted and rejected. The team chose an unconditional deny rather than an exemption-based pattern (e.g., a break-glass role that can modify the trail), because “a role that can turn off logging” is exactly the finding an examiner flags. The trade-off is operational friction – any trail change must go through the governed IaC pipeline – in exchange for a control that is unconditional and demonstrable under examination.

2. Centralize address space with an IPAM pool hierarchy

The second anchor is the IPAM pool that guarantees every vended account receives non-overlapping space – the precondition for routable hybrid connectivity to both legacy estates.

resource "aws_vpc_ipam" "org" {
  operating_regions { region_name = var.home_region }
}

resource "aws_vpc_ipam_pool" "top" {
  address_family = "ipv4"
  ipam_scope_id  = aws_vpc_ipam.org.private_default_scope_id
  locale         = var.home_region
}

resource "aws_vpc_ipam_pool_cidr" "top" {
  ipam_pool_id = aws_vpc_ipam_pool.top.id
  cidr         = "[IP_ADDRESS]"          # greenfield space - never overlaps legacy [IP_ADDRESS]
}

resource "aws_vpc_ipam_pool" "workloads" {
  address_family      = "ipv4"
  ipam_scope_id       = aws_vpc_ipam.org.private_default_scope_id
  source_ipam_pool_id = aws_vpc_ipam_pool.top.id
  locale              = var.home_region
  allocation_default_netmask_length = 20   # each workload VPC draws a /20
}

What the team accepted and rejected. The team accepted a single home-region pool at first, deferring multi-region IPAM until a genuine multi-region workload existed – building the full regional hierarchy on Day 1 would have been governance for its own sake. It rejected letting teams choose their own CIDRs (the status quo in both legacy estates), because self-allocated addressing is precisely what makes post-merger networks un-routable. Central allocation is a small constraint that removes an entire class of future migration blockers.

3. Constrain the highest-risk accounts with a scoped SCP

The CloudTrail guardrail is organization-wide. The second guardrail does the opposite – it tightly bounds a specific OU. In this engagement the Sandbox OU (including the AI Center-of-Excellence accounts) was the highest-velocity, highest-experimentation environment, so it received the most restrictive policy: pinned to approved Regions, blocked from creating public network paths, and denied the ability to weaken its own guardrails.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [ "iam:*", "sts:*", "organizations:Describe*", "support:*" ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": [ "us-east-1", "us-west-2" ] }
      }
    },
    {
      "Sid": "DenyPublicIngressAndGuardrailTampering",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateInternetGateway",
        "ec2:AttachInternetGateway",
        "guardduty:DeleteDetector",
        "config:DeleteConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

What the team accepted and rejected. The team accepted that data scientists in the AI-CoE accounts cannot spin up internet-facing infrastructure on their own – a real friction point for experimentation – because an ungoverned public path in a bank’s sandbox is an unacceptable blast radius. It rejected applying this same policy org-wide: production workloads legitimately need controlled ingress, so the strict version is scoped to the Sandbox OU only. Guardrails are not one-size-fits-all – the tightest policy belongs on the most experimental accounts, which is the opposite of many teams’ instinct.

4. Vend accounts that are born governed (Account Factory for Terraform)

The first three artifacts only pay off if every new account inherits them without a human remembering to apply them. That is the job of AFT: an account request is a small Terraform file, and the pipeline provisions the account already enrolled in the OU’s SCPs, the delegated security services, and a non-overlapping CIDR from IPAM.

module "commercial_api_prod" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory//modules/aft-account-request"

  control_tower_parameters = {
    AccountEmail              = "aws+commercial-api-prod@example.com"
    AccountName               = "commercial-api-prod"
    ManagedOrganizationalUnit = "Workloads"          # inherits Workloads-OU SCPs
    SSOUserFirstName          = "Cloud"
    SSOUserLastName           = "Team"
    SSOUserEmail              = "cloud-team@example.com"
  }

  account_tags = {
    "workload"    = "commercial-api"
    "environment" = "prod"
    "data-class"  = "regulated"
  }

  # Account-level customizations run automatically post-provisioning:
  #   - VPC drawn from the shared IPAM pool (non-overlapping CIDR)
  #   - GuardDuty / Security Hub / Config auto-enrolled via delegated admin
  #   - baseline IAM roles + break-glass access
  account_customizations_name = "workload-baseline"
}

What the team accepted and rejected. The team accepted the up-front cost of building the AFT pipeline before vending a single production account – roughly the first two weeks of the 42-day path produced no workloads, only the factory. It rejected click-ops account creation, even for the “quick” first account, because every manually created account becomes a governance exception someone has to reconcile later. The payoff showed up at Day 134, when six accounts were vended in about eleven minutes, each born governed – a pace that is only possible because the factory, not a runbook, enforces the baseline.

What we measured

The metrics below are the strongest evidence that “governed and fast” are not in tension. They compare this engagement to what a conventional post-close, extend-the-landing-zone approach typically yields in regulated-industry integrations.

Industry-typical figures are based on the authors’ experience across multiple regulated-industry integrations and published benchmarks (Bain, BankDirector).

Two clarifications keep these honest. Organic monthly spend at month 13 was approximately 178 times the first full month’s spend (the 1x baseline), reflecting genuine workload adoption on the new foundation rather than migration lift-and-shift. And “under 10 minutes” for the security baseline reflects Control Tower plus delegated-admin automation enabling nine services organization-wide, not nine services fully tuned, which is the multi-month hardening work of the Consolidate phase.

What this is not

To keep the pattern credible, it is worth stating its boundaries plainly:

• This is not a data-migration playbook. It governs the foundation onto which workloads move; the core-system conversion itself (a single high-stakes weekend, in this case) is a separate discipline.
• This is not “secure in ten minutes.” The baseline is enabled in minutes; achieving the fully hardened control set – full-feature threat detection, vulnerability scanning, data-loss controls – took months and is expected to.
• This is not vendor-neutral identity magic. Federating two identity providers into one organization enables workforce coexistence; it does not consolidate directories, and it does not remove the eventual project to rationalize them.
• This is not a substitute for the pre-close window. The 42-day result depends on design work done before Day 0. A team that starts at close should expect the timeline to shift right by the length of its planning phase.

Why it matters now: the regulatory frame

For a financial institution, the governance-first sequence is not an aesthetic preference – it maps directly to examination requirements. Establishing an immutable, organization-wide audit trail while the organization is still empty means records-retention obligations such as SEC Rule 17a-4 and FINRA Rule 4511 are satisfiable by design rather than by remediation. Delegated security administration gives examiners a single, demonstrable control plane across every account. And central address governance is what makes the combined network auditable at all. Doing this work first is what lets a merged bank answer “show me your controls” on Day 30 instead of Month 6.

Conclusion

The post-merger cloud question is not “extend or rebuild.” It is “when does governance begin?” By moving foundation design into the pre-close window and standing up a greenfield governed organization before any workload exists, this combined bank turned what is usually two quarters of post-close latency into a matter of days – and did so with stronger, more demonstrable controls than an extended landing zone would have inherited. The pattern is repeatable: discover before close, stabilize governance before workloads, consolidate onto the proven foundation, then modernize. The team that executed this 42-day build comprised approximately six engineers with deep Control Tower and Terraform expertise, supported by an AWS Solutions Architect and Technical Account Manager. To apply this pattern to your own integration, engage your AWS account team during the pre-close window.

Learn more

• Customizations for AWS Control Tower (CfCT)
• AWS Security Reference Architecture – AWS Organizations
• SEC01-BP01: Separate workloads using accounts – AWS Well-Architected Security Pillar
  • Best Practices for Service Control Policies in an AWS Organizations Multi-Account Environment
  • Account Factory for Terraform (AFT)
  • VPC IPAM administration guide
  • IAM Identity Center multi-account setup

The customer in this post is anonymized. Durations, sequences, ratios, and architecture patterns are drawn from a real engagement; company names, absolute dates, account identifiers, and vendor specifics have been removed or genericized. This post reflects the author’s experience and does not represent customer endorsement.