Launching Ec2 Instance With Best Practices
Launch an EC2 instance through a guided AWS SOP with security-hardened defaults, IAM, sizing, and tagging before production traffic.
Overview
Launching EC2 Instance with Best Practices is an agent skill for the Operate phase that guides safe EC2 launches with hardened defaults, IAM, sizing, and tagging.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill launching-ec2-instance-with-best-practicesWhat is this skill?
- Single-message parameter intake for workload_type, region, and optional VPC/subnet context
- Workload-aware defaults for web, app, database, batch, dev, test, and bastion patterns
- Security hardening emphasis: IAM roles, least privilege, and sensible network posture
- Cost-conscious instance sizing suggestions tied to environment (default development)
- Comprehensive resource tagging aligned to AWS best-practice governance
- Seven example workload_type values including web-server, database, and bastion-host
- Required parameters: workload_type and region before the SOP proceeds
- Default environment parameter: development when not specified
Adoption & trust: 969 installs on skills.sh; 819 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need an EC2 instance quickly but lack confidence picking subnets, IAM roles, instance size, and security settings without a checklist.
Who is it for?
Solo builders provisioning AWS VMs for apps, bastions, or batch jobs who want the agent to enforce required inputs before any create API calls.
Skip if: Large orgs with mandatory Terraform/CloudFormation-only pipelines, or teams that already have blessed AMIs and zero interactive launches.
When should I use this skill?
You are ready to launch EC2 and can supply workload_type and region (plus optional VPC/subnet/environment) in one confirmed message.
What do I get? / Deliverables
You get a confirmed parameter set and a best-practice-aligned EC2 launch plan executed through the agent’s AWS toolkit workflow instead of ad-hoc console guessing.
- EC2 instance launched per workload-aware defaults
- IAM role and security posture aligned to the SOP
- Tagged instance metadata for cost and environment tracking
Recommended Skills
Journey fit
Operate infra is where solo builders provision and harden cloud servers they will run and maintain—not just sketch architecture. Infra is the canonical shelf for VPC/subnet placement, instance types, IAM roles, and security-group defaults on EC2.
How it compares
Use as a guided launch SOP—not a generic infrastructure-as-code generator or local Docker substitute.
Common Questions / FAQ
Who is launching-ec2-instance-with-best-practices for?
Indie developers and solo operators using AWS agent toolkits who need EC2 stood up with explicit workload context and security defaults.
When should I use launching-ec2-instance-with-best-practices?
During Operate infra when creating dev/staging/prod instances, bastion hosts, or workload-specific servers after you know region and workload_type.
Is launching-ec2-instance-with-best-practices safe to install?
Review Prism Security Audits and restrict AWS credentials to least-privilege roles; the skill can create billable cloud resources once parameters are confirmed.
SKILL.md
READMESKILL.md - Launching Ec2 Instance With Best Practices
# Launch EC2 Instance with Best Practices ## Overview This SOP provides a guided, safe approach to launching an EC2 instance with sensible defaults optimized for security, cost-efficiency, and AWS best practices. The SOP intelligently suggests defaults based on user context while ensuring security hardening, proper IAM roles, appropriate instance sizing, and comprehensive tagging. ## Parameters Prompt the user in a single message to provide all required parameters at once. Clearly list the required parameters and their descriptions, and include any optional parameters with their default values. Do not proceed until you have received and confirmed all required parameters. If any required parameter is missing or unclear, you MUST explicitly request the missing information before moving forward. - **workload_type** (required): The primary purpose of this instance (e.g., "web-server", "application-server", "database", "batch-processing", "development", "testing", "bastion-host") - **region** (required): The AWS region where the instance will be launched (e.g., "us-east-1", "eu-west-1", "ap-southeast-1") - **environment** (optional, default: "development"): The environment type (e.g., "production", "staging", "development", "testing") - **vpc_id** (optional): VPC ID where the instance should be launched (if not provided, will use default VPC) - **subnet_id** (optional): Subnet ID for instance placement (if not provided, will select appropriate subnet from VPC) - **services_needed** (optional): Comma-separated list of AWS services the instance needs to access (e.g., "s3,dynamodb,sqs") - **instance_name** (optional): Name tag for the instance (if not provided, will generate based on workload_type and environment) - **enable_public_ip** (optional, default: based on workload_type): Whether to assign a public IP address (true/false) - **root_volume_size** (optional, default: 20): Root volume size in GB (8-100 recommended based on workload) - **enable_monitoring** (optional, default: false): Enable detailed CloudWatch monitoring (costs extra, recommended for production) - **enable_termination_protection** (optional, default: based on environment): Enable termination protection (recommended for production) - **allow_ssh_from** (optional; required if `workload_type` is `bastion-host`): CIDR block to allow SSH access from (e.g., "203.0.113.25/32"). If omitted (and not bastion-host), SSH is disabled and access is via AWS Systems Manager Session Manager instead Only proceed to the steps below if you have all required information. ## 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. Analyze User Context and Set Intelligent Defaults Based on the provided parameters, determine appropriate defaults for unspecified options. **Constraints:** - You MUST analyze the `workload_type` to determine appropriate defaults: - **web-server**: t3.micro or t3.small, public IP enabled, HTTP/HTTPS ports, CloudWatch Logs access - **application-server**: t3.small or t3.medium, private subnet preferred, application ports, S3/CloudWatch access - **database**: t3.small or t3.medium (minimum), private subnet required, database ports, EBS-optimized, larger root volume (50GB+) - **batch-processing**: t3.medium or larger, private subnet, S3/SQS access, larger root volume (50GB+) - **development**: t3.micro or t3.small, public IP optional, broader security group, cost