Back-to-Basics Weekend Reading - Survey of Local Algorithms

As we know the run time of most algorithms increases when the input set increases in size. There is one noticeable exception: there is a class of distributed algorithms, dubbed local algorithms, that run in constant time, independently of the size of the network. Being highly scalable and fault tolerant, such algorithms are ideal in the operation of large-scale distributed systems. Furthermore, even though the model of local algorithms is very limited, in recent years we have seen many positive results for nontrivial problems. In this weekend's paper Jukka Suomela surveys the state-of-the-art in the field, covering impossibility results, deterministic local algorithms, randomized local algorithms, and local algorithms for geometric graphs.

Survey of Local Algorithms, Jukka Suomela, in ACM Computing Surveys (CSUR) Surveys, Volume 45 Issue 2, February 2013, Article No. 24

Join me at the AWS Summit in Paris, Tel Aviv, Berlin, Amsterdam or New York

An important way of engaging with AWS customers is through the AWS Global Summit Series. All AWS Summits feature a keynote address highlighting the latest announcements from AWS and customer testimonials, technical sessions led by AWS engineers, and hands-on technical training. You will learn best practices for deploying applications on AWS, optimizing performance, monitoring cloud resources, managing security, cutting costs, and more. You will also have opportunities to meet AWS staff and partners to get your technical questions answered.

At the Summit we focus on education and helping our customers, there are deep technical developer sessions, broad sessions on architectural principles, sessions for enterprise decision makers and how to best exploit AWS in a public sector or education settings. In all of these we make sure that it is not just the AWS team talking but invite customers to join us to tell about their journey.

I am fortunate to join our customers for a number of these Summits. London and Stockholm were already great events, but now we have another series coming up in 3 very packed weeks starting at the end of June:

• Paris - on June 23 at CNIT La Défense
• Tel Aviv - on June 25 at the Convention Center, Bitan 10
• Berlin - on June 30 at the CityCube
• Amsterdam - on July 2 at De Kromhouthal
• New York City - on July 9 at the Javits Convention Center

Hope to see you in one of these locations!

EC2 Instance History

I received an interesting tweet last night. Steve Goldsmith of ITOC Australia (an APN Advanced Consulting Partner and recipient of an AWS Customer Obsession award earlier this year) asked me if I had a historical timeline of Amazon Elastic Compute Cloud (EC2) instance launches:

I didn’t have one, but it seemed like a worthwhile thing to have and so I spent a few minutes putting the following list together:

• August 2006 – m1.small.
• February 2010 – m2.2xlarge.
• February 2010 – m2.xlarge.
• July 2010 – cc1.4xlarge.
• September 2010 – t1.micro.
• November 2010 – cg1.4xlarge.
• November 2011 – cc2.8xlarge.
• March 2012 – m1.medium.
• July 2012 – hi1.4xlarge.
• October 2012 – m3.xlarge, m3.2xlarge.
• December 2012 – hs1.8xlarge.
• January 2013 – cr1.8xlarge.
• November 2013 – c3.large, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge.
• November 2013 – g2.2xlarge.
• December 2013 – i2.xlarge, i2.2xlarge, i2.4xlarge, i2.8xlarge.
• April 2014 – r3.large, r3.xlarge, r3.2xlarge, r3.4xlarge, r3.8xlarge.
• July 2014 – t2.micro, t2.small, t2.medium.
• January 2015 – c4.large, c4.xlarge, c4.2xlarge, c4.4xlarge, c4.8xlarge.
• March 2015 – d2.xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge.

I am still working on dates for the following instances:

• [Before August 2009] – c1.medium, c1.xlarge.
• [Before October 2009] – m1.large, m1.xlarge.
• [Before September 2010] – m2.4xlarge.

— Jeff;

Now Available – Version 3 of the AWS SDK for PHP

Back in the spring of 2002 I wrote a simple PHP wrapper around the then-new Amazon E-Commerce Service. This little wrapper caught Amazon’s attention and before I knew it I was a member of the Amazon Associates team! Later, when I decided to write a book to show people how to use AWS, PHP was the natural choice, along with the AWS SDK for PHP (formerly CloudFusion (formerly Tarzan)). Sadly, my coding skills have atrophied somewhat since then, but I still remain optimistic that I’ll be able to revive them at some point.

Today I am happy to announce that version 3 of the AWS SDK for PHP, a product that resonates with two significant themes in my professional experience, is now available via Composer and on GitHub.

This version of the SDK was built in response to the feedback that we have received on version 2 over the last couple of years. It upgrades the dependencies, improves performance, and was built in accord with the latest PHP standards.

You can now make asynchronous calls to AWS. The calls return Promises; after you issue the call you can wait for it to complete and then access the result. You can chain multiple calls together to create an asynchronous workflow. Promises are also used to implement higher-level abstractions in the SDK including Paginators, Waiters, and the S3 MultipartUploader.

To learn more, read Version 3 of the AWS SDK for PHP is Released on the AWS PHP Developer Blog.

— Jeff;

The AWS Pop-up Loft opens in New York City

Over a year ago the AWS team opened a "pop-up loft" in San Francisco at 925 Market Street. The goal of opening the loft was to give developers an opportunity to get in-person support and education on AWS, to network, get some work done, or just hang out with peers. It became a great success; every time when I visit the loft there is a great buzz with people getting advice from our solution architects, getting training or attending talks and demos. It became such a hit among developers that we decided to reopen the loft last year August after its initial run of 4 weeks, making sure everyone would have continued access to this important resource.

Building on the success of the San Francisco loft the team will now also open a pop-up loft in New York City on June 24 at 350 West Broadway. It will extend the concept that was pioneered in SF to give NYC developers access to great AWS resources:

• Ask an Architect: You can schedule a 1:1, 60-minute session with a member of the AWS technical team. Bring your questions about AWS architecture, cost optimization, services and features, and anything else AWS related. And don’t be shy — walk-ins are welcome too.
• Technical Presentations: AWS solution architects, product managers, and evangelists deliver technical presentations covering some of the highest-rated and best-attended sessions from recent AWS events. Talks cover solutions and services including Amazon Echo, Amazon DynamoDB, mobile gaming, Amazon Elastic MapReduce, and more.
• AWS Technical Bootcamps: Limited to 25 participants per bootcamp, these full-day bootcamps include hands-on lab exercises that use a live environment with the AWS console. Usually these cost $600, but at the AWS Pop-up Loft we are offering them for free. Bootcamps you can register for include “Getting Started with AWS — Technical,” “Store and Manage Big Data in the Cloud,” “Architecting Highly Available Apps,” and “Taking AWS Operations to the Next Level.”
• Self-paced, Hands-on Labs: Beginners through advanced users can attend labs on topics that range from creating Amazon EC2 instances to launching and managing a web application with AWS CloudFormation. Usually $30 each, these labs are offered for free in the AWS loft.

You are all invited to join us for the grand opening party at the loft on June 24 at 7 PM. There will be food, drinks, DJ, and free swag. The event will be packed, so RSVP today if you want to come and mingle with hot startups, accelerators, incubators, VCs, and our AWS technical experts. Entrance is on a first come, first serve basis.

Both the San Francisco loft and the New York City loft have packed calendars with events. Visit their web pages for more details and to sign up.

I have signed up to do two loft events:

• Fireside Chat with AWS Community Heroes on June 16 starting at 6pm Jeremy Edberg (Reddit/Netflix) and Valentino Volonghi (Adroll) will be joining me at the San Francisco loft for a fireside chat about startups, technology, entrepreneurship and more. Jeremy and Valentino have been recognized by AWS as Community Heroes, an honor reserved for developers who’ve had a real impact within the community. Following the talk, we’ll kick off a unique networking social including specialty cocktails, beer, wine, food, and party swag!
• Fireside Chat with NYC Founders on July 7 a number of startup founders who have gone through NYC accelerators will join me for a conversation about trends in the New York startup scene.

I hope to see you there!

Simplified Multiple Object Invalidation for Amazon CloudFront

Many AWS customers use Amazon CloudFront to deliver content to end users at high data transfer speed with low latency. Because CloudFront has no minimum usage commitment, it is a good fit for web properties of any size.

Each CloudFront edge location caches recently used objects in order to deliver dynamic, static, streaming, or interactive content as expeditiously as possible. CloudFront also allows you to invalidate (remove) an object from the cache before it expires. For example, if you upload a new CSS file for your website, invalidating the file will ensure that your users will see the update the next time they visit the site.

Multiple Object Invalidation
We recently enhanced CloudFront’s invalidation feature by adding support for wildcard invalidations. You can now add a “*” character to the end of an invalidation path to remove all objects that match the path. Wildcard invalidations take no more time than those for individual objects, and can invalidate an unlimited number of objects.

Wildcard invalidation can be of value in many different situations. If you are deploying a new version of your website or web application, you can invalidate the existing content using “/*”. If your content is organized by user name, you can invalidate it using a pattern that looks like “/users/jeffbarr-data”. As you can imagine, wildcard invalidation is often easier to implement. It can also be more cost-effective (see Cost Savings, below).

You can access this feature from the AWS Management Console, AWS Command Line Interface (CLI), AWS Tools for Windows PowerShell, and via CloudFront’s Invalidation API. Here is how you would invalidate multiple objects from the Console:

We also enhanced the limits on invalidation, so you now can have up to 3000 invalidation objects per distribution in progress at one time. This can be one invalidation request for up to 3,000 objects, up to 3,000 requests for one object each, or any other combination that doesn’t exceed 3,000 objects. In addition, you can submit up to 15 invalidation paths that include the “*” wildcard character at one time per distribution. For information about limits on invalidations, see Invalidation Limits.

Cost Savings
You can invalidate up to 1,000 paths per month at no charge when you use CloudFront (each additional invalidation path costs $0.005). An invalidation path that includes the “*” character incurs the same charge as one that does not. You pay for one invalidation path, even if the path matches hundreds or thousands of objects. See the CloudFront Pricing page for more information.

Office Hours
The CloudFront team is planning to demonstrate this new feature at the next CloudFront Office Hour (June 17^th, 2015).

— Jeff;

AWS Week in Review – May 18, 2015

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

Monday, May 18	We announced the EC2 Spot Fleet API for Management of Thousands of Spot Instances with one Request. We announced AWS OpsWorks for Windows. We advised you to Look Before You Leap – The Coming Leap Second and AWS. We announced CloudWatch Logs Stream Search. Developer Jorge Bastida released awslogs, a simple command line tool for querying groups, streams, and events from Amazon CloudWatch logs. The AWS Java Blog published part 3 of a series on Generating Amazon S3 Pre-signed URLs with SSE-S3. A post on the Ruxit Blog announced that Ruxit Integrates CloudWatch API for Full-stack AWS Monitoring. The Cloud Academy Blog talked about AWS IAM: User Access Control and User Management.
Tuesday, May 19	We announced the AWS Pop-up Loft in New York. We announced Additional Parameter Types and an Enhanced Parameter UI for CloudFormation. The BBC News developers released cloudwatch-sender to help you to send EC2, CloudWatch, and custom metrics from CloudWatch to InfluxDB or Graphite.
Wednesday, May 20	We released New SDKs, Code Samples, & Docs for Login and Pay with Amazon. We announced an ELB Security Update to disable Diffie-Hellman Key Agreement. We announced that Amazon Elastic Transcoder Supports XDCAM and FLAC. The AWS Security Blog announced that New SOC 1, 2, and 3 Reports are Available, including a New Region and Service In-Scope. Developer Jon Buckley released assume-aws-role to help you work with multiple AWS accounts more easily. The We Kanban Blog talked about Amazon Web Services Lambda. The Gathering Clouds Blog listed 7 IAM Security Best Practices for HIPAA Compliance and also talked about Oracle RAC and AWS: A Hybrid Cloud Solution.
Thursday, May 21	The AWS Big Data Blog showed you how to Build a Multi-Class ML Model with Amazon Machine Learning. The AWS Security Blog showed you how to Test Your Roles’ Access Policies Using the AWS Identity and Access Management Policy Simulator. We updated the AWS CLI, AWS SDK for JavaScript, AWS SDK for Java, AWS Tools for Windows PowerShell, AWS SDK for .NET, and the AWS SDK for Ruby. The AWS Ruby Development Blog published a RailsConf 2015 Recap. The AWS Partner Network Blog talked about APN Technology Partner Zapproved and how they are Enabling Scalable and Cost-Effective E-Discovery for Customers. The AWS Startup Collection talked about Heyzap: Getting as Close to Elastic as Possible. The BBC News developers released alephant-publisher-queue to support static publishing of Alephant content to S3 based on SQS messages. The CloudNative Blog launched Lambda Chat. The Cloud Academy Blog talked about Writing Your First CloudFormation Template. The Cloudability Blog shared What You Need to Know About Blended Rates on AWS.
Friday, May 22	We added a Consumer Position Metric to Kinesis. We added BlueEHS Electronic Health Solution, ExpeDat Gateway for Amazon S3, and Virtualmin GPL Stack Powered by SAIN3 to the AWS Marketplace. A post on the AWS Security Blog announced that AWS Key Management Service Adds Support for Updating Key Aliases. We added AWS Customer Succcess Stories from CrowdChat, DataXu, and Hearst Corporation. The Cloud Academy Blog reviewed the AWS Summit in Sydney: 5 Things I Learnt. We published four new videos in English:Introduction to AWS CloudFormation, Introduction to AWS Lambda, Administering Amazon RDS for SQL Server, and Introducing Amazon Elastic File System. We published 8 new videos in French (all from AWS Startup Day France): AWS Startup Day France – Introduction, Dix conseils pour supporter la croissance de votre Startup de 0 à 10 millions d’utilisateurs, Moving Viadeo to AWS, Faire grandir votre idée dans le cloud AWS, Table ronde : Commerce Guys, Odaseva, Payplug, Tech Workshop: Backend mobile et objets connectés, Tech Workshop: Micro-services sur AWS, and Tech Workshop: Traitement d’événements en temps réel. We published one new video in German: Einfuhrung in Amazon Elastic Cloud Compute (EC2).

Upcoming Events

• May 26 – Live Event (Edinburgh, Scotland) – Amazon Developer Networking Mixer.
• May 28 – Live Event (Glasgow, Scotland) – Amazon Developer Networking Mixer.
• June 13 – Live Event (Arlington, VA) – Amazon Developer Day.
• June 24-26 – Live Event (London, England) – Windows on AWS Bootcamp for APN Partners.
• AWS Summits.
• AWS re:Invent.

Upcoming Events at the AWS Loft (San Francisco)

• May 28 – Build Your Own Website: Making Web Development Fun and Easy.

Upcoming Events at the AWS Loft (New York)

• June 25 – Chef Bootcamp (10 AM – 6 PM).
• June 25 – Oscar Health (6:30 PM).
• June 26 – AWS Bootcamp (10 AM – 6 PM).
• June 29 – Chartbeat (6:30 PM).
• June 30 – Picking the Right Tool for the Job (HTML5 vs. Unity) (Noon – 1 PM).
• June 30 – So You Want to Build a Mobile Game? (1 PM – 4:30 PM).
• June 30 – Buzzfeed (6:30 PM).
• July 6 – AWS Bootcamp (10 AM – 6 PM).
• July 7 – Dr. Werner Vogels (Amazon CTO) + Startup Founders (6:30 PM).
• July 7 – AWS Bootcamp (10 AM – 6 PM).
• July 8 – Sumo Logic Panel and Networking Event (6:30 PM).
• July 9- AWS Activate Social Event (7:00 PM – 10 PM).
• July 10 – Getting Started with Amazon EMR (Noon – 1 PM).
• July 10 – Amazon EMR Deep Dive (1 PM – 2 PM).
• July 10 – How to Build ETL Workflows Using AWS Data Pipeline and EMR (2 – 3 PM).
• July 14 – Chef Bootcamp (10 AM – 6 PM).
• July 15 – Chef Bootcamp (10 AM – 6 PM).
• July 16 – Science Logic (11 AM – Noon).
• July 16 – Intel Lustre (4 PM – 5 PM).
• July 17 – Chef Bootcamp (10 AM – 6 PM).
• July 22 – Mashery (11 AM – 3 PM).
• July 23 – An Evening with Chef (6:30 PM).
• July 29 – Evident.io (6:30 PM).
• August 5 – Startup Pitch Event and Summer Social (6:30 PM).
• August 25 – Eliot Horowitz, CTO and Co-Founder of MongoDB (6:30 PM).

Help Wanted

• AWS Careers.

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

— Jeff;

New SDKs, Code Samples, & Docs for Login and Pay with Amazon

I met with the Amazon Payments developer relations team a couple of weeks ago in order to get an update on Login and Pay with Amazon (see my post, PeachDish – Login, Pay, Cook, and Eat With AWS, to learn more).

The team has been working to make it even easier for you to add one-time checkout and recurring payments to your application. They have created new PHP, Python, and Ruby SDKs, coded up some helpful interactive and self-documenting samples, and refreshed the documentation.

Let’s review the Login and Pay user experience before we dive in! The Pay with Amazon Simple Checkout Sample shows you how to enable a buyer to make a purchase. It runs in a sandbox and uses a set of test credentials so that you can walk through the payment process yourself without actually making a purchase.

Your customer would simply click on the Pay with Amazon button to make the purchase:

Then they log in to their Amazon account:

This information is displayed in a widget; your code simply sets it up and arranges to handle a couple of events. The SDK will take care of everything else.

Your customer can then complete the payment process by choosing the shipping address and the payment method, and clicking on the Place Order button:

Your code will then confirm and authorize the order.

New Samples
The samples (Simple Checkout and Recurring Payments) are interactive and self-documenting. Each page displays the appropriate widget, and also includes the client and server code needed to set up the widget and to handle user actions. The server code is available in PHP, Python, and Ruby; you can choose the desired language with a click and the sample will change accordingly:

Visit the Pay with Amazon SDK Samples page to see the full list of samples.

New SDKs
The sample code makes use of the new Login and Pay with Amazon SDKs. The SDKs are available in source code form on GitHub as follows:

• Login and Pay with Amazon PHP SDK
• Login and Pay with Amazon Ruby SDK
• Login and Pay with Amazon Python SDK

We are also working on SDKs for other popular languages.

New Documentation
The documentation has been updated, with an updated Reference Guide and new Integration Guides for Login and Pay with Amazon, Recurring Payments, and Express Integration. These updates are the first in a series; the team is working hard to create a great developer experience for their product!

Talk to the Team
The team would love to hear from you. You can contact them at pay-with-amazon-dev-feedback@amazon.com .

— Jeff;

Announcing the AWS Pop-up Loft in New York

We opened up the first AWS Pop-up Loft last year. By virtue of its location (Market Street in San Francisco) it is accessible to entrepreneurs, students, and others interested in learning more about AWS. Our customers have also used it for co-working and for meetings. Personally, I like to use the AWS Loft in San Francisco as my home-away-from-home when I travel.

I’m happy to be able to announce that we will be popping up a second loft, this one in New York City. We have created a unique space and assembled a full calendar of events, with some special help from our friends at Intel and Chef. We look forward to connecting with even more customers and expect that the AWS Pop-up Loft will be a great place to learn, collaborate, and share.

In the City
This loft is located at 350 West Broadway in New York’s SOHO neighborhood and will open its doors on Wednesday, June 24^th with a 7 PM opening party that you are welcome to attend!

The Loft will be open Monday through Friday from 10 AM to 6 PM, with special events during the evening. During the day you will have access to the Ask an Architect Bar, daily AWS education sessions, Wi-fi, a co-working space, and snacks, all at no charge.

Ask an Architect
Step up to the Ask an Architect Bar with your code, architecture diagrams, and your AWS questions at the ready! You can book a session ahead of time or your can simply walk in. You will have access to deep technical expertise and will be able to get guidance on AWS architecture, usage of specific AWS services and features, cost optimization, and more.

AWS Education Sessions
During the day, AWS Solution Architects, Product Managers, and Evangelists will be leading 60-minute educational sessions designed to help you to learn more about specific AWS services and use cases. You can attend these sessions to learn about Mobile & Gaming, Databases, Big Data, Compute & Networking, Architecture, Operations, Security, and more, all at no charge.

The Chef Perspective
Chef is an automation platform for configuring and deploying IT infrastructure and applications in the data center and the cloud. They will bring their DevOps perspective to New York through hosted sessions and training (see the calendar below for more information).

The Intel Perspective
AWS and Intel share a passion for innovation and a history of helping startups to succeed. Intel will bring their newest technologies to New York, with talks and training that focus on the Internet of Things and the latest Intel Xeon processors.

On the Calendar
Here are some of the events that we have scheduled for the first couple of months (the AWS and Chef Bootcamps run from 10 AM to 6 PM):

• Thursday, June 25 – Chef Bootcamp (10 AM – 6 PM).
• Thursday, June 25 – Oscar Health (6:30 PM).
• Friday, June 26 – AWS Bootcamp (10 AM – 6 PM).
• Monday, June 29 – Chartbeat (6:30 PM).
• Tuesday, June 30 – Picking the Right Tool for the Job (HTML5 vs. Unity) (Noon – 1 PM).
• Tuesday, June 30 – So You Want to Build a Mobile Game? (1 PM – 4:30 PM).
• Tuesday, June 30 – Buzzfeed (6:30 PM).
• Monday, July 6 – AWS Bootcamp (10 AM – 6 PM).
• Tuesday, July 7 – Dr. Werner Vogels (Amazon CTO) + Startup Founders (6:30 PM).
• Tuesday, July 7 – AWS Bootcamp (10 AM – 6 PM).
• Wednesday, July 8 – Sumo Logic Panel and Networking Event (6:30 PM).
• Thursday, July 9- AWS Activate Social Event (7:00 PM – 10 PM).
• Friday, July 10 – Getting Started with Amazon EMR (Noon – 1 PM).
• Friday, July 10 – Amazon EMR Deep Dive (1 PM – 2 PM).
• Friday, July 10 – How to Build ETL Workflows Using AWS Data Pipeline and EMR (2 – 3 PM).
• Tuesday, July 14 – Chef Bootcamp (10 AM – 6 PM).
• Wednesday, July 15 – Chef Bootcamp (10 AM – 6 PM).
• Thursday, July 16 – Science Logic (11 AM – Noon).
• Thursday, July 16 – Intel Lustre (4 PM – 5 PM).
• Friday, July 17 – Chef Bootcamp (10 AM – 6 PM).
• Wednesday, July 22 – Mashery (11 AM – 3 PM).
• Thursday, July 23 – An Evening with Chef (6:30 PM).
• Wednesday, July 29 – Evident.io (6:30 PM).
• Wednesday, August 5 – Startup Pitch Event and Summer Social (6:30 PM).
• Tuesday, August 25 – Eliot Horowitz, CTO and Co-Founder of MongoDB (6:30 PM).

Stop in and Say Hello
Please feel free to stop in and say hello to my colleagues at the loft if you happen to find yourself in SOHO. Or, plan ahead and RSVP to attend an event!

— Jeff;

Amazon EC2 Spot Fleet API – Manage Thousands of Spot Instances with one Request

It has been really interesting to watch Amazon Elastic Compute Cloud (EC2) evolve over the last eight or nine years. At first you could launch a single instance type, in one region, at a predetermined (On-Demand) price. Today, you can launch a plethora of instance types, in any one of eleven regions (twelve including AWS GovCloud (US)), with your choice of On-Demand, Reserved, or Spot pricing (currently in nine regions). Along the way, we have added many features to EC2 and have also used it as a building block for other services including Amazon EMR, AWS Elastic Beanstalk, Amazon WorkSpaces, EC2 Container Service, and AWS Lambda.

New Spot Fleet API
Today we are making EC2’s Spot Instance model even more useful with the addition of a new API that allows you to launch and manage an entire fleet of Spot Instances with one request (a fleet is a collection of Spot Instances that are all working together as part of a distributed application. A fleet could be a batch processing job, a Hadoop workflow, or an HPC grid computing job). Many AWS customers launch fleets of Spot Instances (in sizes ranging from one instance up to thousands), using custom-written code that is responsible for discovering capacity, monitoring market prices across instance types and availability zones, and managing bids, all with the goal of running their workloads (ranging from large scale molecular dynamics simulations to continuous integration environments) at the lowest possible cost.

With today’s launch, this custom code is no longer necessary! Instead, a single API function (RequestSpotFleet) does all of the work on your behalf. You simply specify the fleet’s target capacity, a bid price per hour, and tell Spot what instance types you would like to launch. Spot will find the lowest priced spare EC2 capacity available, and work to achieve and maintain the fleet’s target capacity. One call does it all, as they say…

Making the Request
You can have up to 1,000 active Spot fleets per region, with a per-fleet and a per-region limit of 3,000 instances (the usual EC2 per-account and per-region limits are still in effect and will govern the number of instances that you can launch, the number of Amazon Elastic Block Store (EBS) volumes that you can create, and so forth).

Each request (via the API or the CLI) must include the following values:

• Target Capacity – The number of EC2 instances that you want in your fleet.
• Maximum Bid Price – The maximum bid price that you are willing to pay.
• Launch Specifications - The quantities and types of instances that you would like to launch, and how you want them to be configured (AMI Id, VPC, subnets or availability zones, security groups, block device mappings, user data, and so forth). In general, launch specifications that do not target a particular subnet or availability zone are more economical.
• IAM Fleet Role – The name of an IAM role. It must allow EC2 to terminate instances on your behalf.

Each request can also include any or all of the following optional values:

• Client Token – A unique, case-sensitive identifier for the request. You can use this to ensure idempotency for your Spot fleet requests.
• Valid From -The start date and time of the request.
• Valid Until – The end date and time of the request.
• Terminate on Expiration – If set to TRUE, all Spot instances in the fleet will be terminated when the Valid Until time is reached. If set to FALSE (the default), running Spot instances will be left as-is, but no new ones will be launched.

The RequestSpotFleet function will return a Spot Fleet Request Id if all goes well, or an error if the request is malformed. You will also receive an error if you ask for instance types that are not available in Spot form. You can use the Id to call other Spot fleet functions including DescribeSpotFleetRequests, DescribeSpotFleetInstances, DescribeSpotFleetRequestHistory, and CancelSpotFleetRequests (there are also command-line equivalents to each of these functions).

Behind the Scenes
Once your request has been accepted and the start date and time has been reached, EC2 will attempt to reach and then maintain the desired target capacity, even as Spot prices change. It will start by looking up the current Spot price for each launch specification in your request. Then it will launch Spot Instances using the launch specification(s) that result in the lowest price, until capacity, Spot limits, or bid price limits are reached. As instances in the fleet are terminated due to rising prices, replacement instances will be launched using whatever specification(s) result in the lowest price at that point in time.

The request remains active until it expires or you cancel it. The Spot Instances in the fleet will remain running unless you indicated that you wanted them to be terminated. As I mentioned earlier, you need to include an IAM role so that EC2 can terminate instances that are running on your behalf.

Things to Know
As is often the case with new AWS features, this is an initial release and we have a healthy backlog of features in the queue. For example, we plan to add a weighting system. It will allow you to express the relative power of each of your launch specifications in numeric form. The target capacity will also be expressed in these units; this will allow you to indicate that you need a certain amount of “horsepower” in a fleet.

Each fleet is run within a particular AWS region. In the future we would like to support fleets that span two or more regions.

Available Now
You can launch Spot fleets today in all public AWS regions where Spot is available. There is no charge for the Spot fleet; you pay Spot prices for the EC2 instances that you launch and any other resources that they consume.

— Jeff;

Look Before You Leap – The Coming Leap Second and AWS

My colleague Mingxue Zhao sent me a guest post designed to make sure that you are aware of an important time / clock issue.

— Jeff;

---

The International Earth Rotation and Reference Systems (IERS) recently announced that an extra second will be injected into civil time at the end of June 30^th, 2015. This means that the last minute of June 30^th, 2015 will have 61 seconds. If a clock is synchronized to the standard civil time, it will show an extra second 23:59:60 on that day between 23:59:59 and 00:00:00. This extra second is called a leap second. There have been 25 such leap seconds since 1972. The last one took place on June 30^th, 2012.

Not all applications and systems are properly coded to handle this “:60” notation. As a result, some applications or systems may malfunction and it is hard to predict which one will go wrong. To keep services stable, some organizations, including Amazon Web Services, plan to implement alternative solutions to avoid the “:60” leap second. This means that AWS clocks will be slightly different from the standard civil time for a short period of time.

If you want to know whether your applications and systems can properly handle the leap second, contact your providers. If you run time-sensitive workloads and need to know how AWS clocks will behave, read this document carefully. In general, there are three affected parts:

• The AWS Management Console and backend systems
• Amazon EC2 instances
• Other AWS managed resources

For more information about comparing AWS clocks to UTC, see the AWS Adjusted Time section.

AWS Management Console and Backend Systems
The AWS Management Console and backend systems will NOT implement the leap second. Instead, we will spread the one extra second over a 24-hour period surrounding the leap second by making each second slightly longer. During these 24 hours, AWS clocks may be up to 0.5 second behind or ahead of the standard civil time (see the AWS Adjusted Time section for more information).

You can see adjusted times in consoles (including resource creation timestamps), metering records, billing records, Amazon CloudFront logs, and AWS CloudTrail logs. You will not see a “:60” second in these places and your usage will be billed according to the adjusted time.

Amazon EC2 Instances
Each EC2 instance has its own clock and is fully under your control; AWS does not manage instance clocks. An instance clock can be affected by many factors. Depending on these factors, it may implement or skip the leap second. It may also be isolated and not synchronize to an external time system. If you need your EC2 instance clocks to be predictable, you can use NTP to synchronize your clocks to time servers of your choice. For more information about how to synchronize clocks, see the following documentation:

• Instances using Amazon Linux AMIs: Setting the Time for Your Linux Instance.
• Instances using Amazon-provided Microsoft Windows AMIs: Setting the Time for a Windows Instance.
• Instances using other AMIs: Please contact your AMI provider (the information in the preceding bullet points may also be helpful).

Adding the leap second is currently the standard practice. If you use public time servers, like time servers from ntp.org (the default for Amazon Linux AMIs) or time.windows.com (the default for Amazon Windows AMIs), your instance will see the leap second unless these synchronization services announce a different practice.

Other AWS Managed Resources
Other AWS resources may also have their own clocks. Unlike EC2 instances, these resources are fully or partially managed by AWS.

Clocks for the following resources synchronize to the time servers from ntp.org, which implements the standard leap second:

• Amazon CloudSearch clusters
• Amazon EC2 Container Service instances
• Amazon RDS instances
• Amazon Redshift instances

AWS Adjusted Time
This section provides specific details on how clocks will behave in the AWS Management Console and backend systems.

Starting at 12:00:00 PM on June 30^th, 2015, we will slow down AWS clocks by 1/86400. Every second on AWS clocks will take 1+1/86400 seconds of “real” time, until 12:00:00 PM on July 1^st, 2015, when AWS clocks will be behind by a full second. Meanwhile, the standard civil time (UTC) will implement the leap second at the end of June 30^th, 2015 and fall behind by a full second, too. Therefore, at 12:00:00 PM July 1^st, 2015, AWS clocks will be synchronized to UTC again. The table below illustrates these changes.

UTC	AWS Adjusted Clock	AWS vs. UTC	Notes
11:59:59 AM June 30th, 2015	11:59:59 AM June 30th, 2015	+0	AWS clocks are synchronized to UTC.
12:00:00 PM	12:00:00 PM	+0
12:00:01			Each second is 1/86400 longer and AWS clocks fall behind UTC. The gap gradually increases to up to 1/2 second.
	12:00:01	+1/86400
12:00:02
	12:00:02	+2/86400
…	…	…
23:59:59
	23:59:59	+43199/86400
23:59:60			Leap second injected to UTC.
	00:00:00 AM July 1st, 2015	-1/2	AWS clocks gain 1/2 second ahead of UTC.
00:00:00 AM July 1st, 2015			AWS clocks keep falling behind and the gap with UTC shrinks gradually.
	00:00:01	-43199/86400
00:00:01
	00:00:02	-43198/86400
…	…	…
	11:59:59 AM	-1/86400
11:59:59 AM
12:00:00 PM July 1st ,2015	12:00:00 PM July 1st ,2015	+0	The gap shrinks to zero. AWS clocks synchronize to UTC again.
12:00:01	12:00:01	+0
…	…	…

If you have any questions about this upcoming event, please contact AWS Support or post in the EC2 Forum.

— Mingxue Zhao, Senior Product Manager

AWS OpsWorks for Windows

AWS OpsWorks gives you an integrated management experience that spans the entire life cycle of your application including resource provisioning, configuration management, application deployment, monitoring, and access control. As I noted in my introductory post (AWS OpsWorks – Flexible Application Management in the Cloud Using Chef), it works with applications of any level of complexity and is independent of any particular architectural pattern.

We launched OpsWorks with support for EC2 instances running Linux. Late last year we added support for on-premises servers, also running Linux. In-between, we also added support for Java, Amazon RDS , Amazon Simple Workflow, and more.

Let’s review some OpsWorks terminology first! An OpsWorks Stack hosts one or more Applications. A Stack contains a set of Amazon Elastic Compute Cloud (EC2) instances and a set of blueprints (which OpsWorks calls Layers) for setting up the instances in the Stack. Each Stack can also contain references to one or more Chef Cookbooks.

Support for Windows
Today we are making OpsWorks even more useful by adding support for EC2 instances running Windows Server 2012 R2. These instances can be set up by using Custom layers. The Cookbooks associated with the layers can provision the instance, install packaged and custom software, and react to life cycle events. They can also run PowerShell scripts.

Getting Started with Windows
You can now specify Windows 2012 R2 as the default operating system when you create a new Stack. If you do this, you should also click on Advanced and choose version 12. of Chef, as follows:

Now add a Custom Layer. If you select a security group that allows for inbound RDP access, you will be able to use a new OpsWorks feature that allows you to create temporary access credentials for the instances in the Layer:

With the Stack and the Layer all set up, add an Instance to the Layer, and then start it:

Connecting to a Windows Instance
OpsWorks allows you to create IAM users, import them to OpsWorks, give them appropriate permissions, and log in to the instances with the credentials for the user (via RDP or SSH, as appropriate)! For example, you can create a user called winuser and allow it to be used for RDP access:

In order to connect to the instance as winuser, you’ll need to first log in to the console with the appropriate user (as opposed to account) credentials. After you do this, you can request temporary access to the instance. If you have the appropriate permissions (Show and SSH/RDP), you can connect via RDP:

OpsWorks will generate a temporary session for you:

Then it will show you the credentials, and give you the option to download an RDP file:

Use this file to connect, enter your password, and wait a couple of seconds to log in:

And there’s your Windows server desktop:

Available Now
This new functionality is available now and you can start using it today! To learn more, read Getting Started with Windows Stacks in the OpsWorks User Guide.

— Jeff;