Event-Driven Architecture on AWS with EventBridge and SQS

By Khimananda Oli | Last reviewed: August 2026

Building resilient distributed systems requires decoupling producers from consumers, and implementing event-driven architecture on AWS with EventBridge and SQS is currently the most effective pattern for this in 2026. Direct service-to-service calls create brittle dependencies that fail under load or during deployments; replacing them with an asynchronous event bus and durable queues eliminates these bottlenecks while improving auditability. This guide walks through the exact infrastructure-as-code configurations, routing rules, and failure handling strategies I use in production to replace fragile synchronous chains with reliable async workflows.

How does event-driven architecture on AWS with EventBridge and SQS actually work?

At its core, this pattern separates the "what happened" (event) from the "what to do next" (command). Amazon EventBridge acts as the serverless event bus that receives structured JSON events from any source—your application, SaaS partners, or other AWS services. It evaluates these events against defined rules and routes matching payloads to targets. Amazon SQS serves as the durable buffer target, holding messages until downstream workers are ready to process them. This combination prevents backpressure from crashing upstream services and provides natural retry semantics.

In practice, you should never connect EventBridge directly to Lambda for high-throughput paths without an SQS buffer. Lambda concurrency limits can throttle your entire pipeline during spikes. SQS absorbs the burst, allowing workers to poll at their own sustainable pace. For teams transitioning from monoliths, this mirrors the Laravel queues and jobs background processing pattern but operates at the infrastructure level rather than within a single application runtime.

How do you provision EventBridge and SQS with Terraform securely?

Infrastructure as Code is non-negotiable for production event systems. Manual console clicks lead to permission drift and unreproducible outages. Below is a battle-tested Terraform module structure that enforces least-privilege access and enables server-side encryption by default. Always define your resources declaratively; see my guide on infrastructure as code with Terraform for foundational principles.

resource "aws_sqs_queue" "order_processing" {
  name                       = "order-processing-queue"
  visibility_timeout_seconds = 300
  message_retention_seconds  = 1209600 # 14 days
  receive_wait_time_seconds  = 20      # Long polling enabled
  
  # Mandatory encryption for compliance
  kms_master_key_id                 = aws_kms_key.event_bus_key.id
  kms_data_key_reuse_period_seconds = 300
  
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.order_processing_dlq.arn
    maxReceiveCount     = 5
  })
}

resource "aws_cloudwatch_event_rule" "order_created" {
  name        = "order-created-rule"
  description = "Routes OrderCreated events to processing queue"
  event_bus_name = aws_cloudwatch_event_bus.main.name
  
  event_pattern = jsonencode({
    source      = ["com.myapp.orders"]
    detail-type = ["OrderCreated"]
    detail = {
      region = ["ap-south-1"] # Filter at the bus level
    }
  })
}

resource "aws_cloudwatch_event_target" "order_queue_target" {
  rule      = aws_cloudwatch_event_rule.order_created.name
  arn       = aws_sqs_queue.order_processing.arn
  target_id = "OrderProcessingQueue"
  
  # Transform payload if needed before queuing
  input_transformer {
    input_paths = {
      orderId = "$.detail.orderId"
      amount  = "$.detail.totalAmount"
    }
    input_template = "{\"orderId\":<orderId>, \"amount\":<amount>, \"receivedAt\":\"<time>\"}"
  }
}

Critical IAM permissions for the event target

A common mistake is granting overly broad sqs:SendMessage permissions. The EventBridge service principal must be explicitly allowed to write to your specific queue ARN only. Never use wildcards in production policies.

• Define a resource-based policy on the SQS queue allowing events.amazonaws.com to send messages.
• Scope the condition to your specific EventBridge rule ARN to prevent unauthorized cross-account injection.
• Enable KMS key policies that allow both the producer and EventBridge to generate data keys.
• Tag all resources consistently for cost allocation and automated compliance scanning.

When should you choose EventBridge over SNS or direct SQS?

Choosing the right messaging primitive prevents expensive re-architecture later. While SNS excels at fan-out notifications and direct SQS works for simple point-to-point tasks, event-driven architecture on AWS with EventBridge and SQS shines when routing logic is complex or sources are heterogeneous. Use this comparison to validate your design choice before committing.

If you need to route based on payload content (e.g., "process only orders over $500 from Kathmandu"), EventBridge eliminates custom filtering code in consumers. If you simply need to notify 50 microservices that a user signed up, SNS is cheaper and simpler. For teams optimizing spend, review these cloud cost optimization tactics before scaling event volumes.

How do you handle failures and ensure message durability?

In distributed systems, failure is guaranteed. Your architecture must assume messages will fail processing and provide safe recovery paths without data loss. EventBridge retries failed deliveries to SQS automatically, but once a message lands in the queue, your consumer owns the failure contract.

Configure Dead Letter Queues (DLQ) correctly

Every production SQS queue must have a DLQ attached via the redrive_policy. Set maxReceiveCount based on your idempotency tolerance—typically 3–5 attempts. Messages exceeding this threshold move to the DLQ automatically. Never set this to 1 unless your processing is perfectly idempotent and transient errors are impossible.

Implement idempotent consumers

SQS guarantees at-least-once delivery. Your worker must handle duplicates safely. Use the message's MessageDeduplicationId or a business key (like orderId) to check a DynamoDB or Redis store before processing. If you've already handled this event, delete the message immediately without side effects. This is especially critical when integrating payment or inventory systems where duplicate processing causes financial discrepancies.

Monitor DLQ depth proactively

Create CloudWatch alarms on the ApproximateNumberOfMessagesVisible metric for every DLQ. A non-zero DLQ indicates either a bug in your consumer or a downstream dependency outage. Automate alerts to PagerDuty or Slack; never rely on manual dashboard checks. In regulated environments, DLQ contents often serve as audit evidence for failed transactions.

What are the performance and cost considerations for 2026?

EventBridge charges $1.00 per million events ingested, plus additional fees for API destinations and schema registry operations. SQS standard queues charge $0.40 per million requests after the free tier. For high-volume systems, these costs compound quickly. Enable long polling (ReceiveWaitTimeSeconds = 20) to reduce empty receives by up to 90%. Batch sends using SendMessageBatch to cut API calls by 10x.

Consider EventBridge Pipes for direct SQS-to-SQS or SQS-to-Lambda transformations without custom code. Pipes reduce latency and eliminate intermediate compute costs for simple enrichment tasks. However, avoid over-engineering: if your transformation requires database lookups or complex logic, stick with a dedicated consumer service. Performance tuning should always follow observability; instrument first, optimize second.

Implementing Event-Driven Architecture on AWS with EventBridge and SQS Safely

Adopting event-driven architecture on AWS with EventBridge and SQS transforms how your systems scale and recover from failure, but it demands discipline in configuration and monitoring. Start with Terraform-managed resources, enforce DLQs on every queue, enable encryption at rest, and validate your routing rules with synthetic events before going live. Treat your event schemas as contracts—version them, document them, and test breaking changes in staging first.

If you're designing a new system or migrating a legacy workflow to async patterns, get the foundation right before optimizing. Misconfigured visibility timeouts or missing idempotency checks cause silent data corruption that surfaces months later. Need help architecting this correctly for your specific workload? Reach out to discuss your event-driven infrastructure—I help teams build systems that stay reliable under real-world pressure.