Application Integration & APIs

Why This Phase Exists

Decoupled architectures are resilient architectures. A monolithic application where every component calls every other component directly is a single point of failure away from total outage. When Service A makes a synchronous HTTP call to Service B, and Service B is down for 30 seconds, Service A fails too. When Service B sits behind a queue, Service A drops a message and moves on. Service B processes that message whenever it recovers. No cascading failure. No pager going off at 3 AM because one microservice had a bad deployment.

This principle scales from two services to two thousand. Every major distributed system on the planet, from global e-commerce platforms to real-time financial exchanges, runs on decoupled communication patterns. Services communicate through load balancers, API gateways, message queues, event buses, and orchestration engines rather than through direct point-to-point connections. The result is that individual components can fail, scale, deploy, and evolve independently without requiring coordination across teams.

AWS provides a complete portfolio of integration services because different communication patterns solve different problems. A request that needs a synchronous response within 50 milliseconds requires a load balancer. A request that can tolerate seconds of delay benefits from a queue. An event that must fan out to 15 downstream consumers simultaneously needs a notification service. A multi-step workflow with branching logic and error handling demands an orchestration engine. Selecting the wrong integration pattern for a given communication need is one of the most expensive architectural mistakes you can make, because it forces you to fight the technology rather than use it.

This phase teaches you every integration pattern in the AWS ecosystem. You will learn when to use synchronous request routing (ALB, NLB, API Gateway), when to use asynchronous messaging (SQS, SNS), when to use event-driven architectures (EventBridge), and when to use workflow orchestration (Step Functions). By the end, you will design communication patterns between services with the same precision you apply to database selection or compute sizing.

What You Will Master

By the end of Phase 6, you will be able to:

• Configure Application Load Balancers with path-based routing, host-based routing, weighted target groups, and authentication integration to distribute Layer 7 traffic across microservices
• Deploy Network Load Balancers with static IPs and ultra-low latency for TCP/UDP workloads that need millions of connections per second
• Design API Gateway configurations with proper authorization, throttling, caching, and stage management for both REST and HTTP API types
• Implement SQS queues with dead-letter queues, visibility timeouts, and FIFO ordering guarantees to decouple producers from consumers
• Build SNS fan-out architectures that deliver a single event to multiple subscribers across different protocols simultaneously
• Architect EventBridge event buses with content-based filtering rules that route events to the correct targets without coupling producers to consumers
• Orchestrate multi-step workflows with Step Functions using parallel execution, error handling, retry policies, and human approval gates
• Select the correct integration pattern (synchronous routing, async messaging, pub/sub, event-driven, orchestration) for any inter-service communication requirement on the first attempt

Modules in This Phase

The Progressive Path

This phase follows a deliberate progression from synchronous request routing to asynchronous event-driven patterns to workflow orchestration.

Modules 35 and 36 cover load balancing. You start with ALB because it operates at Layer 7 (HTTP/HTTPS) and handles the most common routing scenarios: distributing web traffic, routing to microservices based on URL path or hostname, and integrating with Auto Scaling and containers. Module 36 introduces NLB for Layer 4 use cases where you need static IPs, extreme performance, or protocol support beyond HTTP. You must understand ALB first because the decision between ALB and NLB requires understanding what ALB can and cannot do.

Module 37 introduces API Gateway as the managed API front door. API Gateway serves a different role than ALB. Where ALB distributes traffic to backend targets, API Gateway adds API-specific capabilities: request validation, transformation, authorization, throttling, caching, and API versioning. It is the standard entry point for serverless architectures (API Gateway + Lambda) and for any workload that exposes a formal API contract to consumers. Understanding ALB concepts from Module 35 helps you differentiate when API Gateway is the better choice.

Module 38 pivots to asynchronous communication with SQS. This is the inflection point of the phase. Everything before Module 38 is synchronous: a request comes in, gets routed, and expects a response. SQS introduces the pattern where a producer drops a message and walks away. The consumer processes it later. This decoupling is what makes systems resilient to spikes, failures, and variable processing times.

Module 39 introduces SNS as the pub/sub complement to SQS. Where SQS is point-to-point (one message, one consumer), SNS is one-to-many (one message, many subscribers). The SNS + SQS fan-out pattern is one of the most important architectural patterns in AWS, enabling you to broadcast an event to multiple independent processing pipelines.

Module 40 covers EventBridge, the evolution of event-driven architecture. EventBridge goes beyond SNS by providing content-based filtering (subscribers receive only events matching specific patterns), a schema registry (consumers know the shape of events without reading source code), and native integration with over 100 AWS services as event sources. It represents the modern approach to event-driven architectures on AWS.

Module 41 introduces Step Functions for workflow orchestration. When your business process requires multiple steps with branching logic, error handling, retries, timeouts, and parallel execution, you need an orchestration engine rather than a message queue. Step Functions lets you express complex workflows as state machines with visual monitoring and built-in error recovery.

Module 42 concludes the phase by covering additional integration services (AppSync for GraphQL APIs, Kinesis for real-time streaming, and the decision framework for choosing between all integration services covered in this phase).

Services You Will Command

Application Load Balancer (ALB)

ALB operates at Layer 7 of the OSI model, understanding HTTP and HTTPS protocols. It routes requests to targets based on the content of the request: URL path, hostname, HTTP headers, query strings, and source IP. ALB supports advanced features including weighted target groups for blue/green deployments, built-in authentication with Cognito and OIDC providers, WebSocket connections, HTTP/2, and gRPC. It integrates natively with ECS for dynamic port mapping, making it the default load balancer for containerized microservices.

Network Load Balancer (NLB)

NLB operates at Layer 4, routing TCP, UDP, and TLS connections based on IP protocol data. It handles millions of requests per second with ultra-low latency (single-digit milliseconds added), provides static IP addresses (one per Availability Zone), preserves the client source IP, and supports PrivateLink for exposing services to other VPCs without traversing the public internet. NLB is the correct choice for non-HTTP protocols, extreme performance requirements, and scenarios requiring static endpoint IPs.

Amazon API Gateway

API Gateway is a fully managed service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. It handles all the cross-cutting concerns of API management: authentication, authorization, throttling, request validation, response caching, custom domain names, and API versioning. For serverless architectures, API Gateway paired with Lambda provides a zero-infrastructure API that scales from zero to millions of requests automatically.

Amazon SQS

Simple Queue Service is a fully managed message queuing service that decouples senders from receivers. Standard queues provide nearly unlimited throughput with at-least-once delivery. FIFO queues guarantee exactly-once processing and strict ordering. SQS eliminates the complexity of managing message infrastructure while providing dead-letter queues for failed messages, long polling for efficient consumers, and visibility timeouts that prevent duplicate processing.

Amazon SNS

Simple Notification Service is a fully managed pub/sub messaging service that delivers messages to multiple subscribers simultaneously. A single message published to an SNS topic can fan out to SQS queues, Lambda functions, HTTP endpoints, email addresses, SMS, and mobile push notifications. Message filtering policies allow subscribers to receive only the subset of messages they care about, reducing unnecessary processing.

Amazon EventBridge

EventBridge is a serverless event bus that connects applications using events. It receives events from AWS services, SaaS applications, and your own applications, then routes them to targets based on rules you define. Content-based filtering evaluates the JSON structure of each event against pattern-matching rules, delivering only relevant events to each target. The schema registry discovers and stores event schemas automatically, and archive/replay capabilities let you reprocess historical events.

AWS Step Functions

Step Functions is a serverless orchestration service that lets you combine AWS Lambda functions, ECS tasks, API calls, and other AWS services into workflows defined as state machines. Standard workflows support long-running processes (up to one year) with exactly-once execution. Express workflows handle high-volume, short-duration event processing. Built-in error handling, retries, timeouts, parallel execution, and Map state for dynamic iteration make Step Functions the correct choice for any multi-step business process.

AWS AppSync

AppSync is a fully managed GraphQL API service that connects applications to data sources including DynamoDB, Lambda, RDS, HTTP endpoints, and OpenSearch. It handles real-time subscriptions over WebSocket, offline data synchronization for mobile applications, and field-level resolver mapping. AppSync is the correct choice when your API consumers need flexible query capabilities and real-time data.

Amazon Kinesis

Kinesis provides real-time data streaming for collecting, processing, and analyzing streaming data at any scale. Kinesis Data Streams captures gigabytes of data per second from hundreds of thousands of sources. Kinesis Data Firehose delivers streaming data to S3, Redshift, OpenSearch, and Splunk without writing consumer applications. Kinesis is the correct choice when you need to process data continuously as it arrives rather than in batches.

Architecture Context

Phase 6 connects everything you built in prior phases into cohesive, production-grade architectures.

The load balancers from Modules 35 and 36 sit in the public subnets you designed in Phase 2 (Networking), distributing traffic to compute targets in private subnets. Security groups from Phase 3 (Network Security) control which targets ALBs and NLBs can reach. Auto Scaling groups from Phase 4 (Compute) register with target groups automatically, and containerized services from Phase 4 use dynamic port mapping with ALB.

API Gateway from Module 37 invokes the Lambda functions you built in Phase 4 (Serverless) and authenticates requests using Cognito user pools and IAM roles from Phase 2 (IAM). SQS and SNS from Modules 38 and 39 decouple the microservices you containerized in Phase 4, allowing them to communicate without direct dependencies. EventBridge from Module 40 captures events from the AWS services you have deployed across all prior phases. Step Functions from Module 41 orchestrates Lambda functions and ECS tasks into business workflows.

Looking ahead, the integration patterns from this phase become the communication backbone for monitoring architectures (Phase 7), where CloudWatch alarms trigger SNS notifications and EventBridge routes operational events. Cost optimization (Phase 8) will examine the pricing models of each integration service and when to choose one over another based on volume. The capstone architecture projects will combine load balancing, API management, messaging, and orchestration into complete production systems.

Phase Exam

After completing all eight modules, you will take the Phase 6 Application Integration & APIs exam:

• 35 multiple-choice questions covering all integration services, routing decisions, messaging patterns, and architectural trade-offs from this phase
• 55 minutes time limit
• 70% pass threshold (25/35 correct)
• Questions emphasize pattern selection (when to use ALB vs NLB vs API Gateway, when to use SQS vs SNS vs EventBridge, synchronous vs asynchronous decisions)
• Expect scenario-based questions that present a communication requirement and ask you to select the correct integration service, configuration, or architectural pattern
• ALB routing rules, API Gateway authorization models, SQS/SNS fan-out patterns, EventBridge filtering, and Step Functions error handling are heavily represented