AWS architecture of the TF-Agentic-Engine
Technical Analysis of the TF-Agentic-Engine
The TF-Agentic-Engine converts an existing AWS environment into Terraform code. Its main purpose is to support two tasks: bringing existing AWS resources under Terraform management and creating a reusable copy of an existing environment.
In Import Mode, the system creates Terraform resource blocks and import definitions using the real IDs collected from AWS. It should only generate resources that were found during the scan.
Import Mode output with fixed AWS resource values from the scanned environment.
In Clone Mode, the system converts the same infrastructure into reusable Terraform by replacing account-specific values, names, CIDR ranges and other fixed settings with variables. This allows the environment to be recreated in another AWS account, region or project.
Clone Mode output using Terraform variables to create a reusable infrastructure configuration.
Resource Discovery
The process starts in main.py, which controls the full execution. It starts the AWS scan, creates the initial system state and runs the LangGraph workflow.
The AWS discovery logic is mainly located in src/aws_client.py. It uses boto3 to collect details about resources such as:
- VPCs and subnets
- Route tables and gateways
- EC2 instances
- Security groups
- RDS databases and DB subnet groups
- S3 buckets and DynamoDB tables
For local testing, the same discovery layer can use moto instead of connecting to a real AWS account. This makes it possible to test the pipeline without creating real cloud resources.
AWS API responses contain many values that are not required in Terraform. The system removes runtime details and keeps configuration values that are needed to describe the infrastructure.
Infrastructure Graph
After discovery, the system converts the resource data into a graph.
Each AWS resource is stored as a node. The connection between two resources is stored as an edge. For example, an edge can show that a subnet belongs to a VPC, an EC2 instance uses a subnet or an RDS database uses a DB subnet group.
The compile_infrastructure_graph() function creates this graph from the scanned AWS data. This is important because the resource relationships come from AWS IDs rather than being guessed by the language model.
The graph also helps with incomplete AWS data. For example, when an RDS instance exists but its subnet-group information is missing, the system can create a DB subnet-group entry and connect it to the discovered private subnets.
Generated architecture diagram showing the discovered AWS resources and their dependency relationships.
LangGraph Workflow
The Terraform generation process is controlled by src/agent.py.
LangGraph runs the system in a fixed order:
- Network generation
- Security generation
- Compute generation
- Data generation
- Terraform validation
Each stage is implemented inside src/nodes.py.
The Network Node creates Terraform for VPCs, subnets, gateways and route tables.
The Security Node creates security groups, rules, IAM roles and policies.
The Compute Node creates EC2 and related compute resources.
The Data Node creates RDS, S3 and DynamoDB resources.
Separating the resources this way keeps each generation request smaller and reduces the chance of networking, security and database code being mixed together. The output is normally separated into files such as network.tf, security.tf, compute.tf and data.tf.
GraphState
The nodes share information through a structure called GraphState, defined in src/state.py.
GraphState stores the selected mode, scanned AWS data, infrastructure graph, generated Terraform sections, current phase, validation errors, retry count and final validation result.
This allows every node to work with the latest version of the infrastructure and generated code. It also allows the validation stage to send errors back into the generation process.
Terraform Validation and Repair
After all Terraform files are generated, the Validation Node runs the real Terraform CLI.
It checks the files for invalid syntax, unsupported provider arguments, missing references and incorrect resource structures. A temporary provider file can be added so that the Terraform configuration can be checked locally without using real AWS credentials.
When validation fails, the error is saved in GraphState and the generation workflow runs again. The retry count prevents the system from entering an endless loop.
Execution log showing a failed Terraform validation, automatic retry, and successful validation on the second run (As an example).
The project also includes fixed Python-based corrections for common language-model errors.
The S3 correction logic removes arguments that are no longer valid inside the main S3 bucket resource.
The RDS correction logic removes incorrectly placed subnet IDs, creates a proper DB subnet group and links it to the database.
The security-group correction logic fixes invalid ingress and egress block formats.
The template-protection logic escapes braces found in Terraform and JSON error messages so that LangChain does not treat them as prompt variables.
These corrections are handled by normal code because common Terraform mistakes are easier and safer to fix with fixed rules than by repeatedly asking the model to rewrite everything.
Final Outputs
When Terraform validation succeeds, the system produces the final Terraform files and architecture documents.
The same infrastructure graph is used to generate a PNG image and an editable Draw.io file. This keeps the Terraform output and architecture diagram based on the same resource relationships.
The final output includes:
- Terraform files
- Infrastructure graph data
- Validation results
- PNG architecture image
- Editable Draw.io file
AWS Infrastructure Used by the System
In the AWS architecture, a Discovery Lambda can start an on-demand scan. AWS Config and EventBridge can also detect infrastructure changes and start the process automatically.
Amazon S3 stores the scanned graph, generated Terraform files, diagrams and logs.
Amazon Neptune Serverless is used temporarily to store and query the infrastructure graph. It can check multi-level relationships, such as the connection from an EC2 instance to its subnet, VPC and security group. Neptune does not create the relationships; the Python graph compiler creates them first.
Amazon Bedrock provides the language model used for Terraform generation and repair in the AWS version of the system. LangGraph still controls the order of the generation and validation steps.
After validation finishes and the outputs are stored, the temporary Neptune environment is removed. This prevents the graph database from remaining active when the system is not running.
The system therefore separates the work clearly: Python reads and organizes the AWS environment, LangGraph controls the stages, the language model writes Terraform, and Terraform checks whether the generated code is valid.
(The testing was done in an HPC in the university with the local LLM models gemma3:27b and llama3:70b instead of testing using AWS Bedrock for cost efficiency).
Top comments (0)