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:
Create a Security Group for each tier:
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.
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.
© 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.