LLM Infrastructure Training
Valid syntax, dangerous IaC → RLHF + curated patterns; quality 42% → 89%, security violations <5% of gens.
- Role
- LLM Infrastructure Trainer
- Context
- AI / Enterprise
- Duration
- 8 months
- Team
- Specialized trainer (me) + Amazon AI team
Tech stack
- AWS CDK
- CloudFormation
- TypeScript
- Python
- AWS Bedrock
- Lambda
- VPC
- IAM
- Terraform
- RLHF
Business problem and production context.
Business problem
Amazon needed LLMs that could generate production-quality AWS CDK and CloudFormation code. Existing models produced syntactically correct but architecturally flawed infrastructure code, missing security best practices, cost optimization patterns, and Well-Architected Framework alignment.
Architecture decision
Created high-quality training datasets of AWS infrastructure patterns covering VPC design, IAM policies, Lambda configurations, and multi-account setups. Designed reusable TypeScript CDK constructs as reference implementations. Validated AI-generated infrastructure code against security, cost efficiency, and Well-Architected principles through systematic RLHF feedback loops.
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
- Infrastructure review and training feedback for LLM-related IaC patterns
- AWS infrastructure judgment applied to model-training and evaluation workflows
- Quality feedback on infrastructure tasks where correctness, security, and maintainability mattered
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.
Internal proof
Details are intentionally limited because the work is internal/NDA-sensitive.
IaC correctness
Training tasks needed secure and maintainable infrastructure patterns, not only syntactically valid snippets.
Evaluation quality
Feedback had to distinguish acceptable cloud patterns from risky production shortcuts.
Trade-offs accepted on purpose.
Production risks and how they were controlled.
Small steps, visible changes, fewer surprises.
- 01
Audited 500+ existing CDK/CloudFormation templates to identify common anti-patterns in AI-generated infrastructure code: security gaps, missing encryption, overly permissive IAM roles.
- 02
Created structured training datasets: correct CDK constructs paired with explanations of why each design decision was made (security, cost, reliability rationale).
- 03
Designed reusable TypeScript CDK constructs following AWS Well-Architected Framework. These became reference implementations for model training.
- 04
Built RLHF feedback pipeline: reviewed model outputs, ranked by infrastructure quality, flagged security violations, and provided corrective signals.
- 05
Validated trained model outputs against production deployment scenarios, measuring IAM policy correctness, resource tagging compliance, and cost estimation accuracy.
Before and after.
Rollback path
Public details are constrained; the transferable lesson is to treat generated IaC as production-risky until reviewed.
Cost considerations
The public value is expertise signal rather than client savings disclosure.
Observability notes
The work reinforces why AI-generated infrastructure must be evaluated against operations, security, and maintenance.
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