Series · Securing Nigerian banks on AWS · Part 2 of 3 ← Part 1: The threat picture (DSI ↗) · The architecture · Part 3: The operational implementation →
A CTO at a whiteboard, three constraints, one Tuesday
Picture a CTO in Lagos. He has a whiteboard in his office and three things on it. A core ledger that cannot move — Temenos or Flexcube, depending on the bank, sitting in a data centre he can drive to. A mobile banking surface taking over seventy percent of customer traffic and growing every quarter. And a regulator — the CBN, after the March 2026 CSAT directive — sending letters that ask for demonstrable controls before the next examination cycle. He has been trying to solve all three on the infrastructure that ran the bank in 2015. It worked for the bank in 2015. It is failing for the bank in 2026.
Asking 2015 infrastructure to run a 2026 mobile bank is like asking a town's water mains to handle a city's traffic. The pipes were never sized for the load, the pressure points are all wrong, and every time someone asks for more, something else breaks. The core ledger has to stay where the regulator and the operational risk model want it. The mobile surface needs elasticity that on-prem cannot deliver at credible cost. The audit evidence needs to live somewhere an examiner can query in seconds, not a tape archive that takes two weeks to restore.
The architecture below is the shape we recommend when a bank decides to take AWS managed services seriously without abandoning the on-prem footprint that the regulator and the risk register require. It is hybrid by design. The core stays in Lagos. AWS becomes the elastic surface, the security telemetry plane, and the audit-evidence vault — connected by a private fibre that bypasses the public internet entirely.
Part 1 of this series covered why this matters: the threat patterns hitting the sector and why individual-bank defence keeps failing. Part 3 covers how to run it — the Terraform, the IAM, the runbooks, the CSAT evidence queries. This piece is the architecture itself.
Key takeaways
- The architecture is hybrid by design — the core ledger, NIBSS gateway, and privileged-access stack stay in Lagos; analytics replicas, fraud inference, compliance archive, and security telemetry move to AWS in eu-central-1 with a hot DR replica in af-south-1.
- Direct Connect over MACsec-encrypted dual carriers (MainOne to Frankfurt, Liquid to Cape Town) bypasses the public internet entirely. Transit Gateway with per-workload route tables enforces L3 segmentation that complements the L7 VPC Lattice policies.
- Zero-trust segmentation closes the lateral-movement gap: one AWS account per service domain, SigV4 on every service-to-service call, per-service IAM roles with eight-hour STS sessions, and GuardDuty Runtime Monitoring on every container and EC2 host.
- Multi-region resilience commits to RPO under 5 seconds and RTO under 60 seconds — stricter than the on-prem DR most banks currently achieve. Failover is operator-driven via Route 53 ARC, deliberately not automatic.
- Run-rate cost for a mid-tier Nigerian bank lands at $20,000-$60,000/month (₦30M-₦90M). The Direct Connect ports pay for themselves above ~2.5 TB/month of egress, which every bank exceeds in the first week.
What stays, what moves, what bridges them
The bank's data centre stays in Lagos. The systems anchored there by residency or operational risk stay there: the core banking platform — Temenos, Flexcube, Finacle, depending on the bank — the NIBSS gateway and ATM switch, the internal directory, the privileged-access stack. None of these move. They are the load-bearing walls of the institution.
What moves is everything that benefits from elasticity, managed detection, and a regulator-grade audit trail: the analytics replicas, the fraud-inference workloads, the compliance archive, the security telemetry plane. These run in AWS — first in a single region, Frankfurt by default, then with a hot DR replica in Cape Town for the resilience scenarios this piece discusses later.
The two sides are joined by AWS Direct Connect — a private fibre circuit terminated in a Lagos colocation facility (Rack Centre or MainOne are the usual choices), cross-connected to MainOne's subsea fibre, landing in AWS at Equinix FR5 in Frankfurt. No public internet between the bank and the cloud. MACsec encryption on the wire. Two carriers, so a single cable cut does not take the connection down. Think of it less as a network connection and more as a private corridor with locked doors at both ends and two staircases out.
The topology matters more than any single component. The path from a Lagos branch to an AWS managed service passes through exactly two organisations the bank trusts — its colocation partner and AWS — and never touches the public internet. The route is auditable end to end. Each VLAN carries the traffic of one workload, isolated at layer 2. Compromise a single workload and the blast radius stops at the VLAN boundary, not at the building's edge.
The Transit Gateway as routing fabric
The DX Gateway in the diagram terminates a transit VIF — a virtual interface that hands traffic to an AWS Transit Gateway, which then routes onward to the per-workload VPCs. This is the routing fabric of the architecture, doing more than just making the network function. It enforces a layer of segmentation before VPC Lattice gets a vote.
Each workload account from the landing zone — core banking, payments, analytics, the compliance vault — attaches its VPC to the same Transit Gateway. The routing then runs through separate TGW route tables, one per workload group. The route table associated with the analytics attachment has no route to the ledger VPC. Not denied by firewall. Not present at all. A packet from analytics destined for the ledger has nowhere to go at layer 3 — the routing decision returns no path before the packet ever reaches a security group. Like calling a country code that does not exist; the call never finishes dialling.
This matters because identity-layer controls fail open under certain conditions. A misconfigured IAM policy, a stale role tag, a service that does not enforce SigV4. Network-layer routing does not fail open. The path is either there or it is not. Combine TGW route-table segmentation with VPC Lattice service policies and you have defence in depth at two different layers — L3 and L7 — defending the same architectural property: analytics cannot reach the ledger.
The Transit Gateway also makes the multi-region failover clean. The same TGW (or a peered pair, one per region) carries DX traffic to either eu-central-1 or af-south-1 depending on which DX circuit is active. The workload VPCs attach to whichever region's TGW is local. From the bank's edge router, the routing decision between Frankfurt and Cape Town becomes BGP — and BGP is the protocol that has been failing over circuit by circuit for thirty years.
The canonical AWS reference for this pattern is the Direct Connect + Transit Gateway whitepaper ↗. Worth reading alongside Part 3, which shows the Terraform that provisions it.
What "managed" really buys you
There is a habit in vendor presentations of treating managed as a synonym for secure. It is not. Managed means AWS runs the patching, the scaling, and in the security services the detection logic — on your behalf. Whether the result is secure still depends on how you configure the perimeter around it. Owning a high-end security system does not lock your front door.
What managed services do buy you, concretely, comes in five forms.
Detection telemetry you did not have to build. GuardDuty inspects VPC flow logs, DNS logs, CloudTrail, EKS audit logs, and runtime container syscalls, and produces findings against a threat model AWS maintains. The findings are useful. The infrastructure to produce them in-house would have taken eighteen months and a security data engineer your bank cannot hire.
Compliance posture you can measure. Security Hub maps findings against the NIST CSF, PCI DSS, AWS Foundational Best Practices, and — via custom standards — the CBN CSAT control set. The score is not the same as compliance, but it is the first thing the examiner asks for.
Audit evidence in a queryable form. CloudTrail Lake stores every API call in a SQL-queryable table. When the regulator asks who provisioned the IAM role the attacker used, the answer is a query, not a forensics engagement.
Backup that survives ransomware. S3 Object Lock plus Vault Lock plus a separate KMS key plus a separate account is the configuration that actually survives an attacker who got domain admin. The backups exist and the attacker cannot delete them. Obvious in principle. Almost no bank we audit has it in practice.
Identity that federates. IAM Identity Center connects to the bank's Active Directory and issues per-role permission sets per AWS account. No one logs into the AWS console with a username and password. Every action is attributable to a specific human via SAML — a name on every cheque.
The configurations that make all of this work are Part 3's territory. For now, the architectural point is that these capabilities exist as services the bank consumes, not platforms the bank operates.
Six threats, six controls
The threat patterns hitting the sector in 2026 are not theoretical. They are documented in the public sector reporting — the breach disclosures, the NDIC supervisory communications, the DSI banking threat picture.
The shape is consistent: BEC and insider credential theft, mobile banking account takeover, lateral movement after initial entry, ransomware on payment systems, regional outage exploits, and the regulatory exfiltration claims that follow any visible breach. Each one maps to a control AWS managed services provide.
The honest version is that no single control closes any of these threats by itself. GuardDuty does not stop BEC. It surfaces the credential anomaly that indicates BEC happened. WAF does not stop a sophisticated mobile attack. It raises the cost of bot-driven attempts so the genuine attempts surface above the noise. CloudTrail Lake does not satisfy the CBN's evidence requirements automatically. It makes the queries that satisfy them cheap to run.
What the mapping gives you is a defensible architecture story for the next CSAT examination cycle. For each control area the regulator cares about, there is a managed service with explicit configuration, explicit telemetry, and explicit attestation in Security Hub. That is the standard the architecture has to meet. The detail of how each one gets configured is Part 3.
The week the cables went dark
In early 2024, a series of subsea cable cuts off the West African coast degraded internet access across multiple countries for the better part of a week. The breach data from that period — the parts of it that have surfaced — shows the predictable pattern. Attackers used the chaos windows to compromise institutions whose monitoring stack lived in the cloud on the same public internet that had just gone dark. The defenders' periscope was attached to the same submarine.
A bank that has built its security posture around a single public-internet hop to a single cloud region has built a single point of failure with an attacker's name written on it. Direct Connect addresses part of this — the bank's private circuit runs on different infrastructure to the public internet — but a single carrier is not enough. The architecture must assume both that one cable cuts and that one region goes dark, sometimes in the same week.
The pattern that holds up runs across five components.
Two AWS regions with asymmetric responsibilities. eu-central-1 Frankfurt carries the writes. af-south-1 Cape Town carries the reads and stands ready to take over writes if the primary becomes unreachable. Both regions are always running. Neither is cold. The understudy has been rehearsing every day for years.
Aurora Global Database replicates the relational layer with typical lag under one second. On failover, the secondary cluster is promoted to writer in under sixty seconds. The bank's analytics workloads keep running against the reader.
S3 Cross-Region Replication copies the compliance archive to af-south-1 with an independent KMS key owned by a separate AWS account. An attacker who compromises the primary cannot reach the DR copy, because the IAM trust path between them does not exist. Two safes, two keys, two buildings.
Two Direct Connect circuits terminate at the bank — one via MainOne to Frankfurt, one via Liquid to Cape Town. BGP handles failover at the network layer. The bank's edge routers detect the carrier loss and re-route in seconds.
Route 53 Application Recovery Controller sits above everything. It is operator-driven failover. Readiness checks tell the operator the DR region is healthy, then the operator flips the routing controls. The choice to keep the human in the loop is deliberate. Automatic failover of a regulated banking workload during an active incident is how a regional outage becomes a regional disaster.
The SLOs we commit to in this configuration are RPO under five seconds — data loss bounded by the cross-region replication lag — and RTO under sixty seconds for the first successful write in the DR region. Most banks tell us those numbers are stricter than their current on-prem disaster recovery plan achieves.
Where lateral movement runs out of road
The threat picture in Part 1 makes one pattern clear. The breach almost never begins in core banking. It begins somewhere else — a phished workstation, a compromised contractor account, a forgotten S3 bucket — and pivots laterally until it reaches the systems that actually move money.
The conventional defence against this is network segmentation: VLANs, firewalls, DMZs, layered subnets. In a modern AWS architecture, that is necessary but no longer sufficient. An attacker who reaches the right IAM credential does not need a network path — they have an AWS API call that is allowed to do the thing. A locksmith with the master key does not need to climb the fence.
Identity-based segmentation closes that gap.
The pattern we deploy has four pillars.
One AWS account per service domain. Core banking has its own. Payments has its own. Analytics and AI live in their own. The compliance archive has its own. Each account is its own administrative boundary — no shared roles, no static keys, no trust paths that survive a compromise. Different houses, different deeds.
VPC Lattice as the service mesh. Service-to-service traffic goes through VPC Lattice, which enforces IAM authentication via SigV4 on every call. The service policy for the ledger explicitly lists which other services can call it. Anything else is denied at the service layer, regardless of network reachability. The maître d' has a list, and your name is on it or it is not.
Per-service IAM roles, STS-issued credentials, eight-hour session boundary. No service runs with static keys. Every call carries a credential traceable to a specific role in a specific account.
GuardDuty Runtime Monitoring on every container and EC2 host. When something compromised tries to call something it should not call — the SigV4 signature succeeds, the service policy denies — the denial is logged. When something compromised tries to escalate locally, the syscall pattern surfaces in GuardDuty.
The architectural property we are after is the one in the footer of the diagram: if one role is compromised, the blast radius stops at its service network policy. The compromise still happens. The attacker still gets in. They cannot reach the ledger, because the ledger does not accept calls from their role.
That is the most important shift between a 2018 cloud architecture and a 2026 one. The perimeter is no longer a network boundary. The perimeter is an identity boundary, enforced on every call.
The residency conversation, finally honest
Every bank we work with asks the same question at some point: what data is actually leaving Nigeria?
The honest answer is less than the bank assumes, and more than the regulator assumes. The systems of record — the core ledger, the NIBSS gateway, the privileged-access stack — stay in Lagos. The data that lives in AWS, in descending order of sensitivity, comes in four categories.
Aurora analytics replicas hold read-only copies of customer transaction data, used for fraud inference and reporting. Encrypted with a customer-managed KMS key. Network-isolated to a VPC the bank controls. Accessible only via Direct Connect.
CloudTrail Lake audit data carries metadata about every AWS API call in the bank's accounts. It does not contain customer data. It is what the examiner needs in order to ask questions.
The S3 compliance archive holds encrypted point-in-time backups, immutable, time-locked for the retention period — seven years by default.
GuardDuty findings and Security Hub state are security telemetry. No customer PII.
What does not leave Nigeria is also worth naming directly. The ledger of record stays. The privileged credentials stay. The encryption keys protecting customer data at rest in the core stay in the bank's HSM, even when copies of the encrypted data live in AWS — the keys never travel with the lock.
The NDPA permits this configuration. The CBN's data-residency expectations permit this configuration. The conversation with the data protection officer takes about an hour the first time and is documented as an engagement deliverable.
The number on the CFO's screen
The question that follows every architecture review is the same: what does this cost in naira?
The honest answer depends on the bank's existing infrastructure, transaction volumes, and the specific workloads being moved. The ranges below are the ones we see in actual engagements for a mid-tier Nigerian bank, not theoretical estimates from the AWS calculator.
Direct Connect at dual-carrier scale runs roughly $1,500 to $2,500 a month. Two 1 Gbps ports at AWS sit at about $0.30 an hour each, or $440 a month combined; cross-connect fees at the colocation add $600 to $1,500 a month per carrier depending on the facility. The egress savings via Direct Connect — $0.02 per GB versus $0.085 per GB over public internet — pay for the ports above roughly 2.5 TB of egress per month, which any bank exceeds in the first week.
The AWS managed services tier — GuardDuty, Security Hub, CloudTrail Lake, Macie, IAM Identity Center together — runs $8,000 to $25,000 a month depending on data volumes and account count.
Data and compute is where the bill grows. Aurora Global Database (writer plus reader, multi-AZ, encrypted, point-in-time recovery) lands at $4,000 to $12,000 a month. The S3 compliance archive with Object Lock runs $400 to $1,500 a month at typical retention volumes. SageMaker fraud inference for a real-time endpoint serving a mid-tier bank's transaction rate lands at $2,000 to $8,000 a month.
Total run rate for a mid-tier Nigerian bank running the architecture in production lands at $20,000 to $60,000 a month. The implementation phase is separate and one-off — sixty days of work, costed at the engagement level. Tier 1 banks reach the upper end of the range, regional banks the lower.
At today's exchange rate that is roughly ₦30M to ₦90M a month. The number is significant. It is also significantly lower than the cost of building equivalent capability in-house — the licensing of equivalent on-prem security tools, the staffing of a 24/7 SOC, the procurement and maintenance of storage and compute, the audit overhead. The comparison favours the cloud architecture by a wide enough margin that the conversation with the CFO is about how to phase the deployment, not whether to do it.
One operational note for the CFO stage: the Direct Connect circuit has a lead time of four to twelve weeks depending on partner availability, port speed, and DX Location. AWS publishes a step-by-step procurement walkthrough at AWS Direct Connect: Getting Started ↗, covering location selection, partner engagement, LOA-CFA issuance, and BGP bring-up. Worth initiating in parallel with the contracting work — by the time the platform Terraform is ready to apply, the circuit should already be cabled and tested.
Where this leaves you
The architecture above is the spine. It is what we draw on the whiteboard when a CTO calls to ask whether AWS is a credible foundation for a Nigerian bank in 2026. The answer is yes, and it comes with this specific shape, these specific services, these specific tiers of failover.
What this piece does not have yet is the implementation detail — the Terraform modules that provision it, the IAM identity boundaries that enforce the segmentation, the GuardDuty rules and the runbook for the Friday-evening incident, the CloudTrail Lake queries that satisfy the examiner. That is Part 3.
If you are the CISO reading this and you want to know the threat picture this architecture was built to defend against, Part 1 is where to begin.
FAQs
Why does the core ledger stay in Lagos instead of moving to AWS?
Two reasons: regulatory residency expectations and operational-risk posture. The CBN, NDIC, and the bank's internal risk model want the system of record physically located where the regulator can reach it. Moving the ledger to a foreign region creates a residency conversation that nobody wants to have and an outage scenario nobody can defend. The architecture works because elasticity, detection, and audit-evidence move; the ledger does not.
What does Transit Gateway add that VPC Lattice doesn't already cover?
L3 segmentation as a second layer of defence. VPC Lattice enforces identity-based service policies at L7 — SigV4 on every call. TGW route tables enforce network-layer routing — the path either exists or it does not. If a VPC Lattice policy is misconfigured, TGW routing still blocks the cross-workload path. Two layers, two failure modes, both have to fail for the architecture to fail open.
Why is failover operator-driven rather than automatic?
Because automatic failover of a regulated banking workload during an active incident is how you turn a regional outage into a regional disaster. Route 53 ARC's readiness checks tell the operator the DR region is healthy; the operator then flips the routing controls. The architecture commits to RTO under 60 seconds — the operator decision is part of that budget, deliberately.
What data actually leaves Nigeria in this architecture?
Read-only analytics replicas of customer transaction data (CMK-encrypted), CloudTrail Lake metadata (no customer PII), S3 compliance archive (encrypted, immutable, seven-year time-lock), and GuardDuty findings (no customer PII). What does not leave: the ledger of record, the privileged credentials, and the encryption keys protecting customer data at rest in the core. The NDPA and CBN residency expectations permit this configuration; the DPO conversation takes about an hour the first time.
How does this architecture survive a subsea cable cut?
Two AWS regions running active-active, two Direct Connect carriers landing in different regions, Aurora Global Database replicating sub-second across regions with an independent KMS key in each, and S3 Cross-Region Replication to an account the primary cannot reach. When MainOne's cable cuts, Liquid carries the traffic to Cape Town. When eu-central-1 has a regional event, af-south-1 picks up writes within 60 seconds.
References
The canonical AWS documents this architecture builds on, useful as deeper reading alongside the series:
- AWS Direct Connect + Transit Gateway ↗ — the whitepaper that documents the hub-and-spoke routing pattern between DX and multiple VPCs at scale. The pattern this architecture uses.
- Building Scalable and Secure Multi-VPC AWS Network Infrastructure ↗ — the broader reference on multi-VPC network design, with the Direct Connect chapter covering the connectivity patterns for organisations running many accounts behind a single private link.
- AWS Direct Connect: Getting Started ↗ — the procurement walkthrough: location selection, partner engagement, LOA-CFA, BGP bring-up. Initiate alongside contracting work.
Series · Securing Nigerian banks on AWS ← Part 1: The threat picture (DSI ↗) · Part 2: The architecture · Part 3: The operational implementation →
This is the architecture we design for Nigerian and other African banks. The same patterns are in production for our clients in Europe. Engagement enquiries: [email protected] · Cloud security services