AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a comprehensive, three-phase framework for migrating self-managed Apache Kafka clusters to Amazon MSK Express. It guides users through inventory discovery, compatibility assessment, and performance simulation to ensure a smooth transition. By analyzing existing infrastructure, the skill identifies potential configuration gaps, calculates target sizing, and provides cost projections, while also offering support for data replication using MSK Replicator.
What it does
- Inventories source Kafka clusters from IaC files, CLI output, or manual input.
- Assesses compatibility across topology, Kafka versions, configurations, auth, and quotas.
- Generates target MSK Express specifications, including broker counts and cost estimates.
- Facilitates optional load-testing via temporary MSK Express trial clusters.
- Provides guidance on using MSK Replicator for migration cutovers.
- Produces standardized artifacts for cluster configuration and compatibility findings.
When to use it
- When planning a migration from self-managed Kafka to Amazon MSK Express.
- When you need to assess the compatibility of your current Kafka setup with MSK Express.
- When you require an accurate sizing and cost projection for an MSK Express target.
- When you want to validate performance through a proof-of-concept load test before migrating.
- When you need a structured approach to inventorying your existing streaming infrastructure.
Advantages
- Reduces migration risk through automated compatibility and topology assessment.
- Provides data-driven cost and sizing recommendations based on actual workload metrics.
- Supports informed decision-making with optional pre-migration performance simulation.
- Standardizes the migration process across discovery, assessment, and execution phases.
- Integrates with existing IaC workflows for efficient inventory collection.
Usage examples
- “I need to migrate my on-premises Kafka cluster to MSK Express. Where do I start?”
- The agent will explain the three-phase migration process (Discovery, Assessment, Simulation) and ask for your infrastructure details or IaC files to begin the discovery phase.
- “Here is my Terraform directory for our Kafka cluster. Can you assess if it is compatible with MSK Express?”
- The agent will perform the discovery phase to generate a cluster configuration and then proceed to the assessment phase to validate compatibility and provide sizing recommendations.
- “I have a cluster-config.json file. How do I get a cost estimate for moving to MSK Express?”
- The agent will run the assessment phase using your configuration file to produce a compatibility report and a pricing summary for the recommended MSK Express setup.
- “How do I test MSK Express performance with my current workload?”
- The agent will guide you through the simulation phase, helping you deploy a temporary MSK Express cluster to run load tests and review performance metrics.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/aws/migrate-to-msk/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip migrate-to-msk.zip -d .agents/skills
Documentation by AWS
Migrating to MSK Express
Overview
This skill helps customers migrate self-managed Apache Kafka workloads to Amazon MSK Express. It provides three phases — Discovery, Assessment, and an optional Simulation — that can be run end-to-end or individually depending on the customer's needs.
Scope
This skill covers migrations from self-managed Apache Kafka (on-premises, EC2, Docker, Kubernetes, or other non-MSK deployments) to MSK Express. Migrations from MSK Standard (Provisioned) to MSK Express are out of scope.
Prerequisites
The AWS MCP server is recommended for documentation lookups and informational questions, but is not required. The assessment scripts are pure file processors with no AWS API calls.
Intent Routing
Route the customer's request based on their intent:
1. Open/exploratory question ("How do I migrate to MSK?")
Explain what this skill offers:
This skill helps you migrate to MSK Express in three phases:
Phase 1 — Discovery: Inventory your source Kafka cluster — brokers, topics, partition counts, configs, authentication, and workload metrics — plus two target decisions that drive cost: consumer rack affinity and any negotiated AWS pricing. I can discover this from IaC files (Terraform, CDK, Docker Compose, Kubernetes manifests), provide commands for you to run on your cluster, or you can provide the information manually. Output:
migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json.Phase 2 — Assessment: Validate your cluster against MSK Express across 5 compatibility pillars (topology, Kafka version, configs, auth, quotas) and produce a target Express specification using the managing-amazon-msk Skill's pricing logic. I'll flag what Express will refuse vs what Express will silently convert. Outputs:
compatibility.<cluster_name>.json, the pricing results in Markdownmsk_sizing_pricing.md, andmsk-sizing-inputs.<cluster_name>.json.Phase 3 — Simulation: Spin up an MSK Express cluster with load-testing infrastructure to see how Express performs on your own workload, then run a vended test (End-to-End Latency or Broker Restart Under Load) and review the results on a CloudWatch dashboard.
Data replication: For migrating data to your Express cluster, you can use MSK Replicator. I can provide guidance on setup and configuration.
Where would you like to start? I can begin with discovery if you point me to your infrastructure code or describe your cluster, or jump to assessment if you already have a
cluster-config.jsonfile, or go straight to simulation if you already know your target Express configuration.
Guardrails for this overview response:
This response is an overview and a routing question only. Do NOT begin, simulate, or pre-empt any phase.
Do NOT produce or estimate assessment output here — no verdicts, pillar findings, compatibility conclusions, broker counts, instance recommendations, or cost figures. Those values exist only after you run the Phase 2 scripts against a real
cluster-config.json.Do NOT open, read, or summarize the internals of
compatibility.py,simulation_load_test_config.py, or the reference files to explain how a phase works. Describe the phases at the level shown above; do not walk the customer through the implementation.When the customer chooses a phase, run that phase's scripts or flow to produce real results. Always operate the skill to answer — never answer from having read its source. For the exact commands, see "Running the assessment" in references/assessment-compatibility.md for Phase 2, and references/simulation.md for Phase 3.
2. Discovery intent (DEFAULT when IaC files are provided)
If the customer provides a directory path, IaC files, or says "here's our infra" —
this is discovery intent. Run ONLY Phase 1 (Discovery). Do NOT run assessment,
do NOT suggest migration steps, do NOT mention blockers or compatibility.
Produce the migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json file and stop.
3. Assessment intent
Customer explicitly asks to assess or has a migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json file
already produced. Run Phase 2 (Assessment) only.
4. Simulation intent
Customer wants to test MSK Express with their workload. They can provide cluster sizing directly (instance type, broker count, Kafka version) or reference an earlier assessment. Proceed directly to Phase 3 — Simulation. An assessment is helpful but not required — the simulation asks for sizing inputs directly.
5. Informational questions
Customer asks about Express capabilities, constraints, configuration differences,
authentication support, pricing, or compaction behavior without providing
cluster-specific data. Use AWS documentation tools (aws___search_documentation,
aws___read_documentation) if available to look up the answer from MSK Express
documentation. If MCP tools are not available, reference the
MSK Express documentation
and answer based on knowledge of AWS MSK.
6. Migration strategy questions
Customer asks about MSK Replicator compatibility, version upgrade paths, MirrorMaker 2,
or migration strategies. MSK Replicator is the native AWS-supported solution for data
replication and works for both MSK-to-MSK and non-MSK-to-MSK migrations. Use AWS
documentation tools (aws___search_documentation, aws___read_documentation) if
available to retrieve current requirements and supported configurations. If MCP tools
are not available, reference the
MSK Replicator documentation
and answer based on knowledge of AWS MSK.
Phase 1 — Discovery
Purpose: Inventory the source cluster to build a migration profile.
Input: One of:
A directory path containing IaC files (CDK, CloudFormation, Docker Compose, Kubernetes manifests, Terraform)
Output from Kafka CLI commands the customer runs on their cluster
Manual information provided by the customer in conversation
Output: migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json — saved to the working directory.
Discovery rules
Before doing ANYTHING else in discovery, you MUST read references/discovery.md in full. It defines the input methods, the REQUIRED response template, the forbidden content, and the
cluster-config.jsonschema. Do NOT respond until you have read it, and follow its template EXACTLY.ALWAYS save
migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.jsonin the working directory.Do NOT proceed to Phase 2 without explicit customer confirmation.
Phase 2 — Assessment
Purpose: Assess the cluster against MSK Express requirements and produce a target Express specification (instance type, broker count, monthly cost projection).
Input: migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json from Phase 1.
Outputs:
migrate-to-msk-skill-artifacts/<cluster_name>/compatibility.<cluster_name>.json— five-pillar verdict.migrate-to-msk-skill-artifacts/<cluster_name>/msk_sizing_pricing.md— the managing-amazon-msk Skill's pricing report with broker count and cost recommendations.migrate-to-msk-skill-artifacts/<cluster_name>/msk-sizing-inputs.<cluster_name>.json— a record of the six input values for sizing logic.
Assessment has two independent halves; run them in either order, and a failure in one does not block the other:
Compatibility —
scripts/compatibility.py, a pure file processor (no live AWS API calls) run viauv runwith PEP 723 inline dependencies. It validates the source across five pillars — topology, Kafka version, configs, auth, and quotas — and emits one verdict per pillar (INFO,ADVISORY, orACTION_REQUIRED, worst-of for the overall). Use those three strings verbatim.Sizing — not a script in this skill. Load the managing-amazon-msk Skill and run its
scripts/msk_sizing.pywith the workload inputs derived fromcluster-config.json, passing--broker-classes expressand--regionfor the target Region. The script prices from the live AWS Pricing API when credentials are available and from an embeddedus-east-1snapshot when they are not.
Assessment rules
Read references/assessment-compatibility.md before responding. It carries the invocation commands, the per-pillar thresholds and evidence codes, the verdict definitions, the full forbidden-behavior list, and the required response template covering both artifacts. Do not freestyle the post-script summary.
Read references/assessment-sizing.md before running sizing. It carries the input derivations (several are not one-to-one — getting them wrong silently produces a wrong broker count), the
target-block flags for rack affinity and negotiated discounts, the Region and pricing-source handling, the Express-only presentation rule, and the source-footprint comparison.Surface any
ACTION_REQUIREDevidence to the user for awareness, but do not gate further phases on it. Express may still accept the workload with mitigations.Do NOT pivot back into discovery. Assessment operates on the existing
cluster-config.jsonas-is. Partial data is fine — the scripts emit ADVISORY evidence (METRICS_MISSING,AZ_COUNT_UNKNOWN, etc.) for missing fields; surface those findings and stop. Do not propose Kafka CLI commands, IaC walks, scripts, or questionnaires to fill the gaps.Report broker counts and costs only as read verbatim from the sizing script output. Never round, re-derive, or estimate them. Report the
pricing sourcethe script used alongside the costs; when it isstatic, the rates are an embedded snapshot, not confirmed current pricing.
Phase 3 — Simulation (optional)
Deploy a temporary, isolated MSK Express cluster and client fleet in the customer's account so they can see how Express performs on their own workload, then run one of two vended tests (End-to-End Latency, Broker Restart Under Load) and hand over a CloudWatch dashboard. Follow the 12-step conversational flow and all deploy, sizing, and guardrail details in references/simulation.md; the deterministic artifacts it drives are scripts/simulation_load_test_config.py and the static assets/simulation-stack.yaml.
Execution model
Scripts run on the customer's local machine via uv run. They declare their own
dependencies (PEP 723) and are pure file processors — no AWS API calls, no
network access, and no third-party dependencies (standard library only).
Security Considerations
Apply these controls at every phase. For additional detail, see MSK Security best practices and MSK IAM access control.
Encryption in transit (mandatory). Enforce TLS for client-broker traffic on the MSK Express target (
EncryptionInTransit.ClientBroker = TLS).Encryption at rest (mandatory). Provision the target cluster with a customer-managed KMS key (or AWS-managed if your compliance posture allows).
Authentication — prefer IAM over long-lived credentials. Configure the MSK Express target with IAM authentication as the sole client auth method. This gives ephemeral, role-based credentials with full CloudTrail coverage.
Credential storage — use AWS Secrets Manager. Store SASL/SCRAM and TLS credentials for source cluster access in Secrets Manager. Never pass passwords as CLI arguments.
Network isolation. Deploy MSK clusters in private subnets. Use security groups scoped to specific CIDR ranges or security group references. Do NOT use 0.0.0.0/0 ingress rules.
CloudTrail logging and CloudWatch alarms. Ensure CloudTrail is enabled in the target account and covers
kafka.amazonaws.comAPI calls. Configure alarms:ClientAuthenticationFailure— surge indicates credential problems or attackConnectionCloseCount— abnormal spike may indicate connection-floodingCloudTrail metric filters for denied
kafka-cluster:*actionsConnection-rate alarms approaching the 100 conn/sec/broker IAM limit
Sensitive data handling. Discovery and assessment outputs contain broker addresses, auth hints, and broker config values. Treat these as sensitive — do not paste into public channels or ticketing systems without redaction.
Troubleshooting
Per-pillar findings, including the source topology and out-of-range config cases, are explained in references/assessment-compatibility.md.
Files
- ATTRIBUTION.mdAdded by AutoGineer908 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer67 B
- SKILL.md14.0 KiB
- assets/simulation-stack.yaml47.9 KiB
- references/assessment-compatibility.md23.1 KiB
- references/assessment-sizing.md14.8 KiB
- references/discovery.md14.8 KiB
- references/simulation.md38.6 KiB
- scripts/compatibility.pyScript46.7 KiB
- scripts/simulation_load_test_config.pyScript17.7 KiB
scripts/simulation_load_test_config.py
#!/usr/bin/env python3
# /// script
# requires-python = ">=3.11"
# dependencies = []
# ///
"""
Deterministic compute + guardrail engine for the MSK Express load-test simulation.
Three actions:
compute — given cluster sizing (instance_type, broker_count), emit all derived
values: cluster capacity, auto-sized client fleet, and per-test
default parameters + bounds. Feeds CFN parameters and test templates.
render — given the same sizing, write a local, ready-to-deploy copy of the
CloudFormation template with the customer's sizing AND the computed
fleet baked in as parameter Defaults. The source template stays static;
this emits a derived artifact to a working-directory path so the customer
deploys from a local file (never from the skill source). The Kafka client
is installed post-deploy via SSM, so nothing client-related is baked here.
validate — given a test type and a proposed config, return PASS/REJECT plus
inline WARNINGS. The agent loops back on REJECT, surfaces WARNINGS
as one-sentence notes and proceeds.
Run with:
uv run <script> compute --instance-type express.m7g.4xlarge --broker-count 12
uv run <script> render --instance-type express.m7g.4xlarge --broker-count 12 \
--kafka-version 3.9.x.kraft \
--output migrate-to-msk-skill-artifacts/simulation/simulation-stack.yaml
uv run <script> validate --test e2e_latency --config '{"throughput_mbps":10,...}'
uv run <script> validate --test broker_restart --config '{...}' \
--instance-type express.m7g.4xlarge --broker-count 12
"""
import argparse
import json
import math
import sys
from pathlib import Path
# The static source template lives alongside this script in the skill package.
# It is resolved internally and never surfaced to the customer — render() emits a
# derived local copy, and all customer-facing commands point at that copy instead.
SOURCE_TEMPLATE = Path(__file__).resolve().parent.parent / "assets" / "simulation-stack.yaml"
# Express per-broker INGRESS throttle limits (MB/s), from AWS Express docs:
# (sustained, max_quota)
# sustained = recommended threshold (no performance degradation up to here);
# max_quota = hard ceiling (the cluster throttles read/write traffic beyond it).
# Full table including egress lives in references/simulation.md.
PER_BROKER_INGRESS = {
"express.m7g.large": (15.6, 23.4),
"express.m7g.xlarge": (31.2, 46.8),
"express.m7g.2xlarge": (62.5, 93.7),
"express.m7g.4xlarge": (124.9, 187.5),
"express.m7g.8xlarge": (250.0, 375.0),
"express.m7g.12xlarge": (375.0, 562.5),
"express.m7g.16xlarge": (500.0, 750.0),
}
# The only valid Express version + metadata-mode combinations, as the exact CFN
# KafkaVersion strings the template's AllowedValues accepts. On Express, 3.9 is
# KRaft-only (no ZooKeeper variant) and KRaft is unavailable below 3.9, so these
# three are the whole set. Validated here so a freeform/unsupported version is
# rejected locally instead of failing ~40 min into create-stack.
SUPPORTED_KAFKA_VERSIONS = ("3.6.0", "3.8.x", "3.9.x.kraft")
# Fixed client fleet instance type -- one size for all clusters, only count varies.
# c5.2xlarge: 10 Gbps sustained baseline (no burst credits), $0.34/hr.
# 400 MB/s is a conservative per-node Kafka producer throughput target accounting
# for TLS overhead, acks=all latency, and batching inefficiency.
FLEET_INSTANCE_TYPE = "c5.2xlarge"
FLEET_NODE_THROUGHPUT_MBPS = 400
def compute(instance_type, broker_count, kafka_version=None):
if instance_type not in PER_BROKER_INGRESS:
raise ValueError(
f"unknown instance_type {instance_type!r}; valid: {list(PER_BROKER_INGRESS)}"
)
if broker_count < 3 or broker_count % 3 != 0:
raise ValueError("broker_count must be a multiple of 3 and >= 3")
# Only validate the version when one is supplied; sizing math doesn't need it,
# but rejecting an unsupported value here keeps a freeform answer from reaching
# create-stack. 3.9 ZooKeeper (e.g. "3.9.x") is intentionally not in the set.
if kafka_version is not None and kafka_version not in SUPPORTED_KAFKA_VERSIONS:
raise ValueError(
f"unsupported kafka_version {kafka_version!r}; valid: "
f"{list(SUPPORTED_KAFKA_VERSIONS)} (3.9 is KRaft-only on Express)"
)
per_broker_sustained, per_broker_max = PER_BROKER_INGRESS[instance_type]
cluster_sustained_ingress = round(per_broker_sustained * broker_count, 1)
cluster_max_ingress = round(per_broker_max * broker_count, 1)
fleet_bandwidth = FLEET_NODE_THROUGHPUT_MBPS
# Provision 1.5x the cluster's MAXIMUM ingress quota so the fleet can drive the
# cluster all the way to its throttle ceiling with headroom and never be the
# bottleneck (even when deliberately probing past the limit).
fleet_producer_count = max(2, math.ceil(cluster_max_ingress * 1.5 / fleet_bandwidth))
fleet_consumer_count = fleet_producer_count
fleet_max_mbps = fleet_producer_count * fleet_bandwidth
default_target = round(cluster_sustained_ingress * 0.8)
return {
"instance_type": instance_type,
"broker_count": broker_count,
"supported_kafka_versions": list(SUPPORTED_KAFKA_VERSIONS),
"cluster_sustained_ingress_mbps": cluster_sustained_ingress,
"cluster_max_ingress_mbps": cluster_max_ingress,
"fleet_instance_type": FLEET_INSTANCE_TYPE,
"fleet_instance_bandwidth_mbps": fleet_bandwidth,
"fleet_producer_count": fleet_producer_count,
"fleet_consumer_count": fleet_consumer_count,
"fleet_max_mbps": fleet_max_mbps,
"default_target_throughput_mbps": default_target,
"tests": {
"e2e_latency": {
"throughput_mbps": {"default": 10, "min": 1, "max": fleet_max_mbps},
"duration_minutes": {"default": 10, "min": 5, "max": 120},
"num_producers": {"default": 1, "min": 1, "max": fleet_producer_count},
"num_consumers": {"default": 1, "min": 1, "max": fleet_consumer_count},
},
"broker_restart": {
"target_throughput_mbps": {
"default": default_target,
"min": 1,
"max": fleet_max_mbps,
},
"duration_minutes": {"default": 15, "min": 10, "max": 120},
"reboot_at_minute": {"default": 5, "min": 2, "max": None}, # max = duration-2
"num_producers": {
"default": fleet_producer_count,
"min": 1,
"max": fleet_producer_count,
},
},
},
}
def _set_param_default(template_text, param_name, value):
"""Set the `Default:` of a top-level CloudFormation parameter in-place.
The template is static and authored with each parameter at 2-space indent and
its properties at 4-space indent. We locate the parameter block and rewrite its
existing `Default:` line (every baked parameter already declares one). Raises if
the parameter or its Default line is missing, so a template drift fails loudly
here rather than silently producing an unsized stack.
"""
lines = template_text.splitlines()
out = []
i = 0
n = len(lines)
replaced = False
header = f" {param_name}:"
while i < n:
line = lines[i]
out.append(line)
if line == header:
# Walk this parameter's property lines (indented deeper than 2 spaces).
i += 1
block_done = False
while i < n:
prop = lines[i]
# End of block: a line that isn't blank and is indented <= 2 spaces.
if prop.strip() and (len(prop) - len(prop.lstrip(" "))) <= 2:
break
stripped = prop.lstrip(" ")
if stripped.startswith("Default:") and not block_done:
indent = " " * (len(prop) - len(stripped))
out.append(f"{indent}Default: {value}")
replaced = True
block_done = True
else:
out.append(prop)
i += 1
continue
i += 1
if not replaced:
raise ValueError(
f"could not set Default for parameter {param_name!r}; the source template "
"may have drifted (expected a 2-space-indented block with a Default line)"
)
# Preserve a trailing newline if the original had one.
text = "\n".join(out)
if template_text.endswith("\n"):
text += "\n"
return text
def render(instance_type, broker_count, kafka_version, output_path):
"""Write a local, ready-to-deploy copy of the template with sizing baked in.
Reads the static source template internally, bakes the customer's sizing and the
computed fleet counts in as parameter Defaults, and writes the result to
output_path. The customer deploys from that local file; the skill source path is
never exposed.
The output path is resolved to an ABSOLUTE path (relative paths resolve against
the current working directory) and the resolved location is returned, so the
caller never has to guess where the file landed. As a safety rail, the resolved
path must NOT be inside the skill package -- that both keeps the skill source
clean and prevents the customer-facing artifact from ever pointing back at the
install directory.
"""
caps = compute(instance_type, broker_count, kafka_version)
# Resolve to absolute up front so the returned path is unambiguous regardless of
# the directory the script was launched from.
out = Path(output_path).expanduser().resolve()
skill_root = SOURCE_TEMPLATE.parent.parent # .../skills/migrate-to-msk
if out == skill_root or skill_root in out.parents:
raise ValueError(
f"refusing to write the rendered template inside the skill package "
f"({skill_root}); choose an output path under the customer's working "
f"directory instead, e.g. "
f"$(pwd)/migrate-to-msk-skill-artifacts/simulation/simulation-stack.yaml"
)
template_text = SOURCE_TEMPLATE.read_text()
baked = {
"InstanceType": instance_type,
"BrokerCount": broker_count,
"KafkaVersion": kafka_version,
"ClientInstanceType": caps["fleet_instance_type"],
"ProducerCount": caps["fleet_producer_count"],
"ConsumerCount": caps["fleet_consumer_count"],
}
for name, value in baked.items():
template_text = _set_param_default(template_text, name, value)
out.parent.mkdir(parents=True, exist_ok=True)
out.write_text(template_text)
return {
"output_path": str(out),
"deploy_command": (
f"aws cloudformation create-stack --stack-name msk-express-simulation "
f"--template-body file://{out} --capabilities CAPABILITY_IAM "
f"--region <region>"
),
"baked_parameters": baked,
"fleet_producer_count": caps["fleet_producer_count"],
"fleet_consumer_count": caps["fleet_consumer_count"],
"fleet_instance_type": caps["fleet_instance_type"],
}
def _check_range(name, val, lo, hi, errors):
if val < lo or (hi is not None and val > hi):
errors.append(f"{name}={val} is outside the allowed range [{lo}, {hi}]")
def _throughput_warnings(name, tput, sustained, max_quota, warnings):
"""Tiered throughput warning. Returns True if a degradation/throttle warning fired.
> max_quota -> cluster THROTTLES (hard ceiling; cannot be sustained).
> sustained -> performance DEGRADATION (elevated latency), but no throttling yet."""
if tput > max_quota:
warnings.append(
f"{name}={tput} MB/s exceeds the cluster's maximum ingress quota "
f"({max_quota} MB/s) — MSK Express throttles read/write traffic beyond this, "
f"so the cluster cannot actually sustain that rate."
)
return True
if tput > sustained:
warnings.append(
f"{name}={tput} MB/s is above the cluster's sustained/recommended ingress "
f"({sustained} MB/s); it can run but expect performance degradation "
f"(elevated latency), with no throttling until the {max_quota} MB/s ceiling."
)
return True
return False
def validate(test, config, caps):
"""caps = output of compute(). Returns {decision, errors, warnings}."""
errors: list[str] = []
warnings: list[str] = []
fleet_max = caps["fleet_max_mbps"]
sustained = caps["cluster_sustained_ingress_mbps"]
max_quota = caps["cluster_max_ingress_mbps"]
fleet_bw = caps["fleet_instance_bandwidth_mbps"]
fleet_prod = caps["fleet_producer_count"]
if test == "e2e_latency":
tput = config["throughput_mbps"]
dur = config["duration_minutes"]
prod = config["num_producers"]
cons = config["num_consumers"]
_check_range("throughput_mbps", tput, 1, fleet_max, errors)
_check_range("duration_minutes", dur, 5, 120, errors)
_check_range("num_producers", prod, 1, fleet_prod, errors)
_check_range("num_consumers", cons, 1, caps["fleet_consumer_count"], errors)
if not _throughput_warnings("throughput_mbps", tput, sustained, max_quota, warnings):
if tput > sustained * 0.6:
warnings.append(
f"throughput_mbps={tput} is above 60% of sustained ingress; high load "
f"can inflate latency. For a clean signal, consider <= {round(sustained * 0.5)} MB/s."
)
if prod < math.ceil(tput / fleet_bw):
warnings.append(
f"num_producers={prod} may not sustain {tput} MB/s; "
f"consider >= {math.ceil(tput / fleet_bw)} producers."
)
elif test == "broker_restart":
tput = config["target_throughput_mbps"]
dur = config["duration_minutes"]
reboot = config["reboot_at_minute"]
prod = config["num_producers"]
_check_range("target_throughput_mbps", tput, 1, fleet_max, errors)
_check_range("duration_minutes", dur, 10, 120, errors)
_check_range("reboot_at_minute", reboot, 2, dur - 2, errors)
_check_range("num_producers", prod, 1, fleet_prod, errors)
if not _throughput_warnings("target_throughput_mbps", tput, sustained, max_quota, warnings):
if tput > sustained * 0.6:
warnings.append(
f"target_throughput_mbps={tput} is above 60% of sustained ingress; "
"broker-CPU headroom during the restart is limited, so recovery may take longer."
)
if prod < math.ceil(tput / fleet_bw):
warnings.append(
f"num_producers={prod} may not sustain {tput} MB/s; "
f"consider >= {math.ceil(tput / fleet_bw)} producers."
)
else:
errors.append(f"unknown test {test!r}; valid: e2e_latency, broker_restart")
return {
"decision": "REJECT" if errors else "PASS",
"errors": errors,
"warnings": warnings,
}
def parse_args():
p = argparse.ArgumentParser(
description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter
)
sub = p.add_subparsers(dest="action", required=True)
c = sub.add_parser("compute", help="Emit derived sizing + per-test defaults/bounds.")
c.add_argument("--instance-type", default="express.m7g.4xlarge")
c.add_argument("--broker-count", type=int, default=12)
c.add_argument(
"--kafka-version",
default=None,
help="Optional. If given, rejected unless one of: " + ", ".join(SUPPORTED_KAFKA_VERSIONS),
)
r = sub.add_parser(
"render",
help="Write a local ready-to-deploy template with sizing baked in as Defaults.",
)
r.add_argument("--instance-type", required=True)
r.add_argument("--broker-count", type=int, required=True)
r.add_argument(
"--kafka-version",
required=True,
help="Required. One of: " + ", ".join(SUPPORTED_KAFKA_VERSIONS),
)
r.add_argument(
"--output",
required=True,
help="Path for the filled template. Resolved to an absolute path "
"(relative paths resolve against the current directory); pass an absolute "
"path under the customer's working directory, e.g. "
"$(pwd)/migrate-to-msk-skill-artifacts/simulation/simulation-stack.yaml. "
"Must not be inside the skill package.",
)
v = sub.add_parser("validate", help="Validate a proposed test config.")
v.add_argument("--test", required=True, choices=["e2e_latency", "broker_restart"])
v.add_argument("--config", required=True, help="JSON object of test parameters.")
v.add_argument("--instance-type", default="express.m7g.4xlarge")
v.add_argument("--broker-count", type=int, default=12)
return p.parse_args()
def main():
args = parse_args()
try:
if args.action == "render":
result = render(args.instance_type, args.broker_count, args.kafka_version, args.output)
print(json.dumps(result, indent=2))
return
# validate has no --kafka-version arg; getattr keeps the shared compute() call safe.
caps = compute(args.instance_type, args.broker_count, getattr(args, "kafka_version", None))
if args.action == "compute":
print(json.dumps(caps, indent=2))
else:
result = validate(args.test, json.loads(args.config), caps)
print(json.dumps(result, indent=2))
if result["decision"] == "REJECT":
sys.exit(1)
except (ValueError, KeyError, json.JSONDecodeError, OSError) as e:
print(json.dumps({"error": str(e)}), file=sys.stderr)
sys.exit(2)
if __name__ == "__main__":
main()
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs Python
Security
What our scanner noticed· Low risk
- Instructions that use the network
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- AWS
- Publisher
- AWS (Official)
- Source
- aws/agent-toolkit-for-aws · plugins/aws-data-analytics/skills/migrate-to-msk · commit 0a218f8
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- NOTICE (added by AutoGineer from NOTICE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- aws/agent-toolkit-for-aws
AutoGineer is not affiliated with or endorsed by AWS.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download migrate-to-msk.zip