Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Dashboard Users Guide > Clouds > Generic > Security Groups > Concepts > Configuring multiple Security Groups for a multi-tiered Deployment

Configuring multiple Security Groups for a multi-tiered Deployment

Table of Contents

Table of Contents


Using a single Security Group for a multiple Server, multi-tiered Deployment is fine during the test and development phase of a project, but it is not recommended for production.   This document discusses a possible implementation using multiple Security Groups for a typical 3-tiered Deployment in the cloud.  For example, a Deployment with the following 3 tiers:

  1. Front end load balancers
  2. Application Servers (one or more, possibly even a Server Array)
  3. Back end database Servers (master/slave)



Create a Security Group for each tier:

  • Tier one - Front Ends (Load Balancers)
    • Open ports 22 and 80
    • Open port 443 if you require SSL  (optional)
    • Open ICMP if you want to ping the server  (optional)
  • Tier two - Application Servers
    • Open port 22
    • Add the tier 1 front end Security Group to the application Security Group.  Open up port 8000 for the HAproxy listener.
    • Open application specific ports (if any).  For example, a port used for administrative purposes or dedicated communications port.
  • Tier three - Database Servers
    • Open ports 22
    • Add the tier 2 application Security Group to the database Security Group. Open up port 3306 for MySQL.
    • Note:  The Dashboard allows you to configure port level security.  That is, only application Servers can communicate to database Servers, and that only on a specific port (e.g. 3306).

Although changes to existing Security Groups that are being used by running Servers are dynamic and take effect immediately for new connections, you cannot change which Security Groups are assigned to a running Server.  Security Groups can only be assigned to an instance at launch time and cannot be changed once a launch request has been made.  Therefore, in order to assign a different Security Group to a running server you must either terminate the existing server and launch a new one or use the relaunch option to launch the "Next" server with the modified configuration.  Remember, you can only modify which Security Group(s) will be assigned to a server before it is launched. 

Follow the guidelines below to modify your Security Group configurations.

  • For each Server, select the "next" in the Server Timeline.
  • Edit the Server configuration
    • Remove the "old" (wide open) Security Group
    • Add the new Security Group (for the appropriate tier 1, 2 or 3)
    • Save your changes
  • Terminate running Servers
    • If required by your application, you may need to terminate servers in a specific order
    • Otherwise, disable your Server Array (if you have one), then terminate your front end Servers, application Servers (or Array) and then database Servers
  • Launch Servers
    • Launch new Servers in a specific order if called for by your application
    • Otherwise, launch your Master (once operational, launch your Slave*); launch your front ends;  Launch your application Servers.  Remember to enable and then launch if using a Server Array for your application Servers.

Make sure your Deployment is up, running and functioning properly. 

The primary benefit of deploying multiple Security Groups tailored to your specific Deployment is increased security.  Certainly there is no reason to have a database port potentially opened up to the world. The scenario above increases security, particularly with respect to tiers 2 and 3.

* Make sure the INIT_SLAVE_AT_BOOT Input is set to "true" when you launch your slave database Server.

You must to post a comment.
Last modified
22:26, 16 May 2013



This page has no classifications.



© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.