How to Find AWS EC2 Instance Type Over SSH (6 Methods)

Quick take: The fastest one-liner is IMDSv2: curl -s -H "X-aws-ec2-metadata-token: $(curl -s -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 60')" http://169.254.169.254/latest/meta-data/instance-type. If you need something simpler for a quick check, cat /sys/class/dmi/id/product_name works on most HVM instances with no dependencies.

Introduction

Knowing the EC2 instance type from inside a running instance matters more than you might expect: deployment scripts that tune JVM heap sizes, kernel parameters, or concurrency settings based on instance size need to query the type at runtime. Incident responders triaging a performance issue need to confirm whether a system is on the expected instance family. Infrastructure auditing tools checking for right-sizing need to pull the type programmatically from each host.

You could look this up in the AWS Console or use the CLI from your workstation, but doing it over SSH from inside the instance itself — with no external context — is often faster and is a requirement for automation running on the instance. This guide covers all six reliable methods, from the official AWS recommendation down to the fallbacks that work when the metadata service isn't available.

Method 1: IMDSv2 (Recommended)

The AWS Instance Metadata Service v2 (IMDSv2) is the official, AWS-recommended way to query any instance metadata, including the instance type. It uses a session-oriented flow that adds protection against SSRF (Server-Side Request Forgery) attacks that could otherwise leak metadata to unauthorized code running on the instance.

How it works: You first PUT a request to /latest/api/token to obtain a short-lived session token, then include that token as a header in subsequent GET requests to the metadata endpoints.

# Step 1: Get the IMDSv2 session token (TTL: 6 hours)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2: Query the instance type endpoint
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-type

Example output:

m5.2xlarge

The 169.254.169.254 address is a link-local address accessible from within every EC2 instance. It does not require internet connectivity — it routes directly to the EC2 hypervisor's metadata service, not through any external network.

You can retrieve other useful metadata from the same endpoint family:

# Instance ID
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

# Availability Zone
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/availability-zone

# Region
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/region

# AMI ID
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/ami-id

Method 2: IMDSv1 (Legacy)

IMDSv1 is the original metadata service interface — a simple unauthenticated GET request with no session token. It still works on most instances unless an administrator has explicitly disabled it (which AWS now recommends). It's useful for quick manual checks or in environments where the curl version is old enough to make the PUT+header syntax awkward.

# IMDSv1: simple GET, no token required
curl -s http://169.254.169.254/latest/meta-data/instance-type

If the response is empty or you get a 401 error, IMDSv1 has been disabled on this instance and you must use IMDSv2. AWS recommends disabling IMDSv1 for security — SSRF vulnerabilities in web applications running on EC2 have been exploited to steal IAM credentials via the IMDSv1 endpoint.

Method 3: /sys/class/dmi/id/product_name

On HVM (Hardware Virtual Machine) EC2 instances, the kernel exposes DMI (Desktop Management Interface) data through the sysfs filesystem at /sys/class/dmi/id/. The product_name file directly contains the EC2 instance type string.

# Read instance type from sysfs DMI data
cat /sys/class/dmi/id/product_name

Example output:

m5.2xlarge

This method has zero external dependencies — it requires only a standard read permission on a sysfs file, no network access, no additional tools. It works on every modern Linux distribution running on HVM instances. The downside is it may not return the correct value on Graviton (ARM64) instances or older PV (Paravirtual) instance types where DMI data isn't exposed the same way.

# Check if the value looks like an EC2 instance type
# EC2 types follow the pattern: family.size (e.g., m5.xlarge, c7g.2xlarge)
cat /sys/class/dmi/id/product_name | grep -E '^[a-z][0-9a-z]+\.[a-z0-9]+$'

Method 4: dmidecode

dmidecode reads and parses the system's DMI/SMBIOS table, which on EC2 HVM instances is populated with instance metadata by the hypervisor. It requires root privileges.

# Query system product name via dmidecode
sudo dmidecode -s system-product-name

Example output:

m5.2xlarge

If dmidecode is not installed:

# Install on Debian/Ubuntu
sudo apt install dmidecode

# Install on RHEL/CentOS/Fedora
sudo dnf install dmidecode

# Install on Amazon Linux 2 / Amazon Linux 2023
sudo yum install dmidecode

You can also pull more system information useful for troubleshooting:

# Get full system information block
sudo dmidecode -t system

# Get CPU information as reported by DMI
sudo dmidecode -t processor

Note that dmidecode requires the sudo permission. In hardened environments where sudo is restricted, prefer the sysfs or IMDS methods.

Method 5: AWS CLI from Inside the Instance

If the AWS CLI is installed and the instance has an IAM role attached with at least ec2:DescribeInstances permission, you can query the EC2 API directly from inside the instance.

# Get the instance ID first (using IMDSv1 for brevity — replace with IMDSv2 in prod)
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

# Query EC2 API for instance type
aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].InstanceType' \
  --output text

Or more concisely using the instance identity document from IMDS:

# Get full instance identity document (JSON)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/dynamic/instance-identity/document \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['instanceType'])"

The AWS CLI method is the most verbose and requires both the CLI and appropriate IAM permissions, making it less suitable for quick checks but excellent for automation pipelines that already have CLI context set up.

Method 6: ec2metadata Tool

Some Amazon Linux AMIs and cloud-init configurations include an ec2metadata utility that wraps the IMDS endpoint in a simpler interface:

# Check if ec2metadata is available
which ec2metadata

# Query instance type
ec2metadata --instance-type

# Query multiple fields at once
ec2metadata --instance-type --instance-id --availability-zone

If the tool isn't available, install it via cloud-utils on Debian/Ubuntu:

sudo apt install cloud-utils
# The tool is then available as ec2metadata

On Amazon Linux, it may be included in the ec2-utils or cloud-init packages. This is the most human-friendly option for interactive use but has no advantage over the raw IMDSv2 curl command in scripts.

Quick Reference Comparison

The table below summarizes all six methods:

Using Instance Type in Scripts and Automation

The most robust pattern for scripting is to try IMDSv2 first and fall back to IMDSv1 if the token request fails (for backwards compatibility with environments that have disabled IMDSv2 token enforcement):

#!/bin/bash
get_instance_type() {
  local token
  # Try IMDSv2 first
  token=$(curl -s -m 2 -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 60" 2>/dev/null)

  if [ -n "$token" ]; then
    curl -s -m 2 -H "X-aws-ec2-metadata-token: $token" \
      "http://169.254.169.254/latest/meta-data/instance-type" 2>/dev/null
  else
    # Fall back to IMDSv1
    curl -s -m 2 "http://169.254.169.254/latest/meta-data/instance-type" 2>/dev/null
  fi
}

INSTANCE_TYPE=$(get_instance_type)

if [ -z "$INSTANCE_TYPE" ]; then
  # Fall back to sysfs DMI if IMDS is not reachable
  INSTANCE_TYPE=$(cat /sys/class/dmi/id/product_name 2>/dev/null)
fi

echo "Running on: ${INSTANCE_TYPE:-unknown}"

This pattern works even when the metadata service is temporarily unavailable (which can happen in rare EC2 maintenance events) by falling back to the DMI sysfs entry.

In configuration management tools like Ansible, you can use the amazon.aws.ec2_metadata_facts module, which wraps IMDSv2 and populates ansible_ec2_instance_type as a fact you can use in playbooks without any manual curl commands.

Final Thoughts

For any new code, use IMDSv2 — it's the AWS-supported path, works on every instance type and region, and adding the token step is trivial. Reserve the sysfs and dmidecode methods for environments where the metadata service is explicitly blocked or for diagnostic scripts where you want zero network dependency.

One final tip: if you're building infrastructure automation that checks instance type to make scaling or right-sizing decisions, also pull the instance identity document from http://169.254.169.254/latest/dynamic/instance-identity/document — it contains instanceType, region, availabilityZone, accountId, and architecture in a single JSON response, saving you multiple round trips to the IMDS endpoint.