How to Automate AWS Cloud Operations with Kestrel Workflows: Incident Response, Infrastructure Provisioning, CI/CD, and Security
AWS gives you two hundred services; it doesn't operate them for you. The teams that run AWS well automate the recurring 80% — incident response, resource provisioning, developer requests, CI/CD, and security — as deterministic, approval-gated workflows. Here's how to build all five with Kestrel Workflows, with copy-paste prompts for each.
Every team that runs production workloads on AWS carries the same operational load. A CloudWatch alarm fires at 3am and someone spends an hour in CloudTrail figuring out what changed. A developer needs an S3 bucket and the ticket waits a day. The deploy pipeline ends at "CI passed" and hopes for the best. An IAM policy quietly gains * permissions and nobody notices until the audit. And the bill surprises everyone, monthly.
None of this is an AWS problem — it's an automation problem. Each of those tasks is a known, repeatable sequence of steps that happens to be executed by a human with console access. The way to make AWS easier to operate is not another dashboard; it's codifying those sequences as workflows that run the same way every time, with a human approving anything that has blast radius.
This post shows how to automate the five domains of AWS cloud operations with Kestrel Workflows: incident response, resource provisioning, developer requests, CI/CD, and security. Each section includes three prompts written the way you'd hand them to the Workflow Agent — paste one in, review the workflow it builds, and activate it.
How it works: plain English in, deterministic workflows out
You describe the automation in plain English and the Workflow Agent assembles it from real building blocks — AI root cause analysis for cloud incidents, IaC generation in Terraform, CloudFormation, or AWS CLI, Cost Explorer queries and anomaly detection, Terraform Cloud and Pulumi runs, GitHub Actions and Jenkins builds, Slack, PagerDuty, and Jira. The AI builds the workflow once; the workflow itself runs deterministically — the exact same steps on every execution, not an agent improvising at runtime.
Workflows start from the trigger that fits the job: CloudTrail security events, cost anomaly and budget signals, CloudWatch-driven incident signals, CI/CD events, schedules, or plain-English developer requests. And every workflow runs inside Kestrel's access control and approval model — scope it to specific AWS accounts and regions, restrict who can invoke it, and drop approval gates anywhere in the graph so nothing touches a production account until the right person signs off in the dashboard, in Slack, or by merging a PR.
The Workflow Agent building a production-ready workflow from a plain-English description.
How to automate incident response in AWS
AWS incident response has two halves: the investigation (what broke, what changed, which account, which deploy) and the remediation (revert, resize, fix). The investigation is safe to automate fully; the remediation gets an approval gate. These three workflows cover the incidents that page most cloud teams — alarms nobody can trace, cost spikes, and the recurring ones that deserve a runbook.
When a CloudWatch alarm fires for a production service, run a root cause analysis on the incident — query CloudWatch metrics and logs, check CloudTrail for recent configuration changes, and identify the likely cause — and search recently merged pull requests for the change that likely caused it. Post the RCA summary and the suspect PRs to the #incidents channel in Slack, and send the generated remediation commands to a Slack approval gate. On approval, execute the fix and resolve the PagerDuty alert.
When a cost anomaly is detected in any of our AWS accounts, compare this period's spend against the previous period broken down by service and region, pull the anomaly details with their root cause analysis, and run an AI cost analysis over the results. Post a summary to #cloud-costs in Slack with the top cost movers and recommendations, and create a Jira ticket for any driver that needs engineering follow-up. Read-only, no approval gate.
After a cloud incident's root cause analysis completes, generate a reusable runbook for that class of incident — written for the on-call engineer, with rollback steps included — publish it as a runbook entry in Confluence, and create a Jira ticket for the permanent fix with the RCA attached. No approval gate needed; this workflow only writes documentation.
How to automate resource provisioning in AWS
Provisioning is where cloud teams lose the most time to toil, because every request is slightly different but the shape is always the same: generate the infrastructure as code, review it, apply it, confirm it. Kestrel's provisioning blocks generate Terraform, CloudFormation, or AWS CLI from a description, open pull requests in your IaC repo, and drive Terraform Cloud and Pulumi runs end to end — so the golden path is IaC-first by default, not console clicks.
When a team requests new networking infrastructure — a VPC, subnets, or peering — generate the Terraform for the requested setup following our module conventions and open a pull request in our infra-repo. After the PR is merged, queue a plan run on the matching Terraform Cloud workspace, post the planned resource changes to a Slack approval gate for the platform team, and on approval apply the run and reply to the requester with the result. Always require approval before apply.
When a developer requests a Lambda function with an SQS queue trigger, generate the AWS CLI commands to create the queue, the function with our standard runtime and tags, and the event source mapping between them. Send the commands to an approval gate, execute them on approval, and reply in Slack with the function and queue ARNs. Allow the dev and sandbox accounts; require platform-admin approval for production.
Every night at 2am, check our production Pulumi stacks for drift between the declared program state and real infrastructure. If drift is found, post the drifted stacks and resources to #platform in Slack and send a remediation request to a manual approval gate. On approval, run a remediate-drift deployment on the affected stack and post the result. Never remediate without approval.
The best way to automate developer requests in AWS
Developer requests are provisioning's high-frequency cousin: small, constant asks — a bucket, a resize, a cost question — that each interrupt the platform team for twenty minutes. The fix is a plain-English front door. Developers ask in Slack with /kestrel-workflow, from the CLI, or on the Developer Requests page; Kestrel matches the request to an active request-triggered workflow, extracts the parameters from the phrasing, and runs it inside the guardrails you defined. Cloud infrastructure requests carry real cost and blast radius, which is exactly what approval gates and account scoping are for.
When a developer requests an S3 bucket, create it in the requested AWS account and region with encryption at rest, versioning, and public access fully blocked by default, apply the team's standard tags, and return the bucket name and ARN to the requester in Slack. Restrict this to the dev and sandbox accounts; require platform-admin approval for the production account.
When a developer asks to resize an RDS instance, look up the current instance class and storage for the named database, then post the requested change to a Slack approval gate showing the before and after. On approval, apply the modification during the maintenance window and reply with the new configuration. Fence this to the accounts the requester's team owns and always require approval.
When a developer asks why their AWS costs spiked, investigate cost and usage for the requested account over the last 30 days, break down the increase by service and tag, identify the top drivers, and post a summary with the likely cause and cost-saving recommendations back to the requester. Read-only, so allow it for all developers on the accounts they own with no approval gate.
This is the same pattern our internal developer platform guide builds across the whole stack — Kubernetes, PlanetScale, Vercel, and more. Here it's scoped to AWS, but the request workflows compose: the same front door serves every integration you connect.
How to automate CI/CD in AWS
Most AWS deploy pipelines end at "CI passed" — the artifact exists, and a human still shepherds it to ECS, Lambda, or the Terraform workspace. Kestrel's CI/CD blocks span both halves: trigger and wait on GitHub Actions, Jenkins, or GitLab pipelines on one side, and drive the AWS deployment — service updates, Terraform Cloud plan-and-apply — on the other, with verification and notification built into the same graph.
When a team requests a release, trigger the GitHub Actions workflow that builds the image and pushes it to ECR, wait for the run to complete, and if it succeeds use the AWS CLI to update the ECS service to the new image tag and confirm the deployment rolled out. Post the result — image tag, service, and rollout status — to #deploys in Slack. Require an approval gate before the production service update; staging deploys run without one.
When an infrastructure pull request is merged in our infra-repo, queue a plan run on the matching Terraform Cloud workspace, wait for the plan to finish, and post the resource adds, changes, and destroys to a Slack approval gate for the platform team. On approval, apply the run, wait for it to complete, and post the applied result; if rejected, discard the run and notify the PR author.
When a GitHub Actions run fails on our main branch, investigate the failure — read the run logs, identify the failing step, and classify whether it's a flaky test, an infrastructure issue, or a real code problem. For code problems, generate a fix and open a pull request with the analysis attached; for everything else, post the diagnosis to #ci-alerts in Slack. No approval gate — the fix still goes through normal code review.
How to automate AWS security
AWS security work is dominated by three recurring jobs: reacting to risky changes fast enough to matter, auditing posture on a schedule that never slips, and handling access requests without leaving standing admin credentials everywhere. CloudTrail-triggered workflows handle the first; scheduled investigations handle the second; approval-gated, self-expiring access workflows handle the third.
When CloudTrail records a change to an IAM policy, role, or user, investigate the change — who made it, from where, and what permissions it grants — and post the findings to #security in Slack. If the change wasn't made through our IaC pipeline, send a revert to a Slack approval gate for the security on-call; on approval, execute the revert and add a note to the related PagerDuty alert.
Every Monday at 9am, audit our AWS accounts for security posture issues: publicly accessible S3 buckets, security groups open to 0.0.0.0/0, IAM access keys older than 90 days, and unencrypted EBS volumes. Post the findings as a report to #security in Slack and create a Jira ticket for each new finding that isn't already tracked. Read-only, no approval gate.
When an engineer requests temporary elevated IAM access to a production account, ask them for a justification, send the request with the justification to the security on-call for Slack approval, and on approval attach the scoped policy to their user. Wait four hours, then detach the policy automatically and post the full audit trail — who requested, who approved, what was granted, when it was revoked — to #security.
Making AWS easier to operate
Fifteen workflows, five domains, one pattern: describe the operation in plain English, let the Workflow Agent assemble it from real AWS blocks, review the graph, and put approval gates on anything with blast radius. The recurring 80% of AWS operations — the alarm triage, the bucket requests, the deploy shepherding, the IAM audit — runs itself, and the platform team's time goes to the 20% that actually needs judgment.
This isn't AWS-only, either. The same workflow engine spans 30+ integrations across infrastructure, PaaS, observability, comms, databases, CI/CD, and IaC — so the workflow that resizes an RDS instance lives next to the one that provisions a PlanetScale branch or rolls back a Vercel deploy. For deeper dives, see our AWS incident response playbook, the internal developer platform guide, and the companion post on automating Kubernetes operations.
FAQ: automating AWS cloud operations
How do you automate AWS cloud operations?
Codify each recurring task — incident response, provisioning, developer requests, CI/CD, and security — as a deterministic, approval-gated workflow. With Kestrel, you describe the automation in plain English, the Workflow Agent assembles it from real AWS blocks, and it runs the exact same steps every time, pausing at approval gates before anything touches a production account.
What is the best automation tool for AWS?
It depends on scope. Terraform and CloudFormation automate provisioning; EventBridge and Step Functions route events within AWS; Systems Manager automates instance operations. For automating operations across all of them in one governed system, Kestrel Workflows builds deterministic workflows from plain English with native blocks for AWS, Terraform Cloud, Pulumi, GitHub, GitLab, Jenkins, Slack, PagerDuty, and Jira.
Is it safe to automate changes to production AWS accounts?
Safer than doing them by hand, if the automation is deterministic and gated. Kestrel workflows run fixed step sequences — no runtime improvisation — scoped to specific accounts and regions, and approval gates pause execution before any mutating action until a human signs off in Slack or the dashboard. Read-only workflows (investigations, audits, cost analyses) can run ungated.
How do you make AWS easier to operate?
Reduce how much of AWS your team touches by hand. Automate the recurring operations with workflows, give developers plain-English self-service for the requests they make weekly, and keep humans in the loop only where judgment matters — approvals, not execution.
Getting started
Connect your AWS accounts, pick the domain that hurts most — for most teams that's either the incident channel or the request queue — and paste one of the prompts above into the Workflow Agent. Review the workflow it builds, tighten the scoping and approvals, activate it, and add the next one. The Workflows Quickstart walks through your first workflow end to end, and the Create Workflows guide and Integrations Setup cover connecting Terraform Cloud, GitHub, and the rest of your stack. Prefer the terminal or an AI coding agent? Workflows can also be created and managed through the CLI, Python SDK, and MCP. Within a few weeks you'll have a governed automation layer over your AWS operations that no ticket queue can match.
Automate your AWS operations with $1,000 in credits
Incident response, provisioning, developer requests, CI/CD, and security — describe each workflow in plain English and Kestrel builds it. New accounts get $1,000 in usage credits to get started.
Get Started