Transform AWS Support Case Workflows with Kiro CLI

Operations teams managing AWS infrastructure must resolve issues quickly while maintaining thorough documentation and following best practices. Traditional workflows create bottlenecks where valuable engineering time is consumed by administrative tasks rather than actual problem-solving, directly impacting system availability and customer experience. Kiro CLI removes this administrative overhead.

Kiro CLI is an AI-powered command-line assistant for software development and operations on AWS. Its Model Context Protocol (MCP) integration transforms how teams interact with AWS services. MCP is a protocol that allows Kiro to communicate with external servers to access specialized tools, prompts, and resources. The solution uses three MCP servers: Amazon CloudWatch MCP Server for investigation, AWS MCP Server for documentation lookup, and AWS Support MCP Server for case creation. Together, these integrations convert traditional manual workflows into automated systems that investigate issues, analyze metrics, access documentation, create contextual support cases, and track resolution.

In this blog post, you will explore how Kiro CLI’s MCP integration accelerates support case workflows by combining investigation, documentation lookup, and case creation into a single conversational interface across three real-world scenarios: AWS Glue job failures, AWS Lambda cold start investigation, and AWS WAF false positive analysis.

The Challenge: Traditional Support Workflow

When production issues arise, operations teams typically follow a time-consuming process:

• Manual Investigation: Engineers spend 20-30 minutes collecting logs from CloudWatch, pulling metrics, and correlating events across services
• Context Switching: Moving between the AWS Management Console, CLI, documentation, and support portal fragments the troubleshooting flow
• Case Creation Overhead: Writing detailed support cases requires re-documenting everything the engineer already investigated, often taking 10-15 minutes
• Evidence Gaps: Support engineers request additional logs or metrics that were not included in the original case, adding roundtrips
• Tracking Complexity: Managing multiple cases across different severity levels and services becomes increasingly complex as issues scale

This fragmented workflow often extends resolution times from hours into days, creating operational inefficiencies that directly impact business continuity.

Solution: Kiro CLI with Comprehensive MCP Integration

Kiro CLI’s MCP integration simplifies the entire operational lifecycle. Instead of switching between consoles, Kiro investigates the issue using CloudWatch metrics and logs, searches AWS documentation for known issues and best practices, and when the issue requires AWS-side investigation, creates a support case pre-populated with all diagnostic evidence. The engineer never leaves the terminal.

Figure 1: AWS Architecture Diagram for Kiro CLI MCP Integration

Prerequisites

• Active AWS Support plan (Business, Enterprise On-Ramp, or Enterprise), required for programmatic case creation through the Support API
• A Kiro subscription with Kiro CLI installed and authenticated on your local machine
• AWS credentials configured for the AWS account and identity you will use, with appropriate permissions
• AWS Command Line Interface (AWS CLI) version 2
• The uv package manager installed
• Terminal or command prompt access

Real-World Support Automation Scenarios

The following three scenarios demonstrate how Kiro CLI uses all three MCP servers together.

Note: The prompts shown in these scenarios are examples. Kiro CLI responses are non-deterministic and depend on your environment, so the output you see may differ from the screenshots in this post.

Scenario 1: AWS Glue ETL Job Failure

A data engineer reports that your production AWS Glue ETL job is failing intermittently with Exit Code 2 and BrokenPipeError. The job processes daily data loads and has been running successfully for months. The failures started after a data volume increase, but the job configuration has not changed. You suspect an AWS-side resource allocation issue but cannot confirm from the available logs.

Step 1: Initial Investigation

Prompt:

My Glue job blog-demo-etl is failing with Exit Code 2 and BrokenPipeError. It runs on G.1X workers with 2 max workers. Can you pull the error logs and investigate?

Kiro CLI uses the CloudWatch MCP server to query the /aws-glue/jobs/error log group, retrieves the recent error events, and identifies the failure pattern.

Figure 2: Kiro CLI terminal showing: (1) user prompt about Glue failure, (2) Kiro searching /aws-glue/jobs/error via CloudWatch Logs Insights, (3) output showing the reported error doesn’t match; real failures are ExecutorLostFailure (RPC disassociation) across multiple runs.

Step 2: Documentation Lookup

Prompt:

Can you search AWS documentation for ExecutorLostFailure and Remote RPC client disassociated errors in Glue, and see if there's guidance on cross join partition sizing for G.1X workers?

Kiro CLI uses the AWS MCP Server to search AWS Glue documentation for the specific error codes. It finds relevant troubleshooting guidance, but the documentation indicates that executor allocation failures on managed infrastructure may require AWS-side investigation.

Figure 3: Kiro CLI terminal showing: (1) user prompt about the RPC disassociation error, (2) Kiro searching AWS Glue documentation via the AWS MCP Server, (3) results confirming the failure is executor OOM from oversized shuffle/partitions; a sizing issue, not an AWS-side fault.

Step 3: Creating the Support Case

Prompt:

This looks like a script bug on our end with the chained cross joins; we'll fix that. But I noticed some ambiguity in the G.1X worker documentation around concurrent task slots per DPU. Can you create a support case asking AWS to clarify the actual G.1X task-slot capacity, referencing what we found in the logs and docs?

Kiro CLI asks for your approval, then uses the Support MCP server to create a case. It automatically includes the specific documentation excerpts that conflict, the job’s actual Spark launch configuration, the job run ID for reference, and three concrete clarifying questions for AWS.

Figure 4: Kiro CLI terminal showing: (1) user prompt to escalate the documentation discrepancy, (2) Kiro calling the Support MCP server to create a case (service aws-glue, severity Low), (3) case body citing the conflicting doc sources and the actual Spark launch config, with three clarifying questions for AWS.

Step 4: Case Confirmation and Verification

Kiro CLI confirms the case was created and returns the case ID.

Prompt:

Verify the case was created and show me the case details.

Kiro CLI uses the Support MCP server to retrieve the case and confirms the case ID, severity, and a summary of the evidence included.

Figure 5: Kiro CLI terminal showing case creation success with case ID, severity (Low), service (Glue), and summary of attached evidence.

Scenario 2: AWS Lambda Cold Start Investigation

A DevOps engineer notices that two AWS Lambda functions running the same code exhibit very different cold start behavior: the VPC-attached function takes 8-12 seconds on cold start while the non-VPC function starts in under 200 milliseconds. You plan to ask AWS Support whether Provisioned Concurrency is the right solution and how to size it for your invocation pattern.

Step 1: Metrics Comparison

Prompt:

Our Lambda functions blog-func-vpc and blog-func-standard are showing very different cold start times. Can you pull the duration metrics for both and compare them?

Kiro CLI uses the AWS MCP Server to compare the function configurations and the CloudWatch MCP server to retrieve Duration and InitDuration metrics for both functions, then presents a comparison showing the cold start disparity.

Figure 6: Kiro CLI terminal showing: (1) user prompt about cold start comparison, (2) Kiro calling CloudWatch MCP get_metric_data and Logs Insights for both functions, (3) metrics comparison showing near-identical init times (~395ms VPC vs ~378ms standard); no significant cold-start gap, consistent with modern Lambda’s Hyperplane ENI architecture.

Step 2: Documentation Lookup

Prompt:

Can you check AWS documentation for Lambda cold start best practices and Provisioned Concurrency sizing guidance?

Kiro CLI uses the AWS MCP Server to search Lambda documentation for cold start optimization and Provisioned Concurrency configuration.

Figure 7: Kiro CLI terminal showing: (1) user prompt asking about cold start best practices and Provisioned Concurrency sizing, (2) Kiro calling the AWS MCP Server’s documentation search across multiple sources, (3) results covering cold-start optimization, Hyperplane ENI behavior, and Provisioned Concurrency sizing, concluding PC isn’t warranted for this ~15-17ms gap.

Step 3: Evaluating Whether to Escalate

Prompt:

Can you create a support case asking AWS to confirm whether removing the VPC attachment from blog-func-vpc is safe?

Before creating a case, Kiro CLI checks whether AWS Support can answer the question. It inspects the function’s environment variables, VPC route tables, and security group configuration to determine whether the VPC attachment is load-bearing, then declines to file a case it judges would be rejected and recommends a self-service fix instead.

Figure 8: Kiro CLI terminal showing: (1) user prompt asking to create a case about VPC removal safety, (2) Kiro explaining why this isn’t an AWS-side question and inspecting the function’s actual VPC/network configuration, (3) Kiro declining to file the case and recommending a self-service UpdateFunctionConfiguration change instead.

Step 4: Applying the Self-Service Fix

Kiro CLI confirms there’s no VPC-internal dependency, then makes the configuration change directly; no support case needed.

Prompt:

Agreed, there's no VPC dependency here. Please update blog-func-vpc to remove the VPC attachment.

Kiro CLI confirms the plan, calls UpdateFunctionConfiguration with an empty VpcConfig, polls until LastUpdateStatus is Successful, and confirms the function is detached from the VPC.

Figure 9: Kiro CLI terminal showing the VPC attachment being removed from blog-func-vpc via a direct Lambda configuration update, resolving the investigation without opening an AWS Support case.

Scenario 3: AWS WAF False Positive Analysis

A security engineer reports that legitimate user requests are being blocked by AWS WAF. Users submitting their home address through a web form receive 403 Forbidden errors. The address field contains strings like “456 Union Select Drive” that trigger the AWS Managed Rules SQL injection (SQLi) rule set. You identified the triggering rule but need AWS Support to confirm that adding an exclusion won’t create a security vulnerability.

Step 1: WAF Investigation

Prompt:

Our WAF blog-demo-waf is blocking legitimate user requests. Users get 403 errors when submitting their home address. Can you check the WAF sampled requests and identify which rule is blocking them?

Kiro CLI uses the AWS MCP Server to query the WAF WebACL configuration and pull sampled requests directly from the WAF API, identifying the specific managed rule and sub-rule causing the false positive.

Figure 10: Kiro CLI terminal showing: (1) user prompt about WAF blocking legitimate address submissions, (2) Kiro querying the WebACL configuration and sampled requests via the WAF API, (3) a short summary confirming the block source is the SQLi managed rule’s SQLi_BODY sub-rule, with the sample count and root-cause explanation.

Step 2: Documentation Lookup

Prompt:

Can you check AWS documentation for how to safely exclude specific rules from the AWS Managed Rules SQLi rule set?

Kiro CLI uses the AWS MCP Server to search WAF documentation for managed rule exclusion guidance and best practices.

Figure 11: Kiro CLI terminal showing: (1) user prompt to search docs, (2) Kiro calling AWS MCP Server, (3) results showing WAF rule exclusion guidance.

Step 3: Creating the Support Case

Prompt:

We want to add a RuleActionOverrides exclusion for the SQLi_BODY false positive on the address field, but we need AWS Support to confirm this won't open a security gap. Create a case with the WAF analysis and our proposed fix.

Kiro CLI asks for your approval, then creates a support case that includes the WAF configuration, the specific rule triggering the false positive, sample blocked requests, and the proposed exclusion for AWS review.

Figure 12: Kiro CLI terminal showing: (1) user prompt to create case, (2) Kiro calling Support MCP with service code WAF, (3) case description with rule details, sample requests, and proposed RuleActionOverrides fix.

Step 4: Case Confirmation and Verification

Kiro CLI confirms your case creation with the WAF analysis and proposed exclusion you attached.

Prompt:

Verify the case was created and show me the case details.

Kiro CLI uses the Support MCP server to retrieve the case and confirms the case ID, severity, and a summary of the evidence included.

Figure 13: Kiro CLI terminal showing case creation success with case ID, service (WAF), and summary of the proposed rule exclusion.

Case Management

Prompt:

Show me a summary of all the support cases you created today.

Kiro CLI retrieves all open cases and presents a unified view. Only two cases appear. Kiro determined the Lambda cold-start investigation didn’t warrant escalation and resolved it with a self-service configuration change instead, demonstrating that the same conversational workflow can correctly avoid unnecessary support tickets, not just create them.

Figure 14: Kiro CLI terminal showing a summary table of the two cases created (Glue and WAF) with display IDs, service, severity, status, and creation timestamps.

What Kiro CLI Accomplished Across Three Scenarios

Using conversational commands, Kiro CLI used three MCP servers to perform complete support case workflows:

• Automated Investigation: The AWS MCP Server queried Glue job history, Lambda configuration and metrics, and WAF rules and sampled requests directly against each service’s API, while the CloudWatch MCP server pulled logs and metrics, all without leaving the terminal
• Documentation-Informed Analysis: The AWS MCP Server searched official AWS documentation for each service, surfacing the specific guidance needed to correctly diagnose each issue, including catching a stale, non-matching detail the engineer had reported (Glue), a documentation discrepancy worth flagging to AWS (Glue), and the exact supported mechanism for a WAF rule exclusion (WAF), rather than a guessed-at approach
• Judgment on When to Escalate: Kiro CLI didn’t treat every investigation as automatic grounds for a support case. For the Lambda scenario, it inspected the function’s actual configuration and network setup, concluded AWS Support had no way to answer the question being asked, and recommended (then applied) a self-service fix instead
• Evidence-Rich Case Creation: When escalation was genuinely warranted (the Glue scenario’s documentation discrepancy and the WAF scenario’s request for confirmation that a proposed rule change wouldn’t create a security gap), the Support MCP server created cases pre-populated with the exact log excerpts, configuration details, and documentation references gathered during investigation, plus questions scoped to what AWS Support could actually verify
• Case Tracking: Both cases were visible and manageable from the same conversational interface, alongside a clear account of why the third scenario didn’t need one

In a traditional workflow, each scenario typically requires 20-30 minutes of manual investigation across multiple console tabs, followed by 10-15 minutes of case documentation. With Kiro CLI, each scenario’s investigation and (where warranted) case creation completed in under 5 minutes, with cases containing more diagnostic evidence, and more precisely scoped questions, than a manually written case typically includes.

Key Benefits and Impact

For DevOps Engineers

• Reduced Context Switching: Investigate, research, and escalate without leaving the terminal
• Better Case Quality: Cases include CloudWatch evidence and documentation references automatically, reducing back-and-forth with AWS Support
• Faster Time to Escalation: When an issue requires AWS-side investigation, the case is created in minutes with all evidence attached
• Fewer Unnecessary Tickets: When an issue doesn’t need AWS-side investigation, Kiro CLI can identify that and resolve it directly, saving the case-creation cycle entirely

For Site Reliability Engineers

• Consistent Documentation: Every case follows the same structure with metrics, logs, and timeline, creating a reliable audit trail
• Case History Retrieval: The same conversational interface retrieves and summarizes existing cases, making it easier to spot recurring patterns across services
• On-Demand Log and Metric Analysis: CloudWatch MCP integration runs Logs Insights queries and metric comparisons in the same conversation, so investigations start from data instead of guesses

For Operations Managers

• Visibility: Case tracking across services and severity levels from a single interface
• Resource Optimization: Engineers spend time on investigation and resolution rather than case documentation
• Compliance: Complete audit trail of support interactions with evidence attached to every case

Configuration

Solution Components

The solution uses the following MCP servers:

• AWS Support MCP Server: Creates and manages AWS Support cases programmatically, including adding communications and resolving cases.
• Amazon CloudWatch MCP Server: Retrieves metrics, analyzes logs, checks alarm states, and runs Logs Insights queries for root cause analysis.
• AWS MCP Server: Provides up-to-date AWS documentation, API references, and pre-built Agent SOPs. This managed server consolidates the capabilities of the previous AWS Knowledge MCP and AWS API MCP servers into a single interface.

MCP Server Configuration

To enable the MCP integration, configure your ~/.kiro/settings/mcp.json file. The configuration below is current as of this post’s publication date; for the latest, see the official MCP Server documentation.

{
  "mcpServers": {
    "awslabs_support_mcp_server": {
      "command": "uvx",
      "args": [
        "-m", "awslabs.aws-support-mcp-server@latest",
        "--debug",
        "--log-file", "./logs/mcp_support_server.log"
      ],
      "env": { "AWS_PROFILE": "default" }
    },
    "awslabs.cloudwatch-mcp-server": {
      "autoApprove": [],
      "disabled": false,
      "command": "uvx",
      "args": ["awslabs.cloudwatch-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "transportType": "stdio"
    },
    "aws-mcp": {
      "command": "uvx",
      "timeout": 100000,
      "transport": "stdio",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-east-1"
      ]
    }
  }
}

Alternatively, you can scope these MCP servers to a custom agent for isolated, reusable configuration.

IAM Permissions

Ensure the IAM identity that your AWS CLI is configured to use has the following permissions. This policy follows the principle of least privilege. In addition to the policy below, you need permissions for the services you investigate in these scenarios (AWS Glue, AWS Lambda, Amazon EC2 networking, and AWS WAF).

Note: The AWS MCP Server does not define its own IAM actions; it authenticates with your existing AWS credentials and forwards requests to downstream AWS services, which authorize them using your standard service-level permissions. For fine-grained control, you can reference the aws:ViaAWSMCPService or aws:CalledViaAWSMCP condition keys in your policies:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SupportMCPServer",
      "Effect": "Allow",
      "Action": [
        "support:CreateCase", "support:DescribeCases",
        "support:DescribeCommunications", "support:AddCommunicationToCase",
        "support:ResolveCase", "support:DescribeServices",
        "support:DescribeSeverityLevels"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CloudWatchMCPServer",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:DescribeAlarms", "cloudwatch:DescribeAlarmHistory",
        "cloudwatch:GetMetricData", "cloudwatch:ListMetrics",
        "logs:DescribeLogGroups", "logs:StartQuery",
        "logs:GetQueryResults", "logs:StopQuery"
      ],
      "Resource": "*"
    }
  ]
}

Cleanup

If you created support cases while following this walkthrough, resolve them by prompting Kiro CLI:

Prompt:

Resolve and close all the support cases we created today

If you deployed test resources, delete them to avoid ongoing charges.

Conclusion

Kiro CLI’s MCP integration changes how operations teams handle complex AWS workflows. By combining investigation, documentation lookup, and support case management into a single conversational interface, teams can escalate issues to AWS Support in minutes instead of hours, with better diagnostic evidence than manually written cases.

To learn more about Kiro and MCP integrations, visit the Kiro product page, explore the AWS MCP Server documentation, and browse the full catalog of open source MCP servers for AWS. For pricing, visit the Kiro pricing page.