"CIOs will be well served by understanding the different AWS implementation designs for managing various cloud environments," said Faraz Mohammed, Nisum Director of Advanced Technology Solutions and R&D in Cloud Computing Magazine. Read the article below or on Cloud Computing Magazine's website here! 

How to Optimally Manage Various Environments on the Cloud

Cloud for business is no longer optional. Startups need the cloud for its speed and ease, while enterprises need the cloud for its scalability. No matter an organization’s cloud requirements, any application development life cycle involves various environments, including, but not limited to, development, testing, staging, and production.

Oftentimes when businesses adopt cloud solutions, they don’t consider the challenges associated with multiple environments, and as a result, quickly run into security issues. It's a common mistake; often an organization’s cloud environment is only utilizing a single AWS account for all of the workload environments and segmenting the work environments within the account by using multiple Virtual Private Clouds (VPCs). Using multiple VPCs for this purpose does not provide any additional security benefits; however, it does have the potential to complicate operations and can even limit the usage capacity of some AWS services. 

Per best practices, AWS recommends that when setting up AWS accounts, users “Design AWS account strategy to maximize security and follow your business and governance requirements.”

Taking this recommendation a step further, users should aim to create a separate account for each deployment environment (development, testing, staging, production) with a single VPC per account. Segmenting the AWS environment in this way meets rigorous security requirements and provides visibility into resource usage, while also eliminating the operational complications that can be associated with segmenting multiple VPCs.

Depending on an organization’s business requirements, AWS account design and implementation should be adjusted accordingly. Below are four common business requirements, and the resulting AWS account set up.

• High Security and Scalability: Create separate AWS accounts—one account for production services, another for development, and another for testing. 
• Multiple Autonomous Departments: Create multiple, separate AWS accounts for each autonomous part of the organization, assigning permissions and policies under each account. 
• Centralized Security Management: Create a single AWS account to centralize information security management and minimize overhead. 
• Centralized Security Management with Multiple Autonomous Independent Projects: Begin by creating a single AWS account for common project resources, such as DNS services, Active Directory, CMS, etc. Then create separate AWS accounts per project, assigning permissions and policies under each project account and granting access to resources across accounts. 

Each AWS account contains hard and soft limits for the AWS services used within the account, such as EC2 instance limits, ELB limits, and limits on the number of Simple Storage Service (S3) buckets allowed per account. By creating a separate account for each work environment, users create additional headroom they could need as their account scales up. This “room to grow” reduces the potential risk of hitting the account maximum in any one resource area. 

The implications of reaching these service limits are dependent on two factors. First, which AWS service is meeting the default limit, and second, how important the service is to the ability of the application to function. Consider the following real-world scenario: 

An eCommerce site uses a single AWS account that is segmented into three environments: development, testing, and production. During a high traffic period for the production environment, a developer launches EC2 test instances. With separate accounts, this would not be a problem, but since production and development are housed in the same AWS account, this causes the account to reach the EC2 instance usage limit. Once the account reaches that usage limit, Auto Scaling is prevented from launching new instances needed to match traffic demand on the website, and the website is unable to respond to incoming requests from customers who want to purchase items on their site. With limited compute capacity, the site’s response time to requests continues to slow until it is overloaded and the site fails altogether. This results in revenue loss due to the inability to access the website. More importantly, it creates bad customer experiences on the site, which could lead to the loss of current and future customers. 

Segmenting accounts by deployment environment also provides several benefits from a governance perspective by providing increased visibility into the details of resource usage and utilization for each group. When running workloads on AWS it is very important to keep track of user permissions. Creating an account for each different environment makes it easy for management to assign and manage permissions by functional group. This method of segmenting by the account also enables management to have more visibility into the spending for each environment, making it easier to optimize spend on IT resources.

The impetus for adopting the cloud will differ for every organization; some may be prioritizing for speed, others simplicity, and others scale. Regardless of what prompts the cloud conversation, CIOs will be well served by understanding the different AWS implementation designs for managing various cloud environments. Depending on business requirements, IT can look to implement optimal account design for the best return.