Q: What is AWS OpsWorks Stacks?
AWS OpsWorks Stacks lets you manage applications and servers on AWS and on-premises. With OpsWorks Stacks, you can model your application as a stack containing different layers, such as load balancing, database, and application server. You can deploy and configure Amazon EC2 instances in each layer or connect other resources such as Amazon RDS databases. OpsWorks Stacks lets you set automatic scaling for your servers based on preset schedules or in response to changing traffic levels, and it uses lifecycle hooks to orchestrate changes as your environment scales. You run Chef recipes using Chef Solo, allowing you to automate tasks such as installing packages and programming languages or frameworks, configuring software, and more.
Q: How is AWS OpsWorks Stacks different from AWS OpsWorks for Chef Automate?
OpsWorks for Chef Automate is a configuration management service that helps you instantly provision a Chef server and lets the service operate it, including performing backups and software upgrades. The service offers full compatibility with Chef’s Supermarket cookbooks and recipes. It supports native Chef tools such as TestKitchen and Knife. The OpsWorks Stacks service helps you model, provision, and manage your applications on AWS using the embedded Chef solo client that is installed on Amazon EC2 instances on your behalf.
Q: Who should use AWS OpsWorks Stacks?
System administrators and ops-minded developers who are looking for a powerful end-to-end configuration management solution should consider AWS OpsWorks Stacks. AWS OpsWorks Stacks is targeted at DevOps users who want better management and automation tools to help them customize and control their environments. An AWS OpsWorks Stacks user typically values:
Control. AWS OpsWorks Stacks 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 Stacks performs the tasks for you. For example, AWS OpsWorks Stacks 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 Stacks 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 Stacks that they could not do before?
AWS OpsWorks Stacks 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 Stacks 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 Stacks automatically applies the specified configuration. Because AWS OpsWorks Stacks 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 Stacks 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 Stacks 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 Stacks there is no need to log in to several machines and manually update your configuration. Whenever your environment changes, AWS OpsWorks Stacks updates your configuration.
Q: What kinds of applications are supported by AWS OpsWorks Stacks?
AWS OpsWorks Stacks supports a wide variety of application architectures, from simple web applications to highly complex custom applications.
Q: How can I access AWS OpsWorks Stacks?
AWS OpsWorks Stacks is available through the AWS Management Console, AWS SDKs, and the AWS Command Line Interface.
Q: How is AWS OpsWorks Stacks different than AWS CloudFormation?
AWS OpsWorks Stacks 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 Stacks 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 Stacks 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 Stacks 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 Stacks 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 Stacks different than AWS Elastic Beanstalk?
AWS OpsWorks Stacks 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 Stacks 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 Stacks 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 Stacks 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 Stacks using other service consoles or CLIs?
While all the resources used by OpsWorks Stacks to build your environment are visible in their respective services, in general you should manage the resources exclusively through OpsWorks Stacks to avoid side effects with OpsWorks Stacks automation. There are a few exceptions, however:
- AWS OpsWorks Stacks 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 Stacks 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 Stacks 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 Stacks 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 Stacks 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 Stacks instances the same as Amazon EC2 instances?
An AWS OpsWorks Stacks instance defines an Amazon EC2 instance and its relationship with related resources, such as its availability zone, type, and associated volumes. An AWS OpsWorks Stacks instance may be represented by many Amazon EC2 instances over its lifetime, but only one at a time. This lets AWS OpsWorks Stacks 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 Stacks?
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 Stacks layer. If you want to install a larger number of packages, use a custom cookbook to install packages.
Q: Does AWS OpsWorks Stacks support Windows Server?
Yes. AWS OpsWorks Stacks supports Windows Server 2012 R2.
Q: How do I sign up for AWS OpsWorks Stacks?
To sign up for AWS OpsWorks Stacks, click the Sign Up Now button on the OpsWorks Stacks 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 Stacks process.
Q: How do I get started with AWS OpsWorks Stacks?
The best way to get started with AWS OpsWorks Stacks is to work through the AWS OpsWorks Stacks Getting Started Guide (Linux | Windows), part of our technical documentation. Within a few minutes, you will be able to deploy and use your application.
Application Configuration and Management
Q: What elements of my application can I control when using AWS OpsWorks Stacks?
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 Stacks’ 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 Stacks support?
AWS OpsWorks Stacks 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 Stacks 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 Stacks support?
AWS OpsWorks Stacks currently supports Amazon Linux, Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, and Windows Server 2012 R2.
Q: Does AWS OpsWorks Stacks support Microsoft Windows?
Yes. AWS OpsWorks Stacks supports Windows Server 2012 R2.
Q: Can I use AWS OpsWorks Stacks 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 Stacks’ 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 Stacks?
AWS OpsWorks Stacks 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 Stacks 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 Stacks 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 Stacks supports the ability to deploy multiple apps per stack and per layer.
Q: What is Chef and how does AWS OpsWorks Stacks 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 Stacks 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 Stacks such as PostgreSQL, Nginx, and Solr.
Q: What are lifecycle events?
AWS OpsWorks Stacks 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 Stacks 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 Stacks 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: 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 Stacks Getting Started Guide also includes an example Chef recipe and describes how it works.
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 Stacks support?
OpsWorks Stacks 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 Stacks support?
OpsWorks Stacks 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 Stacks 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 Stacks does not support EC2 Auto Scaling at this time.
Q: What monitoring and alarming options does AWS OpsWorks Stacks support?
OpsWorks Stacks 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 Stacks collects (including CPU, memory, and load) from your instances in the OpsWorks Stacks Monitoring view.
Q: What databases does AWS OpsWorks Stacks 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 Stacks support tags?
OpsWorks Stacks 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: Is it possible to use AWS Identity & Access Management (IAM) with AWS OpsWorks Stacks?
Yes, OpsWorks Stacks 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 Stacks support for IAM roles lets you give a user access to OpsWorks Stacks 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 Stacks if they have OpsWorks Stacks permissions to deploy or manage stack resources. This lets you prevent an OpsWorks Stacks user from inadvertently stopping an instance from the EC2 console.
Q: Can I manage what ports are open on my instances?
AWS OpsWorks Stacks 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 Stacks 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 Stacks requires connectivity outbound from the EC2 instance on port 443 to configure your instance.
Q: What does AWS OpsWorks Stacks run on the instance?
OpsWorks Stacks 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: 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 Stacks 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.