Creating Api Gateway Stage
Provision an API Gateway stage with CloudWatch execution logs, access logging, stage variables, throttling, optional WAF, and IAM roles using AWS best practices.
Overview
Creating API Gateway Stage is an agent skill for the Operate phase that creates a REST API Gateway stage with logging, metrics, throttling, stage variables, IAM roles, and optional WAF using the AWS toolkit SOP.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill creating-api-gateway-stageWhat is this skill?
- Parameterized SOP for rest_api_id, stage_name, deployment_id, log_level, metrics, data trace, and throttling limits
- CloudWatch execution logging and access logging with configurable INFO/ERROR/OFF levels
- Optional WAF web ACL creation and association when enable_waf is true
- Dependency gate: requires call_aws in agent context before executing steps
- Stage variables and IAM roles aligned with AWS API Gateway logging best practices
- Optional defaults: log_level INFO, metrics_enabled true, throttling_rate_limit 1000, throttling_burst_limit 2000
Adoption & trust: 965 installs on skills.sh; 819 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a deployed REST API but no standardized stage with CloudWatch logging, throttling, and optional WAF for safe production exposure.
Who is it for?
Solo builders or small teams operating API Gateway on AWS who want a checklist-driven stage setup with logging and WAF in one agent session.
Skip if: Teams still designing the API contract, choosing compute (Lambda vs EC2), or who lack call_aws and an existing deployment_id.
When should I use this skill?
You need to create or reconfigure an API Gateway stage on an existing REST API with a known deployment_id and want logging, metrics, and optional WAF applied via the AWS agent toolkit.
What do I get? / Deliverables
After the SOP runs, a named stage is associated with your deployment_id with configured log levels, metrics, limits, and security associations ready for traffic.
- Configured API Gateway stage with logging and throttling settings
- IAM roles for logging where the SOP requires them
- Optional WAF web ACL associated to the stage
Recommended Skills
Journey fit
Canonical shelf is Operate because the SOP configures live API exposure, observability, and edge security for stages already tied to a deployment—not greenfield API design. Infra subphase fits REST API stage creation, logging IAM, metrics, X-Ray, and WAF association as production gateway plumbing.
How it compares
Use this SOP for stage-and-observability setup instead of generic Terraform snippets that omit API Gateway execution log IAM and access log formats.
Common Questions / FAQ
Who is creating-api-gateway-stage for?
Indie and solo builders (or tiny ops teams) running REST APIs on AWS API Gateway who need consistent dev, test, or prod stages with logging and optional WAF.
When should I use creating-api-gateway-stage?
Use it in Operate when attaching a new stage to a deployment before go-live, when enabling CloudWatch execution or access logs, or when tightening throttling and WAF on an existing API.
Is creating-api-gateway-stage safe to install?
It orchestrates real AWS changes via call_aws; review the Security Audits panel on this page and restrict IAM permissions before running in production accounts.
SKILL.md
READMESKILL.md - Creating Api Gateway Stage
# Create API Gateway Stage with Logging Configuration ## Overview This SOP creates an API Gateway stage with comprehensive logging configuration, stage variables, and necessary IAM roles. It follows AWS best practices for API Gateway stage setup including CloudWatch logging, X-Ray tracing, and proper access logging. ## Parameters - **rest_api_id** (required): The ID of the REST API for which to create the stage - **stage_name** (required): The name of the stage (e.g., dev, test, prod) - **deployment_id** (required): The deployment ID to associate with the stage - **log_level** (optional, default: "INFO"): The logging level for execution logs (OFF, ERROR, INFO) - **metrics_enabled** (optional, default: "true"): Whether to enable detailed CloudWatch metrics - **data_trace_enabled** (optional, default: "false"): Whether to enable data tracing for all methods - **throttling_rate_limit** (optional, default: "1000"): The throttling rate limit per second - **throttling_burst_limit** (optional, default: "2000"): The throttling burst limit - **enable_waf** (optional, default: "true"): Whether to create and associate a WAF web ACL for security ## Steps ### 1. Verify Dependencies Check for required tools and warn the user if any are missing. **Constraints:** - You MUST verify the following tools are available in your context: `call_aws` - You MUST ONLY check for tool existence and MUST NOT attempt to run the tools because running tools during verification could cause unintended side effects, consume resources unnecessarily, or trigger actions before the user is ready - You MUST inform the user about any missing tools with a clear message - You MUST ask if the user wants to proceed anyway despite missing tools - You MUST respect the user's decision to proceed or abort ### 2. Validate API Gateway Resources Verify that the specified REST API and deployment exist. **Constraints:** - You MUST inform the customer that you are validating the REST API and deployment existence - You MUST use `call_aws` to describe the REST API using: `aws apigateway get-rest-api --rest-api-id {rest_api_id}` - You MUST use `call_aws` to verify the deployment exists using: `aws apigateway get-deployment --rest-api-id {rest_api_id} --deployment-id {deployment_id}` - You MUST stop execution and inform the user if either resource does not exist - You MUST NEVER use positional arguments that require local files or filesystem access ### 3. Check Existing CloudWatch Logs IAM Role Verify if API Gateway has the necessary IAM role for CloudWatch logging. **Constraints:** - You MUST inform the customer that you are checking for existing CloudWatch logging IAM role configuration - You MUST use `call_aws` to check the account settings: `aws apigateway get-account` - You MUST examine the `cloudwatchRoleArn` field in the response - You SHOULD note if the role is already configured or needs to be created ### 4. Create CloudWatch Logs IAM Role (if needed) Create the IAM role for API Gateway CloudWatch logging if it doesn't exist. **Constraints:** - You MUST inform the customer that you are creating the CloudWatch logs IAM role if none exists - You MUST create the role with the following trust policy allowing apigateway.amazonaws.com to assume it: `{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"apigateway.amazonaws.com"},"Action":"sts:AssumeRole"}]}` - You MUST use `call_aws` with: `aws iam create-role --role-name APIGatewayCloudWatchLogsRole --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"apigateway.amazonaws.com"},"Action":"sts:AssumeRole"}]}'` - You MUST attach the AWS managed policy for CloudWatch logs: `aws iam attach-role-policy --role-name APIGatewayCloudWatchLogsRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs` - You MUST NEVER use passwords and always rely on IAM roles and policies for authentication - You MUST skip this s