Q: What is AWS OpsWorks?
AWS OpsWorks is a flexible application management solution with automation tools that enable you to model and control your applications and their supporting infrastructure. AWS OpsWorks makes it easy to manage the complete application lifecycle, including resource provisioning, configuration management, application deployment, software updates, monitoring, and access control. AWS OpsWorks is designed for IT administrators and ops-minded developers who want an easy way to manage applications of nearly any scale and complexity without sacrificing control. With AWS OpsWorks you can create a logical architecture, provision resources based on that architecture, deploy your applications and all supporting software and packages in your chosen configuration, and then operate and maintain the application through lifecycle stages such as auto-scaling events and software updates.
Q: Who should use AWS OpsWorks?
System administrators and ops-minded developers who are looking for a powerful end-to-end application management solution should consider AWS OpsWorks. AWS OpsWorks is targeted at DevOps users who want better management and automation tools to help them customize and control their environments. An AWS OpsWorks user typically values:
Control. AWS OpsWorks makes it easy to model all the components of your application and then configure any aspect of your application and its supporting infrastructure. With support for scripted changes using Chef recipes (see "What is Chef and how does AWS OpsWorks use it?" for details) at defined stages in the application lifecycle, you have fine-grained control of your application and its interaction with related components. Your recipes can be stored with your source code, making it easy to track changes. From one-time deployments to auto scaled growth, your application will reflect your settings through its complete lifecycle.
Automation. Instead of manual steps, you specify how to deploy, scale, and maintain your applications and AWS OpsWorks performs the tasks for you. For example, AWS OpsWorks can set up instances to host your apps based on the exact configurations that you specify (code to deploy, RAID configuration, etc.), scale your apps using load-based or time-based auto scaling, and maintain the health of your apps by detecting and replacing failed instances. When a new app server instance starts, AWS OpsWorks will use built-in recipes to configure the app server software and deploy your apps, and can also apply your specified recipes to make changes to your database and monitoring infrastructure.
Q: What can users do with AWS OpsWorks that they could not do before?
AWS OpsWorks delivers a solution that lets you:
Model and support any application. You can deploy your application in the configuration you choose on Amazon Linux and Ubuntu. AWS OpsWorks lets you model your application with layers. Layers define how to configure a set of resources that are managed together. For example, you might define a web layer for your application that consists of Amazon EC2 instances, Amazon EBS volumes including RAID configuration and mount points, and Elastic IP addresses. You can also define the software configuration for each layer, including installation scripts and initialization tasks. When an instance is added to a layer, AWS OpsWorks automatically applies the specified configuration. AWS OpsWorks provides pre-defined layers for common technologies such as Ruby, PHP, HAProxy, Memcached, and MySQL. AWS OpsWorks promotes conventions but is flexible enough to let you customize any aspect of your environment. You can extend or modify pre-defined layers, or create your own from scratch. Because AWS OpsWorks supports Chef recipes (see What is Chef and how does AWS OpsWorks use it for details), you can leverage hundreds of community-built configurations such as PostgreSQL, Nginx, and Solr. For example, you can create an application that consists of multiple Python apps installed on Django connected to a CouchDB database.
Automate tasks. AWS OpsWorks enables you to automate management actions so that they are performed automatically and reliably. You can benefit from automatic failover, package management, Amazon EBS volume RAID setup, and automatic rule-based or time-based instance scaling. Common tasks automatically handled for you, and you can also extend and customize that automation. AWS OpsWorks supports continuous configuration through lifecycle events that automatically update your instances’ configuration to adapt to environment changes, such as auto scaling events. With AWS OpsWorks there is no need to log in to several machines and manually update your configuration. Whenever your environment changes, AWS OpsWorks updates your configuration.
Q: What kinds of applications are supported by AWS OpsWorks?
AWS OpsWorks supports a wide variety of application architectures, from simple web applications to highly complex custom applications. You simply select from our pre-built layers or build your own layer. OpsWorks includes several built-in layers that support standard application frameworks:
Application Layers: Ruby on Rails, PHP, Node.js, Java, and Nginx
Data Layers: MySQL and Memcached
Utility Layers: Ganglia and HAProxy
Q: How can I access AWS OpsWorks?
AWS OpsWorks is available through the AWS Management Console, AWS SDKs, and the AWS Command Line Interface.
Q: What regions does AWS OpsWorks support?
You can configure OpsWorks instances to be launched in any AWS region except GovCloud. OpsWorks itself runs in US East (Northern Virginia) and provides access to all of your OpsWorks applications, no matter where they’re running.
Q: How is AWS OpsWorks different than AWS CloudFormation?
AWS OpsWorks and AWS CloudFormation are both application management services that support application modeling, deployment, configuration, management, and related activities. Both support a wide variety of architectural patterns, from simple web applications to highly complex applications. AWS OpsWorks and AWS CloudFormation differ in abstraction level and areas of focus.
AWS CloudFormation is a building block service that enables customers to provision and manage almost any AWS resource via a JSON-based domain specific language. AWS CloudFormation focuses on providing foundational capabilities for the full breadth of AWS, without prescribing a particular model for development and operations. Customers define templates and use them to provision and manage AWS resources, operating systems and application code.
In contrast, AWS OpsWorks is a higher level service that focuses on providing highly productive and reliable DevOps experiences for IT administrators and ops-minded developers. To do this, AWS OpsWorks employs an application management model based on concepts such as stacks and layers, and provides integrated experiences for key activities like deployment, monitoring, auto-scaling, and automation. Compared to AWS CloudFormation, AWS OpsWorks supports a narrower range of application-oriented AWS resource types including Amazon EC2 instances, Amazon EBS volumes, Elastic IPs, and Amazon CloudWatch metrics. For more information about our application management services, see our Application Management page.
Q: How is AWS OpsWorks different than AWS Elastic Beanstalk?
AWS OpsWorks and AWS Elastic Beanstalk are both application management services. They differ in the breadth of architectural patterns that they support, and in their operations orientation.
AWS Elastic Beanstalk is an easy-to-use application management service for building web apps and web services with popular application containers such as Java, PHP, Python, Ruby and .NET. Customers upload their code and Elastic Beanstalk automatically does the rest.
AWS OpsWorks supports a wider variety of architectural patterns than Elastic Beanstalk. Whereas AWS Elastic Beanstalk is specifically optimized for the most common web application and web service patterns and application middleware, AWS OpsWorks supports a wide variety of architectural patterns, from simple web applications to highly complex applications.
AWS OpsWorks and AWS Elastic Beanstalk both focus on operations, but with very different orientations. AWS Elastic Beanstalk seeks to automatically provide key operations activities so that developers can maximize the time they spend on development and minimize the time they spend on operations. In contrast, AWS OpsWorks delivers integrated experiences for IT administrators and ops-minded developers who want a high degree of productivity and control over operations. For more information about our application management services, see our Application Management page.
Q: Can I manage resources created by AWS OpsWorks using other service consoles or CLIs?
While all the resources used by OpsWorks to build your environment are visible in their respective services, in general you should manage the resources exclusively through OpsWorks to avoid side effects with OpsWorks automation. There are a few exceptions, however:
- AWS OpsWorks will create and delete volumes for instances based on the configuration specified in your layer. If you want to snapshot the volumes, or manage volumes you have chosen to retain when an instance is terminated, you can do this directly with the Amazon EC2 service.
- AWS OpsWorks provides security groups for your layers with defaults that match the ports required for that layer. If you want to customize the security group or create new security groups, you can do this directly with the EC2 service.
- AWS OpsWorks uses key pairs that enable you to ssh into your instances. If you want to create or manage key pairs, you can do this directly with the Amazon EC2 service.
- AWS OpsWorks creates default AWS IAM policies for the users you add to your stack. If you want finer grained permissions, you will need to add those permissions to the user in IAM.
- AWS OpsWorks sends metrics from all your resources to Amazon CloudWatch. If you want to view these metrics or set alarms, you can do this directly with Amazon CloudWatch.
Q: Are AWS OpsWorks instances the same as Amazon EC2 instances?
An AWS OpsWorks instance defines an Amazon EC2 instance and its relationship with related resources, such as its availability zone, type, and associated volumes. An AWS OpsWorks instance may be represented by many Amazon EC2 instances over its lifetime, but only one at a time. This lets AWS OpsWorks consistently bind resources such as volumes and Elastic IPs with the Amazon EC2 instance when it is started.
Q: Are there any limits to AWS OpsWorks?
By default, you can create up to 20 Stacks, and each stack can hold up to 20 layers, 20 instances, and 20 apps. You should also be aware of other AWS limits. For example, the default AWS account limits allow you to launch up to 20 Amazon EC2 instances. If you need more resources, complete a request form and your request will be evaluated promptly. You can also install a limited number of packages through each OpsWorks layer. If you want to install a larger number of packages, use a custom cookbook to install packages.
Q: How do I sign up for AWS OpsWorks?
To sign up for AWS OpsWorks, click the Sign Up Now button on the OpsWorks detail page. You must have an Amazon Web Services account to access this service; if you do not already have one, you will be prompted to create one when you begin the AWS OpsWorks process.
Q: How do I get started with AWS OpsWorks?
The best way to get started with AWS OpsWorks is to work through the AWS OpsWorks Getting Started Guide, part of our technical documentation. Within a few minutes, you will be able to deploy and use your application.
Q: What elements of my application can I control when using AWS OpsWorks?
An AWS OpsWorks stack defines the configuration of your entire application: the load balancers, server software, database, etc. You control every part of the stack by building layers that define the software packages deployed to your instances and other configuration details such as Elastic IPs, security groups, and RAID configuration. You can also deploy your software onto layers by identifying the repository and optionally using Chef recipes to automate everything Chef can do, such as creating directories and users, configuring databases, etc. You can use OpsWorks’ built-in automation to scale your application and automatically recover from instance failures. You can control who can view and manage the resources that are used by your application, including ssh access to the instances that your application uses.
Q: What software versioning and revision control systems does AWS OpsWorks support?
AWS OpsWorks can retrieve the code you want to deploy from common version control systems like Git and Subversion as well as HTTP and private or public S3 bundles. For example, you can deploy a specific version of your application by adding the version or branch from your Git repository into your OpsWorks app definition. You can also use Chef recipes to deploy your apps from anywhere you like using rsync or scp.
Q: What operating systems does AWS OpsWorks support?
AWS OpsWorks currently supports Amazon Linux and Ubuntu 12.04 LTS. Both operating systems are supported and maintained by AWS and are designed to provide a stable, secure, and high performance execution environment.
Q: Does AWS OpsWorks support Microsoft Windows?
No, not at this time. Your feedback on the AWS forums will help us prioritize this on our roadmap.
Q: Can I use AWS OpsWorks to deploy applications that are highly available?
Yes. If your application supports horizontal scaling, you can create instances in multiple availability zones, and your load balancer will route traffic among your instances. If any instance fails, OpsWorks’ auto healing can replace it. If your application uses other techniques to achieve availability goals, such as a database with an active and a passive node, you can use Chef recipes to configure it.
Q: How do I model my application in AWS OpsWorks?
AWS OpsWorks provides three concepts to model your application:
A Stack is the highest-level management unit. A stack contains the set of Amazon EC2 instances and instance blueprints, called layers, used to launch and manage these instances. Applications, user permissions, and other resources are scoped and controlled in the context of the Stack. For example, you might create a stack for your development web application that includes a front-end load balancer, the PHP servers, your PHP apps, and the MySQL database. You can also create a stack for your production web application with a similar configuration by cloning the development stack.
A Layer is a blueprint for how to setup and configure an instance and related resources such as volumes, Elastic IPs, and can automatically take care of infrastructure configuration like SSL settings. You can also define the software configuration for each layer, including installation scripts, initialization tasks, and packages. For example, if you select the Ruby layer, OpsWorks can install not only Rails, but also all the Gems your application requires. AWS OpsWorks provides a set of built-in layers (e.g., Rails, PHP, Node.js, HAProxy, Ganglia) and makes it easy to create custom layers. Layers also include lifecycle events that let you automate configuration actions in response to changes in an instance’s status (see “What are Lifecycle Events” for details) using Chef recipes (see “What is Chef and how does AWS OpsWorks use it” for details). Layers can include time- or load-based auto scaling to handle demand peaks without manual interaction.
An App is software downloaded from a repository (e.g., Git, S3) and deployed to a layer. You can use the deploy lifecycle event to automate configuration steps such as connecting your application to a database. OpsWorks supports the ability to deploy multiple apps per stack and per layer.
Q: What is Chef and how does AWS OpsWorks use it?
Chef is an open source systems integration framework sponsored by Opscode that automates the deployment of software. AWS OpsWorks uses Chef recipes to deploy and configure software components on Amazon EC2 instances. Chef has a rich ecosystem with hundreds of Cookbooks that can be used with AWS OpsWorks such as PostgreSQL, Nginx, and Solr.
Q: What are lifecycle events?
AWS OpsWorks creates events that correspond to lifecycle stages. These events can be used to trigger Chef recipes on each instance to perform specific configuration tasks. OpsWorks has built-in recipes to perform basic management for each event based on the type of layer. You can also create custom recipes to script any configuration change that your application needs for a specific lifecycle event. The following lifecycle events are supported:
Setup is sent to the instance when it is instantiated or successfully booted. For example, the OpsWorks Rails application server layer uses the setup event to trigger a Chef recipe that installs dependencies like Apache, Ruby, Passenger, and Ruby on Rails.
Configure notifies all instances whenever the state of the stack changes. For example, when a new instance is successfully added to an application server layer, the configure event triggers a Chef recipe that updates the OpsWorks Load Balancer layer configuration to reflect the added application server instance.
Deploy is triggered whenever an application is deployed. For example, the OpsWorks Rails application server layer uses the deploy event to trigger a Chef recipe that executes the tasks needed to check out and download your application and tells Passenger to reload it.
Undeploy is sent when you delete an application. For example, the undeploy event can trigger a custom Chef recipe that specifies any cleanup steps that need to be run, such as deleting database tables.
Shutdown is sent to an instance 45 seconds before actually stopping the instance. For example, the shutdown event can trigger a custom Chef recipe that shuts down services.
Q: Does AWS OpsWorks support existing Chef cookbooks?
Yes, you can use existing Chef recipes as long as they don't require functionality provided exclusively by Chef Server. Chef recipes that rely on Chef Server features require modification. If your recipe includes search, you will need to replace it with node lookup. If your recipe includes data bags, you will need to replace it with a JSON data object.
Q: How do I create Chef cookbooks and recipes?
Probably the easiest way to get started is to use existing Chef recipes. There is a rich ecosystem of public repositories containing Chef cookbooks with recipes that can run with little to no modification. The OpsWorks Getting Started Guide also includes an example Chef recipe and describes how it works.
Q: Can I use my own AMIs?
Yes, you can use your own AMIs or customize the AMIs OpsWorks supports using Chef scripts to install agents and other software that you require.
Q: Can I use Amazon EC2 user data to customize instance setup?
No, instance setup is done exclusively through Chef recipes.
Q: What load balancing options does AWS OpsWorks support?
OpsWorks supports Elastic Load Balancing, HAProxy through a built-in layer, or any load balancer you choose to install on your EC2 instances using a custom layer and Chef recipes. This gives you rich customization options and fine-grained control of your application’s load balancer.
Q: What automatic instance scaling options does AWS OpsWorks support?
OpsWorks supports automatic time and load-based instance scaling to adapt the number of running instances to match your load. With load-based auto scaling, you can set thresholds for CPU, memory, or load to define when additional instances will be started. Once the load spike is gone and your down-scaling thresholds are met, OpsWorks will shut down the additional instances. With time-based auto scaling, you can define at what time of the day instances will be started and stopped. The instances in your auto scaling pool can vary in size, letting you scale gradually or quickly, and can be configured for multiple availability zones to improve reliability. OpsWorks does not support EC2 Auto Scaling at this time.
Q: What monitoring and alarming options does AWS OpsWorks support?
OpsWorks sends all of your instance and volume metrics to CloudWatch, making it easy to view graphs and set alarms to help you troubleshoot and take automated action based on the state of your resources. You can also see the thirteen 1-minute metrics OpsWorks collects (including CPU, memory, and load) from your instances in the OpsWorks Monitoring view. The built-in Ganglia layer provides additional application monitoring options.
Q: What databases does AWS OpsWorks support?
OpsWorks supports MySQL through a built-in layer, or any database you choose to install on your EC2 instances using a custom layer and Chef recipes, such as Cassandra, PostgreSQL, etc. This gives you rich customization options and fine-grained control of your application’s database. You can also use a Chef recipe to configure a connection from your application to an existing Amazon RDS instance or Amazon DynamoDB table. For example, your recipe can assign the appropriate permissions to your existing RDS instances or DynamoDB tables and pass the table name to the application.
Q: Does AWS OpsWorks support tags?
OpsWorks automatically tags all resources with the name of the stack and layer that they are associated with. You can use these tags with Cost Allocation Reports to organize and track your AWS costs using tagging. To learn more about Cost Allocation and tagging, please visit AWS Account Billing.
Q: Can I run my application inside an Amazon Virtual Private Cloud (VPC)?
Yes. See the OpsWorks documentation for more information.
Q: Is it possible to use AWS Identity & Access Management (IAM) with AWS OpsWorks?
Yes, OpsWorks supports IAM users, permissions, and roles. You can designate permissions by user, including view, deploy, and manage. You can also specify which users can ssh directly into instances. OpsWorks support for IAM roles lets you give a user access to OpsWorks without having to give access to dependent services like EC2. For example, you can explicitly deny a user the ability to perform EC2 actions, but the user can still control EC2 instances through OpsWorks if they have OpsWorks permissions to deploy or manage stack resources. This lets you prevent an OpsWorks user from inadvertently stopping an instance from the EC2 console.
Q: How are operating system security updates installed?
When an instance boots, all security updates are installed. You can also install security updates at any time to any number of instances using an OpsWorks deployment.
Q: Can I manage what ports are open on my instances?
Yes, you can use security groups to control the traffic allowed to reach the instances in your layers. OpsWorks creates default security groups for each layer, which you can customize or change using the EC2 security group console or CLI. OpsWorks does not need any ports to be open, but you should consider the ports required for your application. For example, if you want to use ssh you need to have port 22 open.
Q: What does AWS OpsWorks run on the instance?
OpsWorks uses an agent on the instance to perform configuration tasks and provide heartbeat health status. The agent runs as an unprivileged user on the operating system. Every instance also has a user that is used for deployments. This user doesn't have any login rights or access rights apart from deployment.
Q: Where can I find more information about security and running applications on AWS?
For more information about AWS security please refer to our Amazon Web Services: Overview of Security Processes document and visit our Security Center.
Q: How much does AWS OpsWorks cost?
There is no additional charge for OpsWorks – you only pay for the AWS resources actually used to store and run your application.
Q: How do I check how many AWS resources have been used by my application and access my bill?
You can view your charges for the current billing period at any time on the Amazon Web Services web site by logging into your Amazon Web Services account and clicking Account Activity under Your Web Services Account. OpsWorks automatically tags all resources with the name of the stack and layer that they are associated with. You can use these tags with Cost Allocation Reports to organize and track your AWS costs using tagging.