AWS Blog

LiveOps Cloud is ready to break open a huge untapped market. The company is a long-time solutions provider for the contact center industry, and just recently launched CxEngage, a new contact center-as-a-service platform built and run entirely on AWS. I asked Jeff Thompson, LiveOps Cloud’s CTO and SVP for engineering, to tell us a bit about their decision to launch this great new service.

We like to say that LiveOps Cloud is a 16-year-old startup. We’re a new company carved out of LiveOps Inc., and our mission is to take the original company’s long history of providing contact center solutions into a new era of cloud-first convenience, performance, and lower costs.

The contact center business is huge, with estimates of at least 15 million seats worldwide that comprise a multi-billion-dollar market. But the industry is a late-comer to cloud computing, with only about 10 percent of contact center operations working in some capacity with cloud infrastructure and tools. So there still are a lot of legacy, on-premises call center systems in place—especially in traditional industries like banking and retail—that are quickly reaching their expiration date. These systems are inadequate for meeting the demands of today’s market, with companies having to hold down costs, provide ever-better performance and sophistication, and serve emerging markets.

Cloud Bake-Off
Our plan was to create a pure cloud contact center-as-a-service (CCaaS) that could deliver an always-on, secure, multi-tenant, and instantly scalable platform so businesses can deliver exceptional customer experiences anywhere, anytime. We anticipated that if done right, our CCaaS would take off in in a true ‘hockey stick’ growth pattern. To get there, we needed to carefully consider what platform would make the most sense.

We held a bake-off that looked at a number of alternatives. Azure, Rackspace, Google, and AWS were in the cloud provider mix, and we also looked at using a colocated facility. That last one was the first to go. We knew from experience that running the platform out of a co-lo would simply not provide the redundancy and scalability we wanted to bake into the new platform. We ruled out Azure because we’re not a Microsoft shop, and were using a lot on non-Windows tools and Linux to create the platform. Rackspace has good IaaS, but their global reach was insufficient for our business goals. We also ruled out Google because they didn’t have the breadth of apps we felt were required to build our platform.

A Clear Winner
In our view, AWS was the clear winner. It delivers all the features and benefits we were seeking. It has an incredibly rich catalog of services, with new ones being released at a pace that competing cloud providers simply are not matching. We might not need them all now, but knowing those services are there, and that AWS is innovating and adding to them all the time, instills real confidence. We know that if we have some need or feature request in the future, chances are AWS already has a service that can address it. Good examples—and just a small portion of the AWS services that we use—are Amazon Redshift and Amazon Kinesis, two powerful data services that are essential to our platform, and Amazon Simple Queue Service (SQS), which drives messaging out to agent toolbars.

AWS also has broad global reach, which is critical to the CxEngage business model. The North American and Western European markets are certainly an important source of revenue. We also see great opportunity in emerging call center markets in places like China, India, and the Asia-Pacific region. AWS operates in 12 regions around the world. That means we can provide services in close physical proximity to new customers, which boosts performance by reducing latency. When a call comes in, the businesses using our platform don’t want lag times in the system. And in some cases, it helps when there are sovereignty issues related to keeping data within particular boundaries.

AWS also provides major benefits in terms of flexibility and financial performance. For example, we can carefully plan for specific Amazon EC2 instance types to match the performance needs of particular services in the CxEngage platform. Some may require more I/O, some more memory. We can pick exactly what we need and not overprovision, which helps us not only optimize for performance, but also meet our financial goals. That, and the pay-as-you-go model of AWS, has made AWS very popular with our finance department.

Simple, with No Drama
AWS also makes it easier to build the business. For example, the built-in support for PCI and HIPAA, and the compliance and regulatory standards included with AWS GovCloud (US), help us quickly overcome potential barriers to signing new and important customers. We can check off those boxes and keep moving.

We started the journey of building the next-generation solution for call centers in 2014. We placed our bet on AWS, and 18 months later when we launched CxEngage, all of our financial and performance predictions for the platform were borne out. Everything we thought would happen by using AWS happened. It was simple, with no drama. We’re looking at AWS as a partner that is fundamental to our business, and to our growth plan.

— Jeff Thompson, CTO and SVP, LiveOps Cloud Platform

My colleagues Jessica Beegle and Christopher Crosbie shared the inspiring story below!

The science of cancer research is continually evolving to include new fields of study. Examples include development of chemotherapies, radiology amplified treatments, and epidemiology for identifying carcinogens. Pathology continues to help deepen the understanding of the disease’s manifestations.

The discipline of computer science is a relatively new entrant in the quest to understand, treat and cure cancer. Computer science is needed to decipher how certain variations in our DNA relate to cancer and what treatment paths have the greatest potential for success for each individual. This type of task is best suited for computer science because the study of DNA, typically referred to as genomics, requires significant big data processing capabilities. In fact, scientists predict genomics will generate more digital information than astronomy, YouTube, and Twitter by 2025.

Today, much of the software developed to collect, analyze and visualize this data is created in silos among different IT systems, research departments, health care institutions, and even nations. This separation greatly hinders the speed of scientific discovery.

Researchers at Fred Hutchinson Cancer Research Center in Seattle wanted to change this. Led by Eric Holland, M.D., Ph.D., director of the Human Biology Division and Solid Tumor Translational Research at Fred Hutch, the team developed Oncoscape, an open-source web application to apply and develop analysis tools for molecular and clinical data.  Oncoscape enables researchers to discover new patterns and relationships, which further cancer research.

To utilize current technology in computer science, the Oncoscape team collaborated with GitHub and AWS. The goal was to leverage the code-sharing platform that GitHub provides with the cloud computing capabilities that AWS offers. According to Dr. Holland:

Hosting Oncoscape in the cloud makes it easy for our development team to make changes and redeploy the software in order to keep up with the needs of the research community. Knowing I can securely access the site from anywhere in the world allows me to show collaborators what is possible with data visualization and how we can use a common platform to work together in cancer research.

Robert McDermott, the IT Solutions Architect behind the AWS deployment of Oncoscape explains: “AWS is a very capable, reliable and flexible platform that allows us to quickly adapt to the needs of the project.” He cites maturity, reliability, breadth and depth of services and security as the key drivers for using AWS.

Oncoscape uses several AWS services including Amazon EC2, Elastic Load Balancing, Amazon CloudWatch, and Amazon S3. This approach makes it easy to distribute traffic across physical locations (Availability Zones), as well as quickly obtain actionable notifications in the event of a site issue. Amazon Route 53 has also proven useful for quickly making modifications to the development environment.

The diagram below depicts the full Oncoscape integration and deployment pipeline, including the merger points between GitHub, Circleci, DockerHub, Slack, and AWS.

To learn more about the collaboration behind the Oncoscape project please watch this video or visit the Oncoscape home page.

— Jessica Beegle (Global Healthcare & Life Sciences Ecosystem Leader) and Christopher Crosbie (Healthcare and Life Science Solution Architect)

My colleague Sanjay Padhi is part of the AWS Scientific Computing team. He wrote the guest post below to share the story of how AWS provided computational resources that aided in an important scientific discovery.

The Higgs boson (sometimes referred to as the God Particle), responsible for providing insight into the origin of mass, was discovered in 2012 by the world’s largest experiments, ATLAS and CMS, at the Large Hadron Collider (LHC) at CERN in Geneva, Switzerland. The theorists behind this discovery were awarded the 2013 Nobel Prize in Physics.

Deep underground on the border between France and Switzerland, the LHC is the world’s largest (17 miles in circumference) and highest-energy particle accelerator. It explores nature on smaller scales than any human invention has ever explored before.

From Experiment to Raw Data
The high energy particle collisions turn mass in to energy, which then turns back in to mass, creating new particles that are observed in the CMS detector. This detector is 69 feet long, 49 feet wide and 49 feet high, and sits in a cavern 328 feet underground near the village of Cessy in France. The raw data from the CMS is recorded every 25 nanoseconds at a rate of approximately 1 petabyte per second.

After online and offline processing of the raw data at the CERN Tier 0 data center, the datasets are distributed to 7 large Tier 1 data centers across the world within 48 hours, ready for further processing and analysis by scientists (the CMS collaboration, one of the largest in the world, consists of more than 3,000 participating members from over 180 institutes and universities in 43 countries).

Processing at Fermilab
Fermilab is one of 16 National Laboratories operated by the United States Department of Energy. Located just outside Batavia Illinois, Fermilab serves as one of the Tier 1 data centers for Cern’s CMS experiment.

With the increase in LHC collision energy last year, the demand for data assimilation, event simulations, and large-scale computing increased as well. With this increase came a desire to maximize cost efficiency by dynamically provisioning resources on an as-needed basis.

In order to address this issue, the Fermilab Scientific Computing Division launched the HEP (High Energy Physics) Cloud project in June of 2015. They planned to develop a virtual facility that would provide a common interface to access a variety of computing resources including commercial clouds. Using AWS, the HEP Cloud project successfully demonstrated the ability to add 58,000 cores elastically to their on-premises facility for the CMS experiment.

The image below depicts one of the simulations that was run on AWS. It shows how the collision of two protons creates energy that then becomes new particles.

The additional 58,000 cores represents a 4x increase in Fermilab’s computational capacity, all of which is dedicated to the CMS experiment in order to generate and reconstruct Monte Carlo simulation events. More than 500 million events were fully simulated in 10 days using 2.9 million jobs. Without help from AWS, this job would have taken 6 weeks to complete using the on-premises compute resources at Fermilab.

This simulation was done in preparation for one of the major high energy physics international conferences, Recontres de Moriond. Physicists across the world will use these simulations to probe nature in detail and will share their findings with their international colleagues during the conference.

Saving Money with HEP Cloud
The HEP Cloud project aims to minimize the costs of computation. The R&D and demonstration effort was supported by an award from the AWS Cloud Credit for Research.

HEP Cloud’s decision engine, the brain of the facility, has several duties. It oversees EC2 Spot Market price fluctuations using  tools and techniques provided by Amazon’s Spot team,  initializes Amazon EC2 instances using HTCondor, tracks the DNS names of the instances using Amazon Route 53 , and makes use of AWS CloudFormation templates for infrastructure as a code.

While on the road to success, the project team had to overcome several challenges, ranging from fine-tuning configurations to optimizing their use of Amazon S3 and other resources. For example, they devised a strategy to distribute the auxiliary data across multiple AWS Regions in order to minimize storage costs and data-access latency.

Automatic Scaling into AWS
The figure below shows elastic, automatic expansion of Fermilab’s Computing Facility into the AWS Cloud using Spot instances for CMS workflows. Monitoring of the resources was done using open source software provided by Grafana with custom modifications provided by the HEP Cloud.

Panagiotis Spentzouris (head of the Scientific Computing Division at Fermilab), told me:

Modern HEP experiments require massive computing resources in irregular cycles, so it is imperative for the success of our program that our computing facilities can rapidly expand and contract resources to match demand.  Using commercial clouds is an important ingredient for achieving this goal, and our work with AWS on the CMS experiment’s workloads though HEPCloud was a great success in demonstrating the value of this approach.

I hope that you enjoyed this brief insight into the ways in which AWS is helping to explore the frontiers of physics!

— Sanjay Padhi, Ph.D, AWS Scientific Computing

AWS CloudFormation lets you create, manage, and update a collection of AWS resources (a “stack”) in a controlled, predictable manner. Every day, customers use CloudFormation to perform hundreds of thousands of updates to the stacks that support their production workloads. They define an initial template and then revise it as their requirements change.

This model, commonly known as infrastructure as code, gives developers, architects, and operations teams detailed control of the provisioning and configuration of their AWS resources. This detailed level of control and accountability is one of the most visible benefits that you get when you use CloudFormation. However, there are several others that are less visible but equally important:

Consistency – The CloudFormation team works with the AWS teams to make sure that newly added resource models have consistent semantics for creating, updating, and deleting resources. They take care to account for retries, idempotency, and management of related resources such as KMS keys for encrypting EBS or RDS volumes.

Stability – In any distributed system, issues related to eventual consistency often arise and must be dealt with. CloudFormation is intimately aware of these issues and automatically waits for any necessary propagation to complete before proceeding. In many cases they work with the service teams to ensure that their APIs and success signals are properly tuned for use with CloudFormation.

Uniformity – CloudFormation will choose between in-place updates and resource replacement when you make updates to your stacks.

All of this work takes time, and some of it cannot be completely tested until the relevant services have been launched or updated.

Improved Support for Updates
As I mentioned earlier, many AWS customers use CloudFormation to manage updates to their production stacks. They edit their existing template (or create a new one) and then use CloudFormation’s Update Stack operation to activate the changes.

Many of our customers have asked us for additional insight into the changes that CloudFormation is planning to perform when it updates a stack in accord with the more recent template and/or parameter values. They want to be able to preview the changes, verify that they are in line with their expectations, and proceed with the update.

In order to support this important CloudFormation use case, we are introducing the concept of a change set. You create a change set by submitting changes against the stack you want to update. CloudFormation compares the stack to the new template and/or parameter values and produces a change set that you can review and then choose to apply (execute).

In addition to additional insight into potential changes, this new model also opens the door to additional control over updates. You can use IAM to control access to specific CloudFormation functions such as UpdateStack, CreateChangeSet, DescribeChangeSet, and ExecuteChangeSet. You could allow a large group developers to create and preview change sets, and restrict execution to a smaller and more experienced group. With some additional automation, you could raise alerts or seek additional approvals for changes to key resources such as database servers or networks.

Using Change Sets
Let’s walk through the steps involved in working with change sets. As usual, you can get to the same functions using the AWS Command Line Interface (CLI), AWS Tools for Windows PowerShell, and the CloudFormation API.

I started by creating a stack that runs a LAMP stack on a single EC2 instance. Here are the resources that it created:

Then I decided to step up to a more complex architecture. One of my colleagues shared a suitable template with me. Using the “trust but verify” model, I created a change set in order to see what would happen were I to use the template. I clicked on Create Change Set:

Then I uploaded the new template and assigned a name to the change set. If the template made use of parameters, I could have entered values for them at this point.

At this point I had the option to modify the existing tags and to add new ones. I also had the option to set up advanced options for the stack (none of these will apply until I actually execute the change set, of course):

After another click or two to confirm my intent, the console analyzed the template, checks the results against the stack, and displayed the list of changes:

At this point I can click on Execute to effect the changes. I can also leave the change set as-is, or create several others in order to explore some alternate paths forward. When I am ready to go, I can locate the change set and execute it:

CloudFormation springs to action and implements the changes per the change set:

A few minutes later my new stack configuration was in place and fully operational:

And there you have it! As I mentioned earlier, I can create and inspect multiple change sets before choosing the one that I would like to execute. When I do this, the other change sets are no longer meaningful and are discarded.

Managing Rollbacks
If a stack update fails, CloudFormation does its best to put things back the way there were before the update. The rollback operation can fail on occasion; in many cases this is due to a change that was made outside of CloudFormation’s purview. We recently launched a new option that gives you additional control over what happens next. To learn more about this option, read Continue Rolling Back an Update for AWS CloudFormation stacks in the UPDATE_ROLLBACK_FAILED state.

Available Now
This functionality is available now and you can start using it today!

Amazon ElastiCache makes it easy for you to deploy, operate, and scale an in-memory database in the cloud. As you may already know, ElastiCache supports the Memcached and Redis engines.

More Power for Redis
Today we are launching an ElastiCache update that provides you with additional control over your Redis-based ElastiCache clusters. You can now scale up to a larger node type while ElastiCache preserves (on a best-effort basis) your stored information. While ElastiCache for Redis has always allowed you to upgrade the engine version, you can now do so while preserving the stored information. You can apply both changes immediately or during the cluster’s maintenance window.

Behind the scenes, ElastiCache for Redis uses several different strategies to scale up and to upgrade engines. Scaling is based on Redis replication. Engine upgrades use a foreground snapshot (SAVE) when Multi-AZ is turned off, and replication followed by a DNS switch when it is on.

To scale up to a larger node type, simply select the Cache Cluster in the AWS Management Console and click on Modify. Then select the new Node Type, decide if you want to apply the change immediately, and click on Modify to proceed:

Similarly, to upgrade to a newer version of the Redis engine, select the new version and click on Modify:

I would like to take this opportunity to encourage you to upgrade to the engine that is compatible with version 2.8.24 of Redis. This version contains a number of fixes and enhancements to Redis’ stability and robustness (some contributed by the ElastiCache team; see the What’s New for more information).

You can, as always, accomplish the same operations by way of the ElastiCache API.  Here are some quick examples in PHP (via the AWS SDK for PHP):

// Scale to larger node size
$res = $client->modifyCacheCluster(['CacheNodeType' => 'cache.r3.4xlarge', 
                                    'ApplyImmediately' => true]);

// Upgrade engine version
$res = $client->modifyCacheCluster(['EngineVersion' => '2.8.24',
                                    'ApplyImmediately' => true]);

// Do both at once
$res = $client->modifyCacheCluster(['CacheNodeType' => 'cache.r3.4xlarge', 
                                    'EngineVersion' => '2.8.24', 
                                    'ApplyImmediately' => true]);

In all three of these examples, the ApplyImmediately parameter indicates that the changes will be made right away rather than during the maintenance window.

To learn more, read Scaling Your Redis Cluster.

Available Now
This feature is available now and you  can start using it today!

Airbnb is a classic story of how a few people with a great idea can disrupt an entire industry. Launched in 2008, over 80 million guests have stayed on Airbnb in over 2 million homes in over 190 countries. They recently opened 4,000 homes in Cuba to travelers around the globe. The company was also an early adopter of AWS.

In the guest post below, Airbnb Engineering Manager Kevin Rice talks about how AWS was an important part of the company’s startup days, and how it stays that way today.

PS – Learn more about how startups can use AWS to get their business going.

Early Days
Our founders recognized that for Airbnb to succeed, they would need to move fast and stay lean. Critical to that was minimizing the time and resources devoted to infrastructure. Our teams needed to focus on getting the business off the ground, not on basic hosting tasks.

Fortunately, at the time, Amazon Web Services had built up a pretty mature offering of compute and storage services that allowed our staff to spin up servers without having to contact anyone or commit to minimum usage requirements. They decided to migrate nearly all of the company’s cloud computing functions to AWS. When you’re a small company starting out, you need to be as leveraged as possible with your available resources. The company’s employees wanted to focus on things that were unique to the business success.

Airbnb quickly adopted many of the essential services of AWS, such as Amazon EC2 and Amazon S3. The original MySQL database was migrated to the Amazon Relational Database Service (Amazon RDS) because RDS greatly simplifies so many of the time-consuming administrative tasks typically associated with databases, like automating replication and scaling procedures with a basic API call or through the AWS Management Console.

Sample Airbnb Listings for Barcelona, Spain as of March 23, 2016

Continuous Innovation
A big part of our success is due to an intense focus on continual innovation. For us, an investment in AWS is really about making sure our engineers are focused on the things that are uniquely core to our business. Everything that we do in engineering is ultimately about creating great matches between people. Every traveler and every host is unique, and people have different preferences for what they want out of a travel experience.

So a lot of the work that we do in engineering is about matching the right people together for a real world, offline experience. Part of it is machine learning, part of it is search ranking, and part of it is fraud detection—getting bad people off of the site and verifying that people are who they say they are. Part of it is about the user interface and how we get explicit signals about your preferences. In addition, we build infrastructure that both enables these services and that supports our engineers to be productive and to safely deploy code any time of the day or night.

We’ve stayed with AWS through the years because we have a close relationship, which gives us insight and input in to the AWS roadmap. For example, we considered building a key management system in house, then saw that the AWS Key Management Service could provide the functionality we were looking for to enhance security. Turning to KMS saved three engineers about six months of development time—valuable resources that we could redirect to other business challenges, like making our matching engine even better. Or take Amazon RDS, which we’ve now relied on for years. We take advantage of the RDS Multi-AZ deployments for failover, which would be really time-consuming to create in house. It’s a huge feature for us that protects our main data store.

Supporting Growth
As we’ve grown from a startup to a company with a global presence, we’re still paying close attention to the value of our hosting platform. The flexibility AWS gives us is important. We experiment quickly and continuously with new ideas. We are constantly looking at ways to better serve our customers. We don’t always know what’s coming and what kind of technology we’ll need for new projects, and being able to go to AWS and get the hosting and services we need within a matter of minutes is huge.

We haven’t slowed down as we’ve gotten bigger, and we don’t intend to. We still view ourselves as a scrappy startup, and we’ll continue to need the same things we’ve always needed from AWS.

I should mention that we are looking for developers with AWS experience. Here are a couple of openings:

• Software Engineer, Site Reliability.
• Software Engineer, Production Infrastructure.

— Kevin Rice, Engineering Manager, Airbnb

Regular readers of this blog will know that I am a big fan of Amazon Relational Database Service (RDS). As a managed database service, it takes care of the more routine aspects of setting up, running, and scaling a relational database.

We first launched support for SQL Server in 2012. Since that time we have added many features including SSL support, major version upgrades, transparent data encryption, and Multi-AZ.  Each of these features broadened the applicability of RDS for SQL Server and opened the door to additional use cases.

Many organizations store their account credentials and the associated permissions in Active Directory. The directory provides a single, coherent source for this information and allows for centralized management.  Given that you can use the AWS Directory Service to run the Enterprise Edition of Microsoft Active Directory in the AWS Cloud,  it is time to take the next step!

Support for Windows Authentication
You can now allow your applications to authenticate against Amazon RDS for SQL Server using credentials stored in the AWS Directory Service for Microsoft Active Directory (Enterprise Edition). Keeping all of your credentials in the same directory will save you time and effort because you will no longer have to find and update each copy. This may also improve your overall security profile.

You can enable this feature and choose an Active Directory when you create a new database instance that runs SQL Server. You can also enable it for an existing database instance. Here’s how you choose a directory when you create a new database instance (you can also create a new one):

To learn more, read about Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instance.

Now Available
This feature is now available in the US East (Northern Virginia), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo), and Asia Pacific (Singapore) Regions and you can start using it today. There is no charge for the feature, but you will pay the standard rate for the use of AWS Directory Service for Microsoft Active Directory.

Forward-looking ISVs (Indepdendent Software Vendors) are making great use of AWS Marketplace.  Users can find, buy, and start using products in minutes, without having to procure hardware or install any software. This streamlined delivery method can help ISVs to discover new customers while also decreasing the length of the sales cycle. The user pays for the products via their existing AWS account, per the regular AWS billing cycle.

As part of the on-boarding process for AWS Marketplace, each ISV has the freedom to determine the price of the software. The ISV can elect to offer prices for monthly and/or annual usage, generally with a discount. For software that is traditionally licensed on something other than time, ISVs make multiple entries in AWS Marketplace, representing licensing options on their chosen dimension.

This model has worked out well for many types of applications. However, as usual, there’s room to do even better!

More Pricing Options
ISVs have told us that they would like to have some more flexibility when it comes to packaging and pricing their software and we are happy to oblige. Some of them would like to extend the per-seat model without having to create multiple entries. Others would like to charge on other dimensions. A vendor of security products might want to charge by the number of hosts that were scanned. Or, a vendor of analytic products might want to charge based on the amount of data processed.

In order to accommodate all of these options, ISVs can now track and report on usage based on a pricing dimension that makes sense for their product (number of hosts scanned, amount of data processed, and so forth). They can also establish a per-unit price for this usage ($0.50 per host, $0.25 per GB of data, and so forth). Charges for this usage will appear on the user’s AWS bill.

I believe that this change will open the door to an even wider variety of products in the AWS Marketplace.

Implementing New Pricing Options
If you are an ISV and would like to use this new model price to your AWS Marketplace products, you need to add a little bit of code to your app. You simply measure usage along the appropriate dimension(s) and then call a new AWS API function to report on the usage. You must send this data (also known as a metering record) once per hour, even if there’s no usage for the hour. AWS Marketplace expects each running copy of the application to generate a metering record each hour in order to confirm that the application is still functioning properly. If the application stops sending records, AWS will email the customer and ask them to adjust their network configuration.

Here’s a sample call to the new MeterUsage function:

AWSMarketplaceMetering::MeterUsage("4w1vgsrkqdkypbz43g7qkk4uz","2015-05-19T07:31:23Z", "HostsScanned", 2);

The parameters are as follows:

1. AWS Marketplace product code.
2. Timestamp (UTC), in ISO-8601 format.
3. Usage dimension.
4. Usage quantity.

The usage data will be made available to you as part of the daily and monthly seller reports.

Some Examples
Here are a couple of examples of products that are already making use of this new pricing option. As you can see in the Infrastructure Fees, these vendors have chosen to price their products along a variety of interesting (and relevant) dimensions:

SoftNAS Cloud NAS:

Aspera faspex On-Demand:

Chef Server:

Trend Micro Deep Security:

Available Now
This new pricing option is available now and you can start using it today!

You can launch an EC2 Spot fleet with a couple of clicks. Once launched, the fleet allows you to draw resources from multiple pools of capacity, giving you access to cost-effective compute power regardless of the fleet size (from one instance to many thousands). For more information about this important EC2 feature, read my posts: Amazon EC2 Spot Fleet API – Manage Thousands of Spot Instances with One Request and Spot Fleet Update – Console Support, Fleet Scaling, CloudFormation.

I like to think of each Spot fleet as a single, collective entity. After a fleet has been launched, it is an autonomous group of EC2 instances. The instances may come and go from time to time as Spot prices change (and your mix of instances is altered in order to deliver results as cost-effectively as possible) or if the fleet’s capacity is updated, but the fleet itself retains its identity and its properties.

New Spot Fleet Metrics
In order to make it even easier for you to manage, monitor, and scale your Spot fleets as collective entities, we are introducing a new set of Spot fleet CloudWatch metrics.

The metrics are reported across multiple dimensions: for each Spot fleet, for each Availability Zone utilized by each Spot fleet, for each EC2 instance type within the fleet, and for each Availability Zone / instance type combination.

The following metrics are reported for each Spot fleet (you will need to enable EC2 Detailed Monitoring in order to ensure that they are all published):

• AvailableInstancePoolsCount
• BidsSubmittedForCapacity
• CPUUtilization
• DiskReadBytes
• DiskReadOps
• DiskWriteBytes
• DiskWriteOps
• EligibleInstancePoolCount
• FulfilledCapacity
• MaxPercentCapacityAllocation
• NetworkIn
• NetworkOut
• PendingCapacity
• StatusCheckFailed
• StatusCheckFailed_Instance
• StatusCheckFailed_System
• TargetCapacity
• TerminatingCapacity

Some of the metrics will give you some insights into the operation of the Spot fleet bidding process. For example:

• AvailableInstancePoolsCount – Indicates the number of instance pools included in the Spot fleet request.
• BidsSubmittedForCapacity – Indicates the number of bids that have been made for Spot fleet capacity.
• EligibleInstancePoolsCount – Indicates the number of instance pools that are eligible for Spot instance requests. A pool is ineligible when either (1) The Spot price is higher than the On-Demand price or (2) the bid price is lower than the Spot price.
• FulfilledCapacity – Indicates the amount of capacity that has been fulfilled for the fleet.
• PercentCapacityAllocation – Indicates the percent of capacity allocated for the given dimension. You can use this in conjunction with the instance type dimension to determine the percent of capacity allocated to a given instance type.
• PendingCapacity – The difference between TargetCapacity and FulfilledCapacity.
• TargetCapacity – The currently requested target capacity for the Spot fleet.
• TerminatingCapacity – The fleet capacity for instances that have received Spot instance termination notices.

These metrics will allow you to determine the overall status and performance of each of your Spot fleets. As you can see from the names of the metrics, you can easily observe the disk, CPU, and network resources consumed by the fleet. You can also get a sense for the work that is happening behind the scenes as bids are placed on your behalf for Spot capacity.

You can further inspect the following metrics across the Availability Zone and/or instance type dimensions:

• CPUUtilization
• DiskReadBytes
• DiskReadOps
• DiskWriteBytes
• FulfilledCapacity
• NetworkIn
• NetworkOut
• StatusCheckFailed
• StatusCheckFailed_Instance
• StatusCheckFailed_System

These metrics will allow you to see if you have an acceptable distribution of load across Availability Zones and/or instance types.

You can aggregate these metrics using Max, Min, or Avg in order to observe the overall utilization of your fleet. However, be aware that using Avg does not always make sense when used across a fleet comprised of two or more types of instances!

Available Now
The new metrics are available now.

Let’s take a quick look at what happened in AWS-land last week:

New & Notable Open Source

• Tumbless is a blogging platform based only on S3 and your browser.
• aws-amicleaner cleans up old, unused AMIs and related snapshots.
• alexa-aws-administration helps you to do various administration tasks in your AWS account using an Amazon Echo.
• aws-s3-zipper takes an S3 bucket folder and zips it for streaming.
• aws-lambda-helper is a collection of helper methods for Lambda.
• CloudSeed lets you describe a list of AWS stack components, then configure and build a custom stack.
• aws-ses-sns-dashboard is a Go-based dashboard with SES and SNS notifications.
• snowplow-scala-analytics-sdk is a Scala SDK for working with Snowplow-enriched events in Spark using Lambda.
• StackFormation is a lightweight CloudFormation stack manager.
• aws-keychain-util is a command-line utility to manage AWS credentials in the OS X keychain.

New SlideShare Presentations

• Account Separation and Mandatory Access Control on AWS.
• Crypto Options in AWS.
• Security Day IAM Recommended Practices.
• What’s Nearly New.

New Customer Success Stories

• AdiMap measures online advertising spend, app financials, and salary data. Using AWS, AdiMap builds predictive financial models without spending millions on compute resources and hardware, providing scalable financial intelligence and reducing time to market for new products.
• Change.org is the world’s largest and fastest growing social change platform, with more than 125 million users in 196 countries starting campaigns and mobilizing support for local causes and global issues. The organization runs its website and business intelligence cluster on AWS, and runs its continuous integration and testing on Solano CI from APN member Solano Labs.
• Flatiron Health has been able to reach 230 cancer clinics and 2,200 clinicians across the United States with a solution that captures and organizes oncology data, helping to support cancer treatments. Flatiron moved its solution to AWS to improve speed to market and to minimize the time and expense that the startup company needs to devote to its IT infrastructure.
• Global Red specializes in lifecycle marketing, including strategy, data, analytics, and execution across all digital channels. By re-architecting and migrating its data platform and related applications to AWS, Global Red reduced the time to onboard new customers for its advertising trading desk and marketing automation platforms by 50 percent.
• GMobi primarily sells its products and services to Original Design Manufacturers and Original Equipment Manufacturers in emerging markets. By running its “over the air” firmware updates, mobile billing, and advertising software development kits in an AWS infrastructure, GMobi has grown to support 120 million users while maintaining more than 99.9 percent availability
• Time Inc.’s new chief technology officer joined the renowned media organization in early 2014, and promised big changes. With AWS, Time Inc. can leverage security features and functionality that mirror the benefits of cloud computing, including rich tools, best-in-class industry standards and protocols and lower costs.
• Seaco Global is one of the world’s largest shipping companies. By using AWS to run SAP applications, it also reduced the time needed to complete monthly business processes to just one day, down from four days in the past.

New YouTube Videos

• AWS Database Migration Service.
• Introduction to Amazon WorkSpaces.
• AWS Pop-up Loft.
• Save the Date – AWS re:Invent 2016.

Upcoming Events

• March 22nd – Live Event (Seattle, Washington) – AWS Big Data Meetup – Intro to SparkR.
• March 22nd – Live Broadcast – VoiceOps: Commanding and Controlling Your AWS environments using Amazon Echo and Lambda.
• March 23rd – Live Event (Atlanta, Georgia) – AWS Key Management Service & AWS Storage Services for a Hybrid Cloud (Atlanta AWS Community).
• April 6th – Live Event (Boston, Massachusetts) AWS at Bio-IT World.
• April 18th & 19th – Live Event (Chicago, Illinois) – AWS Summit – Chicago.
• April 20th – Live Event (Melbourne, Australia) – Inaugural Melbourne Serverless Meetup.
• April 26th – Live Event (Sydney, Australia) – AWS Partner Summit.
• April 26th – Live Event (Sydney, Australia) – Inaugural Sydney Serverless Meetup.
• ParkMyCloud 2016 AWS Cost-Reduction Roadshow.
• AWS Loft – San Francisco.
• AWS Loft – New York.
• AWS Loft – Tel Aviv.
• AWS Zombie Microservices Roadshow.
• AWS Public Sector Events.
• AWS Global Summit Series.

Help Wanted

• AWS Careers.

Stay tuned for next week! In the meantime, follow me on Twitter and subscribe to the RSS feed.

— Jeff;