Nmap Cloud Scanning: Map AWS, Azure, GCP Infrastructure (2026)

The most surprising thing about cloud infrastructure scanning is that it’s not fundamentally different from scanning your own datacenter, but the access and permissions are entirely different beasts.

Let’s see Nmap in action against an AWS EC2 instance. First, ensure you have the Nmap script engine (NSE) installed, as many cloud-specific scripts rely on it.

# Scan a public EC2 instance's open ports
nmap -sV -p- 1.2.3.4

# Scan for AWS-specific metadata services (requires running *within* the VPC or from a compromised instance)
nmap -p 80,443,8080,8443 --script aws-metadata 1.2.3.4

The aws-metadata script, for instance, attempts to query the EC2 instance metadata service (IMDS) on 169.254.169.254. If successful, it can reveal instance IDs, security group memberships, IAM roles, and even temporary security credentials if the IMDSv1 is accessible. This is a critical reconnaissance step for understanding an attacker’s potential lateral movement or an auditor’s view of your cloud posture.

The Problem: Visibility in Ephemeral Environments

Cloud environments are dynamic. Servers spin up and down, IP addresses change, and security groups are modified constantly. Traditional network mapping tools struggle with this ephemeral nature. Nmap, when properly configured and authorized, provides a consistent way to inventory and assess the security posture of cloud assets, much like it does on-premises. The core challenge is bridging the gap between your local machine (or a dedicated scanning VM) and the cloud provider’s network, and then gaining the necessary permissions to perform meaningful scans.

How it Works: Bridging the Network and Gaining Access

For cloud scanning, you’re typically interacting with your cloud provider’s API to orchestrate the scans or directly scanning public-facing IP addresses.

Public IP Scanning: This is the most straightforward. You run Nmap from your workstation or a cloud-based VM against the public IP addresses of your cloud resources (e.g., EC2 instances, Load Balancers, RDS instances). This reveals open ports and services accessible from the internet.
- Command: nmap -sT -p 22,80,443,3306,5432 --script http-enum,ssl-enum-ciphers <public_ip>
- Why it works: Standard TCP connect scan (-sT) attempts to establish a full connection to each port. The NSE scripts (--script) extend this by checking for common web vulnerabilities or enumerating SSL/TLS cipher suites.
Private IP Scanning (within the VPC/VNet): To scan private subnets, you need to run Nmap from within the cloud environment. This usually means launching an EC2 instance (AWS), a VM (Azure), or a Compute Engine instance (GCP) in the same VPC/VNet as the targets. You then SSH into this "scanner instance" and run Nmap.
- Command (from scanner instance): nmap -sV -p 10.0.0.0/24 --script discovery,smb-os-discovery
- Why it works: Running Nmap from within the private network bypasses the need for complex routing or VPNs to reach internal IPs. The smb-os-discovery script can help identify Windows machines and their operating systems.
Cloud Provider API Integration (NSE Scripts): Nmap has a growing collection of NSE scripts designed to interact with cloud provider APIs. These scripts can query metadata services, list resources, and sometimes even initiate scans.
- AWS Example (EC2): nmap -p 80 --script aws-ec2-info <public_ip>
- Why it works: This script uses the AWS SDK (if configured with credentials) to query AWS APIs for information about the EC2 instance associated with the target IP. It can reveal tags, instance type, and more, without needing direct network access to metadata endpoints.

Controlling the Scan

The primary levers you control are:

Target Selection: IPs, CIDR ranges, or hostnames. For cloud, this means knowing your public IP allocation and internal VPC/VNet address space.
Port Specification: -p- for all 65535 ports, or specific ranges like -p 22,80,443.
Scan Techniques: -sT (TCP connect), -sS (SYN scan - often requires root/administrator), -sU (UDP scan).
Service/Version Detection: -sV attempts to determine service versions.
OS Detection: -O attempts to guess the operating system.
NSE Scripts: --script <script_name or category> is where cloud-specific magic happens. Look for scripts prefixed with aws-, azure-, gcp-, or categories like discovery, vuln.

One powerful but often overlooked aspect is using Nmap’s --script-args to fine-tune NSE script behavior. For example, many cloud scripts can accept region names, credentials (though this is generally discouraged for security reasons; prefer IAM roles or instance profiles), or specific resource identifiers to narrow down their queries.

The next hurdle you’ll likely face is understanding the nuances of credential management when using NSE scripts that interact with cloud APIs directly.