Simple Message Queue (SMQ, formerly MNS) offers seamless data migration from services like AWS Simple Queue Service (SQS) or AWS Simple Notification Service (SNS). This topic describes the differences between SMQ, Amazon SQS, and Amazon SNS based on features, limits, and SDKs. It also walks you through the process of migrating data from Amazon SQS or Amazon SNS to SMQ.
Background information
SMQ, Amazon SQS, and Amazon SNS share similar messaging capabilities:
SMQ provides both the queue-based messaging model and the topic-based messaging model.
Amazon SQS provides the queue-based messaging model.
Amazon SNS provides the topic-based messaging model.
Because the services overlap in functionality, migrating from Amazon SQS or Amazon SNS to SMQ is straightforward. The sections below help you understand the differences and plan your migration.
Prerequisites
Before you begin the migration, make sure you have completed the following:
An Alibaba Cloud account with SMQ activated. For more information, see Activate SMQ and authorize RAM users to access SMQ.
An inventory of your existing Amazon SQS queues and Amazon SNS topics, including their configurations (retention periods, visibility timeouts, delay settings, subscription endpoints, and retry policies).
Access credentials for both your AWS environment and your Alibaba Cloud environment.
A clear understanding of your current message producers and consumers, so you can plan the dual-read and dual-write cutover.
Concept mapping
The following table maps key concepts between Amazon SQS/Amazon SNS and SMQ. Although many features are functionally equivalent, pay attention to the behavioral differences noted in the third column.
| AWS concept | SMQ equivalent | Behavioral differences |
|---|---|---|
| SQS Standard Queue | SMQ Queue (queue-based messaging model) | Both support Active, Inactive, Deleted, and Expired message states. SMQ has a default visibility timeout of 30 seconds; Amazon SQS does not define a default. |
| SQS FIFO Queue | SMQ FIFO Queue (sequencing) | Both supported. |
| SQS Dead-letter Queue | SMQ Dead-letter Queue | Both supported. |
| SNS Topic | SMQ Topic (topic-based messaging model) | SMQ topic names are not case-sensitive (1-120 characters). Amazon SNS topic names are case-sensitive (3-64 characters). |
| SNS FIFO Topic | SMQ FIFO Topic (sequencing) | Both supported. |
| SNS Subscription (JSON filter policy) | SMQ Subscription (tag-based filtering) | Data filtering differs: SMQ uses tag-based filtering. Amazon SNS uses JSON policy-based filtering. You will need to convert filter logic during migration. |
| SNS Subscription endpoints (Queue, HTTP, SMS, Email, Mobile push, Lambda) | SMQ Subscription endpoints (Queue, HTTP, Text message, Email, Mobile push, Function Compute) | Amazon SNS integrates with AWS Lambda; SMQ integrates with Function Compute. |
| SNS Dead-letter Queue | SMQ Dead-letter Queue (topic model) | Both supported. |
Comparison of features
The following table compares the features of SMQ, Amazon SQS, and Amazon SNS by queue-based messaging model and topic-based messaging model.
Queue-based messaging model
| Feature | SMQ | Amazon SQS |
|---|---|---|
| Message lifecycle | Supported. The message state machine has the following states: Active, Inactive, Deleted, and Expired. | Supported. The message state machine has the following states: Active, Inactive, Deleted, and Expired. |
| Custom retention period for messages | Supported | Supported |
| Message delay (scheduled period) | Supported | Supported |
| Visibility timeout period | Supported | Supported |
| Maximum message length | Supported | Supported |
| Dead-letter queue | Supported | Supported |
| FIFO queue (sequencing) | Supported | Supported |
Topic-based messaging model
| Feature | SMQ | Amazon SNS |
|---|---|---|
| Data filtering | Data filtering by tag | Data filtering by JSON policy |
| Queue subscription | Supported | Supported |
| HTTP subscription | Supported | Supported |
| Text message subscription | Supported | Supported |
| Email subscription | Supported | Supported |
| Mobile push | Supported | Supported |
| Function Compute | Supported | Supported |
| Dead-letter queue | Supported | Supported |
| FIFO topic (sequencing) | Supported | Supported |
Comparison of limits
Review these limits carefully as some differences may affect your migration plan. The following tables compare the limits of SMQ, Amazon SQS, and Amazon SNS by messaging model.
Queue-based messaging model limits
| Limit | SMQ | Amazon SQS |
|---|---|---|
| Queue naming | Queue names are case-sensitive. Each name must be 1 to 120 characters in length. | Queue names are case-sensitive. Each name must be 1 to 80 characters in length. |
| Message retention period | 7 days | 14 days |
| Long polling interval | Valid values: 0 to 30. Default value: 15. Unit: seconds. | Valid values: 0 to 20. Unit: seconds. |
| Maximum message payload | 64 KB. If you want to increase the maximum message payload, submit a ticket. | 256 KB |
| Visibility timeout period | Valid values: 1 to 43200. Default value: 30. Unit: seconds. | Valid values: 1 to 43200. Unit: seconds. No default value is defined. |
| Queue ID | Each queue name is unique for a region. Each message ID is globally unique. The name of each receipt handle is a custom string. | Each queue name is unique for a region. Each message ID is globally unique. The name of each receipt handle is a custom string. |
| Message delay | The DelaySeconds parameter specifies the message delay. Valid values: 0 to 604800. Unit: seconds. | The DelaySeconds parameter specifies the message delay. Valid values: 0 to 604800. Unit: seconds. |
| Maximum number of accumulated messages | No limit | No limit |
| Maximum queries per second (QPS) | No limit is imposed on the queue resources used by users. The QPS of queue-based messaging and topic-based messaging is limited, up to 20,000 for each Alibaba Cloud account in each region. For more information, see Throttling policy. | No limit |
Topic-based messaging model limits
| Limit | SMQ | Amazon SNS |
|---|---|---|
| Topic name | Each topic name must be 1 to 120 characters in length. Topic names are not case-sensitive. | Each topic name must be 3 to 64 characters in length. Topic names are case-sensitive. |
| Maximum message length | 64 KB | 256 KB |
| Retry policy | Backoff mode: The system performs three retries. The interval between two consecutive retries ranges from 10 seconds to 20 seconds. Exponential decay mode: The system performs 176 retries within only one day. | Backoff mode: The system performs three retries. The interval between two consecutive retries is 20 seconds. Exponential decay mode: You can change the number of retries. |
| Maximum number of subscriptions to a single topic | 100. If you want to increase the limit, you can submit a ticket. | 12500000 |
| Maximum QPS | No limit is imposed on the queue resources used by users. The QPS of queue-based messaging and topic-based messaging is limited, up to 20,000 for each Alibaba Cloud account in each region. For more information, see Throttling policy. | 300 QPS per topic or 10 MB/s. The system starts to count when a topic receives the first query. |
Key limit differences and workarounds
When planning your migration, pay special attention to these significant limit differences:
Maximum message payload (64 KB vs. 256 KB): SMQ has a default maximum message payload of 64 KB, compared to 256 KB for Amazon SQS and Amazon SNS. If your current workloads send messages larger than 64 KB, you can submit a ticket to request a higher limit. Alternatively, you can store large message bodies in Alibaba Cloud OSS and pass the object reference in the message, similar to the Amazon SQS Extended Client Library pattern. For more information, see Transmit oversized messages.
Maximum subscriptions per topic (100 vs. 12,500,000): SMQ supports up to 100 subscriptions per topic by default, compared to 12,500,000 for Amazon SNS. If your topics have more than 100 subscribers, you can submit a ticket to increase the limit.
Message retention period (7 days vs. 14 days): SMQ retains messages for up to 7 days, whereas Amazon SQS retains messages for up to 14 days. Make sure your consumers can process messages within the 7-day window, or adjust your processing pipeline accordingly.
Data filtering mechanism: SMQ uses tag-based data filtering for topic subscriptions, while Amazon SNS uses JSON policy-based filtering. You will need to redesign your filter logic when migrating subscriptions.
Comparison of SDKs
The following table compares the SDKs available for SMQ, Amazon SQS, and Amazon SNS.
| SDK | Alibaba Cloud SMQ | Amazon SQS | Amazon SNS |
|---|---|---|---|
| API operations | API reference | API reference | API reference |
| HTTP SDK | SDK for Java, SDK for Python, SDK for C#, SDK for PHP, SDK for C++, SDK for Go, and SDK for JMS | SDK for Java, SDK for JavaScript, SDK for PHP, SDK for Python, SDK for Ruby, and SDK for .NET | SDK for Java, SDK for JavaScript, SDK for PHP, SDK for Python, SDK for Ruby, and SDK for .NET |
Migration process
To ensure that your applications are smoothly migrated from Amazon SQS or Amazon SNS to SMQ, we recommend that you synchronize queues, topics, and subscribed metadata between the services. Then, enable the dual-read and dual-write policies on the application side to migrate data. The following figure shows the process of how data is migrated from Amazon SQS to SMQ.
The migration process consists of four stages. For each stage, we describe the goal, the actions you need to take, and the exit criteria before moving to the next stage.
Stage 1: Existing workloads produce and consume messages through Amazon SQS
Goal: Establish your baseline and prepare SMQ resources.
Actions:
Inventory all Amazon SQS queues and Amazon SNS topics in your AWS environment. Record their configurations including retention periods, visibility timeouts, delay settings, and subscriptions.
Create corresponding queues and topics in SMQ with equivalent configurations. Pay attention to the limit differences described above (message payload size, subscription limits, retention periods).
Synchronize subscription metadata. Convert Amazon SNS JSON filter policies to SMQ tag-based filters where applicable.
Set up monitoring for both the AWS and SMQ environments so you can compare message flow during the migration.
Exit criteria: SMQ queues and topics are created and configured. Monitoring is in place for both environments.
Stage 2: Consumer services simultaneously consume messages from both Amazon SQS and SMQ
Goal: Enable dual-read so that consumers process messages from both services.
Actions:
Update your consumer applications to read from both Amazon SQS and SMQ queues (dual-read). This ensures consumers are ready to handle messages from SMQ before any producers switch over.
Validate that messages published to SMQ are consumed correctly. Verify message format compatibility, acknowledgment behavior, and error handling.
Monitor consumer lag and error rates on both sides to confirm that SMQ consumption is stable.
Exit criteria: Consumers successfully process messages from SMQ with no errors for a sustained period.
Stage 3: Producer services are connected to SMQ
Goal: Switch producers to write to SMQ while maintaining dual-read on the consumer side.
Actions:
Update your producer applications to publish messages to SMQ instead of (or in addition to) Amazon SQS.
If you are running dual-write (writing to both Amazon SQS and SMQ simultaneously), monitor both message flows to confirm that messages arrive correctly in SMQ.
Once producers are fully switched to SMQ, you can stop dual-write. Consumers should continue dual-read to drain any remaining messages from Amazon SQS.
Exit criteria: All producers are successfully publishing to SMQ. Message delivery is confirmed through monitoring.
Stage 4: Producer services are disconnected from Amazon SQS after existing messages are consumed
Goal: Complete the migration by decommissioning the Amazon SQS/Amazon SNS resources.
Actions:
Wait for all remaining messages in Amazon SQS queues to be consumed. Monitor the queue depth to confirm it reaches zero.
Once no messages remain, remove the dual-read logic from your consumer applications so they only read from SMQ.
Decommission the Amazon SQS queues and Amazon SNS topics in AWS.
Update your documentation and runbooks to reflect the new SMQ-based architecture.
Exit criteria: All Amazon SQS/Amazon SNS resources are decommissioned. All producers and consumers operate exclusively through SMQ.
Testing and validation
Before and during the migration, perform the following tests to ensure data integrity and application stability:
Functional testing: Send test messages through SMQ and verify that consumers receive and process them correctly. Confirm that message attributes, delays, and visibility timeouts behave as expected.
Filter validation: If you use data filtering, verify that your SMQ tag-based filters produce the same results as your Amazon SNS JSON policy filters.
Performance testing: Compare message throughput and latency between your Amazon SQS/Amazon SNS setup and SMQ. Keep in mind the SMQ QPS limit of 20,000 per Alibaba Cloud account per region. For more information, see Throttling policy.
Dead-letter queue testing: Deliberately send malformed or unprocessable messages to verify that dead-letter queues in SMQ capture them correctly.
Retry behavior testing: Verify that the retry policy (backoff mode and exponential decay mode) meets your application requirements. Note the differences in retry intervals and counts between SMQ and Amazon SNS.
Monitoring and alerting: Confirm that your monitoring tools correctly capture SMQ metrics (message count, consumer lag, error rates) and that alerts fire as expected.
Rollback readiness: During Stage 2 and Stage 3, keep your Amazon SQS/Amazon SNS resources active. If you encounter issues with SMQ, you can revert producers to Amazon SQS and consumers to dual-read or Amazon SQS-only mode until the issue is resolved.