AzureAzure Event GridApplication Integration

`azurerm_eventgrid_topic` cost estimation

A managed event-routing topic. Priced per million operations, with a generous free tier and no always-on cost.

An azurerm_eventgrid_topic is a managed endpoint for publish/subscribe event routing: publishers send events, Event Grid delivers them to subscribers with retries and filtering. The pricing is purely usage-based and refreshingly cheap, billed per operation.

An operation is an event ingress, a delivery attempt, an advanced filter match, or a delivery, billed at roughly $0.60 per million after the first 100,000 free each month. There is no provisioned capacity and no hourly fee, so a topic with no traffic costs nothing. Even busy event-driven systems often spend only a few dollars a month on Event Grid itself.

c3x prices the topic from the monthly operation volume you supply in c3x-usage.yml, applying the free-tier allowance. Without usage input the standing cost is zero, which is correct. The real cost of an event-driven architecture is almost always the handlers (Functions, Logic Apps, Service Bus) that the events trigger, not Event Grid's routing fee.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "azurerm_eventgrid_topic" "orders" {
  name                = "orders-events"
  resource_group_name = azurerm_resource_group.app.name
  location            = "eastus"

  input_schema = "EventGridSchema"
}

Pricing dimensions

What you actually pay for when you provision azurerm_eventgrid_topic.

Dimension	Unit	What's being charged
Operations	per million operations	Ingress, delivery attempts, filter matches, and deliveries. First 100,000/month free, then ~$0.60/million. Usage-based. $0.60 per million operations

Sample C3X output

Example output from c3x estimate (10M operations/month):

azurerm_eventgrid_topic.orders
└─ Operations               10  M-operations    $6.00

OVERALL TOTAL                                   $6.00

Optimization tips

Common ways to reduce azurerm_eventgrid_topic cost without changing the workload.

Filter at the subscription, not the handler

Wasted delivery operations

Each delivery is a billed operation, but so is invoking a handler that immediately discards the event. Server-side subscription filters avoid delivering (and paying for) events a subscriber doesn't want.

Batch events where the schema allows

Ingress operations

Publishing events in batches reduces ingress operation count for high-volume publishers. Combined with the free tier, many workloads stay near zero.

Watch the handlers, not the topic

Downstream handler cost

Event Grid is cents; the Functions, Logic Apps, or Service Bus queues it triggers are where real cost lives. Optimize handler runtime and downstream fan-out before the routing fee.

FAQ

How does c3x estimate Event Grid topic cost?

It prices the monthly operation volume you supply in c3x-usage.yml at ~$0.60/million after the 100,000 free operations. With no usage supplied the standing cost is zero, since Event Grid has no hourly fee.

Why does an Event Grid topic with no traffic cost nothing?

Event Grid has no provisioned capacity or always-on charge. You pay only per operation, so an idle topic incurs no cost.

What counts as an operation?

Event ingress, each delivery attempt, advanced filter evaluations, and successful deliveries. A single published event that fans out to several subscribers generates multiple operations.

What's usually the real cost in an Event Grid architecture?

The event handlers, Azure Functions, Logic Apps, or Service Bus, that the events trigger. Event Grid's per-operation fee is typically a rounding error next to handler compute.

How does this differ from a system topic or domain?

A custom topic (this resource) is one you publish to directly. System topics emit Azure resource events; domains group many topics for multi-tenant routing. All bill on the same per-operation model.