Category: Amazon EC2


Running Couchbase on AWS – New White Paper

As the third installement in our series of white papers that are designed to show you how to run popular relational and NoSQL databases on AWS, I am pleased to tell you that our new Couchbase on AWS white paper is now available.

Written by AWS Solution Architects Kyle Lichtenberg and Miles Ward, this detailed white paper contains everything you’ll need to know to design, setup, monitor, and maintain your Couchbase installation. You will learn how to design for performance, durability, and scalabilty, and how to choose the right EC2 instance types and EBS volume settings. The paper includes a detailed discussion of Couchbase’s Cross Datacenter Replication (XDCR) and shows you how to use it for disaster recovery and geographic replication.

— Jeff;

PS – If Couchbase isn’t your thing, what about PostgreSQL or Riak?

Elastic Load Balancing adds Support for Proxy Protocol

My colleague Lesley Mbogo is a Senior Product Manager on the Elastic Load Balancing team. She sent along the post below to tell you all about an important new feature — support for the Proxy Protocol.

— Jeff;


Starting today, Elastic Load Balancing (ELB) supports Proxy Protocol version 1. You can now identify the originating IP address of a client connecting to your servers using TCP load balancing. Client connection information, such as IP address and port, is typically lost when requests are proxied through a load balancer. This is because the load balancer sends requests to the server on behalf of the client, making your load balancer appear as though it is the requesting client. Having the originating client IP address is useful if you need more information about visitors to your applications. For example, you may want to gather connection statistics, analyze traffic logs, or manage whitelists of IP addresses.

Until today, ELB allowed you to obtain the clients IP address only if you used HTTP(S) load balancing, which adds this information in the X-Forwarded-For headers. Since X-Forwarded-For is used in HTTP headers only, you could not obtain the clients IP address if the ELB was configured for TCP load balancing. Many of you told us that you wanted similar functionality for TCP traffic, so we added support for Proxy Protocol. It simply prepends a human readable header with the clients connection information to the TCP data sent to your server. The advantage of Proxy Protocol is that it can be used with any protocol layer above TCP, since it has no knowledge of the higher-level protocol that is used on top of the connection. Proxy Protocol is useful when you are serving non-HTTP traffic. Alternatively, you can use it if you are sending HTTPS requests and do not want to terminate the SSL connection on the load balancer. For more information, please visit the Elastic Load Balancing Guide.

Creating a Simple Web Application Running Behind an ELB with Proxy Protocol
Id like to show you how we can use the Proxy Protocol feature in a simple Node.js application running behind an ELB. This application retrieves the client IP address and port number from the Proxy Protocol header in the TCP connection and outputs the information in an HTML response.

Well use AWS Elastic Beanstalk to quickly deploy and manage the application. Elastic Beanstalk automatically provisions an environment that includes Elastic Load Balancing, a set of EC2 instances with all the necessary software, and more. Elastic Beanstalk supports many languages and platforms; for this example, we chose to use Node.js.

Our sample application (elb-pp-app.zip, click to download) is a simple Node.js server bundled in a zip archive. Inside elb-pp-app.zip youll find the following files:

  • server.js a simple Node.js server that receives and responds to TCP connections from the ELB.
  • package.json declares the node-proxy-protocol package dependency that parses the Proxy Protocol header inserted by the ELB. Elastic Beanstalk installs these dependencies automatically.
  • .ebextensions/ – a directory containing two YAML files that we created to customize our environment. Elastic Beanstalk automatically detects these files and applies the customizations.

The first file, .ebextensions/01_elb.config, configures the ELB to listen for TCP connections on port 80 and forward requests to back-end instances on port 80, and finally enables Proxy Protocol. To enable Proxy Protocol for an existing ELB in your account, please see the Elastic Load Balancing Guide.

The second file, .ebextensions/02_container.config, customizes Node.js to listen to requests directly on port 80. The Node.js container can be configured to proxy traffic locally through Apache or Nginx before sending requests to our application. Weve however chosen to disable this feature and allow our Node.js application to act as the server because neither Apache nor Nginx currently support the Proxy Protocol header inserted by the ELB. To learn more about customizing your environment resources, visit the Elastic Beanstalk Developer Guide.

We are now ready to deploy the sample application to Elastic Beanstalk using the AWS Management Console.

  1. Log into the Elastic Beanstalk Console, choose Node.js, and then click Get Started.
  2. Wait for the default environment to spin up and turn green, then click Upload and Deploy to upload the Node.js application. (Beanstalk creates a sample application in the default environment, so we need to upload our new version).
  3. Choose the elb-pp-app.zip file that you downloaded, and deploy the new version in the default environment.
  4. Wait for the application to deploy and for the default environment to update. When the environment turns green, click the environments URL to access the Node.js application.
  5. The Node.js application parses the Proxy Protocol data from the ELB and responds with HTML output showing your original Source IP and Port, as well as the IP of the ELB that proxied the request to the application.

I hope that you find this useful. If you have any feature requests for Elastic Load Balancing, please leave a note in the EC2 forum.

Lesley Mbogo

EC2 Dedicated Instance Price Reduction

I’m happy to announce that we are reducing the prices for Amazon EC2 Dedicated Instances.

Launched in 2011, Dedicated Instances run on hardware dedicated to a single customer account. They are ideal for workloads where corporate policies or industry regulations dictate physical isolation from instances run by other customers at the host hardware level.

Like our multi-tenant EC2 instances, Dedicated Instances let you take full advantage of On-Demand and Reserved Instance purchasing options. Todays price drop continues the AWS tradition of innovating to reduce costs and passing on the savings to our customers. This reduction applies to both the dedicated per region fee and the per-instance On-Demand and Reserved Instance fee across all supported instance types and all AWS Regions. Here are the details:

  • Dedicated Per Region Fee An 80% price reduction from $10 per hour to $2 per hour in any Region where at least one Dedicated Instance of any type is running.
  • Dedicated On-Demand Instances A reduction of up to 37% in hourly costs. For example the price of an m1.xlarge Dedicated Instance in the US East (Northern Virginia) Region will drop from $0.840 per hour to $0.528 per hour.
  • Dedicated Reserved Instances A reduction of up to 57% on the Reserved Instance upfront fee and the hourly instance usage fee. Dedicated Reserved Instances also provide additional savings of up to 65% compared to Dedicated On-Demand instances.

These changes are effective July 1, 2013 and will automatically be reflected in your AWS charges.

To launch a Dedicated Instance via the AWS Management Console, simply choose a target VPC and select the Dedicated Tenancy option when you configure your instance. You can also create a Dedicated VPC to ensure that all instances launched within it are Dedicated Instances.

To learn more about Dedicated Instances and to see a complete list of prices, please visit the Dedicated Instances page.

— Jeff;

Resource-Level Permissions for EC2 and RDS Resources

With AWS being put to use in an ever-widening set of use cases across organizations of all shapes and sizes, the need for additional control over the permissions granted to users and to applications has come through loud and clear.  This need for control becomes especially pronounced at the enterprise level. You don’t want the developers who are building cloud applications to have the right to make any changes to the cloud resources used by production systems, and you don’t want the operators of one production system to have access to the cloud resources used by another.

The Story So Far
With the launch of IAM in the middle of 2010, we gave you the ability to create and apply policies that control which users within your organization were able to access AWS APIs.

Later, we gave you the ability to use policies to control access to individual DynamoDB, Elastic Beanstalk, Glacier, Route 53, SNS, SQS, S3, SimpleDB, and Storage Gateway resources.

Today we are making IAM even more powerful with the introduction of resource-level permissions for Amazon EC2 and Amazon RDS. This feature is available for the RDS MySQL, RDS Oracle, and RDS SQL Server engines.

On the EC2 side, you can now construct and use IAM policies to control access to EC2 instances, EBS volumes, images, and Elastic IP addresses. On the RDS side, you can use similar policies to control access to DB instances, Read replicas, DB Event subscriptions, DB option groups, DB parameter groups, DB security groups, DB snapshots, and subnet groups.

Let’s take a closer look!

Resource-Level Permissions for EC2
You can now use IAM policies to support a number of important EC2 use cases. Here are just a few of things that you can do:

  • Allow users to act on a limited set of resources within a larger, multi-user EC2 environment.
  • Set different permissions for “development” and “test” resources.
  • Control which users can terminate which instances.
  • Require additional security measures, such as MFA authentication, when acting on certain resources.

This is a complex and far-reaching feature and we’ll be rolling it out in stages. In the first stage, the following actions on the indicated resources now support resource-level permissions:

  • Instances – Reboot, Start, Stop, Terminate.
  • EBS Volumes – Attach, Delete, Detach.

EC2 actions not listed above will not be governed by resource-level permissions at this time. We plan to add support for additional APIs throughout the rest of 2013.

We are also launching specific and wild-card ARNs (Amazon Resource Names) for all EC2 resources. You can refer to individual resources using ARNs such as arn:aws:ec2:us-east-1:1234567890:instance/i-i-96d811fe and groups of resources using ARNs of the form arn:aws:ec2:us-east-1:1234567890:instance/*.

EC2 policy statements can include reference to tags on EC2 resources. This gives you the power to use the same tagging model and schema for permissions and for billing reports.

In order to make it easier for you to test and verify the efficacy of your policies, we are extending the EC2 API with a new flag and a couple of new functions.  The new flag is the DryRun flag, available as a new general option for the EC2 APIs. If you specify this flag the API request will perform an authorization determination, but will not actually process the API request (for example, to determine whether a user has permission to terminate an instance without actually terminating the instance). 

In addition, when using API version 2013-06-15 and above, you will now receive encoded authorization messages along with authorization denied errors that can be used in combination with a new STS API, DecodeAuthorizationMessage, to learn more about the IAM policies and evaluation context that led to a particular authorization determination (permissions to the new STS API can be controlled using an IAM policy for the sts:DecodeAuthorizationMessage action).

The final piece of the EC2 side of this new release is an expanded set of condition tags that you can use in your policies. You can reference a number of aspects of each request including ec2:Region, ec2:Owner, and ec2:InstanceType (consult the EC2 documentation for a complete list of condition tags).

Resource Permissions for RDS
You can also use policies to support a set of important RDS use cases. Here’s a sampling:

  • Implement DB engine and Instance usage policies to specific group of users. For example, you may limit the usage of the m2.4xl instance type and Provisioned IOPS to users in the Staging users or Production users groups.
  • Permit a user to create a DB instance that uses specific DB parameter groups and security groups. For example, you may restrict Web application developers to use DB instances with Web application parameter groups and Web DB Security groups. These groups may contain specific DB options and security group settings you have configured.
  • Restrict a user or user group from using a specific parameter group to create a DB instance. For example, you may prevent members of the Test users group from using Production parameter groups while creating test DB instances.
  • Allow only specific users to operate DB instances that have a specific tag (e.g. DB instances that are tagged as “production”). For example, you may enable only Production DBAs to have access to DB instances tagged with Production label.

As you might have guessed from my final example, you can now make references to tags on any of the RDS resources (see my other post for information on the newly expanded RDS tagging facility), and you can use the same tags and tagging schema for billing purposes.

As we did for EC2, we have added a set of RDS condition tags for additional flexibility. You can reference values such as rds:DatabaseClass, rds:DatabaseEngine, and rds:Piops in your policies.

For more information, consult the Managing Access to Your Amazon RDS Resources and Database chapter in the RDS documentation.

The AWS Security Blog takes an even more detailed look at this feature and shows you how to use it!

Go For It
These new features are available now and you can start using them today.

— Jeff;

Running Riak on AWS – New White Paper

Continuing with our theme of publishing white papers to show you how to run popular relational and NoSQL databases on AWS, I am pleased to tell you that our new Riak on AWS white paper is now available.

Authored by AWS Solutions Architect Brian Holcomb (a one-time member of the Obama for America campaign), this 14 page paper shows you how to launch Riak from the AWS Marketplace and to set up clustering.

It covers architecture and scale, data distribution, replication, and node failure. The paper provides detailed guidelines on a number of operational considerations including EC2 instance sizing, storage configuration, and network configuration. It provides handy tips for simulating uprades, scaling, and failure states, and also addresses security.

— Jeff;

Running PostgreSQL on AWS – New White Paper

You have a plethora of options when you want to run a relational or NoSQL databases on AWS.

On the relational side, you can use the Relational Database Service (RDS) to run a MySQL, Oracle, or SQL Server database. RDS will take care of the scaling, backup, maintenance, patching, and failover for you so that you can focus on your application.

On the NoSQL side, DynamoDB can scale to accommodate any amount of data and any request rate, making it ideal for applications with an unlimited potential to grow.

The AWS Marketplace also contains a very well-curated selection of relational and NoSQL databases and caches.

You also have the option to launch the database of your choice on an Amazon EC2 instance. In order to provide you with the information that you need to do this while taking advantage of all of the flexibility that AWS has to offer, we have worked with our partners to write some very detailed white papers.

The first such white paper, RDBMS in the Cloud: PostgreSQL on AWS, was released a few days ago. This 23 page document was authored by AWS Solutions Architect Miles Ward and the senior staffers at PalominoDB.

The document covers installation, use of SSD storage, and use of EBS. It also addresses the operational side with detailed information about maintenance, backup and restore, storage of backup files, replication, and monitoring. It concludes with a detailed look at security, touching on disk encryption, row-level encryption, and SSL.

Stay tuned for additional white papers in this series!

— Jeff;

 

 

EBS Snapshot Copy Performance Improvement

The EBS Snapshot Copy feature gives you the power to copy EBS snapshots across AWS Regions. Effective today, we have made the snapshot copy even faster than before with support for incremental copies between Regions. It is now practical to copy snapshots to other regions more frequently, making it easier for you to develop applications that are highly available.

The first time you copy an EBS snapshot of a volume to a particular Region, all of the data will be copied.  The second and subsequent copies of snapshots from the same volume to the same destination region will be incremental: only the data that has changed since the last copy will be transferred. As a result, the snapshot will transfer less data and complete more quickly than before. 

The magnitude of the improvement will depend on the amount of data that has been changed since the last snapshot copy. To give you a sense for how much of a benefit you can expect, we measured the amount of change between snapshots across a wide variety of EBS volumes running a number of applications. Based on our findings, we expect to see a 50x speedup for the second and subsequent incremental copies of an EBS volume snapshot.

AWS customer Aptean uses EBS Snapshot Copy as part of their enterprise disaster recovery offering.  Aptean Vice President Mario Baldasserini told me that:

Aptean has been using EBS Snapshot Copy since its launch in providing innovative disaster recovery solutions for our worldwide customers.  We are thrilled with the incremental support availability as it will allow us to further reduce our recovery objectives in providing a worldwide product solution on AWS.

I look forward to hearing more about how you leverage the faster cross-Region EBS Snapshot Copy in your own applications.

Earlier this year, we launched the cross-region EC2 AMI Copy feature, which builds on the EBS Snapshot Copy.  Today’s enhancement also makes the AMI Copy faster when you copy EBS-backed AMIs.

Other than the speed and efficiency benefits mentioned above, this change is transparent and you need not do anything special in order to take advantage of it if you are making copies using the AWS Management Console, the ec2-copy-snapshot or ec2-copy-image commands, or the CopySnapshot or CopyImage API.

— Jeff;

The first time you copy an EBS snapshot, to a particular Region, all of the data will be copied.  For the second and subsequent copies of the same volume transferred to the same destination region [R1] will be incremental, resulting in faster copy to the same destination Region, only the data that has changed since the last copy will be transferred.  As a result, the snapshot will transfer less data and complete more quickly than before.  Of course, the magnitude of the improvement will depend on the amount of data that has been changed since the last snapshot copy.


 [R1]Added this to follow through in the example on the point made earlier that incremental snapshots are specific to a region pair.

Amazon EC2 Expansion – Additional Instance Types in Japan

I’m happy to announce that the following EC2 instance types are now available in the Asia Pacific (Tokyo) Region and that you can start using them today:

Cluster Compute Eight Extra Large (cc2.8xlarge) – With 60.5 GiB of RAM, a pair of Intel Xeon E5-2670 processors, and 3.3 TB of instance storage, the very high CPU performance and cluster networking features of this instance type make it a great fit for applications such as analytics, encoding, renderings, and High Performance Computing (HPC).

High Memory Cluster Eight Extra Large Instance (cr1.8xlarge) – Featuring 244 GiB of RAM, dual Xeon E5-2670’s, and 240 GB of SSD instance storage, you can run memory-intensive analytics, databases, HPC workloads, and other memory-bound applications on these instances.

High I/O Quadruple Extra Large (hi1.4xlarge) – 60.5 GiB of RAM and 2 TB of SSD storage, along with 16 virtual cores make this instance a perfect host for transactional systems and NoSQL databases like Cassandra and MongoDB that can benefit from very high random I/O performance.

High Storage Eight Extra Large (hs1.8xlarge) – 117 GiB of RAM, 48 TB of instance storage (24 drives, each with 2 TB), and 16 virtual cores provide high sequential I/O performance across very large data sets. You can build a data warehouse, run Hadoop jobs, and host cluster file systems on these instances.

All of the instances listed above also include 10 Gigabit Ethernet networking and feature very high network I/O performance. You can learn more about them on the EC2 Instance Types page. You may also find the EC2 Instance Types table handy.

— Jeff;

 PS – We are also launching Amazon Redshift in the Tokyo Region.

Amazon Route 53 Adds ELB Integration for DNS Failover

I’m happy to announce that Route 53 DNS Failover now supports Elastic Load Balancing (ELB) endpoints.

Route 53 launched DNS Failover on February 11, 2013. With DNS Failover, Route 53 can detect an outage of your website and redirect your end users to alternate or backup locations that you specify. Route 53 DNS Failover relies on health checks-regularly making Internet requests to your applications endpoints from multiple locations around the world-to determine whether each endpoint of your application is up or down.

Until today, it was difficult to use DNS Failover if your application was running behind ELB to balance your incoming traffic across EC2 instances, because there was no way configure Route 53 health checks against an ELB endpoint-to create a health check, you need to specify an IP address to check, and ELBs dont have fixed IP addresses.

Whats different about DNS Failover for ELB?
Determining the health of an ELB endpoint is more complex than health checking a single IP address. For example, what if your application is running fine on EC2, but the load balancer itself isnt reachable? Or if your load balancer and your EC2 instances are working correctly, but a bug in your code causes your application to crash? Or how about if the EC2 instances in one Availability Zone of a multi-AZ ELB are experiencing problems?

Route 53 DNS Failover handles all of these failure scenarios by integrating with ELB behind the scenes. Once enabled, Route 53 automatically configures and manages health checks  for individual ELB nodes. Route 53 also takes advantage of the EC2 instance health checking that ELB performs (information on configuring your ELB health checks is available here). By combining the results of health checks of your EC2 instances and your ELBs, Route 53 DNS Failover is able to evaluate the health of the load balancer and the health of the application running on the EC2 instances behind it. In other words, if any part of the stack goes down, Route 53 detects the failure and routes traffic away from the failed endpoint.

A nice bonus is that, because you dont create any health checks of your own, DNS Failover for ELB endpoints is available at no additional charge-you arent charged for any health checks.

When setting up DNS Failover for an ELB Endpoint, you simply set Evaluate Target Health to true-you dont create a health check of your own for this endpoint:

Scenarios Possible with DNS Failover
Using Route 53 DNS Failover, you can run your primary application simultaneously in multiple AWS regions around the world and fail over across regions. Your end users will be routed to the closest (by latency), healthy region for your application. Route 53 automatically removes from service any region where your application is unavailable-it will pull an endpoint out service if theres a region-wide connectivity or operational issue, if your application goes down in that region, or if your ELB or EC2 instances go down in that region.

You can also leverage a simple backup site hosted on Amazon S3, with Route 53 directing users to this backup site in the event that your application becomes unavailable. In February we published a tutorial on how to create a simple backup website. Now you can take advantage of this simple backup scenario if your primary website is running behind an ELB-just skip the part of the tutorial about creating a health check for your primary site, and instead create an Alias record pointing to your ELB and check the evaluate target health option on the Alias record (full documentation on using DNS Failover with ELB is available in the Route 53 Developer Guide.

Get Started and Learn More
Join the High Availability with Route 53 DNS Failover Webinar at 10:00 AM PDT on July 9, 2013 to learn more about DNS Failover and the high-availability architecture options that it makes possible.

To get started with DNS Failover for Route 53, visit the Route 53 product page or review our walkthrough in the Amazon Route 53 Developer Guide. Getting started with Route 53 is easy, and there are no upfront costs. See the Route 53 product page for full details and pricing.

— Jeff (with help from Sean Meckley, Product Manager)

AWS OpsWorks Update – Elastic Load Balancing, Monitoring View, More Instance Types

Chris Barclay of the AWS OpsWorks team has put together a really nice guest post to introduce you to three new AWS OpsWorks features.

— Jeff;


We are pleased to announce three new AWS OpsWorks features that make it even easier to manage your applications: Elastic Load Balancing support, a monitoring view of your stacks Amazon CloudWatch metrics, and support for additional Amazon EC2 instance types.

Elastic Load Balancing Support

You can now use Elastic Load Balancing to automatically distribute traffic across your applications instances. Some of the advantages of using Elastic Load Balancing with your OpsWorks applications are

  • Elastic Load Balancing automatically scales its request handling capacity in response to incoming application traffic.
  • Elastic Load Balancing spans multiple AZs for reliability, but provides a single DNS name for simplicity.
  • Elastic Load Balancing metrics such as request count and request latency are reported by Amazon CloudWatch.
  • SSL certificates are stored using IAM credentials, allowing you to control who can see your private keys.

To get started, once you have created your ELB in the EC2 console, simply add it to the layer you want to load balance, such as your Rails app server. The layer can have a fixed pool of instances or it can use instance-based scaling to grow the capacity based on load or time. OpsWorks automatically takes care of adding and removing the instances in your layer with the load balancer.

Monitoring View
The new monitoring view is a convenient way to see the status of the instances running your application. OpsWorks sends thirteen 1-minute metrics to CloudWatch for each instance, including CPU, memory and load. The metrics are automatically grouped and filtered by each layer in the stack. You can specify a time period, select a particular metric that you want to view, or drill down to specific instances to get a more detailed view.

Additional Instance Type Support
OpsWorks now supports EBS-backed EC2 instances to give you more instance types to choose for your development needs, including the AWS Free Usage Tier-eligible micro instance.

Go For It
You can use all of these new features with a few clicks of the AWS Management Console.

You may also want to sign up for our upcoming AWS OpsWorks Webinar (May 23 at 10:00 AM PST). In the webinar you will learn about key concepts and design patterns for continuous deployment and integration using technologies like AWS OpsWorks and Chef.

Chris Barclay, Senior Product Manager