What is EC2 - Other in Cost Explorer? (2026)

EC2 - Other is not a service. It is a bucket Cost Explorer invents, it does not appear on your invoice, and on a mature account it is routinely the second or third largest line in the console. Everything in it is something you provisioned and probably forgot.

What is EC2 - Other in Cost Explorer?

It is a display grouping. The AWS page on the differences between Billing and Cost Explorer data is explicit that the two surfaces group charges differently: "With billing data, your AWS charges are grouped into AWS services on your invoice. To help with deep-dive analysis, Cost Explorer will group some costs differently."

It then names this exact split as the example. "Instead of a single group for Amazon EC2 costs, Cost Explorer will group costs into EC2 - Instances and EC2 - Other." The stated purpose is to let you compare compute against "ancillary cost, such as Amazon Elastic Block Store volumes or NAT gateways".

So EC2 - Other is defined by exclusion. It is every charge AWS bills under Amazon EC2 that is not an instance-hour. That is why it has no pricing page, no documentation page of its own, and no line on your bill. It is also why the same dollars are grouped under plain "Amazon Elastic Compute Cloud" on the invoice, which is the usual reason a Cost Explorer total and a CUR total disagree at the service level while agreeing overall.

What does EC2 - Other include?

AWS's own Cloud Financial Management team lists the contents in Optimize and save on "other" services: "Amazon EBS volumes and snapshots, elastic IP address, data transfer, NAT gateways, and more". In practice the bucket resolves into these meters.

Detailed monitoring is worth pricing out because it is enabled per instance and never appears as its own service. The CloudWatch pricing page linked above bills detailed monitoring as custom metrics at $0.30 per metric per month in the first tier, and its worked example assumes 7 metrics per instance: "If your application runs on 5 Amazon EC2 instances 24x7 for a 30-day month, and you enable EC2 Detailed Monitoring on all instances ... 35 * $0.30 = $10.50". That is $2.10 per instance per month, on the AWS example's own assumption. On 400 instances it is a $10,000 a year line item that nobody owns. The same page notes the metric count "is dependent on the EC2 instance type", so check yours rather than assuming 7.

How do you break down EC2 - Other costs?

Group by usage type. AWS gives the same answer: "You can view the details of your 'EC2-Other' spend by grouping with 'usage type' in Cost Explorer." Usage type is the only dimension that separates these meters, because they all share one service name.

aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["EC2 - Other"]}}'

Read the strings, not just the numbers. The AWS reference on understanding data transfer charges documents the naming, and one detail there catches people out: "Data transfer usage types that don't have the Region prefix, such as DataTransfer-Regional-Bytes or DataTransfer-Out-Bytes, represent data transfer from the US East (N. Virginia) Region." A bare string is not a global total. It is Northern Virginia.

How do you find EC2 - Other costs in the CUR?

Cost Explorer stops at usage type. It cannot tell you which volume, which gateway or which snapshot. For that you need resource IDs, which means the Cost and Usage Report with the INCLUDE_RESOURCES table configuration turned on. The CUR 2.0 table dictionary is direct about the trade: enabling it "causes the CUR 2.0 table to have a line item for each resource that incurred usage for a given service" and "can greatly increase the number of rows, and also the file size of your export."

We run this over a partitioned CUR in Athena. The query that actually answers "what is EC2 - Other" is three columns wide:

SELECT line_item_usage_type,
       line_item_resource_id,
       SUM(line_item_unblended_cost) AS cost
FROM   cur
WHERE  billing_period = '2026-05'
  AND  line_item_product_code = 'AmazonEC2'
  AND  line_item_usage_type NOT LIKE '%BoxUsage%'
  AND  line_item_usage_type NOT LIKE '%SpotUsage%'
GROUP  BY 1, 2
ORDER  BY cost DESC
LIMIT  50;

Excluding BoxUsage and SpotUsage is what reproduces the EC2 - Instances versus EC2 - Other split by hand, because AWS does not ship the split as a column. If your CUR is not queryable yet, the setup is in querying your CUR in Athena with no crawler. If your line_item_resource_id comes back empty, the resources table configuration is off.

How do you reduce EC2 - Other cost?

Rank the usage types first, then attack in that order. In every account we have looked at, the ranking is some permutation of four things.

Unattached EBS volumes and orphaned snapshots. A volume bills on provisioned size, not on use, so a detached one costs exactly what an attached one costs. Snapshots are subtler: the EBS snapshot documentation warns that "because snapshots are incremental, deleting a snapshot might not reduce your data storage costs". The AWS cost management post above names the specific trap: "when you deregister your AMI, but did not opt to delete the snapshot, that snapshot will persist and cause full storage charge". See what an EBS snapshot actually costs for how the chains bill.

Public IPv4 addresses. Charged at the same rate whether they are attached to anything or not, which makes an abandoned Elastic IP pure waste. AWS publishes a break-even formula for replacing them with a NAT Gateway, covered in what AWS charges for a public IPv4 address.

NAT Gateway processing. Two meters, and the hourly one bills an idle gateway at about $32.85 a month. Where the traffic is S3 or DynamoDB, a gateway VPC endpoint carries it for free and removes the processing charge entirely.

Cross-AZ traffic. Billed in both directions, which is the part people miss. See what cross-AZ data transfer costs.

Why doesn't EC2 - Other appear on your invoice?

Because it is a Cost Explorer construct and the invoice uses billing data, where all of it is grouped under Amazon Elastic Compute Cloud. The same AWS page notes a second regrouping in the opposite direction: "to help analyze data transfer costs, Cost Explorer groups your transfer costs by service. In billing data, data transfer costs are grouped into a single service named Data Transfer."

So the two surfaces disagree on where transfer belongs, in both directions, and neither is wrong. Reconcile at the account total, never at the service row. And pick your cost column deliberately while you are doing it, since Cost Explorer's default and your CUR's default are not the same measure. That choice is set out in which CUR cost column you should actually be summing.