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 / Data & AI (NDA)
- Duration
- Ongoing (6+ months)
- Team
- 2 senior architects (me + 1) mentoring 8 junior engineers
Why they called
Fourteen VPCs had been built by hand across the accounts, with overlapping subnets, inconsistent CIDR ranges and no tagging. Every project carried its own security posture, a new environment took two to three weeks, drift was causing about a dozen incidents a month, and the quarterly security audit was returning 47 findings.
Tech stack
- AWS
- VPC
- RDS
- Terraform
- CloudFormation
- MySQL
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.
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
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.
Trade-offs accepted on purpose.
Production risks and how they were controlled.
Small steps, visible changes, fewer surprises.
- 01
Audited existing AWS accounts and found 14 manually provisioned VPCs with inconsistent CIDR ranges, overlapping subnets, and no tagging standards.
- 02
Designed a reference architecture with secure VPC templates: public/private/isolated subnets, NAT gateways, flow logs, and consistent CIDR allocation.
- 03
Built Terraform modules for VPC, RDS, ECS, and IAM with opinionated defaults. SOC2-compliant out of the box with override escape hatches.
- 04
Created AWS Service Catalog products using CloudFormation for teams that needed self-service provisioning without Terraform knowledge.
- 05
Led weekly architecture review workshops with junior engineers, reviewing pull requests, explaining trade-offs, and building internal cloud competency.
Before and after.
What the team runs now.
The point of the work is what the client's own engineers can change and operate without me.
- The Terraform modules for VPC, RDS, ECS and IAM, with SOC2 defaults and documented override escape hatches.
- Self-service provisioning through AWS Service Catalog for the teams that do not write Terraform.
- Tagging enforcement through AWS Config rules, and the per-team, per-service cost dashboards that depend on it.
- The architecture decisions themselves. Three of the junior engineers from the weekly review workshops now design compliant environments on their own.
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
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.
Request the reliability audit