{"id":455,"date":"2026-04-14T03:04:28","date_gmt":"2026-04-14T03:04:28","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-event-grid-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-integration\/"},"modified":"2026-04-14T03:04:28","modified_gmt":"2026-04-14T03:04:28","slug":"azure-event-grid-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-integration","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-event-grid-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-integration\/","title":{"rendered":"Azure Event Grid Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Integration"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Integration<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure <strong>Event Grid<\/strong> is a fully managed <strong>event routing<\/strong> service that helps you connect systems using an <strong>event-driven<\/strong> (reactive) architecture. Instead of services constantly polling for changes or building brittle point-to-point integrations, producers emit events (for example, \u201cblob created\u201d or \u201cresource group deleted\u201d) and Event Grid reliably routes those events to subscribers (for example, Azure Functions, Logic Apps, Service Bus, or a webhook).<\/p>\n\n\n\n<p>In simple terms: <strong>something happens<\/strong>, Event Grid <strong>detects or receives an event<\/strong>, and then <strong>delivers<\/strong> that event to one or more destinations so downstream automation can run quickly and independently.<\/p>\n\n\n\n<p>Technically, Event Grid implements a pub\/sub pattern using <strong>topics<\/strong> (where events are published) and <strong>event subscriptions<\/strong> (rules that define which events go where). It supports Azure-native event sources (like Storage and Azure Resource Manager), custom application events, filtering, retries, dead-lettering, and multiple delivery targets. It is designed for high fan-out, low operational overhead, and clean separation of concerns across microservices and automation.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> Event Grid solves the integration challenge of reliably reacting to changes across Azure services and your own applications\u2014without tightly coupling systems, building custom polling, or maintaining always-on message routers for simple event notifications.<\/p>\n\n\n\n<blockquote>\n<p>Service status \/ naming: <strong>Azure Event Grid<\/strong> is an active Azure Integration service and the current official name is <strong>Event Grid<\/strong>. (Always verify recent changes in the official docs if you\u2019re reading this long after publication.)<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Event Grid?<\/h2>\n\n\n\n<p><strong>Official purpose:<\/strong> Event Grid is Azure\u2019s event routing service for building event-driven architectures. It enables publishers to emit discrete events and subscribers to receive those events through push-based delivery to supported endpoints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Event ingestion<\/strong> from:<\/li>\n<li><strong>Azure services<\/strong> (system events) such as Azure Storage, Azure Resource Manager, and many others<\/li>\n<li><strong>Custom applications<\/strong> (custom topics)<\/li>\n<li><strong>Partner\/SaaS systems<\/strong> (partner events\/topics, where available)<\/li>\n<li><strong>Event routing<\/strong> to multiple subscribers with:<\/li>\n<li><strong>Filtering<\/strong> (by event type, subject patterns, and advanced filters)<\/li>\n<li><strong>Retry policies<\/strong> and <strong>dead-lettering<\/strong><\/li>\n<li><strong>Fan-out<\/strong> to many handlers<\/li>\n<li><strong>Schema support<\/strong> including:<\/li>\n<li><strong>Event Grid event schema<\/strong><\/li>\n<li><strong>CloudEvents 1.0<\/strong> (an industry standard format)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (mental model)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Component<\/th>\n<th>What it is<\/th>\n<th>Why it matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Event source<\/strong><\/td>\n<td>Something that emits events (e.g., Storage account, your app)<\/td>\n<td>Drives automation based on real changes<\/td>\n<\/tr>\n<tr>\n<td><strong>Topic<\/strong><\/td>\n<td>A named endpoint that receives events<\/td>\n<td>Logical boundary for publishers and subscribers<\/td>\n<\/tr>\n<tr>\n<td><strong>System topic<\/strong><\/td>\n<td>A topic representing events from an Azure resource<\/td>\n<td>Simplifies subscribing to Azure service events<\/td>\n<\/tr>\n<tr>\n<td><strong>Custom topic<\/strong><\/td>\n<td>A topic you create for your own app events<\/td>\n<td>Lets you build your own event-driven contracts<\/td>\n<\/tr>\n<tr>\n<td><strong>Partner topic<\/strong><\/td>\n<td>A topic fed by a partner\/SaaS integration (when offered)<\/td>\n<td>Consumes external events in a standardized way<\/td>\n<\/tr>\n<tr>\n<td><strong>Event subscription<\/strong><\/td>\n<td>A routing rule: filter + destination<\/td>\n<td>Connects events to handlers safely and cleanly<\/td>\n<\/tr>\n<tr>\n<td><strong>Event handler<\/strong><\/td>\n<td>Destination endpoint (Function, Logic App, webhook, etc.)<\/td>\n<td>Where work actually happens<\/td>\n<\/tr>\n<tr>\n<td><strong>Dead-letter destination<\/strong><\/td>\n<td>Storage location for undeliverable events<\/td>\n<td>Prevents silent loss and supports replay workflows<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed event routing \/ event notification<\/strong> service (pub\/sub).<\/li>\n<li>Push-based delivery to handlers (Event Grid attempts delivery; handlers must be reachable and respond correctly).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope and geography (how it\u2019s deployed)<\/h3>\n\n\n\n<p>Event Grid resources (topics, system topics, event subscriptions) are created in an <strong>Azure subscription<\/strong> and typically associated with an <strong>Azure region<\/strong> (resource location). Events can be delivered to endpoints in the same region or different regions, but latency, compliance, and network controls should be evaluated.<\/p>\n\n\n\n<p>Because Azure capabilities can vary by region and cloud (public vs sovereign), <strong>verify region availability<\/strong> for specific event sources\/handlers in the official documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Fit in the Azure ecosystem<\/h3>\n\n\n\n<p>Event Grid is part of Azure\u2019s <strong>Integration<\/strong> portfolio and is commonly used alongside:\n&#8211; <strong>Azure Functions<\/strong> and <strong>Logic Apps<\/strong> for serverless automation\n&#8211; <strong>Azure Service Bus<\/strong> for durable command\/message processing\n&#8211; <strong>Azure Event Hubs<\/strong> for high-throughput streaming ingestion\n&#8211; <strong>Azure Monitor<\/strong> \/ <strong>Log Analytics<\/strong> for observability\n&#8211; <strong>Azure Storage<\/strong> for dead-lettering and event-driven file workflows\n&#8211; <strong>Azure API Management<\/strong> and microservices platforms (AKS) for application integration<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Event Grid?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time-to-automation:<\/strong> React immediately to business events (order created, file uploaded, VM started).<\/li>\n<li><strong>Reduced integration cost:<\/strong> Avoid building custom polling services and point-to-point integrations.<\/li>\n<li><strong>Better agility:<\/strong> Add new subscribers without changing producers, enabling safer iteration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Decoupling:<\/strong> Producers don\u2019t need to know about consumers.<\/li>\n<li><strong>Fan-out:<\/strong> One event can trigger multiple independent actions.<\/li>\n<li><strong>Filtering:<\/strong> Route only relevant events (by type, subject, and advanced filters).<\/li>\n<li><strong>Standardization:<\/strong> CloudEvents support helps define consistent event contracts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Fully managed:<\/strong> No broker cluster to patch, scale, or shard for typical event notification patterns.<\/li>\n<li><strong>Reliable delivery attempts:<\/strong> Built-in retries and optional dead-lettering.<\/li>\n<li><strong>Native Azure integration:<\/strong> Many Azure services emit events without additional agents.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security \/ compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Integrates with Azure identity and access control patterns (for example, Azure RBAC where supported).<\/li>\n<li>Supports secure endpoint patterns (private networking options depend on endpoint type and your architecture).<\/li>\n<li>Provides auditability through Azure monitoring and diagnostic logs (where enabled).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability \/ performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Designed for high-scale, low-latency event routing.<\/li>\n<li>Supports large fan-out patterns (many subscriptions) without building your own routing tier.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Event Grid<\/h3>\n\n\n\n<p>Choose Event Grid when you need:\n&#8211; <strong>Event notification<\/strong> (\u201csomething happened\u201d) rather than streaming analytics or transactional queuing\n&#8211; Many subscribers, loose coupling, and quick reactions\n&#8211; Azure-native event sources (Storage events, resource lifecycle events, etc.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose Event Grid<\/h3>\n\n\n\n<p>Avoid (or pair with other services) when you need:\n&#8211; <strong>Ordered processing<\/strong>, strict FIFO, sessions, or transactions \u2192 consider <strong>Azure Service Bus<\/strong>\n&#8211; <strong>Very high-throughput telemetry streaming<\/strong> and long retention \u2192 consider <strong>Azure Event Hubs<\/strong>\n&#8211; Complex orchestration with human approvals and long-running workflows \u2192 consider <strong>Logic Apps<\/strong> (possibly triggered by Event Grid)\n&#8211; Pull-based consumption semantics (Event Grid is primarily push delivery) \u2192 consider Service Bus\/Event Hubs if you need consumers to pull at their own pace<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Event Grid used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Retail\/e-commerce:<\/strong> order events, inventory updates, file-based catalog ingestion<\/li>\n<li><strong>Finance\/insurance:<\/strong> document ingestion, audit-triggered workflows, compliance automation<\/li>\n<li><strong>Healthcare\/life sciences:<\/strong> secure file processing pipelines, data lifecycle events<\/li>\n<li><strong>Media &amp; entertainment:<\/strong> video upload workflows, encoding triggers, metadata updates<\/li>\n<li><strong>Manufacturing\/IoT backends:<\/strong> device events routed into processing pipelines (often combined with IoT services and messaging)<\/li>\n<li><strong>SaaS\/platform providers:<\/strong> multi-tenant event-driven integrations and webhook replacement patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Application developers building microservices<\/li>\n<li>DevOps\/SRE teams automating operations and remediation<\/li>\n<li>Data engineering teams triggering pipelines from file drops<\/li>\n<li>Platform engineering teams building internal integration platforms<\/li>\n<li>Security engineering teams automating detection\/response workflows<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Event-driven microservices<\/li>\n<li>Serverless automation and background processing<\/li>\n<li>\u201cLanding zone\u201d automation (policy, tags, governance triggers)<\/li>\n<li>Content and document processing pipelines<\/li>\n<li>GitOps and CI\/CD adjunct automation (for example, triggering actions when artifacts land in storage)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> event routing for critical workflows with dead-lettering and monitoring<\/li>\n<li><strong>Dev\/test:<\/strong> integration testing of event-driven components; validating filters, schemas, and idempotency<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic ways teams use Azure Event Grid in production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Blob upload triggers processing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Files land in Azure Storage; you need to validate, virus-scan, transform, or index them.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Storage emits native BlobCreated events; Event Grid routes to Functions\/Logic Apps quickly.<\/li>\n<li><strong>Example:<\/strong> A PDF uploaded to <code>inbox\/<\/code> triggers a Function that extracts text and stores it in Azure AI Search.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Event-driven data pipeline kickoffs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Data pipelines start late because they poll for new data.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Event-driven triggers eliminate polling and reduce compute waste.<\/li>\n<li><strong>Example:<\/strong> When a new parquet file lands, Event Grid triggers a workflow that starts an Azure Data Factory pipeline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Automated governance on Azure resource changes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams create resources without tags, naming rules, or security configuration.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Azure Resource Manager emits resource lifecycle events.<\/li>\n<li><strong>Example:<\/strong> On \u201cresource created\u201d events, a Logic App checks required tags and opens a ticket or remediates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Cache invalidation for web applications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Content updates require manual cache purge or slow TTL-based expiry.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Content changes emit events; subscribers purge caches immediately.<\/li>\n<li><strong>Example:<\/strong> Uploading a new image triggers a Function to invalidate CDN paths.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Fan-out notifications to many systems<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> One business event must notify multiple downstream systems without tight coupling.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> One-to-many routing via multiple event subscriptions.<\/li>\n<li><strong>Example:<\/strong> \u201cOrderCreated\u201d is delivered to billing, shipping, analytics, and customer-notification services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Security automation on suspicious changes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Critical configuration changes need rapid detection and response.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Can route resource events to automation handlers; supports quick response loops.<\/li>\n<li><strong>Example:<\/strong> If a public IP is attached to a protected subnet, Event Grid triggers remediation and alerts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) CI\/CD environment automation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Environments need post-deployment configuration steps that should run automatically.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Publish custom events at pipeline milestones; route to automation.<\/li>\n<li><strong>Example:<\/strong> After deployment, a pipeline publishes an event that triggers smoke tests and config updates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) SaaS integration without exposing internal services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> External systems need notifications, but you don\u2019t want to open internal services broadly.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> You can centralize outbound notifications and control destinations.<\/li>\n<li><strong>Example:<\/strong> Publish \u201cInvoicePaid\u201d events to a webhook endpoint owned by a trusted SaaS integration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Central event backbone for microservices (lightweight)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams need an event backbone but don\u2019t want to run Kafka for simple notifications.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Managed routing; pair with Service Bus for durable commands if needed.<\/li>\n<li><strong>Example:<\/strong> Microservices publish domain events to a custom topic; multiple Functions subscribe.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Multi-tenant event routing (logical isolation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multi-tenant SaaS needs to route events to tenant-specific handlers safely.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Topics\/domains and subscription filters can separate tenant traffic patterns.<\/li>\n<li><strong>Example:<\/strong> Events include tenant ID; subscriptions route only a tenant\u2019s events to its processing function.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Operational automation and self-healing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Operations teams want automatic remediation when known error signals happen.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Route signals\/events to automation quickly; pair with monitoring alerts.<\/li>\n<li><strong>Example:<\/strong> A monitoring system publishes \u201cCPUHot\u201d events; a Function scales out a service or opens an incident.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Document approval workflows (with orchestration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Approval workflows need a trigger when new content arrives.<\/li>\n<li><strong>Why Event Grid fits:<\/strong> Use Event Grid as the trigger; use Logic Apps for the orchestration steps.<\/li>\n<li><strong>Example:<\/strong> New contract uploaded \u2192 Logic App requests approval \u2192 upon approval triggers signing process.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on widely used, current Event Grid capabilities. For features that vary by region, endpoint type, or subscription, <strong>verify in official docs<\/strong> before standardizing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Topics (custom, system, partner)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides a logical endpoint for events. System topics represent Azure resource events; custom topics are for your own events; partner topics are for supported partner integrations.<\/li>\n<li><strong>Why it matters:<\/strong> Establishes clear boundaries between producers and consumers.<\/li>\n<li><strong>Practical benefit:<\/strong> Teams can add\/remove subscribers without modifying publishers.<\/li>\n<li><strong>Caveats:<\/strong> Availability of system\/partner events varies by service and region\u2014verify supported event sources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Event subscriptions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines routing rules: which events to accept (filters) and where to deliver them (handler).<\/li>\n<li><strong>Why it matters:<\/strong> Enables fan-out and independent evolution of subscribers.<\/li>\n<li><strong>Practical benefit:<\/strong> One event stream can serve multiple apps and teams safely.<\/li>\n<li><strong>Caveats:<\/strong> Subscriptions have quotas and limits; check Azure limits documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Filtering (basic + advanced)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Filters on event type, subject prefix\/suffix, and other event properties (advanced filters).<\/li>\n<li><strong>Why it matters:<\/strong> Prevents unnecessary downstream invocations and reduces noise\/cost.<\/li>\n<li><strong>Practical benefit:<\/strong> A single topic can serve many workflows without each handler doing its own filtering.<\/li>\n<li><strong>Caveats:<\/strong> Filtering capabilities depend on schema and event fields; design event contracts carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Delivery to multiple handler types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Delivers events to supported endpoints such as Azure Functions, Logic Apps, webhooks, and Azure messaging services (supported types vary; verify current list).<\/li>\n<li><strong>Why it matters:<\/strong> Lets you choose the right compute\/messaging target per workload.<\/li>\n<li><strong>Practical benefit:<\/strong> Use Functions for code, Logic Apps for workflows, Service Bus for durable processing, etc.<\/li>\n<li><strong>Caveats:<\/strong> Some endpoints require specific authentication or networking configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Retry policy and at-least-once delivery<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Event Grid retries deliveries when endpoints fail, supporting at-least-once semantics.<\/li>\n<li><strong>Why it matters:<\/strong> Improves reliability without building custom retry loops.<\/li>\n<li><strong>Practical benefit:<\/strong> Temporary endpoint failures don\u2019t cause immediate data loss.<\/li>\n<li><strong>Caveats:<\/strong> At-least-once means duplicates are possible; subscribers must be idempotent. Ordering is not guaranteed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dead-lettering<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Stores events that couldn\u2019t be delivered after retries in a Storage destination (dead-letter).<\/li>\n<li><strong>Why it matters:<\/strong> Prevents silent loss of events and enables investigation\/replay patterns.<\/li>\n<li><strong>Practical benefit:<\/strong> Operations teams can inspect failed deliveries and reprocess.<\/li>\n<li><strong>Caveats:<\/strong> Dead-letter storage costs money and requires lifecycle management and security controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Event schemas: Event Grid schema and CloudEvents 1.0<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides standardized structure for events; CloudEvents improves portability.<\/li>\n<li><strong>Why it matters:<\/strong> Consumers can parse events consistently; governance and tooling become easier.<\/li>\n<li><strong>Practical benefit:<\/strong> Easier to build shared libraries and validation.<\/li>\n<li><strong>Caveats:<\/strong> Don\u2019t break contracts\u2014version events instead of changing fields in-place.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Validation handshake for webhooks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> When using webhook destinations, Event Grid performs a validation handshake to prove the endpoint controls the URL.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents accidental routing to an endpoint that isn\u2019t prepared for Event Grid.<\/li>\n<li><strong>Practical benefit:<\/strong> Safer webhook setup and less misconfiguration.<\/li>\n<li><strong>Caveats:<\/strong> Your webhook must implement the expected validation response behavior (framework samples help).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Managed integration with Azure services (system events)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Many Azure services emit events without you writing producers.<\/li>\n<li><strong>Why it matters:<\/strong> Enables automation on resource and data changes.<\/li>\n<li><strong>Practical benefit:<\/strong> Storage events, resource events, and other service events can trigger workflows rapidly.<\/li>\n<li><strong>Caveats:<\/strong> Each source has its own event schema details and constraints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Observability hooks (metrics, diagnostics)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Integrates with Azure Monitor metrics and diagnostic logs (capabilities vary by resource type).<\/li>\n<li><strong>Why it matters:<\/strong> You need to detect delivery failures, throttling, and unusual patterns.<\/li>\n<li><strong>Practical benefit:<\/strong> Build dashboards and alerts for delivered\/failed\/dead-lettered events.<\/li>\n<li><strong>Caveats:<\/strong> Diagnostic settings must be explicitly enabled; retention costs apply in Log Analytics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Private connectivity options (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports private endpoints\/Private Link patterns for some Event Grid resources and\/or integrations (verify specifics in docs).<\/li>\n<li><strong>Why it matters:<\/strong> Reduces public internet exposure.<\/li>\n<li><strong>Practical benefit:<\/strong> Aligns with enterprise network security requirements.<\/li>\n<li><strong>Caveats:<\/strong> Private networking support depends on the Event Grid resource type and the destination type.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Event Grid implements a publish\/subscribe routing plane:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Producer<\/strong> emits an event to a <strong>topic<\/strong> (custom topic) or Azure emits to a <strong>system topic<\/strong>.<\/li>\n<li>Event Grid evaluates <strong>event subscriptions<\/strong> attached to that topic:\n   &#8211; filter rules\n   &#8211; event types\n   &#8211; subject prefix\/suffix<\/li>\n<li>For matching subscriptions, Event Grid attempts delivery to the configured <strong>event handler<\/strong>.<\/li>\n<li>If delivery fails, Event Grid retries based on policy. If still failing and configured, it writes to <strong>dead-letter<\/strong> storage.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Data flow vs control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: Creating topics, subscriptions, setting filters, and enabling diagnostics via ARM\/Portal\/CLI.<\/li>\n<li><strong>Data plane<\/strong>: Publishing events and delivering them to handlers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common patterns:\n&#8211; <strong>Event Grid \u2192 Azure Functions<\/strong>: serverless compute on event arrival\n&#8211; <strong>Event Grid \u2192 Logic Apps<\/strong>: workflow automation and connectors\n&#8211; <strong>Event Grid \u2192 Service Bus \/ Event Hubs<\/strong> (when supported): durable processing or streaming fan-in\n&#8211; <strong>Event Grid + Storage<\/strong>: file-based workflows and dead-letter storage<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security \/ authentication model (overview)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Publishing<\/strong> to custom topics can be secured using supported auth methods (commonly keys and\/or Azure AD depending on configuration\u2014verify current options for your topic type).<\/li>\n<li><strong>Delivery<\/strong> to Azure services often uses Azure AD \/ managed identity patterns or service integration, depending on destination type.<\/li>\n<li><strong>Webhooks<\/strong> must be publicly reachable unless fronted by a service that can receive from Event Grid; secure with HTTPS and supported auth patterns (and validate webhook events).<\/li>\n<\/ul>\n\n\n\n<p>Because authentication varies significantly by handler type, treat identity configuration as a first-class design item and validate against the official handler documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (overview)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Event Grid is a managed service. Your topic is an Azure resource.<\/li>\n<li>Deliveries to your endpoint depend on endpoint reachability:<\/li>\n<li>Webhook endpoints must be reachable and respond quickly.<\/li>\n<li>Azure-native endpoints (Functions, Service Bus, etc.) use Azure internal routing, but network restrictions can still apply.<\/li>\n<li>If you require \u201cno public exposure,\u201d design around private endpoints where supported or place an internal ingress tier (for example, API Management or an internal Function endpoint) that can receive events appropriately. <strong>Verify supported private networking configurations in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring \/ logging \/ governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Azure Monitor metrics<\/strong> to track:<\/li>\n<li>delivery success\/failures<\/li>\n<li>dead-letter counts<\/li>\n<li>throttling indicators<\/li>\n<li>Enable <strong>diagnostic settings<\/strong> to send logs to:<\/li>\n<li>Log Analytics workspace<\/li>\n<li>Storage account<\/li>\n<li>Event Hubs (for centralized SIEM ingestion)<\/li>\n<li>Use Azure Policy and IaC to enforce:<\/li>\n<li>consistent naming\/tagging<\/li>\n<li>diagnostic settings enabled<\/li>\n<li>required dead-letter configuration for critical subscriptions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[Event Source&lt;br\/&gt;Azure Storage \/ App] --&gt; B[Event Grid Topic or System Topic]\n  B --&gt;|Filter + Route| C[Event Subscription]\n  C --&gt; D[Handler: Azure Function]\n  C --&gt; E[Handler: Logic App]\n  C --&gt; F[Handler: Webhook]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Producers\n    P1[Azure Storage Events&lt;br\/&gt;BlobCreated]\n    P2[Custom App Events&lt;br\/&gt;OrderCreated]\n    P3[Azure Resource Events&lt;br\/&gt;ResourceWriteSuccess]\n  end\n\n  subgraph Routing[\"Azure Event Grid\"]\n    T1[System Topic&lt;br\/&gt;Storage Account]\n    T2[Custom Topic&lt;br\/&gt;Orders]\n    S1[Event Subscription&lt;br\/&gt;Filter: subject startswith \/inbox\/]\n    S2[Event Subscription&lt;br\/&gt;Filter: type=OrderCreated]\n    S3[Event Subscription&lt;br\/&gt;Filter: resource writes]\n    DL[Dead-letter Storage&lt;br\/&gt;Blob Container]\n  end\n\n  subgraph Handlers\n    F1[Azure Function&lt;br\/&gt;Validate &amp; enqueue]\n    SB[Azure Service Bus&lt;br\/&gt;Queue\/Topic for durable processing]\n    LA[Logic App&lt;br\/&gt;Approvals\/Notifications]\n    SIEM[Log Analytics \/ SIEM&lt;br\/&gt;Diagnostics]\n  end\n\n  P1 --&gt; T1 --&gt; S1 --&gt; F1 --&gt; SB\n  P2 --&gt; T2 --&gt; S2 --&gt; SB\n  P3 --&gt; T1 --&gt; S3 --&gt; LA\n\n  S1 -.failed deliveries.-&gt; DL\n  S2 -.failed deliveries.-&gt; DL\n\n  Routing -.metrics\/logs.-&gt; SIEM\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start designing or running the lab:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Azure account\/subscription<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong> with billing enabled.<\/li>\n<li>Permission to create:<\/li>\n<li>Resource groups<\/li>\n<li>Storage accounts<\/li>\n<li>Event Grid system topics \/ event subscriptions<\/li>\n<li>If you are in a restricted enterprise environment, confirm:<\/li>\n<li>Allowed regions<\/li>\n<li>Azure Policy constraints<\/li>\n<li>Private networking requirements<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles (typical)<\/h3>\n\n\n\n<p>You may need (depending on your organization):\n&#8211; <strong>Contributor<\/strong> on the resource group (for creating resources)\n&#8211; Additional permissions to configure role assignments if your chosen handler requires managed identity access<\/p>\n\n\n\n<p>In locked-down subscriptions, you may need a platform admin to pre-create resources or grant RBAC.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Portal (browser)<\/li>\n<li>Azure CLI (<code>az<\/code>) installed and logged in<br\/>\n  Install instructions: https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/li>\n<\/ul>\n\n\n\n<p>Optional but helpful:\n&#8211; Azure Storage Explorer (GUI) for inspecting queue messages and blobs<br\/>\n  https:\/\/azure.microsoft.com\/products\/storage\/storage-explorer\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Event Grid and specific event sources\/handlers may not be available in all regions or sovereign clouds.<\/li>\n<li><strong>Verify supported regions and feature availability<\/strong> in the Event Grid documentation for your cloud environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Event Grid has quotas for items like:\n&#8211; number of subscriptions per topic\n&#8211; event size limits\n&#8211; delivery\/retry behavior and rates<\/p>\n\n\n\n<p>Because limits can change, use the official \u201climits\/quotas\u201d documentation for Event Grid and your specific event source. Verify in official docs:\n&#8211; https:\/\/learn.microsoft.com\/azure\/event-grid\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services for the lab<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Storage account (for blob events and for a queue destination)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Azure Event Grid pricing is <strong>usage-based<\/strong>. Exact rates vary by region and can change, so rely on the official pricing page and calculator:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/azure.microsoft.com\/pricing\/details\/event-grid\/<\/li>\n<li>Pricing calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you are charged)<\/h3>\n\n\n\n<p>Event Grid typically charges based on <strong>operations<\/strong>, such as:\n&#8211; <strong>Event ingress<\/strong> (publishing events to a topic or receiving system events)\n&#8211; <strong>Event delivery attempts<\/strong> (each attempt to deliver an event to a subscriber)\n&#8211; Potentially other operation types depending on feature set (verify the current pricing definition)<\/p>\n\n\n\n<p><strong>Key concept:<\/strong> Fan-out increases deliveries. If one event is routed to 5 subscriptions, you pay for <strong>one ingress<\/strong> plus <strong>multiple delivery attempts<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier \/ free grant<\/h3>\n\n\n\n<p>Azure services often include limited free monthly usage grants for certain operation counts. Whether Event Grid has a free grant and the amount can change\u2014<strong>verify on the official pricing page<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Number of events published\/ingested<\/li>\n<li>Number of subscriptions per topic (fan-out multiplier)<\/li>\n<li>Delivery retries (failures increase delivery attempts)<\/li>\n<li>Use of dead-lettering (storage transactions + storage capacity)<\/li>\n<li>Downstream handler costs (Functions executions, Logic App runs, Service Bus operations)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs (commonly missed)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Functions<\/strong>:<\/li>\n<li>Execution cost (Consumption\/Premium)<\/li>\n<li>Networking (if using VNET integration in Premium)<\/li>\n<li>Application Insights ingestion<\/li>\n<li><strong>Logic Apps<\/strong>:<\/li>\n<li>Per-action execution and connector costs<\/li>\n<li><strong>Storage<\/strong>:<\/li>\n<li>Dead-letter container storage and transactions<\/li>\n<li>Queue storage transactions and message retention<\/li>\n<li><strong>Monitoring<\/strong>:<\/li>\n<li>Log Analytics ingestion and retention<\/li>\n<li>Diagnostic logs volume<\/li>\n<li><strong>Network egress<\/strong>:<\/li>\n<li>If delivering to endpoints across regions or to the public internet, data transfer costs may apply depending on traffic path and service rules<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Filter early:<\/li>\n<li>Use event types and subject filters to avoid unnecessary deliveries<\/li>\n<li>Reduce fan-out where possible:<\/li>\n<li>Combine closely related workflows behind a single handler that re-dispatches internally (only if it doesn\u2019t reintroduce coupling)<\/li>\n<li>Ensure handler reliability:<\/li>\n<li>Reduce retries by handling validation, timeouts, and transient errors correctly<\/li>\n<li>Use dead-lettering intentionally:<\/li>\n<li>Enable for critical workflows, but apply retention and lifecycle policies<\/li>\n<li>Monitor and alert:<\/li>\n<li>Catch failing endpoints early to prevent retry storms<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A small dev\/test setup might include:\n&#8211; Storage events (small number of blob uploads per day)\n&#8211; One event subscription to a Storage Queue or Function\n&#8211; Minimal diagnostic logging<\/p>\n\n\n\n<p>Your Event Grid portion is primarily operations-based and may be low, but <strong>your total cost<\/strong> may be driven more by:\n&#8211; Function executions (if used)\n&#8211; Log Analytics ingestion (if verbose diagnostics are enabled)<\/p>\n\n\n\n<p>Because pricing is region-specific and changes, don\u2019t treat any numeric estimate as authoritative\u2014use the pricing calculator with your expected event volume and fan-out.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, cost planning should model:\n&#8211; Peak event rate per minute\/hour\/day\n&#8211; Average number of subscribers per event\n&#8211; Failure\/retry rate (especially during outages)\n&#8211; Log ingestion volume and retention policy\n&#8211; Downstream compute costs for handlers\n&#8211; Cross-region delivery patterns and any egress<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab is designed to be <strong>beginner-friendly<\/strong>, <strong>low-cost<\/strong>, and <strong>real<\/strong>. You will:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Azure Storage<\/strong> as the event source (BlobCreated).<\/li>\n<li>Use <strong>Event Grid<\/strong> to route events.<\/li>\n<li>Deliver the events to an <strong>Azure Storage Queue<\/strong> (no code required).<\/li>\n<li>Validate by uploading a blob and reading the queue message.<\/li>\n<\/ul>\n\n\n\n<p>This is a practical Integration pattern: \u201cdata lands \u2192 event emitted \u2192 queue receives \u2192 downstream workers can process reliably.\u201d<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create an Event Grid subscription so that when a blob is uploaded to a container, Event Grid delivers the event payload to a Storage Queue message.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build this flow:<\/p>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[You upload a blob] --&gt; SA[Azure Storage&lt;br\/&gt;Blob container]\n  SA --&gt; EG[Event Grid&lt;br\/&gt;System events]\n  EG --&gt; Q[Azure Storage Queue&lt;br\/&gt;Message with event JSON]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a resource group and storage account<\/h3>\n\n\n\n<p>You can do this in the Portal or CLI. The Portal is easiest for beginners; CLI is reproducible.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Azure CLI<\/h4>\n\n\n\n<p>1) Sign in and select your subscription:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az login\naz account show\n# If needed:\naz account set --subscription \"&lt;YOUR_SUBSCRIPTION_ID&gt;\"\n<\/code><\/pre>\n\n\n\n<p>2) Create a resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">RG=\"rg-eg-lab\"\nLOCATION=\"eastus\"   # choose a region allowed in your subscription\naz group create -n \"$RG\" -l \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<p>3) Create a storage account (must be globally unique name):<\/p>\n\n\n\n<pre><code class=\"language-bash\">SA=\"steglab$RANDOM$RANDOM\"\naz storage account create \\\n  -g \"$RG\" -n \"$SA\" -l \"$LOCATION\" \\\n  --sku Standard_LRS \\\n  --kind StorageV2\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Resource group and storage account exist.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Verify<\/h4>\n\n\n\n<pre><code class=\"language-bash\">az storage account show -g \"$RG\" -n \"$SA\" --query \"{name:name,location:primaryLocation,kind:kind,sku:sku.name}\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a blob container and a queue<\/h3>\n\n\n\n<p>1) Get a storage account key (for quick lab use). In production, prefer least-privilege identities and avoid distributing keys.<\/p>\n\n\n\n<pre><code class=\"language-bash\">SA_KEY=$(az storage account keys list -g \"$RG\" -n \"$SA\" --query \"[0].value\" -o tsv)\n<\/code><\/pre>\n\n\n\n<p>2) Create a blob container:<\/p>\n\n\n\n<pre><code class=\"language-bash\">CONTAINER=\"inbox\"\naz storage container create \\\n  --account-name \"$SA\" \\\n  --account-key \"$SA_KEY\" \\\n  --name \"$CONTAINER\"\n<\/code><\/pre>\n\n\n\n<p>3) Create a queue:<\/p>\n\n\n\n<pre><code class=\"language-bash\">QUEUE=\"events\"\naz storage queue create \\\n  --account-name \"$SA\" \\\n  --account-key \"$SA_KEY\" \\\n  --name \"$QUEUE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a blob container named <code>inbox<\/code> and a queue named <code>events<\/code>.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Verify<\/h4>\n\n\n\n<pre><code class=\"language-bash\">az storage container list --account-name \"$SA\" --account-key \"$SA_KEY\" -o table\naz storage queue list --account-name \"$SA\" --account-key \"$SA_KEY\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an Event Grid event subscription (Storage BlobCreated \u2192 Storage Queue)<\/h3>\n\n\n\n<p>In this lab, you will subscribe to <strong>system events<\/strong> emitted by the storage account.<\/p>\n\n\n\n<p>You can create the subscription using the <strong>Azure Portal<\/strong>, which is usually the least error-prone because it guides you through identity and endpoint selection.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A (recommended): Azure Portal<\/h4>\n\n\n\n<p>1) Go to the storage account <strong><code>$SA<\/code><\/strong> in the Azure Portal.\n2) In the left menu, select <strong>Events<\/strong> (sometimes under \u201cEvent Grid\u201d or \u201cEvents\u201d).\n3) Select <strong>+ Event Subscription<\/strong>.\n4) Configure:\n   &#8211; <strong>Name<\/strong>: <code>es-blobcreated-to-queue<\/code>\n   &#8211; <strong>Event Schema<\/strong>: choose <strong>Event Grid Schema<\/strong> (default) or <strong>CloudEvents<\/strong> if you prefer standardization (either is fine for the lab).\n   &#8211; <strong>Event Types<\/strong>: select <strong>Blob Created<\/strong> (or the equivalent \u201cMicrosoft.Storage.BlobCreated\u201d option)\n   &#8211; <strong>Endpoint Type<\/strong>: <strong>Storage Queue<\/strong>\n   &#8211; <strong>Endpoint<\/strong>:\n     &#8211; Select your storage account (same <code>$SA<\/code> is fine)\n     &#8211; Select queue: <code>events<\/code>\n5) (Optional but recommended) Set a <strong>Subject filter<\/strong>:\n   &#8211; <strong>Subject begins with<\/strong>: <code>\/blobServices\/default\/containers\/inbox\/<\/code>\n   This ensures only events from the <code>inbox<\/code> container are delivered.\n6) Create the subscription.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> An Event Grid subscription exists and is in a succeeded\/provisioned state.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Verify (Portal)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Return to the storage account <strong>Events<\/strong> page and confirm the subscription appears.<\/li>\n<li>Open the subscription and confirm:<\/li>\n<li>Event type: BlobCreated<\/li>\n<li>Endpoint: Storage Queue <code>events<\/code><\/li>\n<li>Filters: subject prefix (if configured)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Azure CLI (advanced; verify syntax in official docs)<\/h4>\n\n\n\n<p>CLI support for Event Grid subscription creation and delivery identity options can vary by CLI version and installed extensions. If you prefer CLI, start from:\n&#8211; Event Grid CLI reference: https:\/\/learn.microsoft.com\/cli\/azure\/eventgrid<\/p>\n\n\n\n<p>If your CLI version differs, <strong>verify in official docs<\/strong> and adapt accordingly.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Upload a blob to trigger the event<\/h3>\n\n\n\n<p>Create a small local file and upload it to the <code>inbox<\/code> container.<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"hello event grid\" &gt; hello-eg.txt\n\naz storage blob upload \\\n  --account-name \"$SA\" \\\n  --account-key \"$SA_KEY\" \\\n  --container-name \"$CONTAINER\" \\\n  --name \"hello-eg.txt\" \\\n  --file \"hello-eg.txt\" \\\n  --overwrite true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Blob upload succeeds, and Storage emits a BlobCreated event. Event Grid routes it to the queue.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Verify the blob exists<\/h4>\n\n\n\n<pre><code class=\"language-bash\">az storage blob list \\\n  --account-name \"$SA\" \\\n  --account-key \"$SA_KEY\" \\\n  --container-name \"$CONTAINER\" \\\n  -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Read the queue message (the delivered event)<\/h3>\n\n\n\n<p>Peek at the queue to see if an event message arrived:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az storage queue message peek \\\n  --account-name \"$SA\" \\\n  --account-key \"$SA_KEY\" \\\n  --queue-name \"$QUEUE\" \\\n  --num-messages 5 \\\n  -o json\n<\/code><\/pre>\n\n\n\n<p>You should see a message body containing JSON for the Event Grid event. The payload often includes fields like <code>eventType<\/code>, <code>subject<\/code>, <code>eventTime<\/code>, and <code>data<\/code> (schema depends on Event Grid schema vs CloudEvents and the source type).<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> At least one message appears in the queue shortly after upload.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) <strong>Event subscription is provisioned<\/strong>\n&#8211; In Portal, the event subscription shows as created without errors.<\/p>\n\n\n\n<p>2) <strong>Blob uploaded successfully<\/strong>\n&#8211; <code>az storage blob list<\/code> shows <code>hello-eg.txt<\/code>.<\/p>\n\n\n\n<p>3) <strong>Queue message exists<\/strong>\n&#8211; <code>az storage queue message peek<\/code> returns a JSON message with an Event Grid event payload.\n&#8211; Confirm the <code>subject<\/code> includes your container path and blob name.<\/p>\n\n\n\n<p>Optional deeper validation:\n&#8211; Upload multiple blobs and confirm multiple messages arrive.\n&#8211; Upload a blob outside <code>inbox\/<\/code> (if you configured subject filtering) and confirm <strong>no message<\/strong> arrives.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: No queue messages arrive<\/h4>\n\n\n\n<p>Common causes and fixes:\n&#8211; <strong>Event subscription filter mismatch<\/strong>\n  &#8211; If you used \u201cSubject begins with\u201d, ensure it matches the exact subject format used by Storage events.\n  &#8211; Quick test: remove subject filter and try again, then refine.\n&#8211; <strong>Wrong event type selected<\/strong>\n  &#8211; Confirm you subscribed to BlobCreated (not BlobDeleted or a different event family).\n&#8211; <strong>Queue doesn\u2019t exist or wrong queue selected<\/strong>\n  &#8211; Confirm queue name <code>events<\/code> exists in the selected storage account.\n&#8211; <strong>Permissions\/identity problem for delivery<\/strong>\n  &#8211; Storage Queue delivery may require Event Grid to have the correct permissions.\n  &#8211; If using Portal, it often configures required access; if using CLI\/IaC, you may need to grant RBAC roles. Verify the official docs for \u201cEvent Grid delivery to Storage Queue\u201d.\n&#8211; <strong>Delay<\/strong>\n  &#8211; Delivery is typically fast, but allow a minute and re-check. Then investigate metrics\/logs.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Queue message body is base64\/encoded or hard to read<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some tools display the message body encoded. Use tooling that can decode the message, or output raw JSON and decode if needed.<\/li>\n<li>Storage Explorer often makes inspection easier.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Too many duplicate events<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Event Grid delivery is <strong>at-least-once<\/strong>. Duplicates can occur, especially with retries.<\/li>\n<li>Design consumers to be <strong>idempotent<\/strong> (dedupe by event ID + time window, or by blob URL + ETag, etc.).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete -n \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All created resources (storage account, event subscription configuration) are removed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Choose the right service for the job<\/strong><\/li>\n<li>Use Event Grid for <strong>event notifications and routing<\/strong><\/li>\n<li>Use Service Bus for <strong>durable commands, workflows requiring FIFO\/sessions, or transactional messaging<\/strong><\/li>\n<li>Use Event Hubs for <strong>streaming telemetry and analytics ingestion<\/strong><\/li>\n<li><strong>Use clear event contracts<\/strong><\/li>\n<li>Prefer <strong>CloudEvents 1.0<\/strong> when standardization matters across teams\/systems<\/li>\n<li>Version event payloads; don\u2019t break consumers by changing fields silently<\/li>\n<li><strong>Design for idempotency<\/strong><\/li>\n<li>Assume duplicate deliveries and implement dedupe in subscribers<\/li>\n<li><strong>Keep handlers fast<\/strong><\/li>\n<li>If work is heavy, enqueue to Service Bus\/Storage Queue and return success quickly<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM \/ security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>Azure AD \/ Entra ID<\/strong> and <strong>managed identity<\/strong> patterns where supported.<\/li>\n<li>Apply least privilege:<\/li>\n<li>Publishers can only send to their topic<\/li>\n<li>Subscribers can only receive or read dead-letter data needed for their role<\/li>\n<li>Use HTTPS-only endpoints; validate webhook signatures\/claims where applicable.<\/li>\n<li>Restrict who can create event subscriptions (they can exfiltrate events if misused).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Filter aggressively to reduce:<\/li>\n<li>handler invocations<\/li>\n<li>delivery attempts<\/li>\n<li>Monitor and alert on failures to reduce retries.<\/li>\n<li>Right-size diagnostic logging:<\/li>\n<li>send only necessary logs to Log Analytics<\/li>\n<li>set retention intentionally<\/li>\n<li>Consider per-environment isolation:<\/li>\n<li>separate dev\/test\/prod topics\/subscriptions to avoid noisy dev traffic in prod<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid slow webhook endpoints; scale handlers to handle bursts.<\/li>\n<li>Use queue-based buffering (Service Bus\/Storage Queue) if handlers can\u2019t scale instantly.<\/li>\n<li>Keep payload sizes minimal (don\u2019t ship large blobs in events; ship references\/URLs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>dead-lettering<\/strong> for critical workflows.<\/li>\n<li>Implement replay tooling\/process:<\/li>\n<li>dead-letter storage inspection<\/li>\n<li>republish\/reprocess pipeline<\/li>\n<li>Test failure modes:<\/li>\n<li>handler downtime<\/li>\n<li>permission failures<\/li>\n<li>filter misconfiguration<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable metrics\/diagnostic logs and build:<\/li>\n<li>delivery failure alerts<\/li>\n<li>dead-letter alerts<\/li>\n<li>Document ownership:<\/li>\n<li>Who owns the topic?<\/li>\n<li>Who is allowed to create subscriptions?<\/li>\n<li>How are changes approved?<\/li>\n<li>Use IaC (Bicep\/Terraform) for repeatable, reviewable configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance, tagging, and naming<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent naming like:<\/li>\n<li><code>egst-&lt;app&gt;-&lt;env&gt;-&lt;region&gt;<\/code> for system topics (if you name them)<\/li>\n<li><code>egt-&lt;domain&gt;-&lt;env&gt;-&lt;region&gt;<\/code> for custom topics<\/li>\n<li><code>egs-&lt;producer&gt;-to-&lt;consumer&gt;-&lt;purpose&gt;<\/code> for subscriptions<\/li>\n<li>Tag resources with:<\/li>\n<li><code>env<\/code>, <code>owner<\/code>, <code>costCenter<\/code>, <code>dataClassification<\/code><\/li>\n<li>Enforce with Azure Policy where feasible.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<p>Event Grid involves two primary access paths:<\/p>\n\n\n\n<p>1) <strong>Publisher \u2192 Topic<\/strong> (data plane)\n&#8211; Ensure only authorized publishers can send events.\n&#8211; Where supported, prefer Azure AD RBAC roles designed for Event Grid publishing (verify current role names and applicability in official docs).<\/p>\n\n\n\n<p>2) <strong>Event Grid \u2192 Handler<\/strong> (delivery)\n&#8211; For Azure service handlers, use secure integration patterns (often Azure AD\/managed identity, depending on handler type).\n&#8211; For webhook handlers:\n  &#8211; Use HTTPS\n  &#8211; Implement validation handshake correctly\n  &#8211; Authenticate requests (for example, validate tokens\/claims if using Azure AD-based delivery, or validate headers as documented)<\/p>\n\n\n\n<p>Because handler auth varies by destination, consult the official handler documentation for the exact configuration and supported methods.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit: use TLS\/HTTPS for webhooks.<\/li>\n<li>Data at rest:<\/li>\n<li>Dead-letter storage is stored in your Storage account and inherits its encryption settings (Microsoft-managed keys by default; customer-managed keys if you configure them at the storage layer).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Webhook endpoints are often the riskiest path because they can require public reachability.<\/li>\n<li>Prefer Azure-native endpoints (Functions\/Logic Apps\/Service Bus) with restricted network access when your environment requires it.<\/li>\n<li>If using private connectivity features (Private Link\/private endpoints), confirm exactly what is supported for your Event Grid resource type and destination type\u2014<strong>verify in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding keys in code or pipelines.<\/li>\n<li>Use:<\/li>\n<li>Managed identities where supported<\/li>\n<li>Azure Key Vault for secrets if keys are unavoidable<\/li>\n<li>Rotate keys if you use topic keys for publishing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable diagnostic settings and route to Log Analytics\/SIEM for:<\/li>\n<li>operational visibility<\/li>\n<li>threat hunting and change investigations<\/li>\n<li>Audit who can create\/modify event subscriptions; subscription creation can become an exfiltration vector.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Consider data classification:<\/li>\n<li>Events may contain sensitive identifiers (file paths, customer IDs).<\/li>\n<li>Keep payload minimal; store sensitive data in secure stores and pass references.<\/li>\n<li>Ensure region and data residency requirements are met:<\/li>\n<li>topic location<\/li>\n<li>handler location<\/li>\n<li>logging location (Log Analytics workspace region\/retention)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Leaving webhook endpoints unauthenticated or broadly reachable.<\/li>\n<li>Over-permissioning users to create event subscriptions across sensitive topics.<\/li>\n<li>Sending sensitive payload data directly in event bodies.<\/li>\n<li>Not securing dead-letter storage (it may contain sensitive event payloads).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use least privilege RBAC and separation of duties.<\/li>\n<li>Use private networking patterns where supported and required.<\/li>\n<li>Turn on monitoring and alerting for delivery failures and dead-letter growth.<\/li>\n<li>Treat event subscriptions as production integration code\u2014review and manage via IaC and change control.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Event Grid spans many event sources and handler types, limitations can be contextual. Here are common, real-world gotchas to plan for:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Delivery semantics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>At-least-once delivery<\/strong>: duplicates can occur.<\/li>\n<li><strong>Ordering is not guaranteed<\/strong>: don\u2019t assume event order.<\/li>\n<li><strong>Eventual consistency<\/strong>: events may arrive slightly later than the actual state change.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Handler behavior requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Webhook endpoints must:<\/li>\n<li>handle the validation handshake<\/li>\n<li>respond with appropriate HTTP codes quickly<\/li>\n<li>Slow responses can cause retries and duplicate deliveries.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Filtering surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Subject formats differ by event source (Storage vs ARM vs custom).<\/li>\n<li>Small filter mistakes can lead to:<\/li>\n<li>missed events (over-filtering)<\/li>\n<li>noisy subscriptions (under-filtering)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits exist for:<\/li>\n<li>max event size<\/li>\n<li>number of subscriptions<\/li>\n<li>retry duration\/attempt behavior<\/li>\n<li>throughput characteristics<\/li>\n<li>These can change\u2014use the official limits documentation:<\/li>\n<li>https:\/\/learn.microsoft.com\/azure\/event-grid\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fan-out multiplies delivery attempts.<\/li>\n<li>Failures multiply delivery attempts (retries).<\/li>\n<li>Logging (Log Analytics) can out-cost Event Grid itself in some environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional and feature availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all event sources\/handlers are supported in all regions or clouds.<\/li>\n<li>Some advanced networking\/security capabilities vary\u2014verify before committing to an architecture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from a queue-based integration (Service Bus) to Event Grid can expose:<\/li>\n<li>duplicate handling requirements<\/li>\n<li>differences in delivery guarantees<\/li>\n<li>Moving from ad-hoc webhooks to Event Grid requires implementing validation and standard event parsing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances (Azure specifics)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>System events are defined by Azure resource providers; schema fields and subjects can vary.<\/li>\n<li>Identity configuration for delivery differs by handler type\u2014don\u2019t assume one approach fits all.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Event Grid is one piece of Azure Integration. Here\u2019s how it compares to common alternatives.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure Event Grid<\/strong><\/td>\n<td>Event notifications, reactive automation, fan-out routing<\/td>\n<td>Managed routing, native Azure events, filtering, retries, dead-lettering<\/td>\n<td>At-least-once (duplicates), no ordering guarantees, push delivery model<\/td>\n<td>When you need \u201csomething happened\u201d events across many subscribers<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Service Bus<\/strong><\/td>\n<td>Durable messaging, commands, workflows needing FIFO\/sessions, decoupled services with pull<\/td>\n<td>Stronger messaging semantics, sessions\/FIFO patterns, dead-letter queues, durable pull<\/td>\n<td>More design complexity; not a native \u201cresource events\u201d service<\/td>\n<td>When you need durable work queues or enterprise messaging patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Event Hubs<\/strong><\/td>\n<td>High-throughput telemetry\/streaming ingestion<\/td>\n<td>Extremely high throughput, partitions, streaming ecosystem<\/td>\n<td>Not an event router for discrete notifications; consumer complexity<\/td>\n<td>When you ingest massive streams for analytics\/processing<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Logic Apps (alone)<\/strong><\/td>\n<td>Workflow automation and connectors<\/td>\n<td>Visual orchestration, connectors, approvals, long-running workflows<\/td>\n<td>Not a general event routing backbone; can become central monolith<\/td>\n<td>When the main problem is workflow orchestration (often triggered by Event Grid)<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS EventBridge<\/strong><\/td>\n<td>AWS-native event routing<\/td>\n<td>Deep AWS integrations, event bus model<\/td>\n<td>Different cloud ecosystem; migration overhead<\/td>\n<td>When building primarily on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Eventarc<\/strong><\/td>\n<td>GCP event routing<\/td>\n<td>GCP integrations, CloudEvents<\/td>\n<td>Different cloud ecosystem; feature parity differs<\/td>\n<td>When building primarily on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Apache Kafka (self-managed\/managed)<\/strong><\/td>\n<td>Streaming + event backbone with ordering\/retention<\/td>\n<td>Durable log, replay, ordering per partition, ecosystem<\/td>\n<td>Operational overhead, cost, complexity<\/td>\n<td>When you need long retention, replay at scale, and stream processing<\/td>\n<\/tr>\n<tr>\n<td><strong>RabbitMQ\/NATS (self-managed)<\/strong><\/td>\n<td>Messaging patterns, low-latency pub\/sub<\/td>\n<td>Flexible protocols, strong community<\/td>\n<td>You operate it; scaling\/HA complexity<\/td>\n<td>When you need protocol-level control or non-cloud portability<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Regulated document intake and processing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial institution receives customer documents into blob storage. Each upload must trigger scanning, classification, and case creation. The system must be auditable, reliable, and avoid exposing public endpoints.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Azure Storage receives uploads into per-case containers<\/li>\n<li>Storage emits BlobCreated events<\/li>\n<li>Event Grid routes events with subject filters to:<ul>\n<li>Azure Function (validation + metadata extraction)<\/li>\n<li>Service Bus queue (durable processing pipeline)<\/li>\n<\/ul>\n<\/li>\n<li>Dead-lettering enabled for critical subscriptions<\/li>\n<li>Diagnostics to Log Analytics\/SIEM<\/li>\n<li>Strict RBAC and private networking where supported; avoid public webhooks<\/li>\n<li><strong>Why Event Grid was chosen:<\/strong><\/li>\n<li>Native Storage integration (no polling)<\/li>\n<li>Fan-out to multiple internal workflows<\/li>\n<li>Filtering by container prefix and file type<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster processing start times (seconds, not minutes)<\/li>\n<li>Lower compute waste (no pollers)<\/li>\n<li>Better audit trail via centralized monitoring and dead-letter analysis<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Image upload \u2192 thumbnail \u2192 CDN purge<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small SaaS app stores user images in blob storage and needs thumbnails and cache invalidation without running background servers.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>BlobCreated events from Storage<\/li>\n<li>Event Grid subscription to an Azure Function<\/li>\n<li>Function generates thumbnails and writes to <code>thumbnails\/<\/code><\/li>\n<li>Function triggers CDN purge API (or emits another custom event)<\/li>\n<li><strong>Why Event Grid was chosen:<\/strong><\/li>\n<li>Minimal operational overhead<\/li>\n<li>Simple Integration between storage and serverless compute<\/li>\n<li>Cost aligned with usage<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster user experience (immediate availability of thumbnails)<\/li>\n<li>Clean separation of upload path and processing<\/li>\n<li>Easy to add new subscribers later (e.g., analytics) without changing upload logic<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Event Grid a message queue?<\/strong><br\/>\nNo. Event Grid is primarily an <strong>event routing\/notification<\/strong> service. It pushes events to handlers. For durable queue semantics and pull consumption, consider <strong>Azure Service Bus<\/strong> or <strong>Storage Queues<\/strong> (often used downstream of Event Grid).<\/p>\n\n\n\n<p>2) <strong>Does Event Grid guarantee exactly-once delivery?<\/strong><br\/>\nNo. Event Grid is <strong>at-least-once<\/strong>. Duplicates can occur, so handlers must be idempotent.<\/p>\n\n\n\n<p>3) <strong>Does Event Grid preserve ordering of events?<\/strong><br\/>\nDo not assume ordering. If ordering matters, design for it (for example, use a durable queue with sessions or implement ordering logic in the consumer).<\/p>\n\n\n\n<p>4) <strong>What\u2019s the difference between a system topic and a custom topic?<\/strong><br\/>\nA <strong>system topic<\/strong> represents events emitted by an Azure resource (like a storage account). A <strong>custom topic<\/strong> is for events published by your own applications to Event Grid.<\/p>\n\n\n\n<p>5) <strong>What event schema should I use: Event Grid schema or CloudEvents?<\/strong><br\/>\nCloudEvents is a widely adopted standard and can help portability and consistency. Use it if you want standardization across platforms. Event Grid schema is also common in Azure examples. Choose one and apply it consistently.<\/p>\n\n\n\n<p>6) <strong>Can I use Event Grid to integrate microservices?<\/strong><br\/>\nYes\u2014especially for domain events and fan-out notifications. For durable processing and back-pressure, combine Event Grid with Service Bus.<\/p>\n\n\n\n<p>7) <strong>How do I handle duplicate events safely?<\/strong><br\/>\nUse idempotency keys. Common patterns:\n&#8211; dedupe by event <code>id<\/code> plus a time window\n&#8211; dedupe by resource URI + ETag\/version\n&#8211; store processed IDs in a cache\/store for a short retention window<\/p>\n\n\n\n<p>8) <strong>What happens if my handler is down?<\/strong><br\/>\nEvent Grid retries delivery for a period based on the retry policy. If configured, it can dead-letter undeliverable events to storage.<\/p>\n\n\n\n<p>9) <strong>What is dead-lettering used for?<\/strong><br\/>\nTo store events that could not be delivered after retries. This is essential for investigating failures and enabling replay processes.<\/p>\n\n\n\n<p>10) <strong>Can Event Grid deliver to private endpoints only?<\/strong><br\/>\nPrivate connectivity support depends on the Event Grid resource type and the destination handler type. Many enterprise designs avoid public webhooks and use Azure-native handlers. Verify private networking support in official docs.<\/p>\n\n\n\n<p>11) <strong>Is Event Grid good for high-throughput telemetry ingestion?<\/strong><br\/>\nUsually no. For telemetry and streaming, use <strong>Event Hubs<\/strong>. Event Grid is optimized for discrete events and routing.<\/p>\n\n\n\n<p>12) <strong>How do I monitor Event Grid?<\/strong><br\/>\nUse Azure Monitor metrics and diagnostic settings. Track delivery failures, dead-letter counts, and latency indicators. Send logs to Log Analytics\/SIEM where needed.<\/p>\n\n\n\n<p>13) <strong>Can I route one event to multiple subscribers?<\/strong><br\/>\nYes. That\u2019s a core strength: multiple event subscriptions can be attached to the same topic.<\/p>\n\n\n\n<p>14) <strong>What are common reasons deliveries fail?<\/strong><br\/>\n&#8211; endpoint is unavailable or slow\n&#8211; authentication\/authorization issues\n&#8211; webhook validation not implemented\n&#8211; networking restrictions (firewalls, private endpoints not configured)\n&#8211; filters exclude the events you expect<\/p>\n\n\n\n<p>15) <strong>Can I test Event Grid locally?<\/strong><br\/>\nYou can test consumers locally by simulating event payloads (sending HTTP requests that mimic Event Grid events) and validating parsing\/idempotency logic. For end-to-end tests, deploy a dev environment in Azure.<\/p>\n\n\n\n<p>16) <strong>Should I put sensitive data in events?<\/strong><br\/>\nPrefer not to. Put references (URLs\/IDs) and store sensitive data in secure systems. Events may be logged, dead-lettered, or forwarded.<\/p>\n\n\n\n<p>17) <strong>How do I manage Event Grid at scale across many teams?<\/strong><br\/>\nUse IaC, standardized naming\/tagging, RBAC boundaries, and policies restricting who can create subscriptions on sensitive topics. Establish an internal \u201cevent governance\u201d practice (schemas, versioning, ownership).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Event Grid<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Event Grid documentation (Microsoft Learn) \u2014 https:\/\/learn.microsoft.com\/azure\/event-grid\/<\/td>\n<td>Primary, up-to-date reference for concepts, schemas, and configuration<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Event Grid pricing \u2014 https:\/\/azure.microsoft.com\/pricing\/details\/event-grid\/<\/td>\n<td>Current pricing dimensions and regional notes<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Azure Pricing Calculator \u2014 https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<td>Model costs with your expected event volume and fan-out<\/td>\n<\/tr>\n<tr>\n<td>Getting started<\/td>\n<td>Event Grid quickstarts (in docs) \u2014 https:\/\/learn.microsoft.com\/azure\/event-grid\/<\/td>\n<td>Step-by-step guidance for common source\/handler combos<\/td>\n<\/tr>\n<tr>\n<td>Event schemas<\/td>\n<td>Event Grid event schemas \u2014 https:\/\/learn.microsoft.com\/azure\/event-grid\/event-schema<\/td>\n<td>Understand event formats, required fields, and parsing<\/td>\n<\/tr>\n<tr>\n<td>CloudEvents<\/td>\n<td>CloudEvents overview (Event Grid) \u2014 https:\/\/learn.microsoft.com\/azure\/event-grid\/cloudevents-schema<\/td>\n<td>Guidance on using CloudEvents with Event Grid<\/td>\n<\/tr>\n<tr>\n<td>Azure Architecture Center<\/td>\n<td>Azure Architecture Center \u2014 https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<td>Reference architectures and best practices for Azure solutions<\/td>\n<\/tr>\n<tr>\n<td>Monitoring<\/td>\n<td>Azure Monitor documentation \u2014 https:\/\/learn.microsoft.com\/azure\/azure-monitor\/<\/td>\n<td>Metrics, logs, alerting patterns for Event Grid-based systems<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>Azure CLI <code>eventgrid<\/code> reference \u2014 https:\/\/learn.microsoft.com\/cli\/azure\/eventgrid<\/td>\n<td>Automate topic\/subscription creation and management<\/td>\n<\/tr>\n<tr>\n<td>Samples (official\/trusted)<\/td>\n<td>Azure Samples on GitHub \u2014 https:\/\/github.com\/Azure-Samples<\/td>\n<td>Many Azure-maintained examples; search for Event Grid scenarios<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Microsoft Azure YouTube channel \u2014 https:\/\/www.youtube.com\/@MicrosoftAzure<\/td>\n<td>Conceptual and demo-based learning (search \u201cEvent Grid\u201d)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following are training providers to explore for Event Grid and Azure Integration learning. Modes and course specifics can change\u2014check each website directly.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, cloud engineers<\/td>\n<td>Azure DevOps, cloud operations, automation, integration patterns<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate IT professionals<\/td>\n<td>DevOps fundamentals, tooling, cloud basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations and platform teams<\/td>\n<td>Cloud ops practices, monitoring, reliability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and platform engineering teams<\/td>\n<td>Reliability engineering, incident response, observability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting automation<\/td>\n<td>AIOps concepts, automation and operational analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites are presented as training resources\/platforms to explore for DevOps\/Azure learning.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Students, engineers seeking practical learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and coaching<\/td>\n<td>DevOps engineers, freshers, teams<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps freelancing\/training content<\/td>\n<td>Practitioners looking for applied skills<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources<\/td>\n<td>Ops\/DevOps teams needing hands-on guidance<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These consulting organizations may help with Azure Integration architecture, Event Grid implementations, and platform delivery. Descriptions are intentionally general and should be validated via direct engagement.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture review, implementation support, operational readiness<\/td>\n<td>Event-driven integration rollout, automation pipelines, monitoring design<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps\/cloud consulting and enablement<\/td>\n<td>Training + consulting engagements, platform practices<\/td>\n<td>Event Grid + Functions integration, CI\/CD automation, governance setup<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services<\/td>\n<td>Delivery acceleration, best practices, tooling<\/td>\n<td>Event-driven workflows, production hardening, cost optimization<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Event Grid<\/h3>\n\n\n\n<p>To use Event Grid effectively, you should understand:\n&#8211; Azure fundamentals:\n  &#8211; subscriptions, resource groups, regions\n  &#8211; Azure RBAC and managed identities\n&#8211; Networking basics:\n  &#8211; HTTPS, DNS, firewall concepts\n  &#8211; private vs public endpoints (conceptually)\n&#8211; Messaging fundamentals:\n  &#8211; pub\/sub vs queues\n  &#8211; at-least-once delivery and idempotency\n&#8211; JSON and event payload design<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Event Grid<\/h3>\n\n\n\n<p>To build production-grade Integration platforms:\n&#8211; Azure Functions (triggers, scaling, error handling)\n&#8211; Azure Logic Apps (workflow orchestration, connectors, retries)\n&#8211; Azure Service Bus (queues\/topics, sessions, dead-letter queues)\n&#8211; Azure Event Hubs + stream processing (if you have telemetry\/analytics workloads)\n&#8211; Observability:\n  &#8211; Azure Monitor, Log Analytics, alerting\n&#8211; Infrastructure as Code:\n  &#8211; Bicep\/ARM or Terraform\n&#8211; Security:\n  &#8211; Key Vault, private networking, threat modeling<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use Event Grid<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Azure Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>Integration Engineer<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Backend Developer (microservices\/event-driven systems)<\/li>\n<li>Security Engineer (automation and governance triggers)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Microsoft certifications evolve over time. Commonly relevant tracks include:\n&#8211; Azure fundamentals and administrator tracks\n&#8211; Developer-focused Azure certifications\n&#8211; Architecture-focused certifications<\/p>\n\n\n\n<p>Rather than naming a specific cert that might change, align to your role and check current Microsoft certification paths:\n&#8211; https:\/\/learn.microsoft.com\/credentials\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<p>1) Storage-driven processing pipeline:\n&#8211; BlobCreated \u2192 Event Grid \u2192 Function \u2192 Service Bus \u2192 Worker<\/p>\n\n\n\n<p>2) Governance automation:\n&#8211; Resource write event \u2192 Event Grid \u2192 Logic App \u2192 tag enforcement + notifications<\/p>\n\n\n\n<p>3) Multi-subscriber event fan-out:\n&#8211; Custom topic \u201cOrderEvents\u201d \u2192 subscriptions to billing, shipping, analytics<\/p>\n\n\n\n<p>4) Dead-letter replay tool:\n&#8211; Read dead-letter blob events \u2192 validate \u2192 republish to topic (with dedupe)<\/p>\n\n\n\n<p>5) Cost\/performance study:\n&#8211; Simulate event bursts and observe retries, handler scaling, and costs in Azure Monitor<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Event-driven architecture (EDA):<\/strong> A design where services react to events rather than coordinating through synchronous calls and polling.<\/li>\n<li><strong>Event:<\/strong> A record that something happened (for example, \u201cBlobCreated\u201d). Usually immutable and time-stamped.<\/li>\n<li><strong>Publisher\/Producer:<\/strong> The system that emits events.<\/li>\n<li><strong>Subscriber\/Consumer:<\/strong> The system that receives and processes events.<\/li>\n<li><strong>Topic:<\/strong> An Event Grid resource endpoint that receives events (custom or system\/partner variants).<\/li>\n<li><strong>System topic:<\/strong> A topic representing events from a specific Azure resource.<\/li>\n<li><strong>Event subscription:<\/strong> A configuration that routes matching events to a destination with filters and delivery options.<\/li>\n<li><strong>Event handler:<\/strong> The destination endpoint (Function, Logic App, webhook, etc.) that receives the event.<\/li>\n<li><strong>Filtering:<\/strong> Rules that decide which events are delivered to a subscription (event type, subject prefix\/suffix, advanced filters).<\/li>\n<li><strong>At-least-once delivery:<\/strong> Delivery guarantee where events may be delivered more than once; consumers must handle duplicates.<\/li>\n<li><strong>Dead-lettering:<\/strong> Capturing undeliverable events into storage for later investigation and replay.<\/li>\n<li><strong>CloudEvents:<\/strong> A standard event format specification (CloudEvents 1.0) to normalize event metadata across platforms.<\/li>\n<li><strong>Idempotency:<\/strong> The ability to process the same event multiple times without causing incorrect results.<\/li>\n<li><strong>Fan-out:<\/strong> Routing one event to multiple subscribers.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure <strong>Event Grid<\/strong> is a managed <strong>Integration<\/strong> service for routing events from Azure resources, partner systems, and custom applications to multiple subscribers with filtering, retries, and optional dead-lettering. It matters because it enables clean, scalable event-driven architectures without building and operating your own routing layer.<\/p>\n\n\n\n<p>Event Grid fits best when you need <strong>event notification and fan-out<\/strong> across systems. Plan for <strong>at-least-once delivery<\/strong> (duplicates), implement <strong>idempotent consumers<\/strong>, and use <strong>dead-lettering<\/strong> plus <strong>monitoring<\/strong> to achieve production reliability. Cost is primarily driven by <strong>operations<\/strong>, <strong>fan-out<\/strong>, <strong>retries<\/strong>, and downstream services (Functions\/Logic Apps\/Service Bus) plus logging.<\/p>\n\n\n\n<p>Next learning step: pick one production pattern\u2014<strong>Event Grid \u2192 Function \u2192 Service Bus<\/strong>\u2014and implement end-to-end monitoring, dead-letter replay, and IaC so your event-driven workflow is not just working, but supportable.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Integration<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,48,16],"tags":[],"class_list":["post-455","post","type-post","status-publish","format-standard","hentry","category-azure","category-integration","category-internet-of-things"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/455","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=455"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/455\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}