Book a call

EngineeringSoftware built to last

Custom software →Web applications →Mobile apps →SaaS product engineering → Cloud applications →AWS development →DevOps & CI/CD →Cloud migration →

IntelligenceAI in production, not slideware

AI & machine learning →Generative AI applications →AI automation & integrations →Data engineering & analytics →

Experience & GrowthDesign and growth, one roof

UX/UI design →Brand identity →Marketing websites →Digital marketing & growth →Creative & campaign design →
We ship our own productsSeven of them, from GST books to gaming venues, built and run by this team. All 17 services Ways to partner with us Insights
Solution blueprint 02 · Cloud engineering

Ready for the auditor, and for the worst day.

A fast-growing lending app has outgrown the way it started: one AWS account, shared admin keys, logs nobody can vouch for, and no plan if a region goes down. This is how we would bring it to an audit-ready setup, keep borrower data in India and make recovery a drill, not a hope.

A blueprint, not a client story: a problem we see often in lending, and how we would solve it.

Talk about your version All blueprints
The situation · what hurts

Where itbreaks today

The symptoms that bring a team to us, in their own words.

  • Shared admin keysEngineers deploy with one long-lived key that never expires.
  • Everything in one accountTest and production side by side, one mistake apart.
  • Logs nobody can trustWho changed what, and when, cannot be proven.
  • No plan BIf the region has a bad day, so does every borrower.
The solution · 10 parts, 8 flows

The blueprint,drawn

How the pieces fit together. Follow the numbers.

BorrowersMobile and webCFCloudFront + WAFTLS, rate limitsECSLending servicesPrivate subnets, FargatePGAurora PostgreSQLEncrypted with your keysEngineersLaptops, CIIDIAM Identity CenterMFA, no standing keysORGSeparate accountsProd, staging, logs, auditDRHyderabad standbyAurora Global DatabaseGDGuardDutyThreats, every accountLOGLog archiveCloudTrail, locked12345678
  1. 1Borrowers → CloudFront + WAFBorrowers, over TLS
  2. 2CloudFront + WAF → Lending servicesFiltered and rate limited
  3. 3Lending services → Aurora PostgreSQLEvery field encrypted at rest
  4. 4Aurora PostgreSQL → Hyderabad standbyReplicated to a second region
  5. 5Engineers → IAM Identity CenterShort-lived access with MFA
  6. 6IAM Identity Center → Separate accountsLeast privilege, per account
  7. 7Separate accounts → Log archiveEvery action recorded
  8. 8GuardDuty → Log archiveFindings kept with the trail
Blueprint 02 · Lending
The decisions · 4 that matter

What we woulddecide, and why

Reliable, scalable, secure and sensible on cost: the choices that get there, with the settings beside them.

01Data

Keys you control, data that stays in India.

An organisation policy allows only the Mumbai and Hyderabad regions, so nothing can be created elsewhere by accident. Databases and storage are encrypted with customer-managed keys per class of data, and the most sensitive fields, like PAN and bank accounts, are encrypted again in the application.

The settings · dataspec
Regions
ap-south-1 and ap-south-2, enforced by SCP
At rest
KMS customer-managed keys, rotated yearly
Fields
PAN and bank details encrypted in the app
Storage
S3 Block Public Access, organisation-wide
In transit
TLS everywhere, old ciphers off
02Access

Nobody holds a permanent key.

People sign in through one identity provider with MFA and get access that expires within hours. The deployment pipeline assumes a role through OIDC instead of storing keys, production is reached only through that pipeline, and a sealed break-glass account raises an alarm the moment it is used.

The settings · accessspec
People
IAM Identity Center with MFA
Sessions
Short-lived, a few hours at most
CI/CD
GitHub OIDC roles, no stored keys
Production
Changed only by the pipeline
Break glass
Sealed account, alarmed on use
03Audit

Every change, provable.

Every account sends its trail to a separate log archive that even administrators cannot edit or delete. Config rules and Security Hub check the setup against recognised benchmarks continuously, and threat findings from every account land in one place with an owner.

The settings · auditspec
Trail
Organisation CloudTrail to a log account
Tamper-proof
S3 Object Lock in compliance mode
Posture
Security Hub: CIS and AWS best practice
Drift
AWS Config rules on every account
Threats
GuardDuty, triaged weekly
04Recovery

A region can fail; the business does not.

The database replicates continuously to Hyderabad, and the whole environment is code, so it can be rebuilt there rather than remembered. A written runbook says who does what, and a recovery drill every quarter proves it still works.

The settings · recoveryspec
Database
Aurora Global Database to Hyderabad
Infrastructure
Terraform for every account
Backups
AWS Backup, copied across regions
Runbook
Owners, steps and decision points
Proof
A recovery drill every quarter
Design targets · agreed up front

What goodlooks like

Targets we would set together before the first line of work, and measure against after.

< 1 mindata loss if a region fails (RPO target)
< 1 hback in service (RTO target)
0long-lived access keys
100%of actions in a trail no one can edit

The plan

  1. 01Assessment against the audit checklist1 wk
  2. 02Landing zone and separate accounts2 wks
  3. 03Identity, MFA and keyless pipelines1 wk
  4. 04Encryption and data residency2 wks
  5. 05Logging, detection and posture2 wks
  6. 06Recovery region and the first drill2 wks
  7. 07The evidence pack for the auditor1 wk
Next · blueprint 03 · Mobile appsLogisticsProof of delivery that works in a basement.

Sound likeyour problem?

Tell us what is breaking. We reply within a working day with how we would approach your version of it.

Start a project All blueprints