Rackspace Cloud Load Balancers (Beta) Now Available For All US Cloud Customers

Josh Odom leads the Platform Product Line

Last November, we announced that we were actively developing a high-performance, on-demand cloud load balancing solution and were seeking customers to participate in our cloud load balancers private beta phase.

Since then, our engineers and our private beta customers have been evaluating and testing our cloud load balancers along with the API.  Our private beta customers have provided us critical feedback on what works well and what improvements needed to be made.  We’re pleased to announce the availability of cloud load balancers (Beta) to all Rackspace US Cloud customers.

Our cloud load balancers include features our customers have been asking for and  features unique in the industry, including:
•    Static IP addresses
•    Support for multiple protocols
•    Advanced algorithms
•    Built-in high availability
•    Health checks
•    Advanced access control
•    Session persistence
•    REST-based API
•    Connection logging
•    Connection throttling

If you want to learn more, click here for a PDF document that provides additional details.


Implementation and management of our cloud load balancer solution is currently available only through our API.   In the near future, we will integrate the cloud load balancer into the Rackspace Cloud Control Panel.  To download the API Guide, click here.   In order to use our API, you should have a general understanding of the load balancing service and be familiar with:
• RESTful Web Services
• HTTP/1.1 Conventions
• JSON and/or XML Data Serialization Formats
• ATOM Syndication Format


You pay for each cloud load balancer (instance) by the hour + the number of concurrent connections + bandwidth.  There are no upfront base fees.  Here are the details:

Note*: Concurrent connections are a measure of average utilization over an hour based on 5 minute polling.

Bandwidth for Rackspace cloud load balancers is calculated separately:
•    Bandwidth (Out) is $0.18 per GB
•    Bandwidth (In) is $0.08 per GB

Getting Started

Well…are you ready to add a cloud load balancer?   It’s an easy three step process:

1.    Add a cloud load balancer. If you already have a Rackspace Cloud account, use the “Create Load Balancer” API operation.  If you don’t have a Rackspace Cloud account, go to the Order Now page and get yourself an account….then use the “Create Load Balancer” API operation.
2.   Configure cloud load balancer. Using our API, select name, protocol, port, algorithm, and which servers you need load balanced.
3.   Enjoy your cloud load balancer which will be online in just a few minutes. Using our API, each cloud load balancer can be customized or removed as your needs change.

In the near term, we expect to announce general availability that will include our industry leading service level agreement (SLA) and access via the Rackspace Cloud Control Panel.   We are very excited and can’t wait to hear from you about our new cloud load balancers offering.

Josh leads product development for the Cloud Platform Product Line where he is responsible for product management, engineering, and operations for the Cloud Sites, Load Balancing, Database and DNS product offerings.


  1. Hi Sergii,

    There are a few important distinctions.

    1) This is a managed offering – You do not need to handle any of the associated system maintenance tasks (patching, monitoring, etc.)

    2) No bandwidth limitations on the load balancer – When running a solution on Cloud Servers, you must ensure your instances are sized properly or you will not have enough bandwidth to service your requests. Additionally, since resizes are not instantaneous, you will need to ensure your instances are sized for the maximum amount of bandwidth you expect to traverse through the load balancer at peak.

    3) Built in HA – With ha-proxy, you need to configure shared IPs and a heartbeat (or similar) failover. Depending on your configuration, you may need to procure an additional public IP address, which is a request requiring a support ticket.


    • Youcef,

      There are several key use cases:

      1) IPv6 Enablement – When we enable IPv6 for this offering over the next few months, you will be able to assign an IPv6 interface to your existing load balancing configuration. This allows you to have a very simple strategy to IPv6-enabling your applications.

      2) SSL – If you are running multiple SSL sites on a single shared set of infrastructure, having multiple IP addresses is a requirement.

      Let me know if you have further questions.

  2. Hi there,

    great news! We are currently testing Rackspace cloud servers in Uk and we would like to balance our applications with Rackspace US. Is it possible with this solution?


  3. I am assuming they will connect to the backend via the internal IPs and we will be billed for all of the data coming through the LB instead of double billing right?

    Also, will it be possible to have say domain1.com go to a random server, EXCEPT when someone is posting something to the domain they are taken to the “master” web server for that portion which the data then gets pulled across all of the others?

    I am not an API type person so I will wait for the Control Panel option.

    • Hi Bob,
      The load balancers are “dual-homed” on public and ServiceNet. You should use your internal IPs. With this configuration, you will only be billed for public bandwidth at the load balancer level.

      Unfortunately, there are no mechanisms for altering the load balancing scheme based on the content of the request.


  4. In regards to load balancing https, if I install a certificate on the load balancer, will it then forward the traffic to the backend nodes as http? Will the headers contain some kind of indication that the request was secure (when it arrives at the backend node?

    • Hi Andrew,
      Unfortunately, at this time the service does not support SSL termination at the load balancer. You’ll need to passthrough encrypted traffic and do your termination on your web / application servers.


      • Can you explain a bit more what you mean about “You’ll need to passthrough encrypted traffic and do your termination on your web / application servers.”

        Can you provide an example of how one would do this on a high level?

  5. Is the cloud load balancer suitable for balancing database connections?

    Im looking for a way to handle automatic failover to a hot standby server in the rackspace cloud which currently isn’t possible due to the lack of additional servicenet ip addresses.

    can this service handle generic TCP connection balancing or is it limited to the protocols listed in the documentation?

    • Hi Daniel,
      This is not a capability currently available, but will be something that we add in a future release in Q2.


  6. I’m not a big fan of the pricing model. It seems that running a single site can become expensive with load-balancing multiple services, each requiring it’s own load balancer on a single virtual IP.

    I think it makes more sense to charge per virtual IP. A site that has HTTP and HTTPS is twice the price of HTTP alone, and each service/port to be load-balanced requires another minimum $10.95/month. I’d like to be able to not have to pay an additional $11 for each port I want to load-balance.

    • I should amend that the use-case for me is a 512mb server that I’m running behind load balancers solely for the nature of the elastic (virtual) IP address. I can spin up a new server and toss it behind the LBs, drop older servers, and no one is the wiser. Having to pay almost double the single server instance for the privilege is costly.

  7. Zeus Lb does have trafficscript capabilities..will these be exposed to end user at this time?? We would need to control the way traffic would be redirected to application servers. Also what other features will be available?? Like GeoIP based Loadbalancing or Rate limiting the requests at HTTP level rather than IP???


Please enter your comment!
Please enter your name here