Arif Rahman
← All projects
04 · 2026 · Personal project · fictional fintech briefDeployed

Starling Digital Cloud Migration

Engineered a highly available, secure, decoupled multi-tier AWS environment for a cloud migration, aligned with the AWS Well-Architected Framework.

Problem
A fintech brief: move to AWS in a way that is secure, highly available and ready for audit.
AWS services
VPCALBEC2 Auto ScalingRDSDynamoDBEFSS3Simple AD
Result
Multi-AZ design, a 2–4 instance auto-scaled API tier, central identity and four chained security groups.

Architecture

Starling Digital — multi-AZ AWS architectureA VPC (10.0.0.0/16) in us-east-1 spanning two availability zones. Public subnets hold a bastion host, a NAT gateway and an Application Load Balancer; private subnets hold an auto-scaled Node.js API tier and Multi-AZ RDS. EFS and Simple AD sit inside the VPC; DynamoDB and S3 are regional services. Step 1: Users reach the VPC through the internet gateway over HTTPS. Step 2: The Application Load Balancer in the public subnets takes the request. Step 3: It forwards to the Node.js API tier, auto-scaled 2–4 instances across both AZs. Step 4: The API reads and writes RDS; the DB security group only accepts the backend. Step 5: Market data is stored in DynamoDB. Step 6: User data mounts shared EFS storage when each instance boots. Step 7: Instances join the Starling.Digital domain in Simple AD through SSSD. Step 8: Admins SSH to the bastion host, then on to private instances. No direct SSH from the internet.AWS Region us-east-1VPC 10.0.0.0/16us-east-1aus-east-1bPublic subnetPublic subnetPrivate subnetsPrivate subnets:443123345:204967:2288AdminSSH via bastionUsersHTTPSInternet gatewayBastion hostBastion-SGLoad balancerALB-SG :80/:443NAT gatewayoutbound onlyNode.js APIASG 2–4 · AZ aEFSshared app dataNode.js APIASG 2–4 · AZ bRDS primaryDB-SGSimple ADStarling.DigitalRDS standbyMulti-AZDynamoDBmarket dataS3 × 2frontend + vault
Starling Digital — multi-AZ AWS architecture · scroll sideways to see it allOpen full-size SVG
  1. Step 1: Users reach the VPC through the internet gateway over HTTPS.
  2. Step 2: The Application Load Balancer in the public subnets takes the request.
  3. Step 3: It forwards to the Node.js API tier, auto-scaled 2–4 instances across both AZs.
  4. Step 4: The API reads and writes RDS; the DB security group only accepts the backend.
  5. Step 5: Market data is stored in DynamoDB.
  6. Step 6: User data mounts shared EFS storage when each instance boots.
  7. Step 7: Instances join the Starling.Digital domain in Simple AD through SSSD.
  8. Step 8: Admins SSH to the bastion host, then on to private instances. No direct SSH from the internet.
High availability
Multi-AZ
Compliance posture
Audit-ready
API tier
Auto-scaled

Why it matters

Moves a regulated digital-services team off manually managed single instances and onto a secure, scalable AWS operating model. Multi-AZ services and a 2–4 instance Auto Scaling range improve continuity, while central identity and reusable bootstrapping cut repeat configuration and access risk.

The problem in detail

I created the fictional Starling Digital brief to test how I would design a cloud migration that was secure, highly available, audit-ready and decoupled.

What I built

  1. 01

    Built a Multi-AZ VPC with public/private subnet segregation and stateful security groups enforcing least privilege.

  2. 02

    Integrated AWS Simple AD for centralised directory services, automated Linux RBAC and SSSD domain joining.

  3. 03

    Deployed an Auto Scaling Node.js API tier behind an ALB, bootstrapped via User Data scripts handling DNS, EFS mounting and security config.

  4. 04

    Provisioned Multi-AZ RDS subnets, DynamoDB for market data, shared EFS storage and versioned S3 buckets for compliance.

Evidence

01 / 18
Stage 01 — VPC build-out: subnets, internet gateway, NAT gateway, route tables and associations all provisioned successfully.

Stage 01 — VPC build-out: subnets, internet gateway, NAT gateway, route tables and associations all provisioned successfully.