Move from Amazon SQS and SNS
You can move one application at a time, without downtime, by running both side by side.
How the concepts map
| Amazon | SharkMQ |
|---|---|
| AWS account | Your broker (one private space) |
| IAM user / access key | A SharkMQ user, with an access key id and secret |
| IAM policy | The user's configure / write / read permissions |
| SQS queue / SNS topic | Same names and the same API calls |
| Region | Not needed: one endpoint, replicated across three buildings |
Step by step
- Create users in the portal, one per application, with the permissions it needs.
- Create your queues and topics under the same names (your code may already do this at start-up).
- Move consumers first. Point one worker at SharkMQ (endpoint, key, secret). It waits for messages.
- Move the producers of that queue. New messages now go to SharkMQ.
- Drain Amazon. Keep an old worker on the Amazon queue until it stays empty, then switch it off.
- Repeat for the next queue. Delete the Amazon resources at the end.
Check before you switch
- Your AWS SDK is from 2023 or later.
- You do not need FIFO queues, per-message delays or HTTPS/email/SMS subscriptions yet (see Use Your Existing Amazon SQS Code and SNS Topics and Subscriptions).
- Mobile apps that call SNS directly with Amazon Cognito credentials need a small change: let your own backend publish for them, since SharkMQ users are not given to devices.