Q: What is AWS OpsWorks?
AWS OpsWorks is a flexible configuration 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 configuration 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 (learn more here) 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 scale, maintain, and deploy 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, 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. AWS OpsWorks uses Chef recipes to start new app server instances, configure app server software, and deploy apps. You can also apply your own Chef 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, Ubuntu, RHEL, and Windows. 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, 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. Because AWS OpsWorks supports Chef recipes (visit here 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, Elastic Load Balancing configuration, 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.
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?
Please refer to Regional Products and Services for details of OpsWorks availability by region.
Q: How is AWS OpsWorks different than AWS CloudFormation?
AWS OpsWorks and AWS CloudFormation both 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 a configuration 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.
Q: How is AWS OpsWorks different than AWS Elastic Beanstalk?
AWS OpsWorks is a configuration management platform while AWS Elastic Beanstalk is an application management platform.
AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker. Customers upload their code and Elastic Beanstalk automatically does the rest.
AWS OpsWorks and AWS Elastic Beanstalk both automate operations but serve different needs and purposes. AWS Elastic Beanstalk is designed for developers who want to deploy web applications without worrying about operations. Developers simply upload their code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. The application will be ready to use without any infrastructure or resource configuration work on the developer’s part.
In contrast, AWS OpsWorks is an integrated configuration management platform for IT administrators and DevOps engineers who want a high degree of customization and control over operations. AWS OpsWorks users leverage Chef recipes to automate operations like software configurations, package installations, database setups, server scaling, and code deployment.
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 40 Stacks, and each stack can hold up to 40 layers, 40 instances, and 40 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: Does AWS OpsWorks support Windows Server?
Yes. AWS OpsWorks supports Windows Server 2012 R2
Q: Does AWS OpsWorks support on-premises servers?
Yes. AWS OpsWorks supports all Linux machines that can install the OpsWorks agent and have connection to AWS public endpoints.
Q: What network requirements do my servers have to have to work with AWS OpsWorks?
Your servers will just need to be able to connect to AWS public endpoints.
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 (Linux | Windows), 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 and security groups. 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, Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, and Windows Server 2012 R2.
Q: Does AWS OpsWorks support Microsoft Windows?
Yes. AWS OpsWorks supports Windows Server 2012 R2.
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 use a Ruby layer, OpsWorks can install not only Rails, but also all the Gems your application requires. 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 framework sponsored by Chef Software, Inc. that automates how applications are configured, deployed, and managed through the use of code. 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 leverages Chef 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, you could trigger a Chef recipe for a Rails application server 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, you could trigger a Chef recipe for a Rails application server 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. For more information, see the documentation.
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. Using your own Windows AMIs is not currently supported.
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 using community Chef recipes, 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.
Q: What databases does AWS OpsWorks support?
You can use AWS services such as Amazon RDS or use Chef recipes to install databases such as MySQL, Cassandra, or MongoDB. This gives you rich customization options and fine-grained control of your application’s database.
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: Can I manage what ports are open on my instances?
AWS OpsWorks provides a standard set of built-in security groups — one for each layer — which are associated with layers by default. The stack's Use OpsWorks security groups setting allows you to instead provide your own custom security groups. With this option, you must create appropriate EC2 security groups and associate a security group with each layer that you create. However, you can still manually associate a built-in security group with a layer on creation; custom security groups are required only for those layers that need custom settings. For more information on security groups, see Amazon EC2 Security Groups. Note that OpsWorks requires connectivity outbound from the EC2 instance on port 443 to configure your instance.
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?
You pay for on-premises servers supported by AWS OpsWorks by the hour; there are no minimum fees and no upfront commitments. The pricing for each on-premises server on which you install the OpsWorks agent is $0.02 per hour.
There is no additional charge for Amazon EC2 instances supported by AWS OpsWorks. You pay for AWS resources (e.g. EC2 instances, EBS volumes, Elastic IP addresses) created using OpsWorks in the same manner as if you created them manually. You only pay for what you use, as you use it; there are no minimum fees and no upfront commitments.
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.