Series · Securing Nigerian banks on AWS · Part 2 of 3 ← Part 1: The threat picture (DSI ↗) · The architecture · Part 3: The operational implementation →
The architectural problem, stated honestly
A Tier 1 Nigerian bank in 2026 is running three things at once. A core ledger that cannot move. A mobile banking surface that is taking over 70% of customer traffic. And a regulator — the CBN, after the March 2026 CSAT directive — that wants demonstrable controls in the next examination cycle. Most banks try to solve all three on the same infrastructure that ran the bank in 2015.
That doesn't work. The core ledger has to stay where the regulator and operational risk model want it. The mobile surface needs the elasticity that on-prem cannot provide at credible cost. The audit evidence needs to live in a system that 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 its on-prem footprint. 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.
This is Part 2 of the series. Part 1 covered why this matters — the threat patterns hitting the sector and why individual-bank defence keeps failing. Part 3 covers how to actually run it: Terraform, IAM, runbooks, CSAT evidence queries.
The shape of the system
The bank's data centre stays in Lagos. The systems that have to stay there for residency or operational-risk reasons stay there: the core banking platform (Temenos, Flexcube, Finacle), the NIBSS gateway and ATM switch, the internal directory, the privileged-access stack. None of this moves.
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 — initially in a single region (Frankfurt is our default), with a hot DR replica in Cape Town for the resilience scenarios discussed later.
The two sides are connected 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. Dual carriers so a single cable cut does not take the connection down.
The topology matters more than any single component. The path from a Lagos branch to an AWS managed service goes through exactly two organisations the bank trusts — its colocation partner and AWS — and never traverses the public internet. The path is auditable end to end. Each VLAN carries the traffic of one workload, isolated at layer 2. If a single workload is compromised, the blast radius does not extend to the rest of the connection.
Transit Gateway: the routing fabric
The DX Gateway in the diagram terminates a transit VIF — a virtual interface that carries traffic into an AWS Transit Gateway, which then routes onward to the per-workload VPCs. This is the routing fabric of the architecture, and it does more than make the network function. It enforces another layer of segmentation before VPC Lattice gets involved.
Each workload account from the landing zone — core banking, payments, analytics, the compliance vault — attaches its VPC to the same Transit Gateway. From there, the routing is governed by 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 ledger has nowhere to go at layer 3 — the routing decision returns no path before the packet ever reaches a security group.
This matters because identity-layer controls fail open under certain conditions (misconfigured IAM policy, stale role tags, a service that does not enforce SigV4). Network-layer routing does not fail open. The path either exists or it does not. Combining TGW route-table segmentation with VPC Lattice service policies gives you defence in depth at two different layers — L3 and L7 — for the same architectural property: analytics cannot reach the ledger.
The Transit Gateway also makes the multi-region failover from earlier 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 is 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 of this series, which shows the Terraform that provisions it.
What "managed" actually buys you in this architecture
There is a tendency in vendor presentations to treat "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.
What managed services do buy you, concretely:
- 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 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 what the examiner asks for first.
- 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 that 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. This sounds obvious. Most banks do not have it.
- Identity that federates. IAM Identity Center connects to the bank's AD 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.
The configurations that make all of this work are the subject of Part 3. For now, the architectural point is that these capabilities exist as services the bank consumes, not platforms the bank operates.
Threat patterns and the controls that address them
The threat patterns hitting the sector in 2026 are not theoretical. They are the patterns 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 that AWS managed services provide.
The honest version is that no single control closes any of these threats in isolation. 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 the bot-driven attempts so that 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 above 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 needs to meet. The detail of how each one is configured is Part 3 of this series.
What survives the cable cut
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.
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 on it. Direct Connect partially addresses this — the bank's private circuit to AWS is on different infrastructure to the public internet — but a single carrier is not enough. The architecture has to assume both that one cable cuts and that one region goes dark.
The pattern that holds up:
- Two AWS regions, 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."
- 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 does not exist.
- Two Direct Connect circuits terminate at the bank — one via MainOne to Frankfurt, one via Liquid to Cape Town. BGP handles the 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 an operator-driven failover — readiness checks tell the operator the DR region is healthy, then the operator flips the routing controls. This is deliberate. Automatic failover of a regulated banking workload during an active incident is how you turn a regional outage into 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 (time to first successful write in the DR region). Most banks tell us those numbers are stricter than what their on-prem disaster recovery plan currently achieves.
Zero-trust segmentation: where lateral movement stops
The threat picture in Part 1 makes one pattern clear: the breach almost never starts in core banking. It starts 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 this is necessary but no longer sufficient. The 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.
Identity-based segmentation closes that gap.
The pattern we deploy:
- One AWS account per service domain. Core banking has its own account. Payments has its own account. Analytics and AI have their own account. The compliance archive has its own account. Each account is its own administrative boundary — no shared roles, no static keys, no trust paths that survive a compromise.
- VPC Lattice as the service mesh. Service-to-service traffic goes through VPC Lattice, which enforces IAM authentication (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.
- 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 deny 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 just cannot reach the ledger, because the ledger does not accept calls from their role.
This is the single 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
Every bank we work with asks the same question at some point in the engagement: what data is actually leaving Nigeria?
The honest answer in this architecture 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 is, in descending order of sensitivity:
- Aurora analytics replicas — 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 — metadata about every AWS API call in the bank's accounts. Does not contain customer data. Required for examiner queries.
- S3 compliance archive — encrypted point-in-time backups, immutable, time-locked for the retention period (seven years is our default).
- GuardDuty findings and Security Hub state — security telemetry. No customer PII.
What does not leave Nigeria:
- The ledger of record.
- The privileged credentials.
- The encryption keys that protect customer data at rest in the core (those keys live in the bank's HSM, even when copies of the encrypted data live in AWS).
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 part of the engagement deliverable.
Cost shape, real numbers
The CFO 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 (dual carrier). Two 1 Gbps ports at AWS: ~$0.30/hour each, ~$440/month combined. Cross-connect fees at the colocation: ~$600–$1,500/month per carrier, depending on the facility. Total network spend: $1,500–$2,500/month. The egress savings via Direct Connect ($0.02/GB versus $0.085/GB over public internet) pay for the ports above approximately 2.5 TB/month of egress, which any bank exceeds in the first week of operation.
- AWS managed services tier. GuardDuty, Security Hub, CloudTrail Lake, Macie, IAM Identity Center together: $8,000–$25,000/month depending on data volumes and account count.
- Data and compute. Aurora Global Database (writer + reader, multi-AZ, encrypted, point-in-time recovery): $4,000–$12,000/month. S3 compliance archive with Object Lock: $400–$1,500/month for typical retention volumes. SageMaker fraud inference: $2,000–$8,000/month for a real-time endpoint serving a mid-tier bank's transaction rate.
- Total run rate. $20,000–$60,000/month for a mid-tier Nigerian bank running the architecture in production. The implementation phase is separate and one-off — sixty days of work, costed at the engagement level. Tier 1 banks land at the upper end of this range; regional banks at the lower end.
At today's exchange rate this is in the order of ₦30M–₦90M per 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 the storage and compute footprint, the audit overhead — and 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 worth flagging at the CFO stage: the Direct Connect circuit itself has a lead time of four to twelve weeks depending on partner availability, port speed, and which DX Location you land at. AWS publishes a step-by-step procurement walkthrough at AWS Direct Connect: Getting Started ↗ covering location selection, partner engagement, LOA-CFA issuance, and the BGP session 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.
What's next
The architecture above is the spine. It is what we draw on the whiteboard when a CTO calls us to ask whether AWS is a credible foundation for a Nigerian bank in 2026. The answer is yes — and the answer comes with this specific shape, these specific services, these specific tiers of failover.
What it does not yet have is the implementation detail: the Terraform modules that provision it, the IAM identity boundaries that enforce the segmentation, the GuardDuty rules and runbook for the Friday-evening incident replay, the CloudTrail Lake queries that satisfy the CBN examiner. That is Part 3.
If you are the CISO reading this and you want to know the threat picture we built this architecture to defend against — start with Part 1.
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