My colleague Drew Dennis sent a nice guest post that shows how to use Amazon ECS with Spot fleet.

—

There are advantages to using on-demand EC2 instances. However, for many workloads, such as stateless or task-based scenarios that simply run as long as they need to run and are easily replaced with subsequent identical processes, Spot fleet can provide additional compute resources that are more economical. Furthermore, Spot fleet attempts to replace any terminated instances to maintain the requested target capacity.

Amazon ECS is a highly scalable, high performance, container management service that supports Docker containers and allows you to run applications on a managed cluster of Amazon EC2 instances easily. ECS already handles the placement and scheduling of containers on EC2 instances. When combined with Spot fleet, ECS can deliver significant savings over EC2 on-demand pricing.

Why Spot fleet?

Amazon EC2 Spot instances allow you to bid on spare Amazon EC2 computing capacity. Because Spot instances are often available at a discount compared to On-Demand pricing, you can significantly reduce the cost of running your applications. Spot fleet enables customers to request a collection of Spot instances across multiple Availability Zones and instance types with a single API call.

The Spot fleet API call can specify a target capacity and an allocation strategy. The two available allocation strategies are lowest price and diversified. Lowest price means the instances are provisioned based solely on the lowest current Spot price available while diversified fulfills the request equally across multiple Spot pools (instances of the same type and OS within an Availability Zone) to help mitigate the risk of a sudden Spot price increase. For more information, see How Spot Fleet Works.

Using Spot fleet

The Spot fleet console is available at https://console.aws.amazon.com/ec2spot/home. It provides a simple approach to creating a Spot fleet request and setting up all necessary attributes of the request, including creating an IAM role and base64-encoding user data. The console also provides the option to download the request JSON, which can be used with the CLI if desired.

If you prefer not to use the Spot fleet console, you need to make sure you have an IAM role created with the necessary privileges for the Spot fleet request to bid on, launch, and terminate instances. Note that the iam:PassRole action is needed in this scenario so that Spot fleet can launch instances with a role to participate in an ECS cluster. You need to make sure that you have an AWS SDK or the AWS CLI installed.

This post assumes you are familiar with the process of creating an ECS cluster, creating an ECS task definition, and launching the task definition as a manual task or service. If not, see the ECS documentation.

Creating a Spot fleet request

Before you make your Spot fleet request, make sure you know the instance types, Availability Zones, and bid prices that you plan to request. Note that individual bid prices for various instance types can be used in a Spot fleet request. When you have decided on these items, you are ready to begin the request. In the screenshot below, a fleet request is being created for four c4.large instances using an Amazon Linux ECS-optimized AMI. You can obtain the most up-to-date list of ECS optimized AMIs by region in the Launching an Amazon ECS Container Instance topic.

Notice the very useful warnings if your bid price is below the minimum price to initially launch the instance. From here, you can also access the Spot pricing history and Spot Bid Advisor to better understand past pricing volatility. After choosing Next, you see options to spread the request across multiple zones, specify values for User data, and define other request attributes as shown below. In this example, the user data sets the ECS cluster to which the ECS container agent connects.

Other examples could create a Spot fleet request that contains multiple instance types with Spot price overrides for each instance type in a single Availability Zone. The allocation strategy could still be diversified, which means it will pull equally from the two instance-type pools. This could easily be combined with the previous example to create a fleet request that spans multiple Availability Zones and instance types, further mitigating the risk of Spot instance termination.

Running ECS tasks and services on your Spot fleet

After your instances have joined your ECS cluster, you are ready to start tasks or services on them. This involves first creating a task definition. For more information, see the Docker basics walkthrough. After the task definition is created, you can run the tasks manually, or schedule them as a long-running process or service.

In the case of an ECS service, if one of the Spot fleet instances is terminated due to a Spot price interruption, ECS re-allocates the running containers on another EC2 instance within the cluster to maintain the desired number of running tasks, assuming that sufficient resources are available.

If not, within a few minutes, the instance is replaced with a new instance by the Spot fleet request. The new instance is launched according to the configuration of the initial Spot fleet request and rejoins the cluster to participate and run any outstanding containers needed to meet the desired quantity.

In summary, Spot fleet provides an effective and economical way to add instances to an ECS cluster. Because a Spot fleet request can span multiple instance types and Availability Zones, and will always try to maintain a target number of instances, it is a great fit for running stateless containers and adding inexpensive capacity to your ECS clusters.

Auto Scaling and Spot fleet requests

Auto Scaling has proven to be a great way to add or remove EC2 capacity to many AWS workloads. ECS supports Auto Scaling on cluster instances and provides CloudWatch metrics to help facilitate this scenario. For more information, see Tutorial: Scaling Container Instances with CloudWatch Alarms. The combination of Auto Scaling and Spot fleet provides a nice way to have a pool of fixed capacity and variable capacity on demand while reducing costs.

Currently, Spot fleet requests cannot be integrated directly with Auto Scaling policies as they can with Spot instance requests. However, the Spot fleet API does include an action called ModifySpotFleetRequest that can change the target capacity of your request. The Dynamic Scaling with EC2 Spot Fleet blog post shows an example of a scenario that leverages CloudWatch metrics to invoke a Lambda function and change the Spot fleet target capacity. Using ModifySpotFleetRequest can be a great way to not only fine-tune your fleet requests, but also minimize over-provisioning and further lower costs.

Conclusion

Amazon ECS manages clusters of EC2 instances for reliable state management and flexible container scheduling. Docker containers lend themselves to flexible and portable application deployments, and when used with ECS provide a simple and effective way to manage fleets of instances and containers, both large and small.

Combining Spot fleet with ECS can provide lower-cost options to augment existing clusters and even provision new ones. Certainly, this can be done with traditional Spot instance requests. However, because Spot fleet allows requests to span instance families and Availability Zones (with multiple allocation strategies, prices, etc.), it is a great way to enhance your ECS strategy by increasing availability and lowering the overall cost of your cluster’s compute capacity.

Tipu Qureshi, AWS Senior Cloud Support Engineer

The RequestSpotFleet API allows you to launch and manage an entire fleet of EC2 Spot Instances with one request. A fleet is a collection of Spot Instances that are all working together as part of a distributed application and providing cost savings. With the ModifySpotFleetRequest API, it’s possible to dynamically scale a Spot fleet’s target capacity according to changing capacity requirements over time. Let’s look at a batch processing application that is utilizing Spot fleet and Amazon SQS as an example. As discussed in our previous blog post on Additional CloudWatch Metrics for Amazon SQS and Amazon SNS, you can scale up when the ApproximateNumberOfMessagesVisible SQS metric starts to grow too large for one of your SQS queues, and scale down once it returns to a more normal value.

There are multiple ways to accomplish this dynamic scaling. As an example, a script can be scheduled (e.g. via cron) to get the value of the ApproximateNumberOfMessagesVisible SQS metric periodically and then scale the Spot fleet according to defined thresholds. The current size of the Spot fleet can be obtained using the DescribeSpotFleetRequests API and the scaling can be carried out by using the new ModifySpotFleetRequest API. A sample script written for NodeJS is available here, and following is a sample IAM policy for an IAM role that could be used on an EC2 instance for running the script:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1441252157702",
      "Action": [
        "ec2:DescribeSpotFleetRequests",
        "ec2:ModifySpotFleetRequest",
        "cloudwatch:GetMetricStatistics"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}/

By leveraging the IAM role on an EC2 instance, the script uses the AWS API methods described above to scale the Spot fleet dynamically. You can configure variables such as the Spot fleet request, SQS queue name, SQS metric thresholds and instance thresholds according to your application’s needs. In the example configuration below we have set the minimum number of instances threshold (minCount) at 2 to ensure that the instance count for the spot fleet never goes below 2. This is to ensure that a new job is still processed immediately after an extended period with no batch jobs.

// Sample script for Dynamically scaling Spot Fleet
// define configuration
var config = {
    spotFleetRequest:'sfr-c8205d41-254b-4fa9-9843-be06585e5cda', //Spot Fleet Request Id
    queueName:'demojobqueue', //SQS queuename
    maxCount:100, //maximum number of instances
    minCount:2, //minimum number of instances
    stepCount:5, //increment of instances
    scaleUpThreshold:20, //CW metric threshold at which to scale up
    scaleDownThreshold:10, //CW metric threshold at which to scale down
    period:900, //period in seconds for CW
    region:'us-east-1' //AWS region
};

// dependencies
var AWS = require('aws-sdk');
var ec2 = new AWS.EC2({region: config.region, maxRetries: 5});
var cloudwatch = new AWS.CloudWatch({region: config.region, maxRetries: 5});

console.log ('Loading function');
main();

//main function
function main() {
//main function
    var now = new Date();
    var startTime = new Date(now - (config.period * 1000));
    console.log ('Timestamp: '+now);
    var cloudWatchParams = {
        StartTime: startTime,
        EndTime: now,
        MetricName: 'ApproximateNumberOfMessagesVisible',
        Namespace: 'AWS/SQS',
        Period: config.period,
        Statistics: ['Average'],
        Dimensions: [
            {
                Name: 'QueueName',
                Value: config.queueName,
            },
        ],
        Unit: 'Count'
    };
    cloudwatch.getMetricStatistics(cloudWatchParams, function(err, data) {
        if (err) console.log(err, err.stack); // an error occurred
        else {
            //set Metric Variable
            var metricValue = data.Datapoints[0].Average;
            console.log ('Cloudwatch Metric Value is: '+ metricValue);
            var up = 1;
            var down = -1;
            // check if scaling is required
            if (metricValue = config.scaleDownThreshold)
                console.log ("metric not breached for scaling action");
            else if (metricValue >= config.scaleUpThreshold)
                scale(up); //scaleup
            else
                scale(down); //scaledown
        }
    });
};

//defining scaling function
function scale (direction) {
    //adjust stepCount depending upon whether we are scaling up or down
    config.stepCount = Math.abs(config.stepCount) * direction;
    //describe Spot Fleet Request Capacity
    console.log ('attempting to adjust capacity by: '+ config.stepCount);
    var describeParams = {
        DryRun: false,
        SpotFleetRequestIds: [
            config.spotFleetRequest
        ]
    };
    //get current fleet capacity
    ec2.describeSpotFleetRequests(describeParams, function(err, data) {
        if (err) {
            console.log('Unable to describeSpotFleetRequests: ' + err); // an error occurred
            return 'Unable to describeSpotFleetRequests';
        }
        //set current capacity variable
        var currentCapacity = data.SpotFleetRequestConfigs[0].SpotFleetRequestConfig.TargetCapacity;
        console.log ('current capacity is: ' + currentCapacity);
        //set desired capacity variable
        var desiredCapacity = currentCapacity + config.stepCount;
        console.log ('desired capacity is: '+ desiredCapacity);
        //find out if the spot fleet is already modifying
        var fleetModifyState = data.SpotFleetRequestConfigs[0].SpotFleetRequestState;
        console.log ('current state of the the spot fleet is: ' + fleetModifyState);
        //only proceed forward if  maxCount or minCount hasn't been reached
        //or spot fleet isn't being currently modified.
        if (fleetModifyState == 'modifying')
            console.log ('capacity already at min, max or fleet is currently being modified');
        else if (desiredCapacity  config.maxCount)
            console.log ('capacity already at max count');
        else {
            console.log ('scaling');
            var modifyParams = {
                SpotFleetRequestId: config.spotFleetRequest,
                TargetCapacity: desiredCapacity
            };
            ec2.modifySpotFleetRequest(modifyParams, function(err, data) {
                if (err) {
                    console.log('unable to modify spot fleet due to: ' + err);
                }
                else {
                    console.log('successfully modified capacity to: ' + desiredCapacity);
                    return 'success';
                }
            });
        }
    });
}

You can modify this sample script to meet your application’s requirements.

You could also leverage AWS Lambda for dynamically scaling your Spot fleet. As depicted in the diagram below, an AWS Lambda function can be scheduled (e.g using AWS datapipeline, cron or any form of scheduling) to get the ApproximateNumberOfMessagesVisible SQS metric for the SQS queue in a batch processing application. This Lambda function will check the current size of a Spot fleet using the DescribeSpotFleetRequests API, and then scale the Spot fleet using the ModifySpotFleetRequest API after also checking certain constraints such as the state or size of the Spot fleet similar to the script discussed above.

You could also use the sample IAM policy provided above to create an IAM role for the AWS Lambda function. A sample Lambda deployment package for dynamically scaling a Spot fleet based on the value of the ApproximateNumberOfMessagesVisible SQS metric can be found here. However, you could modify it to use any CloudWatch metric based on your use case. The sample script and Lambda function provided are only for reference and should be tested before using in a production environment.

Tipu Qureshi, AWS Senior Cloud Support Engineer

With Spot Instances, you can save up to 90% of costs by bidding on spare Amazon Elastic Compute Cloud (Amazon EC2) instances. This reference architecture is meant to help enable you to realize cost savings for batch processing applications while maintaining high availability. We recommend tailoring and testing it for your application before implementing it in a production environment.

Below is a multi-part job processing architecture that can be used for the deployment of a heterogeneous, scalable “grid” of worker nodes that can quickly crunch through large batch processing tasks in parallel. There are numerous batch oriented applications in place today that can leverage this style of on-demand processing, including claims processing, large scale transformation, media processing and multi-part data processing work.

Raw job data is uploaded to Amazon Simple Storage Service (S3) which is a highly-available and persistent data store. An AWS Lambda function will be invoked by S3 every time a new object is uploaded to the input S3 bucket. AWS Lambda is a compute service that runs your code in response to events and automatically manages the compute resources for you, making it easy to build applications that respond quickly to new information. Information about Lambda functions is available here and a walkthrough on triggering Lambda functions on S3 object uploads is available here.

AWS Lambda automatically runs your code with an IAM role that you select, making it easy to access other AWS resources, such as Amazon S3, Amazon SQS, and Amazon DynamoDB. AWS lambda can be used to place a job message into an Amazon SQS queue. Amazon Simple Queue Service (SQS) is a fast, reliable, scalable, fully managed message queuing service, which makes it simple and cost-effective to decouple the components of a cloud application. Depending on the application’s needs, multiple SQS queues might be required for different functions and priorities.

The AWS Lambda function will also store state information for each job task in Amazon DynamoDB. DynamoDB is a regional service, meaning that the data is automatically replicated across availability zones. AWS Lambda can be used to trigger other types of workflows as well, such as an Amazon Elastic Transcoder job. EC2 Spot can also be used with Amazon Elastic MapReduce (Amazon EMR).
Below is a sample IAM policy that can be attached to an IAM role for AWS Lambda. You will need to change the ARNs to match your resources.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1438283855455",
      "Action": [
        "dynamodb:PutItem"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:dynamodb:us-east-1::table/demojobtable"
    },
    {
      "Sid": "Stmt1438283929844",
      "Action": [
        "sqs:SendMessage"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:sqs:us-east-1::demojobqueue"
    }
  ]
}

Below is a sample Lambda function that will send an SQS message and put an item into a DynamoDB table in response to a S3 object upload. You will need to change the SQS queue URL and DynamoDB table name to match your resources.

// create an IAM Lambda role with access to Amazon SQS queue and DynamoDB table
// configure S3 to publish events as shown here: http://docs.aws.amazon.com/lambda/latest/dg/walkthrough-s3-events-adminuser-configure-s3.html

// dependencies
var AWS = require('aws-sdk');

// get reference to clients
var s3 = new AWS.S3();
var sqs = new AWS.SQS();
var dynamodb = new AWS.DynamoDB();

console.log ('Loading function');

exports.handler = function(event, context) {
  // Read options from the event.
  var srcBucket = event.Records[0].s3.bucket.name;
  // Object key may have spaces or unicode non-ASCII characters.
  var srcKey = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " "));
  // prepare SQS message
  var params = {
    MessageBody: 'object '+ srcKey + ' ',
    QueueUrl: 'https://sqs.us-east-1.amazonaws.com//demojobqueue',
    DelaySeconds: 0
  };
  //send SQS message
  sqs.sendMessage(params, function (err, data) {
    if (err) {
      console.error('Unable to put object' + srcKey + ' into SQS queue due to an error: ' + err);
      context.fail(srcKey, 'Unable to send message to SQS');
    } // an error occurred
    else {
      //define DynamoDB table variables 
      var tableName = "demojobtable";
      var datetime = new Date().getTime().toString();
      //Put item into DynamoDB table where srcKey is the hash key and datetime is the range key
      dynamodb.putItem({
        "TableName": tableName,
        "Item": {
          "srcKey": {"S": srcKey },
          "datetime": {"S": datetime },
        }
      }, function(err, data) {
        if (err) {
          console.error('Unable to put object' + srcKey + ' into DynamoDB table due to an error: ' + err);
          context.fail(srcKey, 'Unable to put data to DynamoDB Table');
        }
        else {
          console.log('Successfully put object' + srcKey + ' into SQS queue and DynamoDB');
          context.succeed(srcKey, 'Data put into SQS and DynamoDB');
        }
      });
    }
  });
};

Worker nodes are Amazon EC2 Spot and On-demand instances on deployed Auto Scaling groups. These groups are containers that ensure health and scalability of worker nodes. Worker nodes pick up job parts from the input queue automatically and perform single tasks based on the job task state in DynamoDB. Worker nodes will store the input objects in a file system such as Amazon Elastic File System (Amazon EFS) for processing. Amazon EFS is a file storage service for EC2 that provides elastic capacity to your applications, automatically adding storage as you add files. Depending on IO and application needs, the job data can also be stored on local instance store or Amazon Elastic Block Store (EBS). Each job can be further split into multiples sub-parts if there is a mechanism to stitch the outputs together (as in the case of some media processing where pre-segmenting the output may be possible). Once completed, the objects will be uploaded back to S3 using multi-part upload.

Similar to our blog on an EC2 Spot architecture for web applications, Auto Scaling groups running On-demand instances can be used together with groups running Spot instances. Spot Auto Scaling groups can use different Spot bid prices and even different instance types to give you more flexibility and to meet changing traffic demands.

The availability of Spot instances can vary depending on how many unused Amazon EC2 instances are available. Because real-time supply and demand dictates the available supply of Spot instances, you should architect your application to be resilient to instance termination. When the Spot price exceeds the price you named (i.e. the bid price), the instance will receive a warning that it will be terminated after two minutes. You can manage this event by creating IAM roles with the relevant SQS and DynamoDB permissions for the Spot instances to run the required shutdown scripts. Details about Creating an IAM Role Using the AWS CLI can be found here and Spot Instance Termination Notices documentation can be found here.

A script like the following can be placed in a loop and can be run on startup (e.g. via systemd or rc.local) to detect for Spot instance termination. It can then update job task state in DynamoDB and re-insert the job task into the queue if required. We recommend that applications poll on the termination notice at five-second intervals.

#!/bin/bash
while true
  do
    if curl -s http://169.254.169.254/latest/meta-data/spot/termination-time | grep -q .*T.*Z; then /env/bin/runterminationscripts.sh; 
  else
    # Spot instance not yet marked for termination.
    sleep 5
  fi
done

An Auto Scaling group running on-demand instances in tandem with Auto Scaling group(s) running Spot instances will help to ensure your application’s availability in case of changes in Spot market price and Spot instance capacity. Additionally, using multiple Spot Auto Scaling groups with different bids and capacity pools (groups of instances that share the same attributes) can help with both availability and cost savings. By having the ability to run across multiple pools, you reduce your application’s sensitivity to price spikes that affect a pool or two (in general, there is very little correlation between prices in different capacity pools). For example, if you run in five different pools your price swings and interruptions can be cut by 80%.

For Auto Scaling to scale according to your application’s needs, you must define how you want to scale in response to changing conditions. You can assign more aggressive scaling policies to Auto Scaling groups that run Spot instances, and more conservative ones to Auto Scaling groups that run on-demand instances. The Auto Scaling instances will scale up based on the SQS queue depth CloudWatch metric (or more relevant metric depending on your application), but will scale down based on EC2 instance CPU utilization CloudWatch metric (or more relevant metric) to ensure that a job actually gets completed before the instance is terminated. For information about using Amazon CloudWatch metrics (such as SQS queue depth) to scale automatically, see Dynamic Scaling. As a safety buffer, a grace period (e.g. 300 seconds) should also be configured for the Auto Scaling group to prevent termination before a job completes.

Reserved instances can be purchased for the On-demand EC2 instances if they are consistently being used to realize even more cost savings.

To automate further, you can optionally create a Lambda function to dynamically manage Auto Scaling groups based on the Spot market. The Lambda function could periodically invoke the EC2 Spot APIs to assess market prices and availability and respond by creating new Auto Scaling launch configurations and groups automatically. Information on the Describe Spot Price History API is available here. This function could also delete any Spot Auto Scaling groups and launch configurations that have no instances. AWS Data Pipeline can be used to invoke the Lambda function using the AWS CLI at regular intervals by scheduling pipelines. More information about scheduling pipelines is available here and information about invoking AWS Lambda functions using AWS CLI is here.

Meta-announcement: We’re in the process of enabling commenting support for the AWS compute blog. You’ll see it starting to appear on newer posts and getting phased in for a subset of older ones. Looking forward to engaging with our readers directly!

-Tim, Deepak, and our many guest authors

Tipu Qureshi, AWS Senior Cloud Support Engineer

This blog post describes a reference architecture that utilizes Spot Instances and is meant to help enable you to realize additional cost savings for your stateless web tier while maintaining high availability. We recommend tailoring and testing it for your application before implementing it to a production environment.

Spot instances enable you to name your own price for Amazon EC2 computing capacity by simply bidding on unused Amazon EC2 instances, which can often lower your Amazon EC2 costs significantly, depending on your application. For example, Auto Scaling groups running on-demand instances can be placed together with Auto Scaling groups running Spot instances using different Spot bid prices behind the same Elastic Load Balancer to provide more flexibility and to meet changing traffic demands. Please see Launch Spot instances in Your Auto Scaling Group and Load Balance Your Auto Scaling Group for more details about using Spot instances and Auto Scaling groups with an Elastic Load Balancer.

Session state can be stored out of the web tier in a DynamoDB table. DynamoDB is a regional service, meaning that the data is automatically replicated across availability zones for fault tolerance. You can also choose other databases to maintain state in your architecture. The availability of Spot instances can vary depending on how many unused Amazon EC2 instances are available Because real-time supply and demand dictates the available supply of Spot instances as well as the number of instances your business demands, you should architect it to be resilient to instance termination. This includes when the Spot price exceeds the price you named (i.e. the bid price), at which time the instance will receive a two-minute warning that the instance will be terminated. You can manage this by creating IAM roles from the Spot instances that they use to de-register themselves from the ELB once they receive notification that they will be terminated. Details about Creating an IAM Role Using the AWS CLI can be found here and Spot Instance Termination Notices can be found here. The following diagram depicts what this would look like:

Spot Architecture for Web Apps

A script like the following can be placed in a loop and can be run on startup (e.g via systemd or rc.local) to detect Spot instance termination and then place any session information into DynamoDB as well as de-register itself from the ELB so that it will not receive any more requests. We recommend that interested applications poll for the termination notice at five-second intervals.

$ if curl -s http://169.254.169.254/latest/meta-data/spot/termination-time | \
grep -q .*T.*Z; then instance_id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id); \
aws elb deregister-instances-from-load-balancer \
  --load-balancer-name my-load-balancer \
  --instances $instance_id; /env/bin/flushsessiontoDBonterminationscript.sh; fi

An Auto Scaling group running on-demand instances in tandem with Auto Scaling groups running Spot instances behind the same Elastic Load Balancer will help to ensure your application’s availability in case of changes in Spot market price and Spot instance capacity. If the Spot instances in an Auto Scaling group terminate because the Spot price increases past the bid price, then the Auto Scaling group running on-demand instances will scale commensurately according to your defined scaling policy to adequately serve requests. For Auto Scaling to scale according to your application needs, you must define how you want to scale in response to changing conditions. You can assign more aggressive scaling policies to Auto Scaling groups that run Spot instances ( e.g. to scale up when instances reach 75% CPU utilization and scale down when they reach 25% CPU utilization with a large capacity range), and assign more conservative scaling policies to Auto Scaling groups that run on-demand instances. For information about using Amazon CloudWatch metrics to scale automatically, see Dynamic Scaling.

Please note that Elastic Load Balancers use the least outstanding request (for HTTP/HTTPS connections) routing algorithm which favors back-end instances with the fewest outstanding requests. Since we are working with multiple Auto Scaling groups spanning across multiple availability zones, we highly recommend enabling cross-zone load balancing for the load balancer. Cross-zone load balancing allows each load balancer node to route requests across multiple availability zones, ensuring that each zone receives an equal amount of request traffic. To allow in-flight requests to complete when de-registering Spot instances that are about to be terminated, connection draining can be enabled on the load balancer with a timeout of 90 seconds. Connection draining causes the ELB load balancer to stop sending new requests to a deregistering instance or an unhealthy instance, while keeping the existing connections open. For more details please see Enable or Disable Connection Draining for Your Load Balancer.

Tim Wagner, AWS Lambda

AWS re:Invent 2014 Recap

The 2014 re:Invent conference was an exciting venue for us to launch new compute-related services and features, including the Amazon EC2 Container Service, which supports Docker containers and lets you easily run distributed applications on a managed cluster of EC2 instances, and AWS Lambda, a new compute service that runs your code in response to events and manages all the compute resources for you. With over 13,000 attendees, 400 speakers, and more than 250 sessions, it was tough to find time to sleep! If you missed the conference or couldn’t attend some of the compute-related sessions, here’s a list of compute-related videos and slideshare links to get caught up:

Amazon EC2 Container Service (ECS) Launch Announcement, Werner Vogels keynote

In this segment of the Day 2 keynote, Werner announces the new Amazon ECS service and describes how Docker and containers are changing how we think about the composition of distributed applications.

Breakout session: Amazon EC2 Container Service in Action, Deepak Singh APP313

Slides

Deepak and Dan provide an overview of the new Amazon ECS service and its capabilities. Container technology, particularly Docker, is all the rage these days. At AWS, our customers have been running Linux containers at scale for several years, and we are increasingly seeing customers adopt Docker, especially as they build loosely coupled distributed applications. However, to do so they have to run their own cluster management solutions, deal with configuration management, and manage their containers and associated metadata. We believe that those capabilities should be a core building block technology, just like EC2. In this presentation, Deepak and Dan announce the preview of Amazon EC2 Container Service, a new AWS service that makes is easy to run and manage Docker-enabled distributed applications using powerful APIs that allow you to launch and stop containers, get complete cluster state information, and manage linked containers. They discuss the rationale for building the EC2 Container Service, some of the core concepts, and walk you through how you can use the service for your applications.

AWS Lambda Launch Announcement, Werner Vogels keynote

In this segment of the Day 2 keynote, Werner announces the new AWS Lambda service and discusses why AWS is embracing events and event-driven compute as a way to more rapidly construct distributed applications and enhance cloud computing.

Breakout session: Getting Started with AWS Lambda, Tim Wagner MBL202

Slides

AWS Lambda is a new compute service that runs your code in response to events and automatically manages compute resources for you. In this session, we describe what you need to get started quickly, including a review of key features, a live demonstration, how to use AWS Lambda with Amazon S3 event notifications and Amazon DynamoDB streams, and tips on getting the most out of Lambda functions.

Amazon EC2 Instances Deep Dive

Slides

Amazon Elastic Compute Cloud (Amazon EC2) provides a broad selection of instance types to accommodate a diverse mix of workloads. In this technical session, John and Anthony provide an overview of the Amazon EC2 instance platform, key platform features, and the concept of instance generations. They dive into the current generation design choices of the different instance families, including the General Purpose, Compute Optimized, Storage Optimized, Memory Optimized, and GPU instance families. They also detail best practices and share performance tips for getting the most out of your Amazon EC2 instances.

State of the Union: Amazon Compute Services

Slides

In this spotlight talk, Peter De Santis, Vice President of Amazon Compute Services, and Matt Garman, Vice President of Amazon EC2 share a ”behind the scenes” look at the evolution of compute at AWS. You hear about the drivers behind the innovations we’ve introduced, and learn how we’ve scaled our compute services to meet dramatic usage growth.

Lots of exciting announcements, and more to come in 2015! Don’t forget to send us feedback on topics you’d like to hear more about.

-Tim

Tim Wagner, AWS Lambda GM and Deepak Singh, Amazon ECS Sr. Manager

Welcome to the AWS Compute blog! This blog covers compute services offered by AWS, including Amazon EC2, Amazon ECS, and AWS Lambda, with a focus on new trends in cloud computing. In it you’ll find

• Announcements and discussions of new features
• Deep dives on technical topics
• Best practices for using and optimizing AWS compute services
• Code samples, tips, and tricks

You’ll see content from many of our team members, including developers from the EC2, ECS, and Lambda teams.

We hope you’ll come back often to visit. If you’d like to see any specific topics covered, please let us know.

Deepak and Tim