The shared responsibility gap
AWS secures the infrastructure underneath your workloads — physical data centres, hypervisors, and managed service internals. Everything above that — IAM policies, network configuration, encryption settings, application code — is your responsibility. In our architecture reviews, the most common finding is not a single catastrophic misconfiguration but a pattern of small permissive defaults that compound into a serious exposure.
The Nigerian fintech context adds urgency. CBN regulations and the NDPA/NDPR framework require demonstrable controls over customer data. "It is on AWS" is not a compliance answer. You need to prove that your AWS configuration enforces the controls regulators expect.
IAM: least privilege is survival
IAM misconfigurations are the number one entry point in cloud breaches. The pattern we see repeatedly: a single IAM user with AdministratorAccess whose access keys are shared across three developers and embedded in a CI pipeline. If any of those keys leak — via a Git commit, a Slack message, or a compromised laptop — the attacker owns your entire AWS account.
IAM hardening essentials
- Use IAM roles, not long-lived access keys. EC2 instances, Lambda functions, and ECS tasks should assume roles. Delete every access key that does not absolutely need to exist.
- Scope policies to specific resources. Replace
"Resource": "*"with ARNs. An S3 policy should reference exact bucket names, not every bucket in the account. - Enforce MFA on the root account and all human users. Use hardware TOTP keys for the root account.
- Use AWS Organizations with SCPs to create guardrails that even account administrators cannot override — like preventing the disabling of CloudTrail.
- Review IAM Access Analyzer findings weekly. It flags resources shared outside your account and unused permissions you can trim.
VPC design: segment or suffer
A flat VPC where every service can talk to every other service is an attacker's dream. Once they compromise one instance, lateral movement is trivial. Proper segmentation limits blast radius.
Network architecture pattern
Use a multi-tier VPC with public subnets (load balancers only), private subnets (application servers), and isolated subnets (databases, sensitive workloads). Place NAT gateways in public subnets to give private instances outbound internet access without inbound exposure.
They are not interchangeable
Security Groups are stateful and attached to ENIs — they remember return traffic. NACLs are stateless and operate at the subnet level — you must explicitly allow both inbound and outbound traffic. Use Security Groups as your primary control (least privilege per service) and NACLs as a coarse subnet-level backstop. We commonly find fintechs using only Security Groups with 0.0.0.0/0 ingress on port 22, exposing SSH to the entire internet.
S3: the KYC document landmine
If your fintech stores KYC documents, BVN verification responses, or transaction receipts in S3, a single misconfigured bucket policy can expose all of it. The defaults have improved — S3 now blocks public access by default — but legacy buckets and hastily created ones still slip through.
- Enable S3 Block Public Access at the account level, not just per bucket.
- Encrypt at rest with KMS (SSE-KMS), not the default SSE-S3. KMS gives you key rotation, access logging, and the ability to revoke access by disabling the key.
- Enable S3 access logging to a separate bucket for forensic trails.
- Use VPC endpoints for S3 so traffic between your application and S3 never traverses the public internet.
Encryption with KMS
KMS customer-managed keys (CMKs) give you control over encryption across RDS, S3, EBS, and SQS. The key policy defines who can use the key, and CloudTrail logs every key usage event. This is critical for CBN compliance — you can prove that specific data was encrypted and that only authorised services accessed the decryption key.
Enable automatic key rotation (annually) and use separate keys for separate data classifications. Your KYC documents should not share an encryption key with your application logs.
Detection: CloudTrail, GuardDuty, and WAF
Prevention without detection is flying blind. Three AWS services form the minimum detection stack for any fintech.
CloudTrail
Logs every API call across your account. Enable it in all regions (attackers target regions you are not watching), send logs to a dedicated S3 bucket with object lock, and set up CloudWatch alarms for high-risk events like IAM policy changes or console logins from new IP addresses.
GuardDuty
Machine-learning threat detection that analyses CloudTrail, VPC Flow Logs, and DNS logs. It flags cryptocurrency mining on your instances, credential exfiltration attempts, and communication with known command-and-control servers. Enable it — it is a single click and costs pennies per million events.
WAF for APIs
Deploy AWS WAF in front of your API Gateway or ALB. Create rules for rate limiting, SQL injection blocking, and geo-restriction if your API only serves Nigerian users. Use managed rule groups (AWS, F5, Fortinet) as a baseline and add custom rules based on your pentest findings.
Secrets management
Database passwords, API keys, and payment gateway secrets must never live in environment variables baked into container images or EC2 user data scripts. Use AWS Secrets Manager for secrets that need automatic rotation (database credentials) and Systems Manager Parameter Store (SecureString) for configuration values that change less frequently.
Both services integrate natively with IAM — you control exactly which roles can read which secrets. For CI/CD pipelines, inject secrets at deploy time via the pipeline's secrets integration rather than storing them in build artifacts.
Need a security review of your AWS fintech infrastructure?
Request a Cloud Security AssessmentQuick hardening checklist
- Eliminate long-lived IAM access keys. Use roles everywhere.
- Enforce MFA on root and all human IAM users.
- Segment your VPC into public, private, and isolated subnets.
- Block public S3 access at the account level.
- Encrypt everything at rest with KMS CMKs and enable key rotation.
- Enable CloudTrail in all regions with immutable log storage.
- Turn on GuardDuty — it takes sixty seconds.
- Deploy WAF in front of every public-facing API.
- Move all secrets to Secrets Manager or Parameter Store.
Related reading
Blog: Cloud security checklist for fintech · Zero trust for fintech startups · Securing Kubernetes for financial services
Guides: CBN compliance security · NDPR/NDPA compliance · Fintech security checklist
Services: Secure architecture review · Penetration testing · Vulnerability assessment