Amazon Web Services Blog
I'd like to give you an update on the EC2 Maintenance announcement that I posted last week. Late yesterday (September 30th), we completed a reboot of less than 10% of the EC2 fleet to protect you from any security risks associated with the Xen Security Advisory (XSA-108).
This Xen Security Advisory was embargoed until a few minutes ago; we were obligated to keep all information about the issue confidential until it was published. The Xen community (in which we are active participants) has designed a two-stage disclosure process that operates as follows:
- Early disclosure to select organizations (a list maintained and regularly evaluated by the Xen Security Team based on a set of public criteria established by the Xen Project community) with a limited time to make accommodations and apply updates before it becomes widely known.
- Full disclosure to everyone on the public disclosure date.
Because our customers’ security is our top priority and because the issue was potentially harmful to our customers, we needed to take fast action to protect them. For the reasons mentioned above, we couldn’t be as expansive as we’d have liked on why we had to take such fast action.
The zone by zone reboots were completed as planned and we worked very closely with our customers to ensure that the reboots went smoothly for them.
We'll continue to be vigilant and will do our best to protect all AWS customers from similar issues in the future. As an AWS user, you may also want to take this opportunity to re-examine your AWS architecture to look for possible ways to make it even more fault-tolerant. Here are a few suggestions to get you started:
- Run instances in two or more Availability Zones.
- Pay attention to your Inbox and to the alerts on the AWS Management Console. Make sure that you fill in the "Alternate Contacts" in the AWS Billing Console.
- Review the personalized assessment of your architecture in the Trusted Advisor, then open up AWS Premium Support Cases to get engineering assistance as you implement architectural best practices.
- Use Chaos Monkey to induce various kinds of failures in a controlled environment.
- Examine and consider expanding your use of Amazon Route 53 and Elastic Load Balancing checks to ensure that web traffic is routed to healthy instances.
- Use Auto Scaling to keep a defined number of healthy instances up and running.
You should also consult our Overview of Security Practices whitepaper for more information around AWS and security.
Amazon AppStream allows you to build complex applications that run on simple devices, taking advantage of cloud-based graphical rendering (both 2D and 3D) and reducing the need for local compute power and storage. Our customers are also using AppStream to simplify their beta testing process and to control the dispersion of their Intellectual Property (IP). As I have noted in the past, your applications run in a Windows 2008 R2 environment hosted on an Amazon Elastic Compute Cloud (EC2) instance.
Earlier this year I announced that that AppStream was available to all developers. At that time, all AppStream applications were streamed from the US East (Northern Virginia) Region.
Expanding to Japan
Today I am happy to be able to announce that AppStream applications can now be streamed from the Asia Pacific (Tokyo) Region. Developers with a customer base in and around Japan can now deliver their applications with lower latency and improved interactive performance. This is important because streaming responsive video across the Internet is very sensitive to latency and is, of course, limited by the speed of light. Putting the application as close to the user as possible minizes latency and improves the overall experience. Launching AppStream in Tokyo will give developers the ability to reach even more users with their streamed applications.
As part of the AWS Free Tier, developers have access to up to 20 hours of streaming per month for a period of one year at no charge. Additional streaming time is billed at $1.20 per hour. In either case, usage time is calculated and accumulated based on the individual streaming sessions (see the AppStream pricing page for more information).
AppStream in Action
Nissan Motor Company Limited (one of world's largest automobile manufacturers) uses the NVTS (Nissan Virtual Training System) to train mechanics in new procedures without the need for a real vehicle. By using NVTS through Amazon AppStream, the mechanics can train themselves even if they do not have a high-spec computer for 3D image processing.
Even better, mechanics can do the training anywhere, at any time for just the required amount of time, by simply accessing the system. Nissan expects the combination of NVTS and AppStream to reduce maintenance costs and is now planning to extend the use of NVTS globally and in areas other than training of mechanics.
Version 2 of the AWS Mobile SDK has been available in Developer Preview since early July (See my blog post, New AWS Mobile Services to learn more). During the Developer Preview, many developers used the AWS Mobile SDK in their apps and provided us with a lot of really good feedback.
We responded to the feedback that we received during the developer preview and made a number of improvements to the SDK. You can find the details in the release notes section ( iOS, Android). Here are some of the more significant improvements:
- The method count in the AWS Mobile SDK for Android has been reduced by 40% to 13K. This will reduce the size of the final APK and keeps you clear of Android's limit on the number of methods.
- The SDK supports offline sync using Amazon Cognito. The SDK queues requests made when the device is offline. The requests (pending sync operations) are executed when internet connectivity is available. Details can be found here.
- The AWS Mobile SDK for iOS now includes support for pre-signed Amazon Simple Storage Service (S3) URLs. You can use these URLS to perform background transfers using the NSURLSession class.
To get started, take a look at the AWS Mobile SDK Getting Started Guide for iOS and the AWS Mobile SDK Getting Started Guide for Android. You can also take a look at the iOS Samples and the Android Samples on the AWS Labs GitHub repo.
Amazon Cognito, as you may already know, simplifies the task of authenticating users and storing, managing, and syncing their data across multiple devices. We launched Cognito this past summer with support for three public identity providers. The identity providers (Google, Facebook, and Amazon) are used to create unique Cognito identifiers (there's also support for unauthenticated guest users). This allows new users to start using your app without taking the time to register a new identity. You can read my blog post, New AWS Mobile Services, to learn more about Cognito and its role as an identity provider.
Enhanced Identity Support
Today we are making Cognito even more flexible by allowing you to make use of the user identity system of your choice. You can use this feature to allow your users to create an identity that is separate and distinct from their existing social identity.
With today's launch, Cognito takes an identifier that you supply and uses it to manufacture unique Cognito IDs for each person who uses your app. You can use this identifier to save and synchronize user data across devices and to retrieve temporary, limited-privilege AWS credentials through the AWS Security Token Service.
To use this new facility, you must first implement a backend identity provider of your own. Then you call the new
GetOpenIdTokenForDeveloperIdentityfunction and supply it with the name of your identity pool. The function will return a unique Cognito ID and an OpenID connect token. To learn more about how to do this and to see some sample code, read the post Amazon Cognito: Announcing Developer Authenticated Identities on the AWS Mobile Development Blog.
PowerShell Desired State Configuration (DSC) is a powerful tool for system administrators. Introduced as part of Windows Management Framework 4.0, it helps to automate system setup and maintenance for Windows Server 2008 R2 and Windows Server 2012 R2, Windows 7, Windows 8.1, and Linux environments. It can install or remove server roles and features, manage registry settings, environment variables, files, directories, and services, and processes. It can also manage local users and groups, install and manage MSI and EXE packages, and run PowerShell scripts. DSC can discover the system configuration on a given instance, and it can also fix a configuration that has drifted away from the desired state.
This new document will show you how to:
- Use AWS CloudFormation and PowerShell DSC to bootstrap your servers and applications from scratch.
- Deploy a highly available PowerShell DSC pull server environment on AWS.
- Detect and remedy configuration drift after your application stack has been deployed.
This detailed (24 page) document contains all of the information that you will need to get started. The deployed pull server is robust and fault-tolerant; it includes a pair of web servers and Active Directory domain controllers. It can be accessed from on-premises devices and from instances running in the AWS Cloud.
Let's take a quick look at what happened in AWS-land last week. I recently discovered a brand-new set of in-depth AWS articles from Intense School. I am more than happy to include informative, relevant, and timely articles from other partners, bloggers, and so forth. Please let me know when you publish something that you believe would be of attention to the AWS community. I'll do my best to check it out.
Today I’ve received a few questions about a maintenance update we’re performing late this week through early next week, so I thought it would be useful to provide an update.
Yesterday we started notifying some of our customers of a timely security and operational update we need to perform on a small percentage (less than 10%) of our EC2 fleet globally.
AWS customers know that security and operational excellence are our top two priorities. These updates must be completed by October 1st before the issue is made public as part of an upcoming Xen Security Announcement (XSA). Following security best practices, the details of this update are embargoed until then. The issue in that notice affects many Xen environments, and is not specific to AWS.
As we explained in emails to the small percentage of our customers who are affected and on our forums, the instances that need the update require a system restart of the underlying hardware and will be unavailable for a few minutes while the patches are being applied and the host is being rebooted.
While most software updates are applied without a reboot, certain limited types of updates require a restart. Instances requiring a reboot will be staggered so that no two regions or availability zones are impacted at the same time and they will restart with all saved data and all automated configuration intact. Most customers should experience no significant issues with the reboots. We understand that for a small subset of customers the reboot will be more inconvenient; we wouldn’t inconvenience our customers if it wasn’t important and time-critical to apply this update.
Customers who aren’t sure if they are impacted should go to the “Events“ page on the EC2 console, which will list any pending instance reboots for their AWS account.
As always, we are here to help walk customers through this or to answer questions after the maintenance update completes. Just open a support case.
P.S. Note that this update is not in any way associated with what is being called the “Bash Bug” in the news today. For information on that issue, see this security bulletin on the AWS security center.
We are launching a preview of a new, resource-style API model for the AWS SDK for Ruby. I will summarize the preview here, and refer you to the post AWS SDK for Ruby 2 Preview Release on the AWS Ruby Development Blog for full information!
If you’ve used Version 1 of the AWS SDK for Ruby, you are likely already familiar with resource objects available for a number of services. These resource objects allow you to work with AWS resources as Ruby objects with attributes that are automatically loaded from the service and instance methods that map to API actions that can be taken on the resource. The interface also provides collection classes for easy iteration.
With the lessons learned from resource objects in Version 1, we’re now introducing improved resource APIs in the Version 2 of the SDK. We have made three big changes to the model. First, resource objects now hold on to metadata retrieved from the service until explicitly reloaded by the user. This provides more control over network calls made by the SDK and helps users avoid unwanted or unnecessary HTTP requests. Second, we are newly introducing resource waiters, which allow you to wait on a resource to reach a specified state. Third, the resource objects are now data-driven by models defined in JSON. This allows a more structured and consistent definition of resource objects across different AWS services. Additionally, because we plan to share the same models in AWS SDKs for other languages, customers who need to work with multiple languages will be able to easily go from one language to another and work with similar resource definitions in the future.
Here’s an example of using a resource object representing an EC2 instance, along with a waiter method
wait_until_stopped(new in the Version 2 SDK):
instance = ec2.instance('i-1234567') # Get reference to instance instance.stop # Stop instance instance.wait_until_stopped # Wait until instance is stopped puts instance.id + 'has been stopped.'
The resource APIs and resource waiters are now available for the following 6 services in the Version 2 preview release of the SDK for Ruby: Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3), AWS Identity and Access Management (IAM), Amazon Glacier, Amazon Simple Notification Service (SNS), and Amazon Simple Queue Service (SQS). The SDK is also available as a Ruby Gem that can be installed as follows:
$ gem install aws-sdk –-pre
We plan to introduce resource APIs for additional services and AWS SDKs for other languages in the future, so stay tuned and happy coding!
PS - To learn more about Resource APIs, visit the AWS Ruby Development Blog.
We have updated the AWS Console mobile app with support for Amazon DynamoDB. You can now browse your tables in summary and detail form, modify provisioned throughput, and examine CloudWatch metrics and alarms for them.
Take a Look
Let's take a tour of the new features of the Console mobile app! I created a couple of tables and then opened up the Console mobile app to inspect them. There's a new DynamoDB summary on the main page of the console, and I tapped the summary to zoom in to the list of tables:
I installed the latest version of the AWS SDK for PHP and wrote a quick loop to populate the table. Then I returned to the app and zoomed in to my acct_table:
I waited a bit and then took a look at the accumulated CloudWatch metrics for the table.
While my PHP code was running I adjusted the table's read and write capacity a couple of times for demo purposes. This was easy to do from the app (I could imagine doing this while relaxing somewhere other than in front of my computer):
Then I took a closer look at the read capacity since I had adjusted it a couple of times:
But Wait, There's More
The Console mobile app displays the current state of the CloudWatch alarms defined for each table. It also provides access to the Global and Local Secondary Indexes for each DynamoDB table. You can see the metrics and alarms associated with each one and you can also modify the throughput.
Download & Install Now
The new version of the AWS Console mobile app is available now and you can start using it today (I never get tired of saying that). Here are the download links:
I love the community that has formed around AWS! Many of our customers have decided, with no help or encouragement from us, to actively and independently promote our services, solutions, blog posts, success stories, and best practices to their peers online. They do this by blogging, tweeting, creating videos, writing and sharing sample code, authoring books and tutorials, setting up and running AWS user groups, and so forth.
AWS Community Heroes
In order to recognize and publicly acknowledge the efforts of these hard-working folks, we have launched the AWS Community Hero program. An AWS Community Hero has routinely delivered high-quality, impactful, developer-focused activities to the AWS Community.
Our first group of Community Heroes are based in the United States. We plan to add additional heroes from the US and other parts of the world before too long. Without further ado, I'd like to introduce the first group!
Valentino Volonghi currently designs and implements the globally distributed architecture behind AdRoll. He is the President and Founder of the Italian Python Association that runs PyCon Italy. Since 2000, Valentino has specialized in distributed systems and actively worked with several Open Source projects. In his free time, he shows off his biking skills on his Cervelo S2 on 50+ mile rides around the Bay.
Peter Sankauskas is the CEO of CloudNative, Founder of Answers for AWS, a NetflixOSS Cloud Prize winner, and organizer of the Advanced AWS Meetup in San Francisco. His passion for scalability, reliability and simplicity has helped countless people get the most of out of the cloud, and it has only just begun.
Adrian Cockcroft has had a long career working at the leading edge of technology. He’s always been fascinated by what comes next, and he writes and speaks extensively on a range of subjects. At Battery Ventures, he advises the firm and its portfolio companies about technology issues and also assists with deal sourcing and due diligence. Before joining Battery, Adrian helped lead Netflix’s migration to a large scale, highly available AWS based architecture and has presented it at many conferences including packed room sessions at AWS Re:Invent 2012 and 2013. By open sourcing over 40 projects, the cloud-native NetflixOSS platform has helped many other applications use AWS more effectively. Adrian presented prizes for the best ten contributions to NetflixOSS during Werner’s 2013 Re:Invent keynote. Adrian graduated from The City University, London with a Bsc in Applied Physics and Electronics, and was named one of the top leaders in Cloud Computing in 2011 and 2012 by SearchCloudComputing magazine. He can usually be found on Twitter @adrianco.
Eric Hammond has been an active user and supporter of AWS since 2007. An early pioneer in creating community AMIs for Ubuntu, Eric introduced the concept of user-data scripts for EC2 instance initialization. Eric publishes articles on Alestic.com, his tech blog about practical uses of AWS, and is active in answering AWS questions on StackOverflow and ServerFault. Eric has built and led successful technology for a number of early stage Internet startups in the Los Angeles area including Citysearch.com, Stamps.com, Rent.com, and his current company, CampusExplorer.com, which runs entirely on AWS.
Ben Whaley is a consultant in the Bay area focused on cloud systems, automation, and systems architecture. Ben ran the network and systems for Apigee, a globally-distributed API management platform built on Amazon Web Services. He built and operated the AWS-hosted back end services for Anki, a robotics and artificial intelligence company. He is the co-author of the UNIX and Linux System Administration Handbook (the de facto standard text on Linux administration), and is the author of two educational videos: Linux Web Operations and Linux System Administration. Ben is a Red Hat Certified Engineer (RHCE) and a Certified Information Systems Security Professional (CISSP). In his spare time he rides snowboards and mountain bikes, cooks, and shaves yaks.
Jeremy Edberg (aka Jedberg) is an angel investor and advisor for various incubators and startups and was the founding member of the reliability group at Netflix, the largest video streaming service in the world, hosted entirely on AWS. Previously he managed operations for Reddit where he was responsible for reddit's Amazon EC2-based platform that handled over 17 million unique visitors a month and over a billion page views (at the time). Jeremy has also worked as a Systems Administrator, Programmer, and Security Engineer for eBay, PayPal, Sendmail and UC Berkeley. Jeremy also tech-edited the highly acclaimed AWS for Dummies. He holds a Cognitive Science degree from UC Berkeley.
Amazon CTO Werner Vogels recorded a personal greeting for the first AWS Community Heroes: