AWS OpsWorks Best Practices

We, the DevOps team at TO THE NEW have been practicing the DevOps Methodology from the last few years. We call ourselves DevOps architects, who love to do automation irrespective of the scripting language or cloud platform. As a DevOps architect, I have been using OpsWork from quite a long time. Hence, today I thought of sharing few of the best practices to be followed while using OpsWork as per my experience.

Source: leopard.in.ua

What is AWS OpsWorks?

OpsWorks is an AWS cloud-based solution which helps to create multiple resources like EC2 instance, Elastic load balancer, EBS, etc. in a collective manner to run the application. OpsWorks consists of the following things:

• Stack
• Layer
• Instances
• Monitoring
• Permission

Now, I will be sharing the best practices and techniques to avail maximum optimal outcome from AWS OpsWork which are:

Managing Permissions

Most importantly, we suggest everyone not to use the root credentials to access AWS resources.

In OpsWork, each stack has permission page which is segregated in two: Permission access and Instance access:

1. Permission access: Consists of four permission levels with each level representing IAM policy which grants permission for a specific set of actions.
   • Deny: All interactions are prohibited from performing on the stack.
   • Show:  Grants access to view the configuration only.
   • Deploy: Allow user to deploy app along with Show permission.
   • Manage: Includes permission to perform a variety of action on the stack like creation or deletion etc.
2. Instance Access: Using this user is allowed to access EC2 machine with pseudo/admin irrespective of Linux or Windows.

For example, if a user is supposed to perform multiple operations on stack expect addition or deletion of the layer, it can be done using Permission access on the stack and IAM.

• Allows user with Manage permission so that the user can perform all the action stacks including the addition or deletion of the layer.
• Using IAM, create custom managed policy for the user which denies permission for creation or deletion of the layer.

Note: If Any IAM user has conflicting policies between the allow and deny permissions. then denial policy always has precedence and user will not be able to access the stack.

Managing Security Groups

Whenever you create any new stack in OpsWorks, new security groups are automatically created as per the rules. For example inbound port 22 (ssh login) to any network location. Apart from this, there are some other practices which should be followed while using OpsWork:

• If accidentally OpsWork default is deleted, then create the new stack in the same region and default security group will be recreated by OpsWork. You can delete the new stack later if not required.
• Never modify or add restrictive rules in OpsWork default group because whenever the new stack is created OpsWork overwrites the rules in OpsWork default security group. So always create another security group with restrictive rules.

Managing EC2 Machines

OpsWork allows us to manage EC2 machine in three different ways:

1. Time-based instance: Instances can be started or stopped as per the user specified time in OpsWork.
2. 24×7 Instance: These can be started or stopped manually.
3. Load based instance: These instances can be autoscaled or stopped using OpsWork default metrics CPU or Memory or Load Average.

• Auto Healing: Every machine is registered to Opsworks runs an agent which communicates with the service directly to monitor the health of the EC2 machine. If OpsWorks cannot communicate with service, EC2 machine will be marked as failed and will create the new one as one of the life cycle events. Moreover, the Auto Healing feature handles the EBS volume in a different manner.
  • If secondary volumes are not attached to failed instance, then OpsWorks creates a new machine with same volume size with the configuration which you have mentioned over the layer.
  • If secondary volumes are connected to the failed instance, then OpsWorks creates a new machine with the configuration which you have mentioned over the layer and attached same volumes with the new machine and data is saved.

These are few of the best practices which you should follow while using AWS Opsworks. I will be coming up with more such blogs, so stay tuned.