AutoGineer
Generated banner for AWS Compute
Generated logo for AWS Compute

AWS Compute

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Provisions, scales, and operates Amazon EC2 virtual-machine workloads: instance-type selection (Graviton/Arm64, burstable T credits, GPU, instance store vs EBS), launch templates, Auto Scaling groups (scaling policies, instance refresh, mixed instances, Spot, warm pools, lifecycle hooks), IMDSv2, placement groups, Elastic IPs, AMI lifecycle, and Systems Manager fleet operations (Session Manager, Run Command, Patch Manager). Applies to EC2 instance and fleet questions, InsufficientInstanceCapacity, CPU-credit/surplus charges, IMDSv2 401s, instances stuck in Pending:Wait, ASG not replacing unhealthy instances, status-check failures, SSH refused/timed out, or instances missing as SSM managed nodes. For a single secure instance launch, the launching-ec2-instance-with-best-practices skill is more appropriate; for instance profiles, see setting-up-ec2-instance-profiles; for Image Builder, see amazon-ec2-image-builder. Does NOT cover Lambda, ECS/Fargate, EKS, VPC/ALB/NLB design, or IAM policy authoring.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides operational guidance for Amazon EC2, covering the full lifecycle of virtual machine workloads. It addresses instance-type selection, launch template configuration, Auto Scaling group (ASG) management, and fleet operations via AWS Systems Manager. It is designed to help users navigate common pitfalls like IMDSv2 configuration, health check settings, and cost-optimization strategies for burstable instances, while providing clear troubleshooting paths for connectivity, capacity, and status-check failures.

What it does

  • Guides instance-type selection including Graviton, GPU, and burstable T-series options.
  • Configures Auto Scaling groups with scaling policies, instance refresh, and lifecycle hooks.
  • Manages AMI lifecycles including deprecation, disabling, and cross-account sharing.
  • Facilitates fleet operations like patching and SSH-less access via Systems Manager.
  • Provides troubleshooting steps for common EC2 errors like InsufficientInstanceCapacity and status-check failures.
  • Enforces security best practices such as IMDSv2 and instance profile usage.

When to use it

  • When designing or scaling an EC2-based compute fleet.
  • When troubleshooting connectivity, capacity, or health check issues in an ASG.
  • When optimizing EC2 costs through instance-type selection or Spot instance usage.
  • When performing rolling updates or AMI migrations across a fleet.
  • When configuring secure, SSH-less management for private instances.

Advantages

  • Centralizes complex EC2 operational knowledge and common configuration pitfalls.
  • Provides actionable troubleshooting tables for rapid incident resolution.
  • Promotes security-first configurations like IMDSv2 and Session Manager.
  • Clarifies the distinction between deprecated and modern provisioning methods.
  • Offers clear guidance on cost-saving strategies like Graviton and Spot instances.

Usage examples

“How do I ensure my Auto Scaling group replaces instances that fail my load balancer health checks?”
The agent explains that ASGs ignore ELB health checks by default and provides the command to set --health-check-type ELB.
“My instances are stuck in Pending:Wait state, what is happening?”
The agent identifies that a lifecycle hook is likely waiting for a heartbeat and provides the command to complete the action.
“How can I safely roll out a new AMI to my existing fleet?”
The agent details the process of updating the launch template to a specific version and initiating an instance refresh.
“Why am I getting an InsufficientInstanceCapacity error?”
The agent clarifies that this is an AWS capacity issue in a specific AZ, not a user quota, and suggests trying a different AZ or instance type.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/aws/aws-compute/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip aws-compute.zip -d .agents/skills

Documentation by AWS

Amazon EC2 Compute

Best experience with the AWS MCP server; also works with the AWS CLI alone — no hard dependency on either.

Critical Warnings

Launch configurations are deprecated and do not support current EC2 instance types; new accounts cannot create them. Use launch templates for every new Auto Scaling group. See auto-scaling.md.

ASGs ignore ELB health checks by default: An Auto Scaling group only uses EC2 status checks unless you set --health-check-type ELB. Without it, instances failing the load balancer's health check stay in service forever. See auto-scaling.md.

IMDSv2 hop limit breaks containers: the default HttpPutResponseHopLimit of 1 makes the IMDSv2 token PUT response fail to reach a containerized process (the extra hop exceeds the response TTL), so the token request times out. Set HttpPutResponseHopLimit=2 for bridge/awsvpc container workloads. (If IMDSv2 is required, a subsequent tokenless GET returns 401; if optional, it silently falls back to IMDSv1.) See provisioning.md.

T3/T3a/T4g default to unlimited mode: Unlike T2 (standard), these burst without throttling but bill surplus CPU credits when 24h-average CPU exceeds baseline — a silent cost leak. See instance-selection.md.

Instance store is ephemeral: Data on instance store volumes is lost on stop, hibernate, terminate, instance-type change, and host failure — it survives only a reboot. Put anything durable on EBS/EFS/S3. See instance-selection.md.

Which do you need?

If you're deciding...Guidance
Instance family / size / Graviton / GPU / burstableinstance-selection.md — start with the workload→family table
How to define instances once and reuse (launch template)provisioning.md
How to run many instances that scale automaticallyauto-scaling.md
How to access/patch/manage instances without SSH keyssystems-manager.md

Quick Navigation

You want to...Go to
Pick an instance type, Graviton vs x86, burstable credits, GPU, instance store vs EBSinstance-selection.md
Create a launch template, user data, key pairs, IMDSv2, placement groups, Elastic IPsprovisioning.md
Set up or fix an Auto Scaling group, scaling policies, instance refresh, Spot, lifecycle hooksauto-scaling.md
Get SSH-less access, patch a fleet, or fix an instance not showing as a managed nodesystems-manager.md
Create, share, or retire (deprecate/disable/deregister) an AMIami-management.md
Fix something broken (can't connect, status-check fail, capacity error, stuck instances)troubleshooting.md

Common Workflows

"Stand up an autoscaling web fleet" → Create a launch template (AMI, type, IMDSv2), then an ASG referencing it with --health-check-type ELB and a target-tracking policy, see auto-scaling.md. For the public entry point, secure the load balancer (TLS/ACM, WAF, security response headers) per the Security Considerations below and the load-balancer notes in auto-scaling.md — the load-balancer build itself belongs to aws-networking.

"Roll out a new AMI to my fleet" → New launch template version → instance refresh; pin a numeric launch-template version so rollback works, see auto-scaling.md.

"Connect to a private instance without a bastion" → Give the instance SSM permissions (an instance profile with AmazonSSMManagedInstanceCore, or account-level DHMC) plus a network path, then use Session Manager, see systems-manager.md.

"Cut EC2 cost" → Right-size (burstable vs fixed-performance), Graviton where the app supports Arm64, Spot with price-capacity-optimized for fault-tolerant fleets, release idle Elastic IPs, see instance-selection.md.

Troubleshooting

SymptomLikely causeQuick fix
SSH "Connection timed out"Network path (SG/NACL/route/no public IP)Open TCP 22 from your IP; check route to IGW; verify public IP — see troubleshooting.md
SSH "Connection refused"Host: sshd down or still bootingWait for boot; check sshd/port via Session Manager or serial console
InsufficientInstanceCapacityAWS lacks capacity of that type in the AZ (NOT a quota)Try another AZ / instance type / retry; don't request a quota increase
InstanceLimitExceededvCPU quota reached (this IS a quota)Request a Service Quotas increase for the instance family
ASG never replaces LB-unhealthy instancesHealth check type still EC2Set --health-check-type ELB
Instances stuck in Pending:Wait, terminated after ~1hLifecycle hook never completed (heartbeat 3600s, default ABANDON)Call complete-lifecycle-action CONTINUE, or set DefaultResult CONTINUE
System status check failedAWS host/hardwareStop/start to migrate to new hardware (reboot won't)
Instance status check failedInstance OS/network configReboot or fix the OS/network config

Full tables and more errors in troubleshooting.md.

Security Considerations

  • Enforce IMDSv2 (HttpTokens=required) on launch templates to block SSRF-based credential theft; set the account-level default per Region (applies to new launches only).

  • Prefer Session Manager over inbound SSH — no open port 22, no key management, and a CloudTrail record of session API calls; enable Session Manager session logging to CloudWatch Logs/S3 (off by default) to capture the in-session commands themselves — see systems-manager.md.

  • Use instance profiles, never embedded credentials; scope the role to least privilege.

  • Encrypt EBS/AMIs; to share an encrypted AMI cross-account, re-encrypt under a customer-managed KMS key (the default aws/ebs key can't be shared).

  • Enable CloudTrail in all Regions to audit EC2/ASG/SSM API activity, and alarm on sensitive actions (security-group changes, RunInstances/TerminateInstances from unexpected principals) so unauthorized changes surface.

  • For public-facing web fleets, encrypt traffic in transit with an ACM certificate on the load balancer's HTTPS listener and add AWS WAF for defense in depth against common web exploits — the load-balancer/WAF setup itself lives in aws-networking.

  • For hardening beyond this guidance, see AWS EC2 security best practices and CIS Benchmarks for the guest OS.

Not Covered By This Skill

  • Launching a single hardened instance with best-practice defaults → use the launching-ec2-instance-with-best-practices skill

  • Creating IAM roles / instance profiles for EC2 → use the setting-up-ec2-instance-profiles skill

  • Building AMIs with an Image Builder pipeline → use the amazon-ec2-image-builder skill

  • Lambda / serverless → aws-serverless; ECS/Fargate → aws-containers; EKS/Kubernetes → kubernetes

  • VPC, subnets, ALB/NLB, endpoints → aws-networking or built-in knowledge

  • IAM policy logic and CloudWatch dashboards/agent setup → aws-iam, aws-observability

Files

references/ami-management.md

AMI Management

Overview

Creating, sharing, and retiring Amazon Machine Images. For building AMIs with an automated pipeline (recipes, components, distribution), use the amazon-ec2-image-builder skill — this reference covers the AMI lifecycle and sharing that a domain skill owns.

Create a custom AMI

aws ec2 create-image --instance-id <id> --name "my-app-v1" --description "..."

NoReboot defaults to false, so EC2 reboots the instance to guarantee a consistent file system. Setting --no-reboot skips that, and AWS cannot guarantee file-system integrity — only use it if you've quiesced/flushed the disk yourself.

The AMI's snapshots inherit the source volumes' encryption. Image from encrypted EBS volumes so the AMI is encrypted at rest; if the source is unencrypted, copy-image --encrypted --kms-key-id <customer-managed-key> produces an encrypted copy (also the prerequisite for cross-account sharing — see below).

Retire an AMI: deprecate vs disable vs deregister

These are three distinct actions with different reversibility — choosing the wrong one either fails to block launches or destroys the image.

ActionEffectStill launchable?Reversible?
Deprecate (enable-image-deprecation)Hides the AMI from describe-images listings and the console wizard for other accounts after a dateYes — anyone with the AMI ID can still launch; ASGs/launch templates keep using itYes (disable-image-deprecation)
Disable (disable-image)Sets state to disabled, blocks all new launches, and revokes launch permissions/sharingNoPartially — enable-image restores launchability, visibility, and shareability, but accounts/orgs/OUs that lost access when the AMI was disabled do NOT regain it automatically; you must re-grant launch permissions (re-share) via modify-image-attribute. (AMI tags are unaffected by disable/enable.)
Deregister (deregister-image)Permanently removes the AMINoOnly if a Recycle Bin retention rule was set beforehand

To block new launches while keeping the ability to restore, use disable-image — deprecate does not actually stop launch-by-ID, and deregister is effectively permanent.

Share an AMI cross-account / cross-region

Grant launch permission with modify-image-attribute (specific account IDs, an Organization/OU, or public).

Encrypted AMIs have a KMS catch: an AMI whose snapshots are encrypted with the default AWS-managed EBS key (aws/ebs) cannot be shared across accounts — the default service key is usable only within the owning account, so grantees can't decrypt the snapshots even with launch permission. To share an encrypted AMI:

  1. Re-encrypt the snapshots under a customer-managed KMS key (e.g., copy the AMI/snapshot specifying that key).

  2. Grant the target account permission on that customer-managed KMS key via the key policy: kms:DescribeKey, kms:Decrypt, kms:CreateGrant, kms:ReEncrypt*, kms:GenerateDataKey*.

  3. Add the account to the AMI's launch permissions.

KMS keys are Region-scoped, so copying/sharing an encrypted AMI to a different Region or account needs a customer-managed KMS key in each Region. To prevent accidental public exposure, enable AMI block public access at the account level (per Region; it doesn't retroactively unshare existing public AMIs).

Common Errors

Error/SymptomCauseFix
Target account can't launch a shared encrypted AMISnapshots use the default aws/ebs keyRe-encrypt under a customer-managed key and grant the account key access
Users still launch an AMI you "removed"Deprecation only hides; still launchable by IDUse disable-image to block launches (or deregister to delete)
Deregistered AMI can't be recoveredDeregister is permanent without Recycle BinPrefer disable-image to block reversibly; set Recycle Bin rules for critical AMIs
New AMI has a corrupt filesystem--no-reboot skipped the consistency rebootRecreate without --no-reboot, or flush/quiesce before imaging

Security Considerations

  • Cross-account sharing requires a customer-managed KMS key — snapshots under the default aws/ebs key can't be shared. Re-encrypt under a customer-managed key and grant the target account access to it in the key policy. See the "Share an AMI cross-account" section above for the full set of required KMS actions (kms:DescribeKey, kms:Decrypt, kms:CreateGrant, kms:ReEncrypt*, kms:GenerateDataKey*).

  • Enable AMI block public access at the account/Region level to prevent accidental public exposure of an image.

  • Scrub secrets before imaging — an AMI captures the source instance's disk, so remove anything sensitive first: shell history (~/.bash_history), long-lived credentials/API keys, SSH host keys and authorized_keys, and any secrets injected via user data or configuration management. Otherwise they are baked into every instance launched from the AMI (and into anyone you share it with).

  • Prefer reversible retirement — disable-image blocks launches and revokes sharing but is reversible; deregister-image is effectively permanent (only recoverable via a pre-set Recycle Bin rule). Reversible retirement matters for security investigations: if an image is later implicated in a discovered security event, a disabled AMI can be retained and restored for forensic analysis, whereas a deregistered one may be gone.

  • Audit AMI operations with CloudTrail — enable CloudTrail in all Regions and alarm on sensitive AMI actions (ModifyImageAttribute for sharing changes, DeregisterImage, DisableImage) to detect unauthorized cross-account sharing or destructive deregistration.

Related

  • The amazon-ec2-image-builder skill for automated AMI build pipelines

  • provisioning.md to reference the AMI in a launch template

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 Node.js

Security

No issues found by our static scan· No issues found

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 · skills/core-skills/aws-compute · 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 aws-compute.zip