Transcript
I'm very excited to have you all join us for a day of learning and sharing. A few years back, I deployed infrastructure on a Friday afternoon after reviewing Terraform plans showing 40 resource changes. Monday morning, our security team flagged that I had accidentally misconfigured a security group. It was right there in the Terraform plan. I just didn't catch it. If it could happen with me, it could happen with anyone, right? And that's when I realized we needed something better. Manual analysis of complex JSON requiring deep infrastructure knowledge just doesn't scale. That's where our solution, which is Terraform Plan Analyzer, with the power of Amazon Bedrock, could help us shift left security as well as provide you with insightful analysis of your Terraform plans. Today, I won't be doing this presentation alone. My smart and talented colleague, Dr. Rahul Gaikwad, will join me in the second half of the presentation. Before we start, let me quickly introduce myself. I'm Praneet Rajay, working as a solutions architecture specialist at HashiCorp, an IBM company. I'm based out of Mumbai. I have a total of seven plus years of experience in IT industry, specifically in cloud, DevOps, et cetera. Here's what we will cover today. We'll start with some of the common challenges customers face in understanding Terraform plans outputs. Then I will introduce you to Terraform Plan Analyzer, a custom solution that brings the power of AI into your infrastructure workloads. Next, we will look at its architecture and how it actually solves those challenges. Then Rahul will walk through some of the best practices for the solution deployment. And then jump into a live demo to see it in action. Finally, we'll wrap up with a few key takeaways and lessons learned. Let's cover why understanding Terraform plans at scale has become one of the biggest bottlenecks in modern infrastructure workloads. First, the output itself. Terraform plans are incredibly detailed, but they're often long text of JSON files that sometimes become very difficult to parse quickly. You're scrolling through 500 plus lines trying to find whether that one database setting actually changed or not. Second, security blind spots. It's easy to miss that one security group rule, opening port 22 to the internet or an IAM policy with wildcard permissions or it could be accidentally exposed credentials. By the time you catch it, it's already there in the production. Third, time consumption. For complex infrastructure changes, think of like 50 plus resources across networking, compute and databases. Teams spend hours manually reviewing those plans. Fourth, understanding cascading effects. When you modify a subnet's route table, what else breaks? Which Lambda functions are affected? You didn't see that coming, but it was important to understand that ripple effect across 50 or 100 other resources. Fifth, the knowledge gap. What does changing this security group actually mean for our application? That expertise gap slows everything down. And finally, compliance risk. You deploy infrastructure, everything works great, but then two weeks later, the security team flags that you are storing unencrypted PII data in violation of GDPR. It was in the plan, but you just didn't catch it, right? So six challenges all with real consequences. This is the reality most infrastructure teams face today. So we have seen the challenges, but modern problems require modern solution, right? And here's the good news. Generating AI to the rescue. Gen AI has already been one of the hottest topics everywhere, from writing code to analyzing data. So why can't it understand Terraform plans? Let me give you a spoiler, it can. Let's see how. What makes Gen AI uniquely suited for our infrastructure analysis? Unlike traditional automation, modern large language models like Cloud Sonnet don't just parse JSON. They understand relationships, context, and implications. They can explain why a change matters, predict downstream impacts, and even call external APIs to gather additional intelligence. Let's break down the key capabilities that makes this possible. First, natural language understanding. For example, instead of ingress rule quad zero, that is 0.0.0.0, open for port 22, it says this opens SSH access to the entire internet, which is a critical security risk, right? Second is the context-aware analysis. It can identify cascading effects. For example, changing this subnets route table will affect three Lambda functions, two RDS instances, and your NAT gateway configurations. Third is the function calling capabilities. For example, in our solution, when it detects an AMI change, it automatically calls the GitHub API for comparison between old and new AMIs. Then responsible AI with guardrails. Amazon Bedrock guardrails solve this by inspecting both inputs and outputs before they go to or come from the AI model. And these policies are completely customizable, which gives you the confidence to use this in production. And last but not the least, instant insights. Because it uses models like Cloud SONNET 4 with cross-region inference, you get consistent and fast responses regardless of where you're deploying the solution. All right, so we have talked about the problems and the AI capabilities that can solve them. Now let me introduce you to the Terraform Plan Analyzer, which is an AI-powered run task that plugs directly into your existing SAP Terraform workflows. So no workflow changes, no new tools to learn. It just works. Here is what it does. It provides three layers of analysis. First, a plain English plan summary. That explains what's actually changing. Second, a detailed impact analysis covering security concerns, then configuration issues, operational impact, and prioritized recommendations. And third, extended analysis through function calling. Things like your AMI version comparisons or vulnerability checks that pull data from external APIs. Architecture-wise, it's built entirely on AWS Serverless Platform, which includes your Lambda functions, step functions, event bridge, cloud front. So it's a low-cost, scales automatically, and obviously zero servers to manage. And finally, it's also production-ready, out of the box. You get WAF protection, KMS encryption, CloudWatch monitoring, and bedrock guardrails for responsible AI. So you can see this is not just a proof-of-concept. It's an enterprise-grade from day one. Okay, so that's the Terraform Analyzer solution on a high level. Let's dive a little deeper into its features. First up, AI-powered summaries. Basically, it takes that wall of JSON text and translates it into something like a human can actually understand quickly. So something like, for example, you're adding these resources, changing these settings. Here's the security impact. Here's what could go wrong. You get the gist right. Plain English, no technical jargon. Now, here's where it gets really cool. Function calling. Think of this as giving the AI a toolkit. When it sees an AMI change, it doesn't just say AMI has been changed. It loads and fetches the release notes, compares versions, checks for security patches, and you can also hook this up to any API you want. For example, cost calculators, CVE databases, or it could be your own internal compliance systems. The AI figures out what to check and when to check. You just get the insights. Next up, responsible AI. We know you can't just throw production infrastructure data at an AI without safeguards. So we have built in Amazon Bedrock guardrails that automatically catch and block sensitive stuff. So things like AWS access keys, passwords, PII data, before it ever reaches the model. Plus, you can also customize these policies to fit into your organization-specific policies. So security and compliance are not optional. They're baked in from day one. Let me quickly cover the last three features. Secure architecture. This is designed to run in its own dedicated AWS account with optional WAF protection for DDoS and rate limiting. So everything follows AWS security best practices, starting from encrypted secrets, KMS keys, least privileged IAM roles, so that it's production ready from the start. Fifth, seamless integration. It works as a native run task in HCP Terraform, which means zero changes to your existing workflow. Your teams keep doing exactly what they were doing, that is running Terraform plans and applies. They just get the AI insights automatically injected right into the UI. And finally, it's flexible and customizable. You can adapt it to fit your organization-specific needs. So you can customize the guardrails, extend the analysis with your own API integrations, adjust what gets analyzed and when. So you can see this is a framework and not a black box, so you're in control. So that's the feature set. Now let's look under the hood and see how all of this actually works from an architecture perspective. Let me quickly walk you through the architecture. This is a serverless event-driven pipeline from left to right. Starting on the left, when you run Terraform plan in your HCP Terraform account, it sends a webhook to our CloudFront endpoint, or it could also send it directly to Lambda function if you skip the WAF. Then CloudFront provides DDoS protection and the rate limiting. Then there are some Lambda H functions, which validates the HMAC signatures from HCP Terraform using a secret stored in secrets manager. Invalid signatures gets rejected immediately, preventing any unauthorized access. Valid requests flow to EventBridge, which routes event to our step functions state machine based on the run stage, that is pre-plan, post-plan, or pre-apply. Then there is step functions, which orchestrates three Lambda functions in sequence. First is the request handler, which validates the payload and extracts the plan JSON URL. Next is the fulfillment handler, which is the core logic, and it downloads the plan, then invokes the Bedrock CloudSonic with structured prompts, handles the function calls like AMI version lookups, and runs everything through Bedrock cardinals. Then third, which is a callback handler, which sends the formatted results back to HCP Terraform. So step functions gives you the automatic retries as well as error handling. On the right-hand side, Bedrock does the AI inference using CloudSonic 4 with cross-region inference for high availability. Guardrails scan both inputs and outputs, blocking any sensitive information like AWS keys, passwords, PII, and any harmful content. Also, from an observability perspective, everything gets locked to CloudWatch with dedicated lock streams per run ID. Secrets are also encrypted with KMS keys. Lambda has reserved concurrency of 10, also adjustable based on your needs. And this entire workflow completes in 15 to 30 seconds. That's the architecture on a high level, fully serverless, scalable, and production ready. Now let me hand this over to my friend Rahul to show you how this works end-to-end and with a live demo. Thanks again for joining us at HashiTalks 2026. Wishing you all happy terraforming with JNN. Hello, everyone. Welcome to HashiTalks 2026. Thanks, Pranit. That was a great start. Let me expand on it. Before we start, let me quickly introduce myself. I am Dr. Rahul Gaikwad, working as a staff resident solutions architect here at HashiCorp, an IBM company. I am based in Pune, focusing on infrastructure, security, cloud, and generative AI. So Pranit has already covered the basics of terraform run tasks. Let's quickly look at what they actually enable in SAP Terraform. Run task allows Terraform to connect with external systems during a run. This can happen before or after plan and apply steps. Terraform can send data out for checks, validation, or automation. For example, teams can validate configurations before applying changes. This helps catch errors or policy issues early. You can also analyze the Terraform plan to avoid unexpected changes. Security scanning is another common use case, but it does not stop there. Run tasks can trigger notifications, logging, or other automation workflows. They basically bring governance directly into your Terraform pipelines. And one powerful capability, you can add a custom step between plan and apply. That means approvals, testing, or extra checks before changes collide. This makes infrastructure automations safer, smarter, and more controlled. Okay, now let's see how run task actually works behind the scenes. When Terraform reaches a step with a run task, SAP Terraform sends a run data to an external service. This could be a security tool, compliance checker, or even a custom internal service. The system receives the data, usually as a JSON payload. It then evaluates the run. It might check policies, scan for vulnerabilities, or validate the configuration standards. Once done, it sends a response back to the Terraform. That response decides what happens next. Generally, pass means the run will continue, and fail can block the run. If the task is mandatory, the run stops on failure. If it's just advisory, Terraform continues but shows a warning. This gives teams strong governance without slowing automation. And since run tasks can run before or after plan and apply, they fit many real-world automation scenarios. Now let's look at the impact loop behind the run task. Whenever a developer commits any changes, Terraform triggers a run task. Terraform sends a POST request to the configured endpoint. This request usually includes the Terraform plan in JSON format. The external system reads and evaluates this data. It might check policies, security, or configuration standards. First, the system must send an HTTP 200 response. This confirms Terraform received the request. If Terraform does not get this response, it retries automatically. And after evaluation, the system sends a callback to the Terraform. This includes an access token and pass or fail result. This callback must arrive within 10 minutes. Otherwise, the task is marked as an error. Depending on enforcement level, the run may stop. This API-driven model enables strong automation and governance. It allows teams to integrate any tool into the Terraform workflows. Now let's see how run tasks are created and assigned in SAP Terraform. It starts at the organization level. Run tasks are configured from the setting page. This central setup allows reuse across multiple workspaces. While creating a run task, you define the endpoint URL. This endpoint connects Terraform to the external system. For example, validation, security scanning, or approvals. Once created, run tasks can be assigned to multiple workspaces. You can assign them individually or apply them globally across all the workspaces. This gives both flexibility and control. For example, compliance checks can be run everywhere, but approval workflows may apply only to the critical environments. This approach balances governance with agility. It helps teams enforce policies consistently while keeping infrastructure workflows efficient. Now let's talk about where run tasks fit in the Terraform run lifecycle. Once a run task is created, it must be assigned to a specific stage. These stages decide when the task runs. There are four stages. Pre-plan, post-plan, pre-apply, post-apply. First is a pre-plan, before the Terraform creates the plan. It's good for validation and policy checks. Next is a post-plan, after the plan is generated. It's perfect for reviewing the proposed changes. Then comes pre-apply, before changes go live. It's usually used for approvals or final security checks. Finally, post-apply, after deployment completes. And it's useful for the logging, notification, or audits. Each run task has an enforcement level. It can be an advisory or mandatory. Mandatory features can block the run. Advisory ones just raise the warnings. The trip test task always decides the final outcome. Choosing the right stage helps balance governance, security, and operational efficiency. Let's quickly understand the enforcement levels in the run task. There are two types, advisory and mandatory. In advisory, the run continues even if the task gets failed. You will see a warning, but nothing gets blocked. This works well for recommendations like tagging, suggestions, or cost alerts. Mandatory is more strict. If the task fails, the run stops immediately. And Terraform marks the run as an error. This is typically used for the security or compliance checks. So, in simple terms, advisory guides the behavior, mandatory enforces the control. And even if multiple tasks run together, the strictest one decides the final outcomes. This helps balance flexibility with strong governance. Terraform's public registry now includes run tasks that can be directly integrated into SCP-Terraform. These are ready-to-use integrations, so you don't always need to build a custom one. Many tasks are provided by HashiCorp and the wider partner ecosystem. Common use cases include policy checks, security scanning, and configurations. Using this helps teams add governance quickly. Each run task comes up with documentation. It explains setup, purpose, and compatibility. This makes evaluation and adoption easier. You can explore them on the Terraform registry. It's a great place to start, discover integrations, and accelerate the infrastructure best practices. Before I start on the demo, let me quickly summarize what we covered so far. First, we look at run tasks. They allow SCP-Terraform to connect with external systems during a run. This helps with validation, security checks, and custom automation. Then we explored the API workflows. Terraform sends data to external endpoints. The system evaluates and it must respond within 10 minutes. This keeps the automation flow smooth. Next, we discussed about the creation and assignment. Run tasks are set up at the organization level. They can be applied globally or per workspace at different stages of the run. Finally, we saw the Terraform registry. It offers ready-to-use run tasks. This helps extend Terraform quickly without building custom integrations. Overall, run tasks bring governance, automation, and flexibility directly into your Terraform workflows. Now, let me show you the demo of how Terraform run tasks with AI analysis works in action. Let me switch to the browser. This is a HashiCorp Terraform registry. All the run tasks are already available. You can just open any run task and it has all the required documentation including how to use that solution. Today, we will be focusing on this run task Terraform plan analyzer. This is the GitHub repo. I have already forked this repo just to make a minor enhancement. This is our repo for today's demonstration. You can see it has the architecture diagram which Praneet has already explained. I have just added a sequence flow if you want to deep dive how it works in the backend. It has a couple of features that I already added here as screenshots. Just to show the demo, I have created another repo which has two examples. You can call it as a good example and bad example. In good example, we have the example which follows the best practices and another example which does not follow. We will see how it works in action. Let me switch to the SCP Terraform. This is our SCP Terraform. Let me go to the organization. This is our organization. You can see I have two organizations. Let me go to the organization Rahul TFC. In the settings, you can see as I explained the Terraform run task available at the organization level. Here is our run task that we already deployed which is available at the organization level. You can add this run task at the workspace individually or at a global level. Let me go to the workspaces. For the demo purpose, I have created the project, HashiTalks26 project. Here we have a workspace Terraform run task demo workspace. Let me go to that. You can see here the run task is available for this workspace. You can go to here and you can see I already added the run task here at the workspace level. You can take a look in the configure. I have added this task at the post plan stage. Let's quickly go through the demo. What I will do is I will quickly show you the example and we will just do a test commit. Let's see how does it work. I'm just pushing this change to the repository. You can see it has updated in the second and you can go to the run. It should show the new run. You can see you can expand it. This has triggered the Terraform run task. What it will do is it will first show the plan. As we have already configured our run task as a post plan. It will actually perform the AI analysis and it will show us the detailed analysis once the post plan stage is completed. Now you can see the Terraform plan run is completed and as you can see it's showing 17 resources to create. If I go down you can see after the Terraform plan stage we have configured the run task. It is showing past and completed. Let me double down on this. You can see it shows plan summary, impact analysis and AMI summary. You can click on it and it will show you the detailed summary which is easy to read as compared to JSON output. You can see here it shows all the details including networking, security, compute, storage. Then we have impact analysis. What will be the impact of this Terraform run if I apply? It talks about security concern, configuration issues, operational impact. It also gives you the recommendation. Then we have a third AMI summary. It provides all the detailed summary around the AMI, what is AMI ID, what are some validations, security assessment as well as recommendations. This is from the example 1. Let me change the configuration and run it from the example 2. Let me just change the Terraform configuration so that it will run from the example 2. I will come back here and run the new Terraform run. Let's wait to get started with the Terraform run task. Meanwhile, you can go into your AWS console and you can see we have a step function which is deployed as a part of our solution. Here it will actually trigger your run task in the backend. You can see here if you expand your execution, you can see it goes through multiple stages. Once it is passed through all the steps, it will give the end results to the Terraform back. Once it is complete, you can see here it will appear here as an outcome. Once the step function is complete, it will give the output to the Terraform back. Here you can see it has provided the detailed summary. Again, we will go with the plan summary and you can see it is showing all the details again. But this time, as this is a bad example which has some vulnerabilities, it shows this AWS security group provides the extremely permissive roles. It gives all the details. Ingress, egress, IAM role is not configured. It also talks about the compute availability zones which is not following the best practices. The tags are missing. Then in the impact analysis, if you look at, you can see it clearly calls out all the security concerns including the open database ports, S3 public access, high issues, medium issues, configuration issues, operational impact, and it also provides you the recommendation. All these details might not be possible in the traditional Terraform plan, but as a part of this Terraform run task AI solution, it gives you all the details including the insights. In the AMI summary, you can see it has provided you the validations, security assessment, as well as the recommendations. It also provides you the AWS AMI management best practices and some immediate actions as well. This is a very nice solution which provides you the detailed summary of your Terraform plan with some actions. Let's come back to our presentation. How you can get started on Terraform run tasks? I have already collated some resources to get started. First is the documentation. Then the other is the HashCorp blog and the code sample which we use for today's demonstration. What are some key takeaways you want to take from this presentation? First thing is seamless integration. Run tasks can be Terraform with external tools. This could be security scanners, cost tools, compliance checks, or custom automation. Everything runs automatically at different stages of the Terraform lifecycle. No manual intervention is required. The second is automated guardrails. Run tasks can be advisory or mandatory. Advisory gives you the warnings and mandatory can block your runs. This helps enforce security and compliance consistently. The third is a scalable and extensible workflow. Run tasks can be managed centrally. They work across teams, environments, and pipelines. You can use ready integrations or build your own when needed. Overall, run tasks make Terraform workflows more secure, automated, and enterprise-ready. So with that, thank you so much for joining today's HashiTalks on Terraform Run Tasks. Hope you found the session informative and engaging. Your feedback is very invaluable to us. Please scan the QR code on the screen to share your thoughts. With that, I would like to thank you for your time today and happy Terraforming.
