AWS Certification – Application Services – Cheat Sheet

SQS

  • extremely scalable queue service and potentially handles millions of messages
  • helps build fault tolerant, distributed loosely coupled applications
  • stores copies of the messages on multiple servers for redundancy and high availability
  • supports two queue types:
    • Standard Queues – guarantee At-Least-Once Delivery with best-effort ordering
    • FIFO Queues – guarantee Exactly-Once Processing and strict message ordering
  • supports multiple readers and writers interacting with the same queue at the same time
  • holds message for 4 days, by default, and can be changed from 1 min – 14 days after which the message is deleted
  • maximum message size is 1 MiB for both Standard and FIFO queues (increased from 256 KB in Aug 2025)
  • message needs to be explicitly deleted by the consumer once processed
  • allows send, receive and delete batching which helps club up to 10 messages in a single batch (up to 256 KB total payload per batch) while charging price for a single message
  • handles visibility of the message to multiple consumers using Visibility Timeout, where the message once read by a consumer is not visible to the other consumers till the timeout occurs
  • can handle load and performance requirements by scaling the worker instances as the demand changes (Job Observer pattern)
  • message sampling allowing short and long polling
    • returns immediately vs waits for fixed time for e.g. 20 secs
    • might not return all messages as it samples a subset of servers vs returns all available messages
    • repetitive vs helps save cost with long connection
  • supports delay queues to make messages available after a certain delay, can be used to differentiate from priority queues
  • supports dead letter queues (DLQ), to redirect messages which failed to process after certain attempts instead of being processed repeatedly
  • supports DLQ redrive via the StartMessageMoveTask API to move messages from DLQ back to the source queue or a custom destination (supported for both Standard and FIFO queues)
  • FIFO Queue High Throughput Mode
    • supports up to 70,000 transactions per second (TPS) per API action without batching
    • up to 700,000 messages per second with batching
    • available in selected regions (US East, US West, Europe Ireland)
  • Fair Queues (2025) – mitigates noisy neighbor impact in multi-tenant systems by automatically detecting and deprioritizing tenants that generate excessive traffic, improving quality of service for other tenants
  • supports dual-stack (IPv4 and IPv6) endpoints
  • Lambda integration – supports provisioned mode for SQS event source mapping providing 3x faster scaling and 16x higher concurrency for event processing
  • supports server-side encryption (SSE) using AWS KMS keys
  • Design Patterns
    • Job Observer Pattern can help coordinate number of EC2 instances with number of job requests (Queue Size) automatically thus improving cost effectiveness and performance
    • Priority Queue Pattern can be used to setup different queues with different handling either by delayed queues or low scaling capacity for handling messages in lower priority queues

SNS

  • delivery or sending of messages to subscribing endpoints or clients
  • publisher-subscriber (pub/sub) model
  • Producers and Consumers communicate asynchronously with subscribers by producing and sending a message to a topic
  • supports two topic types:
    • Standard Topics – best-effort ordering, at-least-once delivery, nearly unlimited throughput
    • FIFO Topics – strict message ordering, exactly-once delivery, message deduplication
  • supported subscription protocols: Email (plain or JSON), HTTP/HTTPS, SMS, SQS, Lambda, Kinesis Data Firehose
  • supports Mobile Push Notifications to push notifications directly to mobile devices with services like Amazon Device Messaging (ADM), Apple Push Notification Service (APNS), Firebase Cloud Messaging (FCM) etc.
  • Message Filtering – subscription filter policies allow subscribers to receive only a subset of messages published to the topic
    • supports filtering on message attributes or message body (filter policy scope)
    • up to 200 filter policies per topic, 10,000 per account
  • Message Archiving and Replay (FIFO topics) – stores messages within the topic archive for up to 365 days and allows subscribers to replay them on demand for recovery or state synchronization
  • High-Throughput Mode for FIFO Topics (Jan 2025) – increases throughput from default 300 MPS per message group to much higher levels by setting FifoThroughputScope to MessageGroup
  • Cross-Region delivery – supports delivery from an SNS topic in one opt-in Region to an SQS queue in another opt-in Region
  • integrated with Lambda to invoke functions on notifications
  • for Email notifications, use SNS or SES directly, SQS does not work

SWF

⚠️ Note: AWS recommends AWS Step Functions for most new workflow and orchestration needs. SWF is still supported but is no longer the preferred service. Consider Step Functions for new implementations.

  • orchestration service to coordinate work across distributed components
  • helps define tasks, stores, assigns tasks to workers, define logic, tracks and monitors the task and maintains workflow state in a durable fashion
  • helps define tasks which can be executed on AWS cloud or on-premises
  • helps coordinating tasks across the application which involves managing intertask dependencies, scheduling, and concurrency in accordance with the logical flow of the application
  • supports built-in retries, timeouts and logging
  • supports manual tasks (human-in-the-loop)
  • Characteristics
    • deliver exactly once
    • uses long polling, which reduces number of polls without results
    • Visibility of task state via API
    • Timers, signals, markers, child workflows
    • supports versioning
    • keeps workflow history for a user-specified time
  • AWS SWF vs AWS SQS
    • task-oriented vs message-oriented
    • track of all tasks and events vs needs custom handling

Step Functions

  • recommended replacement for SWF for most workflow orchestration use cases
  • serverless visual workflow service to build distributed applications, automate processes, orchestrate microservices, and create data/ML pipelines
  • uses Amazon States Language (ASL) JSON-based language to define state machines
  • supports two workflow types:
    • Standard Workflows – long-running (up to 1 year), exactly-once execution, full execution history
    • Express Workflows – high-volume, short-duration (up to 5 min), at-least-once execution
  • native integrations with 220+ AWS services without custom glue code
  • supports HTTPS endpoints for calling third-party APIs directly
  • Distributed Map state for large-scale parallel processing (e.g., processing millions of S3 objects)
  • built-in error handling with Retry and Catch mechanisms
  • provides visual workflow editor and execution visualization for debugging
  • Step Functions vs SWF
    • JSON-based state machine vs programmatic deciders/workers
    • serverless, managed vs requires custom worker hosts
    • 220+ AWS integrations vs custom integration code
    • visual debugging vs API-based visibility

SES

  • highly scalable and cost-effective email service
  • SESv2 API is the recommended API – all new features are only available through SESv2 (SESv1 still supported but not receiving new capabilities)
  • uses content filtering technologies to scan outgoing emails to check standards and email content for spam and malware
  • supports full-fledged emails to be sent as compared to SNS where only the message is sent in Email
  • ideal for sending bulk emails at scale
  • guarantees first hop
  • eliminates the need to support custom software or applications to do heavy lifting of email transport
  • Virtual Deliverability Manager (VDM) – automatically adjusts email sending in real time to improve inbox placement
    • provides deliverability insights, optimization recommendations, and detailed dashboards
    • tracks open/click rates, bounce/complaint rates at ISP and configuration level
    • Advisor feature provides configuration recommendations for improved deliverability
  • Mail Manager (2024) – advanced email routing and archiving capabilities
    • supports rule-based email processing with actions (invoke Lambda, bounce, archive)
    • Ingress Endpoint with optional TLS and mutual TLS (mTLS) certificate-based authentication
    • simplifies email infrastructure migrations
  • supports both sending and receiving emails – incoming email can integrate with S3, Lambda, and SNS
  • available in multiple AWS regions globally

EventBridge

  • serverless event bus for building event-driven architectures (evolved from CloudWatch Events)
  • supports custom events, AWS service events, and SaaS partner integrations (Stripe, Datadog, Zendesk, etc.)
  • Event Bus – receives events and routes them to target services based on rules
  • Rules – match incoming events using event patterns and route to one or more targets
  • Schema Registry – automatically discovers and stores event schemas
  • EventBridge Pipes – point-to-point integrations between event producers and consumers with optional filter, transform, and enrich steps (without writing custom code)
  • EventBridge Scheduler – fully managed cron and rate-based scheduling for one-time or recurring tasks
  • supports targets including Lambda, Step Functions, SQS, SNS, Kinesis, ECS, and more
  • EventBridge vs SNS
    • content-based filtering on event structure vs attribute-based filtering
    • supports SaaS partner event sources vs no SaaS partner integration
    • schema discovery and registry vs no schema management
    • single target per rule (fan-out via multiple rules) vs fan-out to multiple subscribers per topic

9 thoughts on “AWS Certification – Application Services – Cheat Sheet

  1. Worth mentioning about ReceiveMessageWaitTimeSeconds – w.r.t long polling – saving CPU cycles for a EC2 consumer.

  2. holds message for 4 days, by default, and can be changed from 1 min – 14 days after which the message is deleted
    message needs to be explicitly deleted by the consumer once processed

    Hi Jayendra,
    Can you clarify on the above? Are the messages deleted automatically after 14 days or needs to be explicitly deleted by the consumer after processing the job. Thanks.

  3. For SQS you say…
    supports multiple readers and writers interacting with the same queue as the same time

    Does this not conflict with your SQS comparison with Kinesis Streams on that page? There it says 1 queue for 1 consumer for SQS vs many applications can read from Kinesis Stream.

    Appreciate if you can clarify.

    1. Hi Grif, the statement is “Kinesis supports multiple consumers while SQS allows the messages to be delivered to only one consumer at a time”.
      SQS is a queue where the message can be consumed by a single consumer at a time, after which it should be deleted.
      Kinesis is more like a messaging system for e.g. Kafka, which holds the message and multiple consumers can read the same message.

Comments are closed.