AWS Official Blog

When you pull the curtain back on an AWS-powered application, you’ll find that a lot is happening behind the scenes. EC2 instances are launched and terminated by Auto Scaling policies in response to changes in system load, Amazon DynamoDB tables, Amazon SNS topics and Amazon SQS queues are created and deleted, and attributes of existing resources are changed from the AWS Management Console, the AWS APIs, or the AWS Command Line Interface (CLI).

Many of our customers build their own high-level tools to track, monitor, and control the overall state of their AWS environments. Up until now, these tools have worked in a polling fashion. In other words, they periodically call AWS functions such as DescribeInstances, DescribeVolumes, and ListQueues to list the AWS resources of various types (EC2 instances, EBS volumes, and SQS queues here) and to track their state. Once they have these lists, they need to call other APIs to get additional state information for each resources, compare it against historical data to detect changes, and then take action as they see fit. As their systems grow larger and more complex, all of this polling and state tracking can become onerous.

New CloudWatch Events
In order to allow you to track changes to your AWS resources with less overhead and greater efficiency, we are introducing CloudWatch Events today.

CloudWatch Events delivers a near real-time stream of system events that describe changes in AWS resources. Using simple rules that you can set up in a couple of minutes, you can easily route each type of event to one or more targets: AWS Lambda functions, Amazon Kinesis streams, Amazon SNS topics, and built-in targets.

You can think of CloudWatch Events as the central nervous system for your AWS environment. It is wired in to every nook and cranny of the supported services, and becomes aware of operational changes as they happen. Then, driven by your rules,  it activates functions and sends messages (activating muscles, if you will) to respond to the environment, making changes, capturing state information, or taking corrective action.

We are launching CloudWatch Events with an initial set of AWS services and events today, and plan to support many more over the next year or so.

Diving in to CloudWatch Events
The three main components that you need to know about are events, rules, and targets.

Events (represented as small blobs of JSON) are generated in four ways. First, they arise from within AWS when resources change state. For example, an event is generated when the state of an EC2 instance changes from pending to running or when Auto Scaling launches an instance. Second, events are generated by API calls and console sign-ins that are delivered to Amazon CloudWatch Events via CloudTrail. Third, your own code can generate application-level events and publish them to Amazon CloudWatch Events for processing. Fourth, they can be issued on a scheduled basis, with options for periodic or Cron-style scheduling.

Rules match incoming events and route them to one or more targets for processing. Rules are not processed in any particular order; all of the rules that match an event will be processed (this allows disparate parts of a single organization to independently look for and process events that are of interest).

Targets process events and are specified within rules. There are four initial target types: built-in, Lambda functions, Kinesis streams, and SNS topics, with more types on the drawing board. A single rule can specify multiple targets. Each event is passed to each target in JSON form. Each rule has the opportunity to customize the JSON that flows to the target. They can elect to pass the event as-is, pass only certain keys (and the associated values) to the target, or to pass a constant (literal) string.

CloudWatch Events in Action
Let’s go ahead and set up a rule or two! I’ll use a simple Lambda function called SomethingHappened. It will simply log the contents of the event:

Next, I switch to the new CloudWatch Events Console, click on Create rule and choose an event source (here’s the menu with all of the choices):

Just a quick note before going forward. Some of the AWS services fire events directly. Others are fired based on the events logged to CloudTrail; you’ll need to enable CloudTrail for the desired service(s) in order to receive them.

I want to keep tabs on my EC2 instances, so I choose EC2 from the menu. I can choose to create a rule that fires on any state transition, or on a transition to one or more states that are of interest:

I want to know about newly launched instances, so I’ll choose Running. I can make the rule respond to any of my instances in the region, or to specific instances. I’ll go with the first option; here’s my pattern:

Now I need to make something happen. I do this by picking a target. Again, here are my choices:

I simply choose Lambda and pick my function:

I’m almost there! I just need to name and describe my rule, and then click on Create rule:

I click on Create Rule and the rule is all set to go:

Now I can test it by launching an EC2 instance. In fact, I’ll launch 5 of them just to exercise my code! After waiting a minute or so for the instances to launch and to initialize, I can check my Lambda metrics to verify that my function was invoked:

This looks good (the earlier invocations were for testing). Then I can visit the CloudWatch logs to view the output from my function:

As you can see, the event contains essential information about the newly launched instance. Your code can call AWS functions in order to learn more about what’s going on. For example, you could call DescribeInstances to access more information about newly launched instances.

Clearly, a “real” function would do something a lot more interesting. It could add some mandatory tags to the instance, update a dynamic visualization, or send me a text message via SNS. If you want to do any (or all of these things), you would need to have a more permissive IAM role for the function, of course. I could make the rule more general (or create another one) if  I wanted to capture some of the other state transitions.

Scheduled Execution of Rules
I can also set up a rule that fires periodically or according to a pattern described in a Cron expression. Here’s how I would do that:

You might find it interesting to know that this is the underlying mechanism used to set up scheduled Lambda jobs, as announced at AWS re:Invent.

API Access
Like most AWS services, you can access CloudWatch Events through an API. Here are some of the principal functions:

• PutRule to create a new rule.
• PutTargets and RemoveTargets to connect targets to rules, and to disconnect them.
• ListRules, ListTargetsByRule, and DescribeRule to find out more about existing rules.
• PutEvents to submit a set of events to CloudWatch events. You can use this function (or the CLI equivalent) to submit application-level events.

Metrics for Events
CloudWatch Events reports a number of metrics to CloudWatch, all within the AWS/Events namespace. You can use these metrics to verify that your rules are firing as expected, and to track the overall activity level of your rule collection.

The following metrics are reported for the service as a whole:

• Invocations – The number of times that target have been invoked.
• FailedInvocations – The number of times that an invocation of a target failed.
• MatchedEvents – The number of events that matched one or more rules.
• TriggeredRules – The number of rules that have been triggered.

The following metrics are reported for each rule:

• Invocations – The number of times that the rule’s targets have been invoked.
• TriggeredRules – The number of times that the rule has been triggered.

In the Works
Like many emerging AWS services, we are launching CloudWatch Events with an initial set of features (and a lot of infrastructure behind the scenes) and some really big plans, including AWS CloudFormation support. We’ll adjust our plans based on your feedback, but you can expect coverage of many more AWS services and access to additional targets over time. I’ll do my best to keep you informed.

Getting Started
We are launching CloudWatch Events in the US East (Northern Virginia), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) regions. It is available now and you can start using it today!

— Jeff;

Last November I gave you a heads-up that we planned to increase the length of the resource IDs for EC2 instances, reservations, volumes, and snapshots in early 2016. We are now entering a transition period that will last until early December (2016). During this period, you can opt in to the new format (a resource identifier followed by a 17-character string) on a region-by-region, user-by-user, type-by-type basis.  Once you opt in for a given region and IAM user (or for the root account), newly created resources will receive the longer IDs.

Effective today, you can opt in to the new format for EC2 instances and EC2 reservations. Each reservation represents the results of a single instance launch request, and can be associated with multiple instances.

If you build libraries, tools, or applications that make direct calls to the AWS API, now is the time to opt in and to start your testing process! If you store the IDs in memory or in a database, take a close look at fixed-length fields, data structures, schema elements, string operations, and regular expressions. Resources that were created before you opt in will retain their existing short identifiers; be sure that your revised code can still handle them!

You can opt in to the new format using the AWS Management Console, the AWS Command Line Interface (CLI), the AWS Tools for Windows PowerShell, or though an API function.You can also opt out if your testing uncovers issues that you need to address.

Opting In – Console
To opt in via the Console, simply log in, choose EC2, and click on Resource ID length management:

Then click on Use Longer IDs for the desired resource types:

Opting In – AWS CLI
To opt in using the AWS CLI, use the modify-id-format command and specify the desired resource type:

$ modify-id-format --resource instance --use-long-ids

You can opt out like this:

$ modify-id-format --resource instance --no-use-long-ids

Opting In – AWS Tools for Windows PowerShell
To opt in using the AWS Tools for Windows PowerShell, use the Edit-EC2IdFormat cmdlet and specify the desired resource type:

PS C:\> Edit-EC2IdFormat -Resource instance -UseLongId True

You can opt out like this:

PS C:\> Edit-EC2IdFormat -Resource instance -UseLongId False

Opting In – AWS SDKs
To opt in from your own tools or application code, call the ModifyIdFormat function, specify the resource type (instance or reservation), and set the UseLongIds parameter to True.

Things to Know
You can opt in at the IAM user or account level. After you have opted in, newly created resources of the specified types will receive the new, longer identifiers as soon as the setting takes effect (typically a few minutes). The identifiers will be visible in API results, the command line, and the console.

If a particular IAM user opts in and then creates some resources, the longer identifiers will be visible to other users, even if they have not opted in. You may want to create a separate AWS account for testing purposes in order to avoid confusion. You can also choose to do your testing in an AWS region that you don’t use on a regular basis (see the AWS Global Infrastructure page for a list of current and planned regions).

This blog post applies to all AWS regions and accounts. AWS accounts created on or after March 7, 2016 will default to longer instance and reservation IDs, and can be opted out if necessary.

After you have performed your testing and are satisfied that your tools, code, and applications work to your satisfaction, we recommend that you opt in for all of your AWS accounts before December 2016. This will give you confidence that no surprises will arise when the new identifiers become mandatory.

To learn more about this important update to AWS, please read the Longer EC2 and EBS Resource IDs FAQ.

PS – We’ll be adding support for EBS volumes and snapshots in April; stay tuned for more information.

Amazon CloudFront can be used to deliver static and dynamic content using a global network of edge locations. You can set it up in minutes and give your customers the benefit of fast, low-latency access to your web site, movies, music, and so forth.

Each CloudFront distribution references one or more origins (web servers or S3 buckets). When CloudFront needs content that is not cached at an edge location, it makes a request to the appropriate origin, as determined by a set of mappings (behaviors) that are also specified within the distribution.

Today we are launching three new features that will give you additional control over the connection between CloudFront and your origins:

• Support for TLS v1.1 and v1.2
• HTTPS-only connection
• Control of edge-to-origin request headers

Support for TLS v1.1 and v1.2
We have added TLS v1.1 and TLS v1.2 to the list of protocols that you can configure between the edge and a custom origin. With this change, you can now configure CloudFront to use SSLv3, TLS v1.0, v1.1, and v1.2 for each custom origin you set up for a CloudFront distribution.

HTTPS-Only Connection
You can now configure CloudFront to always use HTTPS while connecting to your origin, regardless of the protocol (HTTP or HTTPS) that was used to connect to the edge. Previously, CloudFront connected to the origin using the same protocol (HTTP or HTTPS) that was used to connect to the edge. When you enable this new feature, both HTTP and HTTPS requests from the viewer will be sent to the origin using HTTPS.

Here is how you configure the desired protocols and HTTP-Only for a custom origin:

Control of Edge-to-Origin Request Headers
You can now configure CloudFront to add custom headers or override the value of existing request headers when CloudFront forwards requests to your origin. You can use these headers to help validate that requests made to your origin were sent from CloudFront (shared secret) and configure your origin to only allow requests that contain the custom header values that you specify.

For Cross-Origin Request Sharing (CORS), you can configure CloudFront to always supply the applicable headers to your origin to accommodate viewers that don’t automatically include those headers in requests. This also allows you to disable varying on the Origin header, which increases your cache hit ratio.

Here’s how you would add new headers named X-CloudFront-Distribution-Id and X-Shared-Secret:

These features are available now and you can start using them today at no additional cost. To learn more, read the CloudFront Developer Guide.

Many AWS customers run some of their mission-critical applications on a periodic (daily, weekly, or monthly), part-time basis. Here are some of the kinds of things that they like to do:

• A bank or mutual fund performs Value at Risk calculations every weekday afternoon.
• A phone company does a multi-day bill calculation run at the start of each month.
• A trucking company optimizes routes and shipments on Monday, Wednesday, and Friday mornings.
• An animation studio performs a detailed, compute-intensive 3D rendering every night.

Our new Scheduled Reserved Instances are a great fit for use cases of this type (and many more). They allow you to reserve capacity on a recurring basis with a daily, weekly, or monthly schedule over the course of a one-year term. After you complete your purchase, the instances are available to launch during the time windows that you specified.

Purchasing Scheduled Instances
Let’s step through the purchase process using the EC2 Console. I start by selecting Scheduled Instances on the left:

Then I click on the Purchase Scheduled Instances button and find a schedule that suits my needs.

Let’s say that I am based in Seattle and want to set up a schedule for Monday, Wednesday, and Friday mornings. I convert my time (6 AM) to UTC, choose my duration (8 hours of processing for my particular use case), and set my recurrence. Then I specify a c3.4xlarge instance (I can select one or more types using the menu):

I can see the local starting time while I am setting up the schedule:

When I click on Find schedules, I can see what’s available at my desired time:

As you can see, the results include instances in several different Availability Zones because I chose Any in the previous step. Leaving the Availability Zone and/or the instance type unspecified will give me more options.

I can add the desired instance(s) to my cart, adjusting the quantity if necessary. I can see my choices in my cart:

Once I have what I need I click on Review and purchase to proceed, verify my intent, and click on Purchase:

I can then see all of my Scheduled Reserved instances in the console:

Launching Scheduled Instances
Each Scheduled Reserved instance becomes active according to the schedule that you chose when you made the purchase. You can then launch the instance by selecting it in the Console and clicking on Launch Scheduled Instances:

Then I configure the launch as usual and click on Review:

Scheduled Reserved instances can also be launched via the AWS Command Line Interface (CLI), the AWS Tools for Windows PowerShell, and the new RunScheduledInstances function. We are also working on support for Auto Scaling, AWS Lambda, and AWS CloudFormation.

Things to Know
With this launch, we now have two types of Reserved Instances. The original Reserved Instance (now called Standard Reserved Instances) model allows you to reserved EC2 compute capacity for a one or three year term and use them at any time. The new Scheduled Reserved Instance model allows you to reserve instances for predefined blocks of time on a recurring basis for a one-year term, with prices that are generally 5 to 10% lower than the equivalent On-Demand rates.

This feature is available today in the US East (Northern Virginia), US West (Oregon), and Europe (Ireland) regions, with support for the C3, C4, M4, and R3 instance types.

Does your operations team practice ChatOps? This brand-new term refers to the practice of conversation-driven operations using one or more “bots” that have the ability to insert notifications & status reports into the conversation and to respond to commands.

The chat environment provides real-time communication, a coherent shared view, multi-user access from web and mobile devices, access to previous messages, and so forth. Integrating bots into the conversation gives operations teams the ability to work collaboratively to understand, diagnose, and address emerging issues while simultaneously tracking changes made to the target system by way of commands directed to a bot.

New Slack Integration
In order to make it even easier for AWS customers to manage their environments in this new and innovative way, we recently launched a collection of Slack Integration Blueprints for AWS Lambda:

You can use these blueprints to build chat-based tools that participate in your own Slack conversations. The slack-echo- blueprints will help you to write bots that respond to commands; the cloudwatch-alarm-to-slack- blueprints will help you to write bots that emit status reports and notifications. Because you have the ability to give the bots access to any desired AWS APIs, you can interact with your AWS resources in any desired way. You can query their status, look for error conditions, change settings, or even create new resources.

Suppose you want to monitor an Auto Scaling group using a CloudWatch alarm, and generate a message to your ChatOps team (a Slack channel) when a limit is exceeded. The team can take a closer look at the situation, and then decide to remedy the issue by scaling up. Using the new Slack integration and various AWS services, the overall flow would look like this (red arrows represent the notification; green arrows represent the response):

In order to implement a system like this you would use a Slack webhook to post messages to the channel, along with the cloudwatch-alarm-to-slack-python blueprint. Following the directions in the blueprint, you would create a AWS Key Management Service (KMS) key, use it to encrypt the URL of the webhook, and base-64 encode it before pasting it in to the code. Then you would create an IAM Role and give it permission to call the KMS Decrypt function on the key. The event handler would then send messages to the Slack channel of your choice like this:

slack_message = {
    'channel': SLACK_CHANNEL,
    'text': "%s state is now %s: %s" % (alarm_name, new_state, reason)
}

req = Request(HOOK_URL, json.dumps(slack_message))

The handler would also need to handle any exceptions raised by the request (this is all spelled out in the blueprint).

You can also create functions that implement custom Slack commands. In order to do this, you use the Amazon API Gateway to create an HTTP endpoint for each function, and then configure your Slack channel to POST to the endpoint when the command is invoked. For example, here’s the configuration for commands named /scale and /forcealarm:

The handler function has access to the user, command, channel, and command text:

def lambda_handler(event, context):
    req_body = event['body']
    params = parse_qs(req_body)

    user = params['user_name'][0]
    command = params['command'][0]
    channel = params['channel_name'][0]
    command_text = params['text'][0]

You will need to configure the endpoint with a POST method, and set the authorization to NONE. You’ll also need to map the body of the request to JSON. The comment block at the top of each of the new blueprints contains more information on this aspect of the integration.

Share your Functions
I would love to see what kinds of cool functions you come up with. Please feel free to post your work as a comment to this post.

We continue to announce, build, and launch additional AWS regions as our customer base becomes larger, more diverse, and accustomed to running many different types of workloads in the cloud.

Hello, Canada
I am happy to announce that we will be opening an AWS region in Montreal, Québec, Canada in the coming year. This region will be carbon-neutral and powered almost entirely by clean, renewable hydro power.

The planned Canada-Montreal region will give AWS partners and customers the ability to run their workloads and store their data in Canada. As a reminder, we currently have 4 other regions in North America—US East (Northern Virginia), US West (Northern California), US West (Oregon), and AWS GovCloud (US)—with a total of 13 Availability Zones, plus the planned but not yet operational region coming to Ohio in 2016.

Today’s announcement means that our global infrastructure now comprises 32 Availability Zones across 12 geographic regions worldwide, with another 5 AWS regions (and 11 Availability Zones) in Canada, China, India, Ohio, and the United Kingdom coming online throughout the next year (see the AWS Global Infrastructure page for more info).

As always, we are looking forward to serving new and existing Canadian customers and to working with partners in the area. Of course, the new region will also be open to existing AWS customers who would like to process and store data in Canada.

Nous continuons d’annoncer, de développer et de lancer de nouvelles régions AWS à mesure que notre clientèle gagne en importance, en diversité et qu’elle s’habitue à exécuter plusieurs activités différentes dans le cloud.

Bonjour Canada
Je suis très heureux d’annoncer que nous ouvrirons une région AWS à Montréal, Québec, au Canada, dans l’année à venir.

Cette région sera carboneutre et alimentée presque entièrement par de l’énergie hydro-électricité propre et renouvelable.

La future région de Montréal (Canada) offrira aux partenaires et aux clients d’AWS la possibilité d’exécuter leurs activités et de stocker leurs données au Canada. Je vous rappelle qu’il existe actuellement quatre autres régions en Amérique – la région USA Est (Virginie du Nord), la région USA Ouest (Californie du Nord), la région USA Ouest (Oregon) et la  région AWS GovCloud (US) – formant un total de 13 zones de disponibilité (AZ), en plus des régions planifiées en Ohio dont l’ouverture est prévue pour 2016, mais qui ne sont pas encore opérationnelles.

L’annonce d’aujourd’hui signifie que notre infrastructure mondiale compte 32 zones de disponibilité (AZ) réparties dans 12 régions du monde, en plus des 5 régions AWS (et 11 zones de disponibilité [AZ]) au Canada, en Chine, en Inde, en Ohio et au Royaume-Uni qui seront en ligne au cours de l’année prochaine (consultez la page Infrastructure mondiale AWS pour obtenir plus de renseignements).

Comme toujours, nous avons bien hâte de servir de nouveaux clients canadiens ou des clients canadiens existants et de travailler avec nos partenaires dans la région. Bien entendu, la nouvelle région sera également disponible pour les clients existants d’AWS qui souhaitent traiter et stocker des données au Canada.

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

New & Notable Open Source

• Squiss is a high-volume Amazon SQS poller for Node.js.
• Blocker is a simple AWS EBS volume plugin for Docker.
• Lambda-test is a generic repository for testing GitHub webhooks with AWS Lambda.
• Awful is a Ruby gem that provides simple AWS command line tasks and YAML persistence.
• Splunk-sqs is an SQS collector for Splunk.
• Lambda-deploy is a proof of concept for deploying Lambda with CloudFormation + Grunt + AWS + Lambda.
• Amazonica is a comprehensive Clojure client for the entire AWS API.
• Lambda6 is a simple and opinionated handler architecture for AWS Lambda using ES6.
• Go-lambda allows you to call Go GRPC services from AWS Lambda functions.
• Thingpin is a Raspberry Pi AWS IoT publisher for IoT enabled sensors.

New Customer Success Stories

• Fin Design + Effect – Visual effects and design.
• Healthdirect Australia – Deliver services across the entire country while controlling costs.
• Hiree – Expediting the hiring process and helping job-seekers to get offers.
• SEAOIL –  Move Oracle E-Business Suite enterprise resource planning system into AWS.
• Syntel – Reduce provisioning time for hardware and increase scalability.
• THRON – Platform to simplify digital content management and distribution.

New YouTube Videos

• Introduction to Amazon Route 53.
• Introduction to Amazon Kinesis Firehose.
• Introduction to Amazon DynamoDB.

Upcoming Events

• January 13th – Live Event (San Francisco) – AWS Big Data Meetup.

Upcoming Events at the AWS Lofts

• What’s Hot at AWS Pop-up Lofts in January.

Help Wanted

• AWS Careers.

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

— Jeff;

The AWS IoT Mega Contest (brought to you by AWS and the great team at Hackster) has been extended until January 31, 2016. We already have over 850 participants, nearly 300 project ideas, and 45 projects, but there’s still time (and room) for more.

As the name suggests, we’re looking for Internet of Things projects that make use of the new AWS IoT service.

Goodies!
Everyone who posts a completed project receives $880 worth of goodies including AWS credits, a month of AWS Support, AWS Technical Professional Training, $80 of credit for Self-Paced Labs.

The first 50 projects receive $100 in cash.

The top 10 projects (based on documentation, creativity, and practicality) will win prizes that include an Amazon Kindle Fire HD, Amazon Echo devices, and the Amazon Fire TV Gaming Edition.

Getting Started
If you were lucky enough to pick up an AWS IoT Button at AWS re:Invent, you can use it as part of your project. If not, you can purchase an AWS IoT Starter Kit from one of our partners or use an Arduino, Raspberry Pi, UDOO, Teensy, or FRDM that you already own.

Now you can build your project based on one of the project ideas. Take good notes as you build it, and be sure that your submission includes high-quality images, clear instructions, a bill of materials, schematics, source code, and CAD files, as appropriate.

Some Cool Ideas
The existing participants have generated hundreds of really cool ideas. As you can see, this is not simply technology for technology’s sake. Instead, people are using AWS to solve problems that are personal and meaningful to them. They are thinking about ways to create a better, healthier environment, focusing on personal safety, and agriculture. In the best Maker fashion, people are scratching their own itch, in ways that will improve life for them, their families, and their neighbor!

Here are some of our favorite ideas:

Allergen Levels Sensory Network by Kevin Kingsbury – Create a network of air quality sensor to monitor pollen, pollution and mold in cities everywhere, processing location and data in real time.

IoT Radiation Monitor by David Fowler – IoT enabled Geiger Counter small enough to be carried in a pocket or mounted to a vehicle and used to monitors radiation levels. The device will collect data and report radiation counts with position and time stamps.

IFTTT Anything with the AWS IoT Button by Drew Alend – Trigger any IFTTT action with a click of the AWS IoT Button. If clicked than that!

Computer Control with AWS ioT by Alex Merchen – Turn your computer BEFORE you come to work with a simple AWS IoT Button push, and save yourself time wasted on reboot and updates.

Hello & Good Night! by Dave Mathews – The smart home has been a dream of geeks since the lightbulb was created. Now, with dozens of apps in the stores controlling vastly different “so called smart” hardware interfaces, you can have a puzzle of connectivity.  We are going to take the AWS IoT button and turn it into a one-touch off button for ALL of our smart home services – Hue, Wemo and Sonos.  The key here is that we will not need another smart home controller, but leverage the power of the AWS Cloud and software APIs for the devices!

Monitoring Food/Water Intake for Dementia Patients by Leigh Carpenter – Caring for patients suffering from dementia who don’t to keep up with consistent eating and drinking habits which hey often neglect.

Some Cool Projects
Here are some projects that have been developed around the ideas:

AWS IoT Button and Sonos by Paul Wakeford – Use the AWS IoT Button to control a Sonos music system.

Summon Uber with the new AWS IoT Dash Button – Press the button and watch for the Uber App on your phone.

AWS IoT Button for LIFX  by Daniel Porrey – Use the AWS IoT Button to control a LIFX light bulb with immediacy and efficiency.

One Button Click Artificial Intelligence Based Home Monitor by Geeve George – Build a voice assistant for home security and  monitoring while while you’re away.

Magic Mirror – Use Amazon Echo to run an image search on the web.

Real Time Crop Monitoring by Sarthak Sethi – Help farmers monitor the health of crops by tapping data and sensors, across seasons and geographies.

Some Resources
Here are some great tutorials to get you started with AWS IoT:

• Beginner’s Guide to Using Your AWS IoT Button.
• Getting Started With the AWS IoT Button (video).
• Try to connect AWS IoT Button to kintone via AWS IoT.
• Using AWS IoT Button (Japanese).

20 Days To Go
With just 20 days to go, you’ll have to hustle if you plan to create and submit a project. Go for it! Be sure to read the FAQ and the official rules (scroll down).

We are expanding the AWS footprint once again, this time with a new region in Seoul, South Korea. AWS customers in the area can use the new Asia Pacific (Seoul) region for fast, low-latency access to the suite of AWS infrastructure services.

New Region
The new Seoul region has two Availability Zones (raising the global total to 32). It supports Amazon EC2 (T2, M4, C4, I2, D2, and R3 instances are available) and related services including Amazon Elastic Block Store (EBS), Amazon Virtual Private Cloud, Auto Scaling, and Elastic Load Balancing.

It also supports the following services:

• AWS CloudFormation
• Amazon CloudFront
• AWS CloudTrail
• Amazon CloudWatch
• Amazon DynamoDB
• AWS Elastic Beanstalk
• Amazon ElastiCache
• Amazon EMR
• Amazon Glacier
• AWS Identity and Access Management (IAM)
• AWS Key Management Service (KMS)
• Amazon Kinesis
• Amazon Redshift
• Amazon Relational Database Service (RDS)
• Amazon Route 53
• Amazon Simple Notification Service (SNS)
• Amazon Simple Queue Service (SQS)
• Amazon Simple Storage Service (S3)
  Amazon Simple Workflow Service (SWF)
• AWS Trusted Advisor
• VM Import

There are two edge locations in Seoul for Amazon Route 53 and Amazon CloudFront. AWS Direct Connect support is available via KINX.

This is our twelfth region (see the AWS Global Infrastructure map for more information). As usual, you can see the full list in the region menu of the AWS Management Console:

Customers
There is already a very broad base of AWS customers in Korea. Here are a couple of examples:

Samsung used AWS to build the Samsung Printing App Center. This complex app can deploy mobile printing, scanning, and copying applications to a global customer base in real time. They chose AWS in order to be cost-effective, agile, and scalable.

Nexon is Korea’s premier gaming company, providing 150 games in 150 countries. AWS allows them to address a global customer base and to experiment with different games without having to invest in local infrastructure. Their newest MMORPG game, HIT, recently achieved the number one sales rank within the Korean mobile gaming industry in a record amount of time, running 100% on AWS.

Mirae Asset Global Investments Group migrated their web properties from on-premises data centers to AWS. This allowed them to stay competitive while reducing their management costs by 50%. With the launch of the new region, they will move additional sensitive, mission-critical workloads to AWS.

Eastar Jet was the first Korean airline company to migrate workloads to the public cloud. As one of the fastest-growing low-cost carriers (4 domestic and 6 international routes), they needed to reduce costs, increase availability, and ensure reliability as the total passenger count grew to over 14 million. They plan to move additional workloads to the new region.

The Beatpacking Company runs a popular music streaming app, with traffic that sometimes surges to 300% of the usual level. Since launching on AWS in March of 2014, they have grown to over 6 million users. Despite this growth, they reduced their AWS cost per user by 97% in the past year.

Partners
We are pleased to be working with a very wide variety of partners in Korea. Here is a sampling:

• AWS Premier Consulting Partners – Megazone and GS Neotek.
• AWS Consulting Partners – BD, NDS, Hostway, Saltware, WellDataSystem, Acloud, IAANSYS, MTOS Solutions, rockPLACE, and Vsystems.
• AWS Technology Partners – Hancom, IGAWorks, PentaSecurity, Gruter, ByteCode Lab, DaliWorks, TMAXSoft, and JenniferSoft.
• AWS Managed Security Service Providers – Ahnlab, SK Infosec, and CyberOne.
• AWS Direct Connect Partners – Dreamline, Sejong Telecom, and KINX.

Offices and Support
We opened an AWS office in Seoul in 2012. This office supports enterprises, government agencies, academic institutions, small-to-mid size companies, startups, and developers. The full range of AWS Support options is also available.

Compliance
Every AWS region is built and designed to meet rigorous compliance standards including ISO 27001, ISO 9001, ISO 27017, ISO 27018, SOC 1, SOC 2, and PCI DSS Level 1 (to name a few); see the AWS Compliance page for more info.

AWS implements an Information Security Management System (ISMS) that is independently assessed by qualified third parties. These assessments address a wide variety of requirements which are communicated by making certifications and audit reports available, either on our public-facing website or upon request.

As customer trust is our top priority, AWS adopts global privacy and data protection best practices. Our most recent example of this commitment is our validation by an independent third party attesting that we align with ISO 27018 – the first international code of practice to focus on protection of personal data in the cloud. This demonstrates to customers that AWS has a system of controls in place specifically to address the privacy protection of their content.

For more information on how we handle data privacy, take a look at our Data Privacy FAQ.

Use it Now
This new region is open for business now and you can start using it today! If you are able to read Korean and want to know more about this region, please visit the new Seoul Region microsite. You’ll find additional information about the new region, documentation on how to migrate, customer use cases, information on training and other events, and  a list of AWS Partners in Korea.

The AWS Cost Explorer (read The New Cost Explorer for AWS to learn more) is a set of a tools that help you to track and manage your AWS costs. Last year we added saved reports, budgets & forecasts, and additional filtering & grouping dimensions.

Today we are adding EC2 usage data to Cost Explorer, along with additional dimensions for filtering and grouping:

• The EC2 cost data is now broken down into three elements: EC2 instances (EC2-Instances), Elastic Load Balancing (ELB), and Elastic Block Store (EBS).
• You can now filter, group, and view costs on additional dimensions, including Instance Type and Region.

Here’s a screen shot of the new usage data and dimensions:

The new features are available now and you can start using them today. To learn more, read about Analyzing Your Costs with Cost Explorer.