AWS Official Blog

AWS Webinars for January, 2016

by Jeff Barr | on | in Webinars | | Comments

Did you resolve to learn something new in 2016? If so, you should attend an AWS webinar!

Each month, we run a series of webinars that are designed to bring you up to speed on the latest AWS services & features, and to make sure that you are aware of the best ways to put them to use. The webinars are conducted by senior AWS Product Managers and Solution Architects and often include a guest speaker from our customer base.

The webinars are free but “seating” is limited and you should definitely sign up ahead of time if you want to attend (all times are Pacific). Here’s what we have in store this month:

Tuesday, January  26
There are several different ways to deploy your applications on AWS including AWS Elastic Beanstalk, AWS CodeDeploy, and Amazon EC2 Container Service. This webinar will help you to understand the strengths of each service and provide you with a framework to help you to decide which one to use.

AWS IoT is a managed cloud platform that lets connected devices interact with cloud applications and other devices. This webinar will show you how constrained devices can send data to the cloud and receive commands back to the device.

AWS provides many options and tools that are a great fit for your big data needs. This webinar will provide you with an overview of the options including Hadoop, Spark, and NoSQL databases.

Wednesday, January 27
Amazon Aurora is a fast and cost-effective relational database designed to be compatible with MySQL.

Do you have existing data that you want to bring to the cloud? Our data migration webinar will review the options and help you to choose the one that fits your use case:

Many developers are using containers to simplify the packaging, deployment, and operation of their applications. This webinar will show you how to use Amazon EC2 Container Service to simplify the use of Docker in production.

Thursday, January 28
Machine Learning helps you to extract value from data. This webinar will show you how to build machine learning models and use them to make predictions.

I am always happy to see ways that two or more AWS services can be combined to create something cool. This webinar will show you how to use AWS Lambda and the new AWS IoT service to do just that:

The phrase “infrastructure as code” has become increasingly popular over the last couple of years. This webinar will show you how do implement this new practice using AWS:

— Jeff;

 

 

AWS Week in Review – January 11, 2016

by Jeff Barr | on | in Week in Review | | Comments

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

Monday

January 11
Tuesday

January 12
Wednesday

January 13
Thursday

January 14
Friday

January 15
Saturday

January 16
Sunday

January 17

New & Notable Open Source

  • Sparta helps you to build & deploy Go functions in AWS Lambda.
  • Apex is a new serverless architecture for AWS Lambda.
  • AWSResco is a standalone SPA (Single Page Application) to get instance and reservation cost info for running infrastructure.
  • Bragg is a web framework for Lambda.
  • Kinesis-common is a common Java package for interacting with Kinesis.
  • aws-cloud-examples is a collection of files (CloudFormation templates) for testing and developing on AWS.
  • mock-aws-s3 is a simple interface that mocks the AWS SDK for Node.js.
  • Vominator is a CLI tool for managing AWS resources at scale.
  • get-aws-pricing queries AWS pricing information using the Price List API.
  • s3-utilities is a tool for undeleting files, folders, and entire buckets from S3 versioned buckets.

New SlideShare Presentations

New Customer Success Stories

New YouTube Videos

Upcoming Events

Help Wanted

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

— Jeff;

Amazon Wind Farm Fowler Ridge is Live!

by Jeff Barr | on | in Announcements | | Comments

Back in November 2014 AWS made a long-term commitment to achieve 100% renewable energy usage for our global infrastructure footprint, and we continue to make progress towards this goal. Today’s news on this topic is particularly exciting for us – our Amazon Wind Farm Fowler Ridge, located in Benton County, Indiana, is now live and producing electricity! This marks the first of our four announced renewable energy projects to move into full operation.

We first announced that we teamed with Pattern Energy Group LP (Pattern Development) on the construction and operation of the 150 megawatt (MW) Amazon Wind Farm Fowler Ridge in January of last year. Over the course of the summer and fall of 2015, Pattern erected the wind farm’s 65 utility-scale turbines. Each of those turbines is tall, so tall in fact that the rotor axis, called a nacelle, is about the height of a 26-story building with blades long enough to sweep an area about the size of a football field.

On January 1, 2016, its first day of full operation, Amazon Wind Farm Fowler Ridge generated more than 1.1 million kilowatt-hours of renewable electricity, enough to power over 100 US homes for an entire year! Each year the project is expected to generate enough renewable electricity to power the equivalent of approximately 46,000 homes. With this wind farm, we’re able to increase the amount of renewable energy produced in the grid that powers AWS’s US East Region in Northern Virginia and upcoming US Region in Ohio. Over time we’ll continue to add more wind and solar power delivered into the grids, reducing the amount of coal and other fossil fuels needed to power those grids.

Today’s news definitely helps us progress towards our goal of 40% renewable energy for our global infrastructure by the end of 2016 and marks more progress in AWS’s march towards our long-term 100% renewable goal, with much more soon to come. Since the Fowler Ridge project, we have announced three other agreements for new wind and solar projects that will be constructed over the coming months and start generating renewable power in late 2016 and early 2017. Stay tuned for more exciting announcements to come in the future as well.

— Jeff;

AWS Global Summits for 2016 – Save the Date

by Jeff Barr | on | in Events | | Comments
Getting Ready to present (photo by Danilo Poccia)

Late last year I traveled to Barcelona and delivered the keynote address at one of the final AWS Summit events of 2015.

My re:Invent recap was well received; the AWS users and partners in the area were excited by our newest services and left the session eager to learn more and to put them to use. As part of the keynote session, attendees learned about AWS security from my colleague Bill Murray and also had the opportunity to hear how several of our customers had used AWS.

After the keynote, attendees spent the afternoon attending deep-dive technical sessions, exploring the partner area, and meeting with each other. We wrapped up the day with snacks, drinks, and a Battle of the Bands. It was wonderful to meet so many AWS users and to learn more about their businesses and their applications.

Summits for 2016
We are now making plans for our 2016 Global Summit series. As in past years, we will focus on education—we want to make sure that you know as much as possible about whatever aspects of AWS are of interest to you, and we want you to leave the summit charged up and ready to build something new, cool, and powerful!

To see the list of cities and dates, check out the AWS Summits page. Click on the Want More Information button to express your interest in a local Summit and to receive registration information as it becomes available.

Follow Along
In addition to the page above, you can also subscribe to the AWS Events RSS feed, follow @AWSSummits on Twitter, and find us on Facebook.

— Jeff;

PS – Members of the AWS Partner Network (APN) should take a look at the 2016 Global Sponsorship Opportunities.

New CloudWatch Events – Track and Respond to Changes to Your AWS Resources

by Jeff Barr | on | in Amazon EC2, Amazon SQS, CloudTrail, CloudWatch, DynamoDB | | Comments

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;

They’re Here – Longer EC2 Resource IDs Now Available

by Jeff Barr | on | in Amazon EC2, Amazon Elastic Block Store | | Comments

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.

— Jeff;

 

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

CloudFront Update – HTTPS & TLS v1.1/v1.2 to the Origin, Add/Modify Headers

by Jeff Barr | on | in Amazon CloudFront | | Comments

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.

— Jeff;

 

New – Scheduled Reserved Instances

by Jeff Barr | on | in Amazon EC2, Price Reduction | | Comments

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.

— Jeff;

New – Slack Integration Blueprints for AWS Lambda

by Jeff Barr | on | in AWS Lambda | | Comments

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.

— Jeff;

In the Works – AWS Region in Canada

by Jeff Barr | on | in Announcements | | Comments

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.

En cours d’élaboration – région AWS au 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.

— Jeff;