1. Infrastructure Design in the LLM Era

 

Large language models have changed how quickly we can create infrastructure designs.

Today, we can describe an application in natural language and ask an LLM to propose an AWS architecture, generate Terraform code, create IAM policies, or suggest monitoring and deployment configurations.

For example, a simple request such as: “Design an AWS architecture for a web application with a backend API, database, and file storage.”

can produce a reasonable-looking architecture within seconds.

The same is true for Infrastructure as Code. An LLM can quickly generate Terraform resources for VPCs, ECS, RDS, S3, IAM, CloudWatch, and many other AWS services.

This is extremely useful, especially during the early stages of architecture design.

However, there is an important difference between:

an architecture that works and: an architecture that is ready for production

A generated architecture may technically deploy and run while still having problems such as overly broad IAM permissions, insufficient monitoring, weak backup strategies, unnecessary infrastructure costs, or a lack of recovery planning.

The LLM also does not automatically know important business requirements.

For example, it may not know the expected availability level, recovery requirements, traffic patterns, security policies, operating budget, or how much operational complexity the team can realistically manage.

This means that LLM-generated infrastructure still needs a clear set of architectural criteria.

Instead of simply asking: “Is this architecture good?”

we need a more structured way to review the design.

This is where the AWS Well-Architected Framework becomes useful.

 

---

2. Using AWS Well-Architected as a Guardrail

The AWS Well-Architected Framework provides a consistent way to evaluate cloud architectures against AWS architectural best practices. AWS organizes the framework around six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability.

In simple terms:

• Operational Excellence — Can we deploy, monitor, operate, and improve the system effectively?
• Security — Are data, identities, systems, and infrastructure appropriately protected?
• Reliability — Can the system continue operating or recover when failures occur?
• Performance Efficiency — Are computing resources being used efficiently for the workload?
• Cost Optimization — Are we getting the required business value without unnecessary cost?
• Sustainability — Are we reducing unnecessary resource consumption and improving efficiency over time?

https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html

The important point is that the framework is not simply a checklist for choosing AWS services.

It provides a review perspective.

AWS itself describes the framework as a consistent approach for evaluating architectures and identifying areas for improvement. It also emphasizes that trade-offs between pillars depend on business requirements. For example, a development environment may prioritize cost over reliability, while a mission-critical workload may justify higher cost for greater resilience.

This makes the framework especially useful when working with LLMs.

Rather than allowing the LLM to freely generate an architecture and assuming the result is appropriate, we can use the six pillars as guardrails for its reasoning.

For example, instead of asking only: “Design an AWS architecture for this application.”

we can ask the LLM to generate the architecture and then review it from the perspectives of security, reliability, operations, performance, cost, and sustainability.

The goal is not to make the LLM the final architect.

The goal is to give the LLM a structured set of questions so that important architectural concerns are less likely to be overlooked.

In the next section, I will look at how to write prompts for infrastructure design using the AWS Well-Architected Framework, including what information the LLM should be asked to clarify instead of simply assuming.

3. What to Watch Out for When Prompting an LLM

When asking an LLM to design infrastructure, one of the biggest risks is allowing it to fill in missing requirements by itself.

For example, if we simply say:

“Design a production AWS architecture for this application.”

the LLM may assume that Multi-AZ, Auto Scaling, a load balancer, centralized logging, or other components are required.

Those choices may be reasonable, but they are still assumptions.

A better approach is to explicitly ask the LLM to separate what is known from what is unknown.

For example:

Review this architecture using the AWS Well-Architected Framework with these aspects, 

• Assumptions
• Risks
• Trade-offs
• Unknown or missing requirements

and do not introduce additional infrastructure unless it is justified by the requirements.

This changes the role of the LLM.

Instead of immediately producing a “best architecture,” it first explains the reasoning behind the design.

This is especially important because infrastructure decisions usually involve trade-offs.

For example:

• Multi-AZ improves reliability, but increases cost.
• Auto Scaling can improve availability and performance, but also adds operational complexity.
• Private networking can improve security, but may require additional NAT or connectivity costs.
• Detailed monitoring improves observability, but also increases log storage and operational cost.

There is rarely a single architecture that is best in every dimension.

Another important point is to avoid blindly asking for “AWS best practices.”

Best practices are useful, but they should still be evaluated against the actual workload.

A small internal application and a mission-critical customer-facing system should not necessarily have the same architecture.

The LLM should therefore be asked not only: “What is the best practice?”

but also: “Is this practice justified for this workload?”

The AWS Well-Architected Framework works well here because it gives the LLM a structured way to think about those trade-offs.

---

4. A Practical Terraform Template

The same idea can also be applied when using an LLM to review or generate Terraform.

From the professional experiences working across different infrastructure projects,

A simplified Terraform project might look like this:

development/
  backend.tf
  budget.tf
  ecs.tf
  iam_role.tf
  parameter_store.tf

modules/
  batch/
  cloudwatch_log_subscription_filter/
  scheduled_batch/

staging/
production/

This type of structure already tells us several things about the infrastructure.

For example:

• development, staging, and production indicate environment separation.

• iam_role.tf suggests that access control is managed explicitly.

• parameter_store.tf indicates that configuration or secrets may be managed outside the application.
• cloudwatch_log_subscription_filter.tf suggests centralized log processing or monitoring.
• budget.tf shows that cost management is also part of the infrastructure design.

Instead of asking an LLM: “Is this Terraform good?”

we can ask more specific questions.

For example:

Review this Terraform project using the AWS Well-Architected Framework.

Focus on:
- IAM permissions and least privilege
- secret and parameter management
- logging and monitoring
- Terraform state management
- environment separation
- backup and recovery
- cost controls

For each issue, explain:
1. the risk,
2. the trade-off,
3. whether more information is required before changing the architecture.

This kind of prompt is much more useful because it does not assume that every recommendation should automatically be implemented.

For example, the LLM may suggest stronger redundancy or additional monitoring.

The engineer can then decide whether those changes are actually necessary for the workload.

The same applies when generating Terraform.

A useful workflow is:

Requirements
    ↓
Architecture Proposal
    ↓
Well-Architected Review
    ↓
Terraform Generation
    ↓
terraform fmt / validate / plan
    ↓
Human Review
    ↓
Deployment

The LLM can accelerate many steps in this process, but the final architectural decision should still be based on the actual system requirements.

---

5. Conclusion

LLMs can significantly speed up infrastructure design.

They can generate architecture proposals, Terraform code, IAM policies, monitoring configurations, and many other building blocks in a very short time.

However, speed does not automatically mean quality.

A generated architecture may work technically while still being too expensive, too complex, insufficiently secure, or difficult to operate.

This is why a framework such as AWS Well-Architected is useful.

It provides a consistent set of perspectives for reviewing the design and helps us ask better questions.

The relationship can be summarized simply:

LLM
→ Generates ideas and implementation options

AWS Well-Architected
→ Provides evaluation criteria

Engineer
→ Makes the final decision

The goal is not to replace infrastructure engineers with LLMs.

The goal is to use LLMs to accelerate design and implementation while keeping architectural decisions grounded in clear requirements, trade-offs, and engineering judgment.