Skip to content
Back to case studies
NDA-safeCloud Architecture2025

Enterprise Cloud Arch

Manual VPC sprawl + quarterly audit pain → standardized IaC, 70% faster setup, findings down 47 → 3.

Role
Senior AWS Solution Architect
Context
Enterprise / Standards
Duration
Ongoing (6+ months)
Team
2 senior architects (me + 1) mentoring 8 junior engineers

Tech stack

  • AWS
  • VPC
  • RDS
  • Terraform
  • CloudFormation
  • MySQL
Executive summary

Business problem and production context.

Business problem

Enterprise teams were manually provisioning AWS resources with no standardization. Each project had different VPC configurations, security postures, and deployment patterns, creating drift, compliance gaps, and slow onboarding.

Architecture decision

Designed standardized cloud architectures with secure VPC configurations, compute provisioning, and database services. Built reusable IaC templates with Terraform and CloudFormation. Led technical workshops mentoring junior architects on cloud-native patterns.

awsAWS Organization / ASTMRequestResponseACCOUNT INGRESSWORKLOAD ACCOUNTSSHARED SERVICES12345678AWS SSOfederated identityControl Toweraccount vendingTransit GatewayVPC peeringDev Acctisolated VPCStaging Acctprod-shapedProd Acctguarded changesAudit AcctCloudTrail + ConfigShared S3log archiveSecrets Mgrcentral rotationCROSS-CUTTING: SCPs at OU level · Terraform modules · Backup vault per acct · Config rules baseline
What Rahul owned

The useful proof is the decision surface, not only the result number.

These are the parts of the work that show production judgment: ownership, constraints, rollback, cost, and observability.

Owned scope

  • Standardized cloud architecture templates with secure network, compute, and database patterns
  • Reusable IaC patterns and workshops so junior engineers understood why decisions were made
  • Enterprise guardrails around accounts, security, and repeatable provisioning

Evidence artifacts

Terraform and CloudFormation templatesJunior architect mentoringManual setup reductionEnterprise cloud standards
Constraints

What would fail first?

Every project has constraints. The useful work is naming them early enough that rollback, cost, and ownership are designed before an incident.

Enterprise compliance

Architecture needed to support secure defaults, repeatability, and audit-friendly implementation.

Team scaling

Junior engineers needed reusable patterns and decision context, not only templates.

Manual setup

Manual provisioning had to shrink so environments were consistent and easier to review.

Decision table

Trade-offs accepted on purpose.

Option
Decision
Reason
Terraform vs CloudFormation
Used both
Terraform vs CloudFormation: Used both. Terraform for multi-account orchestration, CloudFormation for AWS-native Service Catalog integration.
RDS vs Aurora
RDS chosen for predictable workloads where Aurora's auto-scaling would add cost without benefit
RDS vs Aurora: RDS chosen for predictable workloads where Aurora's auto-scaling would add cost without benefit.
Custom modules vs AWS Landing Zone
Custom modules for flexibility while maintaining compliance guardrails
Custom modules vs AWS Landing Zone: Custom modules for flexibility while maintaining compliance guardrails.
Risk table

Production risks and how they were controlled.

Risk
Mitigation
Owner
Templates copied without judgment
Paired IaC modules with workshops explaining constraints, trade-offs, and owner responsibilities.
Architecture lead
Security drift after provisioning
Built secure defaults and reviewable IaC contracts instead of one-off console changes.
Cloud platform team
Manual setup blocked delivery
Standardized repeatable patterns for common compute, network, and database paths.
Platform + app teams
Implementation approach

Small steps, visible changes, fewer surprises.

  1. 01

    Audited existing AWS accounts and found 14 manually provisioned VPCs with inconsistent CIDR ranges, overlapping subnets, and no tagging standards.

  2. 02

    Designed a reference architecture with secure VPC templates: public/private/isolated subnets, NAT gateways, flow logs, and consistent CIDR allocation.

  3. 03

    Built Terraform modules for VPC, RDS, ECS, and IAM with opinionated defaults. SOC2-compliant out of the box with override escape hatches.

  4. 04

    Created AWS Service Catalog products using CloudFormation for teams that needed self-service provisioning without Terraform knowledge.

  5. 05

    Led weekly architecture review workshops with junior engineers, reviewing pull requests, explaining trade-offs, and building internal cloud competency.

Result

Before and after.

New Environment Setup
2-3 weeks (manual)
45 minutes (IaC)
Security Audit Findings
47 per quarter
3 per quarter
Infra Drift Incidents
12/month
0 (Terraform state lock)
Cloud Spend Visibility
None
Per-team, per-service dashboards

Rollback path

Infrastructure templates needed versioned changes so teams could identify and revert risky updates.

Cost considerations

Cost control came from standard defaults, reviewable environment shape, and reducing accidental overbuild.

Observability notes

The baseline included account/environment visibility, template usage, security posture, and provisioning success.

Related services

Forward Deployed AI EngineeringAWS Production Architecture ReviewGenAI / RAG Production Readiness

Have a similar production problem?

Send the current architecture, bill concern, deployment pain, or GenAI reliability issue. I will help you find the first real bottleneck.

Rahul LadumorRequest the reliability auditContact form