AWS Details Post-Merger Cloud Foundation Built in Four Days for a U.S. Bank

AWS has outlined a post-merger cloud integration approach in which a U.S. bank established a new, governed AWS organization four days after its legal merger close.

The approach was designed to address a common challenge in financial services mergers: combining two cloud environments while maintaining security controls, auditability, identity governance, and network connectivity.

In a September 27, 2026, AWS for Industries article, authors Abiola Olanrewaju, Maran Chandrasekaran, and Nathan Preston describe how the combined team built a new AWS organization instead of extending either institution's existing cloud environment.

The customer remains anonymous, but AWS says the implementation sequence and measured outcomes are based on a real engagement.

The reported milestones include:

• Four days after legal close: A governed AWS organization was established.

• Under 10 minutes: A baseline of nine security services was enabled organization-wide.

• 42 days after legal close: The first workload accounts were provisioned.

• Day 134: The team provisioned six workload accounts in about 11 minutes.

AWS attributes the timeline to planning and design work completed before legal close, followed by a controlled sequence of governance milestones.

The approach places governance ahead of workload migration, with account provisioning, security administration, identity federation, logging, and network addressing established before applications enter the new environment.

Why Cloud Integration Becomes Difficult After a Bank Merger

A merger between regulated financial institutions can bring together two separate cloud environments, identity providers, security tools, and network configurations.

Each institution may have different account structures, security policies, and access-management practices. Their private IP address ranges may also overlap, complicating connectivity between the two environments.

These challenges can delay integration while the combined institution is expected to demonstrate consistent security controls and auditability.

AWS describes two conventional approaches:

1. Extend one institution's existing cloud environment and inherit its existing design decisions and limitations.

2. Build a new cloud foundation after legal close, potentially delaying workload migration while the organization establishes its governance model.

In the featured engagement, the acquired institution had a more mature cloud environment, including a data-center exit already codified in Terraform. However, the team chose not to extend that environment.

Instead, it built a new AWS organization with a separate account structure, identity model, security controls, and IP address plan.

The objective was to establish a foundation designed for the combined institution rather than adapt one bank's existing environment to serve both.

Governance and regulatory considerations

The article identifies record-retention requirements under SEC Rule 17a-4 and FINRA Rule 4511 as part of the regulatory context for financial institutions.

AWS's approach establishes organization-wide audit logging before workload accounts are created, allowing the combined institution to begin operating on a foundation with centralized logging already in place.

The article presents this as a way to make auditability part of the initial architecture rather than a control that must be added later.

The Four-Phase Integration Pattern: Discover, Stabilize, Consolidate, Modernize

AWS organizes the approach into four phases, with governance establishment forming the central part of the implementation.

1. Discover

  <badge color="info">Before legal close</badge>
  Define the target operating model, choose the cloud foundation strategy, plan the organizational structure, and model identity federation while regulatory review continues.
</box>

2. Stabilize

  <badge color="success">Day 0 to approximately Day 45</badge>
  Establish the landing zone, organizational units, security policies, delegated administration, centralized logging, identity federation, and address management before provisioning workload accounts.
</box>

3. Consolidate

  <badge color="warning">Approximately Month 2 to Month 6</badge>
  Provision workload accounts, migrate priority applications, strengthen security controls, and prepare for core-system conversion.
</box>

4. Modernize

  <badge color="discovery">Month 6 onward</badge>
  Introduce higher-order workloads, including analytics and generative AI, on the governed foundation and decommission the legacy environment.
</box>

AWS focuses its article on the Stabilize phase, describing it as the stage where the team establishes the controls required for subsequent workload provisioning and migration.

Architecture: A New AWS Organization With Delegated Governance

The team built the environment using AWS Control Tower and Account Factory for Terraform (AFT).

The organization was divided into six organizational units:

• Core

• Operations

• Platform

• Workloads

• Sandbox

• Deployments

The Workloads organizational unit also separated production and non-production environments.

The architecture uses dedicated accounts for security tooling, operations tooling, networking, and log archiving. This separates administrative responsibilities and reduces the role of the management account to enforcing organizational policy.

Three-tier delegated administration

The architecture assigns administrative responsibilities across three functional areas.

Security Tooling account: Owns the nine security services used in the foundation.

Operations Tooling account: Handles identity and observability responsibilities.

Network account: Manages connectivity and IP address allocation.

The security baseline includes:

1. Amazon GuardDuty

2. AWS Security Hub

3. Amazon Detective

4. AWS Config

5. AWS Firewall Manager

6. IAM Access Analyzer

7. Amazon Inspector

8. Amazon Macie

9. AWS CloudTrail

AWS says the nine services were enabled organization-wide in under 10 minutes through Control Tower and delegated-administrator automation. This refers to enabling the baseline, not completing all security tuning.

Organization-wide logging from the beginning

An AWS CloudTrail organization trail sends API activity to a separate log-archive account.

The architecture also applies a Service Control Policy to protect the trail from being disabled or modified by administrators in member accounts.

The objective is to establish centralized audit logging before the first workload account is provisioned.

Centralized IP address management

The team delegated VPC IP Address Manager (IPAM) to the network account and shared its address pools across the organization through AWS Resource Access Manager.

The new environment uses a separate address space designed to avoid overlap with the legacy environments.

This is intended to support hybrid connectivity through AWS Direct Connect without requiring the team to reconcile overlapping private address ranges during the initial integration.

The article does not disclose the actual private IP address ranges used in the deployment.

Why Pre-Close Planning Made the Timeline Possible

AWS identifies the period before legal close as a key factor in the implementation.

The greenfield design workshop took place approximately six weeks before legal close. Identity modeling and the minimum viable product build plan followed while regulatory review was still underway.

By legal close, the team had already defined:

• Organizational unit structure

• Service Control Policy requirements

• Identity federation model

• Network addressing strategy

• Cloud foundation implementation plan

This meant the post-close work could focus on executing a prepared design instead of beginning the architecture process from scratch.

AWS distinguishes between planning infrastructure before legal close and operating the combined environment after close. The article presents the pre-close period as an opportunity to complete design work while the legal and regulatory process continues.

The 42-Day Governance Dependency Chain

AWS describes the foundation build as a sequence of six milestones rather than a set of independent tasks running in parallel.

Each milestone establishes a control required by the next stage. The first workload accounts are provisioned only after the organization, security administration, logging, identity, and address management are in place.

The six milestones

AWS says the sequence is enforced through infrastructure-as-code pipelines and automated checks.

For example, security configuration drift can be detected through AWS Config rules and Security Hub findings. AFT can also detect errors before an account reaches production.

The article describes this sequence as a critical path: workload provisioning depends on the controls established in the earlier milestones.

Four Technical Implementations Behind the Governance Model

AWS highlights four implementation components that demonstrate how the foundation applies security and governance controls before workloads arrive.

These include an organization-wide audit protection policy, centralized IP address allocation, stricter controls for experimental environments, and automated account provisioning.

1. Protecting the audit trail with a Service Control Policy

The team applied a Service Control Policy to prevent member-account administrators from stopping or modifying the organization CloudTrail trail.

The policy denies four actions against the organization trail:

{
  "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 policy does: It blocks the specified CloudTrail modification actions against the organization trail.

AWS says the team chose an unconditional deny rather than creating an exception for a break-glass role. This means trail changes must go through the governed infrastructure-as-code process.

The trade-off is operational flexibility. The team accepted that friction in exchange for a control that can be demonstrated during an audit.

2. Centralizing address space with an IPAM pool hierarchy

The team used VPC IPAM to create a central pool from which workload networks could receive non-overlapping address ranges.

The following Terraform excerpt illustrates the pool hierarchy described in the source:

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 that avoids legacy overlap
}

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
}

The workload pool is configured to allocate /20 network ranges.

The article does not disclose the actual CIDR values. The [IP_ADDRESS] placeholder is retained from the supplied source rather than replaced with an invented network range.

AWS says the team initially chose a single home-region pool and deferred a multi-region hierarchy until a workload required it.

3. Applying stricter controls to the Sandbox organizational unit

The Sandbox OU, which includes AI Center of Excellence accounts, received more restrictive controls than the rest of the organization.

The policy limits activity to approved AWS Regions, blocks specified public-networking actions, and prevents the deletion of selected security controls.

{
  "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": "*"
    }
  ]
}

The policy is scoped to the Sandbox OU rather than applied organization-wide.

AWS says the team accepted restrictions on independent internet-facing infrastructure in experimental accounts because of the risks associated with public network paths in a financial institution's sandbox.

The article does not present this policy as a universal template for every workload environment.

4. Provisioning accounts that inherit governance automatically

Account Factory for Terraform automates the creation of workload accounts through a Terraform-based account request.

The following example shows the structure of the account request described in the source:

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"
    SSOUserFirstName          = "Cloud"
    SSOUserLastName           = "Team"
    SSOUserEmail              = "cloud-team@example.com"
  }

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

  account_customizations_name = "workload-baseline"
}

The source describes account customizations that run after provisioning, including:

• Allocating a VPC from the shared IPAM pool.

• Enrolling the account in delegated security services.

• Applying baseline IAM roles and break-glass access.

The example is a template from the article, not a complete account deployment configuration.

AWS says the team chose to build the AFT pipeline before provisioning production accounts and rejected manual account creation as a shortcut.

At Day 134, the team provisioned six accounts in approximately 11 minutes, with governance controls inherited through the automated process.

Reported Results: Four Days to a Governed Organization

AWS provides a comparison between the engagement and what the authors describe as industry-typical outcomes for a conventional approach that extends an existing landing zone after legal close.

AWS says the industry-typical comparisons draw on the authors' experience across regulated-industry integrations and published benchmarks from Bain and BankDirector. The article does not provide the underlying benchmark calculations.

The company also clarifies two important points about the figures:

• The nine-service baseline is not fully hardened security. Enabling the baseline took under 10 minutes, while full security tuning and hardening took months.

• The approximately 178x spend figure reflects adoption. It compares monthly spend at month 13 with the first full month's spend and is attributed to organic workload adoption rather than a lift-and-shift migration.

These figures describe the reported engagement. They should not be interpreted as guaranteed outcomes for other mergers.

What the Approach Does Not Cover

AWS identifies several boundaries around the implementation.

It is not a data-migration playbook. The approach establishes the cloud foundation onto which workloads can move. The core-system conversion remains a separate activity.

It does not deliver fully hardened security in 10 minutes. The initial baseline is enabled quickly, but full threat detection, vulnerability scanning, and data-loss controls require further work.

It does not consolidate identity directories. Federation allows both workforces to authenticate through the combined environment, but directory rationalization remains a separate project.

It depends on pre-close planning. Organizations that begin design only after legal close should expect the timeline to shift by the duration of that planning phase.

These limitations are important when interpreting the four-day and 42-day milestones. The figures refer to establishing a governed cloud foundation and provisioning the first workload accounts, not completing the entire merger integration.

Why the Governance-First Approach Matters for Financial Services

The article highlights a broader challenge in regulated cloud integration: establishing security and audit controls while two organizations are becoming one.

A new cloud foundation can provide a consistent account structure, centralized logging, delegated security administration, and managed network addressing from the beginning.

For financial institutions, this could help make control ownership and audit evidence easier to demonstrate across the combined environment.

The implementation also illustrates how automation can make governance part of account provisioning rather than a separate manual process.

However, the reported timeline depends on the engagement's preparation, architecture, and implementation sequence. The source does not establish that every bank merger can achieve the same milestones.

Conclusion

AWS has described a post-merger cloud integration pattern in which a U.S. bank established a governed AWS organization four days after legal close and provisioned its first workload accounts after 42 days.

The approach combined pre-close design, a greenfield AWS organization, delegated security administration, centralized logging, identity federation, and IP address management.

Account Factory for Terraform then enabled workload accounts to inherit governance controls during provisioning.

AWS's central lesson is that cloud governance can begin before workloads arrive. The reported results also show the distinction between enabling a baseline quickly and completing the longer process of security hardening and workload migration.

For financial institutions planning a merger, the pattern offers a documented example of how pre-close preparation and a sequential governance model can shape the early stages of cloud integration.