Multi-cloud for Banks: Separating the Core, Data, and the Audit Trail

Introduction

The query "multi-cloud for banks" is not asking for a product list. It is asking for a layout where the core does not talk to the experiment account, data stays in the region agreed with the regulator, and the audit trail survives someone who holds the administrator key.

I saw the same shape at data-center scale: core, satellite, and agent. The core decides. The satellite runs close to the workload. The agent only returns status. In a bank, the cloud repeats the mistake of one shared account: production, staging, and the data lab under the same IAM role.

This article is the minimum split I use when the environment is regulated. It is not a write-up of a specific bank. It is the boundary that keeps the account from becoming a shared drive.

The cost of that split comes later, in the multi-cloud FinOps article. Here the subject is the fence.

Three planes, three accounts

Core. The ledger, authentication, and the payment queue live here. A data-science notebook and a proof of concept do not.

Data. The analytics replica and the lake in the approved region live here. A "quick" copy in another region, opened to try a dashboard, does not.

Audit. CloudTrail, access logs, and change evidence live here. The same account that creates and deletes resources does not.

The audit account does not build anything. It only receives logs. Whoever operates the core has no s3:DeleteObject on that bucket. Whoever runs the proof of concept has no route to the core.

If the core is still UNIX, it stays where it is. HP-UX, Solaris, and AIX do not "move to multi-cloud" because the board asked for three logos. What moves is what has an owner, a region, and a tested restore. The rest is in the UNIX administration article.

Lock the region at the organization root

The control that stops an analyst from creating a bucket in another region is an SCP, not a team agreement. The example below denies everything outside sa-east-1, except global services. Without NotAction, the policy also locks IAM and the whole organization.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegion",
      "Effect": "Deny",
      "NotAction": [
        "iam:",
        "organizations:",
        "route53:",
        "cloudfront:",
        "support:",
        "sts:"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["sa-east-1"]
        }
      }
    }
  ]
}

aws organizations create-policy \ --name DenyOutsideSaEast1 \ --type SERVICE_CONTROL_POLICY \ --content file://deny-region.json

aws organizations attach-policy \ --policy-id p-abc123 \ --target-id ou-bank-workloads

ou-bank-workloads is the OU of the application accounts, not the management account. The management account stays off this SCP. Otherwise you lock yourself out.

On Azure the equivalent is an allowedLocations policy on the management group, not a naming convention on the resource group.

The trail the administrator cannot delete

A log in the same account that produces the log is not an audit. The bucket is born with Object Lock, and the trail writes from another account.

aws s3api create-bucket \ --bucket bank-audit-logs \ --region sa-east-1 \ --create-bucket-configuration LocationConstraint=sa-east-1 \ --object-lock-enabled-for-bucket aws s3api put-object-lock-configuration \ --bucket bank-audit-logs \ --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 365 } } }' aws cloudtrail create-trail \ --name bank-audit \ --s3-bucket-name bank-audit-logs \ --is-multi-region-trail

aws cloudtrail start-logging --name bank-audit

COMPLIANCE stops even root from deleting the object before the retention ends. That is the difference between a trail and a shared folder. Day-to-day change evidence, in the shape an ISO audit asks for, is in the governance article.

Network: the core does not see the lab

Peering the production VPC to the experiment VPC is the shortcut that undoes the split above. The path I accept is different:

The core publishes only what the data plane needs, through a private endpoint, not a public IP.
The lab account has no route to the core subnet.
Administration jumps through a bastion in the audit account, with the session recorded.

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values="$VPC_CORE" \
  --query "RouteTables[].Routes[?DestinationCidrBlock=='10.80.0.0/16']"

If that command returns a route to the lab range, the split exists only on the org chart. Remove the route before discussing a FinOps tool.

What stays out on purpose

Multi-cloud for a bank does not start with Kubernetes on three providers. It starts with region, account, and an immutable log. Three federated clusters, without those three, multiply the places data leaks and the bill grows with no owner.

Once the fence exists, then it is worth optimizing what is left: orphaned IPs, hot storage, and a Savings Plan. That is already written, with commands, in the FinOps article.