This is a list of our most frequently asked questions. For more information about CloudAMQP, or if you need any support, please visit our support page.
Please note that if you use our service via a marketplace, the answers to some of these FAQs might not be applicable.
CloudAMQP has managed RabbitMQ servers in the cloud-hosted message queues that let you pass messages between processes and other systems. Messages are published to a queue by a producer, the consumers can then get the messages off the queue when the consumer wants to handle the messages. In-between, CloudAMQP can route, buffer, and persist the messages according to rules you give it.
Beginners guide of RabbitMQ can be found in our blog: RabbitMQ for beginners - What is RabbitMQ?
RabbitMQ is a high performance messaging broker. It gives your applications a common platform to send and receive messages.
Messages can be sent cross languages, platforms and OS, this way of handling messages decouple your processes from each other and creates a highly scalable system. RabbitMQ implements the AMQP protocol. All AMQP client libraries work with CloudAMQP and there are AMQP client libraries for almost every platform on the market, including: Ruby, Node.js, Java, Python, Clojure and Erlang.
A message is the data transported between the publisher and the consumer, it's essentially a byte array with some headers on top.
Beginners guide about message queuing can be found in our blog: What is message queuing?
Message queues provide an asynchronous communication protocol. They are used to transmit data between components in an architecture. The concept is that messages are put into a queue and then removed from the queue in a predefined order. Messages placed in the queue are stored until the recipient retrieves them. This way of handling messages decouple the sender from the receiver. The sender and the receiver of the message do not need to interact with the message queue at the same time.
A message brokers purpose is to handle incoming messages from applications and perform some action on them. These actions could, for example, be routed to one or many destinations, provide message routing depending on routing keys, to transform messages to an alternative representation or to respond to events or errors.
AMQP is a protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security. RabbitMQ implements the AMQP protocol. All AMQP client libraries work with CloudAMQP and there are AMQP client libraries for almost every platform out there, including Ruby, Node.js, Java, Python, Clojure and Erlang.
A connection is a TCP connection between your application and the RabbitMQ broker.
A channel is a virtual connection inside a connection (inside of a TCP-connection). A Channel is used to send AMQP commands to the broker. When you are publishing or consuming messages or subscribing to a queue is it all done over a channel.
Imagine that you have a web service that receives many requests every second, where no request is afforded to get lost and all requests need to be processed by a process that is time-consuming.
Imagine that your web service always has to be highly available and ready to receive new request instead of being locked by the processing of previously received requests.
In this case, it is ideal to put a queue between the web service and the processing service. The two processes will be decoupled from each other and do not need to wait for each other. If you have a lot of requests coming in a short amount of time, the processing system will be able to process them all anyway. The queue will persist requests if their number becomes really huge.
You can then imagine that your business and your workload is growing and you need to scale up your system. All that is needed to be done now is to add more workers to work off the queues faster.
In addition to providing a buffer between a web service and another processing service, message queues can be used for more advanced scenarios. RabbitMQ can be configured to route and distribute messages according to different rules and different processes. Messages can be added to different queues depending on how the messages should be handled. The processing systems can then process them at their leisure.
A message queue will keep the processes in your application separated and independent of each other. The first process will never need to invoke another process, or post notifications to another process, or follow the process flow of the other processes. It can just put the message on the queue and then continue processing. The other processes can also handle their work independently. They can take the messages from the queue when they are able to process them.
This way of handling messages creates a system that is easy to maintain and easy to scale.
Instead of building a massive application, is it beneficial to decouple different concerns in your application and only communication between them asynchronously with messages. That way different parts of your application can evolve independently, be written in different languages and/or maintained by separated developer teams.
Messages can be stored-and-forwarded. A message can be redelivered until the message is processed.
Instead of polling your data store, publish a message when new data is inserted. Interested parties will be notified immediately and your data store will be ready to answer qualified queries instead.
Message queueing is the key to make your application scale. As the workload goes up you only have to add more workers to work off the queues faster.
Message queues decouple your processes. If a process that is processing messages from the queue fails, other messages can still be added to the queue and be processed when the system has recovered.
Message queues enable asynchronous processing, meaning that it allows you to put a message on a queue without processing it immediately.
CloudAMQP is an excellent backend for real-time applications. Notifications and message streaming is handled very effectively by RabbitMQ, you will be able to push thousands of messages per second.
Cloud-based messaging will increase the speed of getting the application to the market. Developers can focus on the core part of their applications, instead of managing and maintaining servers and queueing infrastructure, like updates and mirroring of clusters.
Our customers are usually developers who want to focus on the core part of their applications, instead of managing and maintaining servers and queueing infrastructure.
We have customers in a range from large enterprise business and startups to individual hobby developers.
It depends. If you have a 2+ nodes cluster, there will be no downtime during the migration.
If you have a 1-node server, then there will be downtime. How long time it will take depends on the length of the queues you have (usually a short downtime). Please note that messages, exchanges, and queues that are not durable and persistent will be lost during the migration.
Yes, but messages have to be published as "persistent" to durable queues for them to survive the upgrade (or any kind of restart). There will, however, be a minute or two of downtime while the instance is being upgraded.
You can delete an instance from the instances list page. If you remove an instance, your queues, exchanges and bindings will be deleted and we will not be able to restore them.
The admin user must have access to all virtual hosts on the server for the queue and consumer alarms to work correctly.
Queue alarms can be triggered to send notification emails to you and your co-workers when a number of messages in a queue reaches a certain threshold, for a given amount of time.
Consumers alarms can be triggered to send notification emails to you and your co-workers when a number of consumers for a queue is less than or equal to a given number of consumers, for a given amount of time.
(Only for dedicated instances) When the CPU alarm is enabled will you receive a notification email when you are using more than 80% of the available CPU for more than 15 minutes. You can change the level at which the alarm will trigger. It is recommended to enable CPU alarms. It can be enabled through the Control Panel.
(Only for dedicated instances) When the Memory alarm is enabled you will receive a notification email when you are using more than 90% of the available memory for more than 15 minutes. The level can be changed. It is recommended to enable Memory alarms. It can be enabled through the Control Panel. Note: This alarm is calculated from how much memory the underlying virtual machine is using, not what RabbitMQ is using.
Virtual Hosts (vhosts) makes it possible to separate applications on one broker. You can isolate users, exchanges, queues etc to one specific vhost. You can separate environments, e.g. production to one vhost and be staging to another vhost within the same broker, instead of setting up multiple brokers.
vhosts can be added to all dedicated instance. The downside of using a single instance is that there's no resource isolation between virtual hosts.
No, there is no queue or message limit on our dedicated plans. Our dedicated plans (Big Bunny and larger) are not artificially limited in any way, the maximum performance is determined by the underlying instance type.
You will need to take action if that happens. You either need to migrate to a larger plan or find the reasons for the high memory/CPU usage. This blog post describes how to handle and avoid high CPU or memory usage. Alarms can be activated to send notifications when you have high CPU or memory usage, information about that can be found in our monitoring pages. The alarms can be activated from the control panel of your instance.
RabbtitMQ Best Practices information can be found: here.
Get started guide can be found here. Once you have created your account you start queuing and processing by using any of the guides, depending on platform and language. These tutorials cover the basics of creating messaging applications using CloudAMQP.
Yes, custom RabbitMQ plugins can be enabled and disabled from the CloudAMQP Control Panel for dedicated plans, that is Big Bunny and larger. We do support custom plugin installation, send us an email or enter the chat and we will support you.
All our plans have protocol support for AMQP, AMQPS, HTTPS, STOMP and MQTT. Dedicated plans do also have support for WEB-STOMP.
No, you cannot access the nodes via SSH. Let us know if you need to perfom any actions on the server and we will help you.
Yes, it is possible. Port should be 443 and --ssl has to be used. Download the same rabbitmqadmin version as the RabbitMQ version in your cluster. (Can be downloaded from here: https://your_host.rmq.cloudamqp.com/cli/)
The example below shows how to list exchanges:
rabbitmqadmin --host=HOST --port=443 --ssl --vhost=VHOST --username=USERNAME --password=PASSWORD list exchanges
All clusters have nodes in multiple availability zones and have automatic fail-over.
Can I set up nodes in different regions in AWS? CloudAMQP does not support nodes in different regions. However, your nodes will be placed in different Availability Zones in AWS, but not in different regions. Let us know if that is a requirement. We can always help you set up a federation between two different nodes, but it's not always recommended.
There are no limitations in the number of channels per connections on our dedicated plans. We limit all shared plans to 200 channels per connection.
When an instance is marked as impaired by AWS it means that something is wrong with the instance, e.g., the underlying physical hardware was faulty or a faulty network equipment cut off its network.
We automatically restart instances onto new hardware when this happens. All data is always safe as long as you have persistent messages and durable queues.
This is not something we or you can prevent, it's all in the hands of AWS. It does happen but it's rare. However, a 2-node setup will keep your other node up and running when the first node needs to be replaced.
More information can be found here.
You can read about Amazon VPC and VCP peering to CloudAMQP in this blog post.
Dedicated VPC is available as an extra option for our dedicated plans, for $99. A dedicated plan is Big Bunny or any plan larger than Big Bunny. Select to create your cluster in a dedicated VPC. When you create your VPC you get to select the VPC subnet, make sure that it does not overlap with any VPC subnets you want to peer with.
As soon as you have created your instance you can go to your AWS console and create a VPC peering request. Necessary details about your CloudAMQP VPC can be found on the VPC tab in the CloudAMQP console.
When you have created the request it can be accepted from the VPC tab in the CloudAMQP console.
Note: The VPC peering option needs to be added when you create the cluster, it cannot be added afterwards. You will have to create a new cluster in order to add this option, if you didn't already add it.
CloudAMQP is fully integrated with the following platforms:
CloudAMQP is available in following clouds and regions:
AP East 1 (Hong Kong), AP NorthEast 1 (Tokyo) *, AP NorthEast 2 (Seoul), AP South 1 (Mumbai), AP SouthEast 1 (Singapore), AP SouthEast 2 (Sydney), CA Central 1 (Canada), EU Central 1 (Frankfurt), EU North 1 (Stockholm) *, EU West 1 (Ireland) *, EU West 2 (London), EU West 3 (Paris), SA East 1 (São Paulo) *, US East 1 (Northern Virginia) *, US East 2 (Ohio) *, US West 1 (Northern California) *, US West 2 (Oregon) *
Amsterdam 2, Amsterdam 3, Frankfurt 1, London 1, New York 2, New York 3, San Francisco 1, Singapore 1, Toronto 1
Chicago, Dallas, Hong Kong, London, Northern Virginia, Sydney
Asia East 1 (Taiwan) *, Asia East 2 (Hong Kong), Asia Northeast 1 (Tokyo), Asia South 1 (Mumbai), Asia Southeast 1 (Singapore), Australia Southeast 1 (Sydney), Europe North 1 (Finland), Europe West 1 (Belgium) *, Europe West 2 (London), Europe West 3 (Frankfurt), Europe West 4 (Netherlands), Europe West 6 (Zürich), North America Northeast 1 (Montréal, Canada), South America East 1' (São Paulo), US Central (Iowa) *, US East 1 (South Carolina) *, US East 4 (North Virginia), US West 1 (Oregon), US West 2 (Los Angeles)
AMS01 - Amsterdam, Western Europe, DAL01 - Dallas, Central United States, DAL05 - Dallas, Central United States *, DAL06 - Dallas, Central United States, HKG02 - Hong Kong, Asia, HOU02 - Houston, Central United States, LON02 - London, Western Europe *, MEL01 - Melbourne 1, Australia, SEA01 - Seattle, West Coast United States, SJC01 - San Jose, West Coast United States, SNG01 - Singapore, Southeast Asia, TOR01 - Toronto 1, Canada, WDC01 - Washington DC, East Coast United States
Austrailia East, Australia Southeast, Brazil South, Canada Central, Canada East, Central India, Central US, East Asia, East US *, East US 2, Japan East, Japan West, North Central US, North Europe, South Central US, South East Asia, South India, UK South, UK West, West Central US, West Europe, West India, West US, West US 2
* Available regions for shared instances are marked with an asterisk
Your CloudAMQP instance is created in the same cloud and region as your Heroku account. If your application is located in AWS us-east-1, then your CloudAMQP instance is created in the same one.
Full information about web-stomp can be found at our web-stomp page or at RabbitMQ. Web-Stomp is a plugin to RabbitMQ which exposes a WebSockets server (with fallback) so that web browsers can communicate with your RabbitMQ server/cluster directly.
The Web-Stomp plugin is enabled on all dedicated plans (launched after June 2014).
The Web-Stomp plugin is enabled on all dedicated plans (launched since June 2014).
Yes, it is possible to enable from the plugin tab for your CloudAMQP instance.
We do support TLS (SSL). In most clients it is easy to use TLS, just replace amqp:// with amqps:// in the URL.
We normally recommend using TLS with a server-side cert for encryption and then username/password authentication. It is possible to use client certificates, but it's not that easy to maintain a CA in terms of proper certificate generation e.t.c. We normally advise against it as the security benefits are questionable.
More details are found here: http://www.rabbitmq.com/ssl.html
All servers are configured with server certificates signed by a CA found in your default trust store.
If you want to use client certificates we can help you install the public part of the CA on the server and enable peer verification, but you have to manage the certificate generation yourself.
Note: TLS will only secure messages during the transport. What we recommend for highly sensitive information (HIPAA, PCI etc) is that you encrypt your message bodies on your side and that you have a shared key between your publishers and your consumers.
Our servers certificate is signed by one of the common trusted root CAs, Comodo, most OSes/browsers come with the Comodo cert built in. If you don't have a trust store you can download the AddTrust/Comodo root cert here: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/979/108/domain-validation-sha-2
AMQP's messages are just byte arrays, you can send anything, encrypted or not.
For encrypting message bodies we can give you examples if you let us know which language(s), framework(s) you indent to use. Email us at email@example.com and we will help you.
Yes, for dedicated instances in AWS and Azure.
A firewall lets you restrict access to your cluster so that only your servers will have access. You can also set up different ports for different ranges, so, for example, your servers can access port 5762 (AMQP), but the management interface is still open to all.
Configure a firewall for your cluster directly from our UI. You can specify an IP range and decide which ports that should be opened for that range. All other ports to your instance will be closed.
One message is counted as consumed when a message is published from your service to RabbitMQ or when one messages are consumed from RabbitMQ.
If it feels like you are publishing/consuming fewer messages then specified in your CloudAMQP console and if you are using Celery - please check if you have disabled celery events. Celery recommended settings can be found here. Have a look att CELERY_SEND_EVENTS, --without-gossip, -without-mingle and--without-heartbeat.
If you are not using Celery, send us an email and we will have a look at your instance.
The reset is performed the first day every month.
It is only possible to manage users, virtual hosts and permissions on dedicated plans. A dedicated plan is Big Bunny or any plan larger than Big Bunny.
Yes, everything is included in the price. There is no extra cost or payment required for data traffic or to other platforms.
All plans are billed by the second, you can try out even the largest instance types for mere pennies. As soon as you delete the instance you won't be charged for it anymore, i.e. if you had a Big Bunny (for $99/month) running for 15 days, then you will only be charged $49.50.
Billing occurs at the end of each month, and you are only charged for the time an instance has been available to you.
You also have the option to prepay an amount that suits your needs. If you'd like to avoid lots of small transactions, then prepayment is for you. A prepayment can be made for one to several months in advance*.
A customer subscribing to our plan Big Bunny equalling $99/month can choose to make a prepayment of $99*12 (and then skip being charged on a monthly basis for one whole year). One thing that is good to know is that a prepayment will be covering all plans the customer have on his/her account. So let's say that the customer in the example would add another Big Bunny plan to his/her account on month five, then the prepayment will cover both plans for three more months. After that, the customer's prepayment will have been fully spent.
You can pay with VISA, Mastercard, American Express, Maestro, JCB, Diners Club or Invoice/transfer. Contact us at firstname.lastname@example.org if you require invoicing. Payment options can be found under Billing information in the Control Panel. Please note that we don’t accept checks.
No. We don’t provide any reseller discounts at this moment.
No. There is no shipping cost since the service is shipped electronically.
No. The service is non-returnable.
You can choose to pay through credit card (due on charge date) or via wire transfers (NET15). If you would like us to enable manual invoicing via wire transfer - send us an email once you have added all information and we will enable it for you. Please note that we don’t accept checks.
Email email@example.com to receive an official quote. Include what plan you want, if the quote should include VPC or not, and the subscription period.
The service will be provided off-premise in a data center and region chosen on behalf of the customer. The data centers and regions currently provided can be found at the bottom of this page: https://www.cloudamqp.com/plans.html.
Our billing is pro-rated, which means that our customers only pay for the time the service has been available to them and that the payment is done the month after delivery. Thus, you won’t receive your first invoice when the account has been created, you will receive it at the beginning of the upcoming month.
No. It’s very common that our customers change their plan while they are using our service, therefore it’s not convenient to pay for a year upfront. However, we do provide the possibility to make prepayments with credits. More information can be found here: https://www.cloudamqp.com/blog/2017-11-01-prepayment-as-a-payment-option-is-now-available-at-cloudamqp.html.
No. We don’t need any documents with signatures from you.
No. Our active subscriptions are running until they are deleted. The reason for this is that we don’t want to delete our customer’s data when they have an active subscription. So for example, if you’re a reseller and has provided us with a PO that concerns two months usage of our Happy Hippo plan, then you’re responsible for deleting the plan after the two months have passed. Otherwise, we will charge you for the upcoming months.
We have a customer using your service with an active subscription and PO. Now it wants to create one more subscription. Should we extend the current PO or issue a new one?
It’s best to extend the current PO. If you need to have two separate PO’s for the subscriptions, you need to open a new account in order to make the subscriptions be billed separately.
Go to https://customer.cloudamqp.com/login and enter your email address. Fill out all your information in the billing section, such as billing address etc, billing email etc. Please note that it’s important that we have your billing information registered and not the end-customers information, since you are our direct customer and not the end-customer.
The PO number can be specified in the billing section under “billing notes”. Or send it to us, and we will add it for you.
You are free to create and delete instances once the billing information is set up. It’s up to you and the end-customer to decide who of you that will create the subscription specified in the PO.
Invite the end-customer to the account via https://customer.cloudamqp.com/team so that he/she can start using the service.
Change the role of the person that created your account to “Billing Manager”. By doing so, you can access all invoices of the account and update the billing information. But you will not be able to edit the customer's subscription. See more information here: https://www.cloudamqp.com/blog/2017-12-15-manage_cloudamqp_instance_access_permissions_with_acl.html.
You don't have to worry about this error. We don't recommend client certs at the moment, it's hard to set up and doesn't necessarily increase the security. We use the username/password as authentication and authorization, just like any HTTPS protected the website, the traffic is still fully encrypted and protected from MITM-attacks etc.
First of all, make sure that your tasks does not take longer time to perform on the client side than the timeout is specified to. The error could also indicate a network glitch or that the server or clients are overloaded and don't get to send heartbeats in time.
All CloudAMQP servers implement sensible TCP keepalive so AMQP Heartbeats are not necessary. Therefore, we recommend turning heartbeats off and rely on the underlying TCP keepalive. It's about the same thing but on the TCP/kernel level instead of on the protocol level.
Yes. You can read more here
Yes, you can sign a DPA with CloudAMQP. You access the DPA in the “Agreements”-section of the control panel.
You have the right to see what personal information 84codes AB holds about you. You are entitled to be given a description of the information, what we use it for, who we might pass it onto, and any information we might have about the source of the information.
A subject access requests should be made via email to firstname.lastname@example.org
You as data controller decide for yourself where you want to host your data by choosing data center and region of the data center. The data will not leave that region unless you choose to move it. In CloudAMQP ’s role as data controller, we may collect and store contact information, such as email address, and physical address, when customers sign up for our services or seek support help.
Your personal customer data (email and billing information) is stored in the US.