All posts by Jeff Barr

Urgent & Important – Rotate Your Amazon RDS, Aurora, and DocumentDB Certificates

Post Syndicated from Jeff Barr original

You may have already received an email or seen a console notification, but I don’t want you to be taken by surprise!

Rotate Now
If you are using Amazon Aurora, Amazon Relational Database Service (RDS), or Amazon DocumentDB and are taking advantage of SSL/TLS certificate validation when you connect to your database instances, you need to download & install a fresh certificate, rotate the certificate authority (CA) for the instances, and then reboot the instances.

If you are not using SSL/TLS connections or certificate validation, you do not need to make any updates, but I recommend that you do so in order to be ready in case you decide to use SSL/TLS connections in the future. In this case, you can use a new CLI option that rotates and stages the new certificates but avoids a restart.

The new certificate (CA-2019) is available as part of a certificate bundle that also includes the old certificate (CA-2015) so that you can make a smooth transition without getting into a chicken and egg situation.

What’s Happening?
The SSL/TLS certificates for RDS, Aurora, and DocumentDB expire and are replaced every five years as part of our standard maintenance and security discipline. Here are some important dates to know:

September 19, 2019 – The CA-2019 certificates were made available.

January 14, 2020 – Instances created on or after this date will have the new (CA-2019) certificates. You can temporarily revert to the old certificates if necessary.

February 5 to March 5, 2020 – RDS will stage (install but not activate) new certificates on existing instances. Restarting the instance will activate the certificate.

March 5, 2020 – The CA-2015 certificates will expire. Applications that use certificate validation but have not been updated will lose connectivity.

How to Rotate
Earlier this month I created an Amazon RDS for MySQL database instance and set it aside in preparation for this blog post. As you can see from the screen shot above, the RDS console lets me know that I need to perform a Certificate update.

I visit Using SSL/TLS to Encrypt a Connection to a DB Instance and download a new certificate. If my database client knows how to handle certificate chains, I can download the root certificate and use it for all regions. If not, I download a certificate that is specific to the region where my database instance resides. I decide to download a bundle that contains the old and new root certificates:

Next, I update my client applications to use the new certificates. This process is specific to each app and each database client library, so I don’t have any details to share.

Once the client application has been updated, I change the certificate authority (CA) to rds-ca-2019. I can Modify the instance in the console, and select the new CA:

I can also do this via the CLI:

$ aws rds modify-db-instance --db-instance-identifier database-1 \
  --ca-certificate-identifier rds-ca-2019

The change will take effect during the next maintenance window. I can also apply it immediately:

$ aws rds modify-db-instance --db-instance-identifier database-1 \
  --ca-certificate-identifier rds-ca-2019 --apply-immediately

After my instance has been rebooted (either immediately or during the maintenance window), I test my application to ensure that it continues to work as expected.

If I am not using SSL and want to avoid a restart, I use --no-certificate-rotation-restart:

$ aws rds modify-db-instance --db-instance-identifier database-1 \
  --ca-certificate-identifier rds-ca-2019 --no-certificate-rotation-restart

The database engine will pick up the new certificate during the next planned or unplanned restart.

I can also use the RDS ModifyDBInstance API function or a CloudFormation template to change the certificate authority.

Once again, all of this must be completed by March 5, 2020 or your applications may be unable to connect to your database instance using SSL or TLS.

Things to Know
Here are a couple of important things to know:

Amazon Aurora ServerlessAWS Certificate Manager (ACM) is used to manage certificate rotations for this database engine, and no action is necessary.

Regions – Rotation is needed for database instances in all commercial AWS regions except Asia Pacific (Hong Kong), Middle East (Bahrain), and China (Ningxia).

Cluster Scaling – If you add more nodes to an existing cluster, the new nodes will receive the CA-2019 certificate if one or more of the existing nodes already have it. Otherwise, the CA-2015 certificate will be used.

Learning More
Here are some links to additional information:



Amazon at CES 2020 – Connectivity & Mobility

Post Syndicated from Jeff Barr original

The Consumer Electronics Show (CES) starts tomorrow. Attendees will have the opportunity to learn about the latest and greatest developments in many areas including 5G, IoT, Advertising, Automotive, Blockchain, Health & Wellness, Home & Family, Immersive Entertainment, Product Design & Manufacturing, Robotics & Machine Intelligence, and Sports.

Amazon at CES
If you will be traveling to Las Vegas to attend CES, I would like to invite you to visit the Amazon Automotive exhibit in the Las Vegas Convention Center. Come to booth 5616 to learn about our work to help auto manufacturers and developers create the next generation of software-defined vehicles:

As you might know, this industry is working to reinvent itself, with manufacturers expanding from designing & building vehicles to a more expansive vision that encompasses multiple forms of mobility.

At the booth, you will find multiple demos that are designed to show you what is possible when you mashup vehicles, connectivity, software, apps, sensors, and machine learning in new ways.

Cadillac Customer Journey – This is an interactive, immersive demo of a data-driven shopping experience to engage customers at every touchpoint. Powered by ZeroLight and running on AWS, the demo uses 3D imagery that is generated in real time on GPU-equipped EC2 instances.

Future Mobility – This demo uses the Alexa Auto SDK and several AWS Machine Learning services to create an interactive in-vehicle assistant. It stores driver profiles in the cloud, and uses Amazon Rekognition to load the proper profile for the driver. Machine learning is used to detect repeated behaviors, such as finding the nearest coffee shop each morning.

Rivian Alexa – This full-vehicle demo showcases the deep Alexa Auto SDK integration that Rivian is using to control core vehicle functions on their upcoming R1T Electric Truck.

Smart Home / Garage – This demo ensemble showcases several of the Alexa home-to-car and car-to-home integrations, and features multiple Amazon & Alexa offerings including Amazon Pay, Fire TV, and Ring.

Karma Automotive / Blackberry QNX – Built on AWS IoT and machine learning inference models developed using Amazon SageMaker, this demo includes two use cases. The first one shows how data from Karma‘s fleet of electric vehicles is used to predict the battery state of health. The second one shows how cloud-trained models run at the edge (in the vehicle) to detect gestures that control vehicle functions.

Accenture Personalized Connected Vehicle Adventure – This demo shows how identity and personalization can be used to create unique transportation experiences. The journeys are customized using learned preferences and contextual data gathered in real time, powered by Amazon Personalize.

Accenture Data Monetization – This demo tackles data monetization while preserving customer privacy. Built around a data management reference architecture that uses Amazon QLDB and AWS Data Exchange, the demo enables consent and value exchange, with a focus on insights, predictions, and recommendations.

Denso Connected Vehicle Reference System – CVRS is an intelligent, end-to-end mobility service built on the AWS Connected Vehicle Solution. It uses a layered architecture that combines edge and cloud components, to allow mobility service providers to build innovative products without starting from scratch.

WeRide – This company runs a fleet of autonomous vehicles in China. The ML training to support the autonomy runs on AWS, as does the overall fleet management system. The demo shows how the AWS cloud supports their connected & autonomous fleet.

Dell EMC / National Instruments – This jointly developed demo focuses on the Hardware-in-Loop phase of autonomous vehicle development, where actual vehicle hardware running in real-world conditions is used.

Unity – This demo showcases a Software-in-Loop autonomous vehicle simulation built with Unity. An accurate, photorealistic representation of Berlin, Germany is used, with the ability to dynamically vary parameters such as time, weather, and scenery. Using the Unity Simulation framework and AWS, 100 permutations of each scene are generated and used as training data in parallel.

Get in Touch
If you are interested in learning more about any of these demos or if you are ready to build a connected or autonomous vehicle solution of your own, please feel free to contact us.


Celebrating AWS Community Leaders at re:Invent 2019

Post Syndicated from Jeff Barr original

Even though cloud computing is a global phenomenon, location still matters when it comes to community. For example, customers regularly tell me that they are impressed by the scale, enthusiasm, and geographic reach of the AWS User Group Community. We are deeply appreciative of the work that our user group and community leaders do.

Each year, leaders of local communities travel to re:Invent in order to attend a series of events designed to meet their unique needs. They attend an orientation session, learn about We Power Tech (“Building a future of tech that is diverse, inclusive and accessible”), watch the keynotes, and participate in training sessions as part of a half-day AWS Community Leader workshop. After re:Invent wraps up, they return to their homes and use their new knowledge and skills to do an even better job of creating and sharing technical content and of nurturing their communities.

Community Leadership Grants
In order to make it possible for more community leaders to attend and benefit from re:Invent, we launched a grant program in 2018. The grants covered registration, housing, and flights and were awarded to technologists from emerging markets and underrepresented communities.

Several of the recipients went on to become AWS Heroes, and we decided to expand the program for 2019. We chose 17 recipients from 14 countries across 5 continents, with an eye toward recognizing those who are working to build inclusive AWS communities. Additionally, We Power Tech launched a separate Grant Program with Project Alloy to help support underrepresented technologists in the first five years of their careers to attend re:Invent by covering conference registration, hotel, and airfare. In total, there were 102 grantees from 16 countries.

The following attendees received Community Leadership Grants and were able to attend re:Invent:

Ahmed Samir – Riyadh, KSA (LinkedIn, Twitter) – Ahmed is a co-organizer of the AWS Riyadh User Group. He is well known for his social media accounts in which he translates all AWS announcements to Arabic.

Veronique Robitaille – Valencia, Spain (LinkedIn, Twitter) – Veronique is an SA certified cloud consultant in Valencia, Spain. She is the co organizer of the AWS User Group in Valencia, and also translates AWS content into Spanish.

Dzenana Dzevlan – Mostar, Bosnia (LinkedIn) – Dzenana is an electrical engineering masters student at the University of Sarajevo, and a co-organizer of the AWS User Group in Bosnia-Herzegovina.

Magdalena Zawada – Warsaw, Poland (LinkedIn) – Magdalena is a cloud consultant and co-organizer of the AWS User Group Poland.

Hiromi Ito – Osaka, Japan (Twitter) – Hiromi runs IT communities for women in Japan and elsewhere in Asia, and also contributes to JAWS-UG in Kansai. She is the founder of the Asian Woman’s Association Meetup in Singapore.

Lena Taupier – Columbus, Ohio, USA (LinkedIn) – Lena co-organizes the Columbus AWS Meetup, was on the organizing team for the 2018 and 2019 Midwest / Chicago AWS Community Days, and delivered a lightning talk on “Building Diverse User Communities” at re:Invent.

Victor Perez – Panama City, Panama (LinkedIn) – Victor founded the AWS Panama User Group after deciding that he wanted to make AWS Cloud the new normal for the country. He also created the AWS User Group Caracas.

Hiro Nishimura – New York, USA (LinkedIn, Twitter) – Hiro is an educator at heart. She founded AWS Newbies to teach beginners about AWS, and worked with LinkedIn to create video courses to introduce cloud computing to non-engineers.

Sridevi Murugayen –  Chennai, India (LinkedIn) – Sridevi is a core leader of AWS Community Day Chennai. She managed a diversity session at the Community Day, and is a regular presenter and participant in the AWS Chennai User Group.

Sukanya Mandal – Mumbai, India (LinkedIn) – Sukanya leads the PyData community in Mumbai, and also contributes to the AWS User Group there. She talked about “ML for IoT at the Edge” at the AWS Developer Lounge in the re:Invent 2019 Expo Hall.

Seohyun Yoon – Seoul, Korea (LinkedIn) – Seohyun is a founding member of the student division of the AWS Korea Usergroup (AUSG), one of the youngest active AWS advocates in Korea, and served as a judge for the re:Invent 2019 Non-Profit Hackathon for Good. Check out her hands-on AWS lab guides!

Farah Clara Shinta Rachmady – Jakarta, Indonesia (LinkedIn, Twitter) – Farah nurtures AWS Indonesia and other technical communities in Indonesia, and also organizes large-scale events & community days.

Sandy Rodríguez – Mexico City, Mexico (LinkedIn) – Sandy co-organized the AWS Mexico City User Group and focuses on making events great for attendees. She delivered a 20-minute session in the AWS Village Theater at re:Invent 2019. Her work is critical to the growth of the AWS community in Mexico.

Vanessa Alves dos Santos – São Paulo, Brazil (LinkedIn) – Vanessa is a powerful AWS advocate within her community. She helped to plan AWS Community Days Brazil and the AWS User Group in São Paulo.

The following attendees were chosen for grants, but were not able to attend due to issues with travel visas:

Ayeni Oluwakemi – Lagos, Nigeria (LinkedIn, Twitter) – Ayeni is the founder of the AWS User Group in Lagos, Nigeria. She is the organizer of AWSome Day in Nigeria, and writes for the Cloud Guru Blog.

Ewere Diagboya – Lagos, Nigeria (LinkedIn, Twitter) – Ewere is one of our most active advocates in Nigeria. He is very active in the DevOps and Cloud Computing community as educator, and also organizes the DevOps Nigeria Meetup.

Minh Ha – Hanoi, Vietnam – Minh grows the AWS User Group Vietnam by organizing in-person meetups and online events. She co-organized AWS Community Day 2018, runs hackathons, and co-organized SheCodes Vietnam.



AWS Links & Updates – Monday, December 9, 2019

Post Syndicated from Jeff Barr original

With re:Invent 2019 behind me, I have a fairly light blogging load for the rest of the month. I do, however, have a collection of late-breaking news and links that I want to share while they are still hot out of the oven!

AWS Online Tech Talks for December – We have 18 tech talks scheduled for the remainder of the month. You can lean about Running Kubernetes on AWS Fargate, What’s New with AWS IoT, Transforming Healthcare with AI, and much more!

AWS Outposts: Ordering and Installation Overview – This video walks you through the process of ordering and installing an Outposts rack. You will learn about the physical, electrical, and network requirements, and you will get to see an actual install first-hand.

NFL Digital Athlete – We have partnered with the NFL to use data and analytics to co-develop the Digital Athlete, a platform that aims to improve player safety & treatment, and to predict & prevent injury. Watch the video in this tweet to learn more:

AWS JPL Open Source Rover Challenge – Build and train a reinforcement learning (RL) model on AWS to autonomously drive JPL’s Open-Source Rover between given locations in a simulated Mars environment with the least amount of energy consumption and risk of damage. To learn more, visit the web site or watch the Launchpad Video.

Map for Machine Learning on AWS – My colleague Julien Simon created an awesome map that categories all of the ML and AI services. The map covers applied ML, SageMaker’s built-in environments, ML for text, ML for any data, ML for speech, ML for images & video, fraud detection, personalization & recommendation, and time series. The linked article contains a scaled-down version of the image; the original version is best!

Verified Author Badges for Serverless App Repository – The authors of applications in the Serverless Application Repository can now apply for a Verified Author badge that will appear next to the author’s name on the application card and the detail page.

Cloud Innovation Centers – We announced that we will open three more Cloud Innovation Centers in 2020 (one in Australia and two in Bahrain), bringing the global total to eleven.

Machine Learning Embark – This new program is designed to help companies transform their development teams into machine learning practitioners. It is based on our own internal experience, and will help to address and overcome common challenges in the machine learning journey. Read the blog post to learn more.



Check out The Amazon Builders’ Library – This is How We Do It!

Post Syndicated from Jeff Barr original

Amazon customers often tell us that they want to know more about how we build and run our business. On the retail side, they tour Amazon Fulfillment Centers and see how we we organize our warehouses. Corporate customers often ask about our Leadership Principles, and sometimes adopt (and then adapt) them for their own use. I regularly speak with customers in our Executive Briefing Center (EBC), and talk to them about working backwards, PRFAQs, narratives, bar-raising, accepting failure as part of long-term success, and our culture of innovation.

The same curiosity that surrounds our business surrounds our development culture. We are often asked how we design, build, measure, run, and scale the hardware and software systems that underlie, AWS, and our other businesses.

New Builders’ Library
Today I am happy to announce The Amazon Builders’ Library. We are launching with a collection of detailed articles that will tell you exactly how we build and run our systems, each one written by the senior technical leaders who have deep expertise in that part of our business.

This library is designed to give you direct access to the theory and the practices that underlie our work. Students, developers, dev managers, architects, and CTOs will all find this content to be helpful. This is the content that is “not sold in stores” and not taught in school!

The library is organized by category:

Architecture – The design decisions that we make when designing a cloud service that help us to optimize for security, durability, high availability, and performance.

Software Delivery & Operations – The process of releasing new software to the cloud and maintaining health & high availability thereafter.

Inside the Library
I took a quick look at two of the articles while writing this post, and learned a lot!

Avoiding insurmountable queue backlogs – Principal Engineer David Yanacek explores the ins and outs of message queues, exploring the benefits and the risks, including many of the failure modes that can arise. He talks about how queues are used to power AWS Lambda and AWS IoT Core, and describes the sophisticated strategies that are used to maintain responsive and to implement (in his words) “magical resource isolation.” David shares multiple patterns that are used to create asynchronous multitenant systems that are resilient, including use of multiple queues, shuffle sharding, delay queues, back-pressure, and more.

Challenges with distributed systems – Senior Principal Engineer Jacob Gabrielson discusses they many ways that distributed systems can fail. After defining three distinct types (offline, soft real-time, and hard real-time) of systems, he uses an analogy with Bizarro to explain why hard real-time systems are (again, in his words) “frankly, a bit on the evil side.” Building on an example based on Pac-Man, he adds some request/reply communication and enumerates all of the ways that it can succeed or fail. He discussed fate sharing and how it can be used to reduce the number of test cases, and also talks about many of the other difficulties that come with testing distributed systems.

These are just two of the articles; be sure to check out the entire collection.

More to Come
We’ve got a lot more content in the pipeline, and we are also interested in your stories. Please feel free to leave feedback on this post, and we’ll be in touch.



AWS Launches & Previews at re:Invent 2019 – Wednesday, December 4th

Post Syndicated from Jeff Barr original

Here’s what we announced today:

Amplify DataStore – This is a persistent, on-device storage repository that will help you to synchronize data across devices and to handle offline operations. It can be used as a standalone local datastore for web and mobile applications that have no connection to the cloud or an AWS account. When used with a cloud backend, it transparently synchronizes data with AWS AppSync.

Amplify iOS and Amplify Android – These open source libraries enable you can build scalable and secure mobile applications. You can easily add analytics, AI/ML, API (GraphQL and REST), datastore, and storage functionality to your mobile and web applications. The use case-centric libraries provide a declarative interface that enables you to programmatically apply best practices with abstractions. The libraries, along with the Amplify CLI, a toolchain to create, integrate, and manage the cloud services used by your applications, are part of the Amplify Framework.

Amazon Neptune Workbench – You can now query your graphs from within the Neptune Console using either Gremlin or SPARQL queries. You get a fully managed, interactive development environment that supports live code and narrative text within Jupyter notebooks. In addition to queries, the notebooks support bulk loading, query planning, and query profiling. To get started, visit the Neptune Console.

Amazon Chime Meetings App for Slack – This new app allows Slack users to start and join Amazon Chime online meetings from their Slack workspace channels and conversations. Slack users that are new to Amazon Chime will be auto-registered with Chime when they use the app for the first time, and can get access to all of the benefits of Amazon Chime meetings from their Slack workspace. Administrators of Slack workspaces can install the Amazon Chime Meetings App for Slack from the Slack App Directory. To learn more, visit this blog post.

HTTP APIs for Amazon API Gateway in Preview – This is a new API Gateway feature that will let you build cost-effective, high-performance RESTful APIs for serverless workloads using Lambda functions and other services with an HTTP endpoint. HTTP APIs are optimized for performance—they offer the core functionality of API Gateway at a cost savings of up to 70% compared to REST APIs in API Gateway. You will be able to create routes that map to multiple disparate backends, define & apply authentication and authorization to routes, set up rate limiting, and use custom domains to route requests to the APIs. Visit this blog post to get started.

Windows gMSA Support in ECS – Amazon Elastic Container Service (ECS) now supports Windows group Managed Service Account (gMSA), a new capability that allows you to authenticate and authorize your ECS-powered Windows containers with network resources using an Active Directory (AD). You can now easily use Integrated Windows Authentication with your Windows containers on ECS to secure services.



AWS Launches & Previews at re:Invent 2019 – Tuesday, December 3rd

Post Syndicated from Jeff Barr original

Whew, what a day. This post contains a summary of the announcements that we made today.

Launch Blog Posts
Here are detailed blog posts for the launches:

Other Launches
Here’s an overview of some launches that did not get a blog post. I’ve linked to the What’s New or product information pages instead:

EBS-Optimized Bandwidth Increase – Thanks to improvements to the Nitro system, all newly launched C5/C5d/C5n/C5dn, M5/M5d/M5n/M5dn, R5/R5d/R5n/R5dn, and P3dn instances will support 36% higher EBS-optimized instance bandwidth, up to 19 Gbps. In addition newly launched High Memory instances (6, 9, 12 TB) will also support 19 Gbps of EBS-optimized instance bandwidth, a 36% increase from 14Gbps. For details on each size, read more about Amazon EBS-Optimized Instances.

EC2 Capacity Providers – You will have additional control over how your applications use compute capacity within EC2 Auto Scaling Groups and when using AWS Fargate. You get an abstraction layer that lets you make late binding decisions on capacity, including the ability to choose how much Spot capacity that you would like to use. Read the What’s New to learn more.

Here’s an overview of the previews that we revealed today, along with links that will let you sign up and/or learn more (most of these were in Andy’s keynote):

AWS Wavelength – AWS infrastructure deployments that embed AWS compute and storage services within the telecommunications providers’ datacenters at the edge of the 5G network to provide developers the ability to build applications that serve end-users with single-digit millisecond latencies. You will be able to extend your existing VPC to a Wavelength Zone and then make use of EC2, EBS, ECS, EKS, IAM, CloudFormation, Auto Scaling, and other services. This low-latency access to AWS will enable the next generation of mobile gaming, AR/VR, security, and video processing applications. To learn more, visit the AWS Wavelength page.

Amazon Managed Apache Cassandra Service (MCS) – This is a scalable, highly available, and managed Apache Cassandra-compatible database service. Amazon Managed Cassandra Service is serverless, so you pay for only the resources you use and the service automatically scales tables up and down in response to application traffic. You can build applications that serve thousands of requests per second with virtually unlimited throughput and storage. To learn more, read New – Amazon Managed Apache Cassandra Service (MCS).

Graviton2-Powered EC2 Instances – New Arm-based general purpose, compute-optimized, and memory-optimized EC2 instances powered by the new Graviton2 processor. The instances offer a significant performance benefit over the 5th generation (M5, C5, and R5) instances, and also raise the bar on security. To learn more, read Coming Soon – Graviton2-Powered General Purpose, Compute-Optimized, & Memory-Optimized EC2 Instances.

AWS Nitro EnclavesAWS Nitro Enclaves will let you create isolated compute environments to further protect and securely process highly sensitive data such as personally identifiable information (PII), healthcare, financial, and intellectual property data within your Amazon EC2 instances. Nitro Enclaves uses the same Nitro Hypervisor technology that provides CPU and memory isolation for EC2 instances. To learn more, visit the Nitro Enclaves page. The Nitro Enclaves preview is coming soon and you can sign up now.

Amazon Detective – This service will help you to analyze and visualize security data at scale. You will be able to quickly identify the root causes of potential security issues or suspicious activities. It automatically collects log data from your AWS resources and uses machine learning, statistical analysis, and graph theory to build a linked set of data that will accelerate your security investigation. Amazon Detective can scale to process terabytes of log data and trillions of events. Sign up for the Amazon Detective Preview.

Amazon Fraud Detector – This service makes it easy for you to identify potential fraud that is associated with online activities. It uses machine learning and incorporates 20 years of fraud detection expertise from AWS and, allowing you to catch fraud faster than ever before. You can create a fraud detection model with a few clicks, and detect fraud related to new accounts, guest checkout, abuse of try-before-you-buy, and (coming soon) online payments. To learn more, visit the Amazon Fraud Detector page.

Amazon Kendra – This is a highly accurate and easy to use enterprise search service that is powered by machine learning. It supports natural language queries and will allow users to discover information buried deep within your organization’s vast content stores. Amazon Kendra will include connectors for popular data sources, along with an API to allow data ingestion from other sources. You can access the Kendra Preview from the AWS Management Console.

Contact Lens for Amazon Connect – This is a set of analytics capabilities for Amazon Connect that use machine learning to understand sentiment and trends within customer conversations in your contact center. Once enabled, specified calls are automatically transcribed using state-of-the-art machine learning techniques, fed through a natural language processing engine to extract sentiment, and indexed for searching. Contact center supervisors and analysts can look for trends, compliance risks, or contacts based on specific words and phrases mentioned in the call to effectively train agents, replicate successful interactions, and identify crucial company and product feedback. Sign up for the Contact Lens for Amazon Connect Preview.

Amazon Augmented AI (A2I) – This service will make it easy for you to build workflows that use a human to review low-confidence machine learning predictions. The service includes built-in workflows for common machine learning use cases including content moderation (via Amazon Rekognition) and text extraction (via Amazon Textract), and also allows you to create your own. You can use a pool of reviewers within your own organization, or you can access the workforce of over 500,000 independent contractors who are already performing machine learning tasks through Amazon Mechanical Turk. You can also make use of workforce vendors that are pre-screened by AWS for quality and adherence to security procedures. To learn more, read about Amazon Augmented AI (Amazon A2I), or visit the A2I Console to get started.

Amazon CodeGuru – This ML-powered service provides code reviews and application performance recommendations. It helps to find the most expensive (computationally speaking) lines of code, and gives you specific recommendations on how to fix or improve them. It has been trained on best practices learned from millions of code reviews, along with code from thousands of Amazon projects and the top 10,000 open source projects. It can identify resource leaks, data race conditions between concurrent threads, and wasted CPU cycles. To learn more, visit the Amazon CodeGuru page.

Amazon RDS Proxy – This is a fully managed database proxy that will help you better scale applications, including those built on modern serverless architectures, without worrying about managing connections and connection pools, while also benefiting from faster failover in the event of a database outage. It is highly available and deployed across multiple AZs, and integrates with IAM and AWS Secrets Manager so that you don’t have to embed your database credentials in your code. Amazon RDS Proxy is fully compatible with MySQL protocol and requires no application change. You will be able to create proxy endpoints and start using them in minutes. To learn more, visit the RDS Proxy page.


New – AWS Step Functions Express Workflows: High Performance & Low Cost

Post Syndicated from Jeff Barr original

We launched AWS Step Functions at re:Invent 2016, and our customers took to the service right away, using them as a core element of their multi-step workflows. Today, we see customers building serverless workflows that orchestrate machine learning training, report generation, order processing, IT automation, and many other multi-step processes. These workflows can run for up to a year, and are built around a workflow model that includes checkpointing, retries for transient failures, and detailed state tracking for auditing purposes.

Based on usage and feedback, our customers really like the core Step Functions model. They love the declarative specifications and the ease with which they can build, test, and scale their workflows. In fact, customers like Step Functions so much that they want to use them for high-volume, short-duration use cases such as IoT data ingestion, streaming data processing, and mobile application backends.

New Express Workflows
Today we are launching Express Workflows as an option to the existing Standard Workflows. The Express Workflows use the same declarative specification model (the Amazon States Language) but are designed for those high-volume, short-duration use cases. Here’s what you need to know:

Triggering – You can use events and read/write API calls associated with a long list of AWS services to trigger execution of your Express Workflows.

Execution Model – Express Workflows use an at-least-once execution model, and will not attempt to automatically retry any failed steps, but you can use Retry and Catch, as described in Error Handling. The steps are not checkpointed, so per-step status information is not available. Successes and failures are logged to CloudWatch Logs, and you have full control over the logging level.

Workflow Steps – Express Workflows support many of the same service integrations as Standard Workflows, with the exception of Activity Tasks. You can initiate long-running services such as AWS Batch, AWS Glue, and Amazon SageMaker, but you cannot wait for them to complete.

Duration – Express Workflows can run for up to five minutes of wall-clock time. They can invoke other Express or Standard Workflows, but cannot wait for them to complete. You can also invoke Express Workflows from Standard Workflows, composing both types in order to meet the needs of your application.

Event Rate – Express Workflows are designed to support a per-account invocation rate greater than 100,000 events per second. Accounts are configured for 6,000 events per second by default and we will, as usual, raise it on request.

Pricing – Standard Workflows are priced based on the number of state transitions. Express Workflows are priced based on the number of invocations and a GB/second charge based on the amount of memory used to track the state of the workflow during execution. While the pricing models are not directly comparable, Express Workflows will be far more cost-effective at scale. To learn more, read about AWS Step Functions Pricing.

As you can see, most of what you already know about Standard Workflows also applies to Express Workflows! You can replace some of your Standard Workflows with Express Workflows, and you can use Express Workflows to build new types of applications.

Using Express Workflows
I can create an Express Workflow and attach it to any desired events with just a few minutes of work. I simply choose the Express type in the console:

Then I define my state machine:

I configure the CloudWatch logging, and add a tag:

Now I can attach my Express Workflow to my event source. I open the EventBridge Console and create a new rule:

I define a pattern that matches PutObject events on a single S3 bucket:

I select my Express Workflow as the event target, add a tag, and click Create:

The particular event will occur only if I have a CloudTrail trail that is set up to record object-level activity:

Then I upload an image to my bucket, and check the CloudWatch Logs group to confirm that my workflow ran as expected:

As a more realistic test, I can upload several hundred images at once and confirm that my Lambda functions are invoked with high concurrency:

I can also use the new Monitoring tab in the Step Functions console to view the metrics that are specific to the state machine:

Available Now
You can create and use AWS Step Functions Express Workflows today in all AWS Regions!


New – Programmatic Access to EBS Snapshot Content

Post Syndicated from Jeff Barr original

EBS Snapshots are really cool! You can create them interactively from the AWS Management Console:

You can create them from the Command Line (create-snapshot) or by making a call to the CreateSnapshot function, and you can use the Data Lifecycle Manager (DLM) to set up automated snapshot management.

All About Snapshots
The snapshots are stored in Amazon Simple Storage Service (S3), and can be used to quickly create fresh EBS volumes as needed. The first snapshot of a volume contains a copy of every 512K block on the volume. Subsequent snapshots contain only the blocks that have changed since the previous snapshot. The incremental nature of the snapshots makes them very cost-effective, since (statistically speaking) many of the blocks on an EBS volume do not change all that often.

Let’s look at a quick example. Suppose that I create and format an EBS volume with 8 blocks (this is smaller than the allowable minimum size, but bear with me), copy some files to it, and then create my first snapshot (Snap1). The snapshot contains all of the blocks, and looks like this:

Then I add a few more files, delete one, and create my second snapshot (Snap2). The snapshot contains only the blocks that were modified after I created the first one, and looks like this:

I make a few more changes, and create a third snapshot (Snap3):

Keep in mind that the relationship between directories, files, and the underlying blocks is controlled by the file system, and is generally quite complex in real-world situations.

Ok, so now I have three snapshots, and want to use them to create a new volume. Each time I create a snapshot of an EBS volume, an internal reference to the previous snapshot is created. This allows CreateVolume to find the most recent copy of each block, like this:

EBS manages all of the details for me behind the scenes. For example, if I delete Snap2, the copy of Block 0 in the snapshot also deleted since the copy in Snap3 is newer, but the copy of Block 4 in Snap2 becomes part of Snap3:

By the way, the chain of backward references (Snap3 to Snap1, or Snap3 to Snap2 to Snap1) is referred to as the lineage of the set of snapshots.

Now that I have explained all this, I should also tell you that you generally don’t need to know this, and can focus on creating, using, and deleting snapshots!


Access to Snapshot Content
Today we are introducing a new set of functions that provide you with access to the snapshot content, as described above. These functions are designed for developers of backup/recovery, disaster recovery, and data management products & services, and will allow them to make their offerings faster and more cost-effective.

The new functions use a block index (0, 1, 2, and so forth), to identify a particular 512K block within a snapshot. The index is returned in the form of an encrypted token, which is meaningful only to the GetSnapshotBlock function. I have represented these tokens as T0, T1, and so forth below. The functions currently work on blocks of 512K bytes, with plans to support more block sizes in the future.

Here are the functions:

ListSnapshotBlocks – Identifies all of the blocks in a given snapshot as encrypted tokens. For Snap1, it would return [T0, T1, T2, T3, T4, T5, T6, T7] and for Snap2 it would return [T0, T4].

GetSnapshotBlock – Returns the content of a block. If the block is part of an encrypted snapshot, it will be returned in decrypted form.

ListChangedBlocks – Returns the list of blocks that have changed between two snapshots in a lineage, again as encrypted tokens. For Snap2 it would return [T0, T4] and for Snap3 it would return [T0, T5].

Like I said, these functions were built to address one specialized yet very important use case. Having said that, I am now highly confident that new and unexpected ones will pop up within 48 hours (feel free to share them with me)!

Available Now
The new functions are available now and you can start using them today in the US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), and Asia Pacific (Tokyo) Regions; they will become available in the remaining regions in the next few weeks. There is a charge for calls to the List and Get functions, and the usual KMS charges will apply when you call GetSnapshotBlock to access a block that is part of an encrypted snapshot.


Amazon EC2 Update – Inf1 Instances with AWS Inferentia Chips for High Performance Cost-Effective Inferencing

Post Syndicated from Jeff Barr original

Our customers are taking to Machine Learning in a big way. They are running many different types of workloads, including object detection, speech recognition, natural language processing, personalization, and fraud detection. When running on large-scale production workloads, it is essential that they can perform inferencing as quickly and as cost-effectively as possible. According to what they have told us, inferencing can account for up to 90% of the cost of their machine learning work.

New Inf1 Instances
Today we are launching Inf1 instances in four sizes. These instances are powered by AWS Inferentia chips, and are designed to provide you with fast, low-latency inferencing.

AWS Inferentia chips are designed to accelerate the inferencing process. Each chip can deliver the following performance:

  • 64 teraOPS on 16-bit floating point (FP16 and BF16) and mixed-precision data.
  • 128 teraOPS on 8-bit integer (INT8) data.

The chips also include a high-speed interconnect, and lots of memory. With 16 chips on the largest instance, your new and existing TensorFlow, PyTorch, and MxNet inferencing workloads can benefit from over 2 petaOPS of inferencing power. When compared to the G4 instances, the Inf1 instances offer up to 3x the inferencing throughput, and up to 40% lower cost per inference.

Here are the sizes and specs:

Instance Name
Inferentia Chips
vCPUsRAMEBS BandwidthNetwork Bandwidth
inf1.xlarge148 GiBUp to 3.5 GbpsUp to 25 Gbps
inf1.2xlarge1816 GiBUp to 3.5 GbpsUp to 25 Gbps
inf1.6xlarge42448 GiB3.5 Gbps25 Gbps
inf1.24xlarge1696192 GiB14 Gbps100 Gbps

The instances make use of custom Second Generation Intel® Xeon® Scalable (Cascade Lake) processors, and are available in On-Demand, Spot, and Reserved Instance form, or as part of a Savings Plan in the US East (N. Virginia) and US West (Oregon) Regions. You can launch the instances directly, and they will also be available soon through Amazon SageMaker and Amazon ECS, and Amazon Elastic Kubernetes Service.

Using Inf1 Instances
Amazon Deep Learning AMIs have been updated and contain versions of TensorFlow and MxNet that have been optimized for use in Inf1 instances, with PyTorch coming very soon. The AMIs contain the new AWS Neuron SDK, which contains commands to compile, optimize, and execute your ML models on the Inferentia chip. You can also include the SDK in your own AMIs and images.

You can build and train your model on a GPU instance such as a P3 or P3dn, and then move it to an Inf1 instance for production use. You can use a model natively trained in FP16, or you can use models that have been trained to 32 bits of precision and have AWS Neuron automatically convert them to BF16 form. Large models, such as those for language translation or natural language processing, can be split across multiple Inferentia chips in order to reduce latency.

The AWS Neuron SDK also allows you to assign models to Neuron Compute Groups, and to run them in parallel. This allows you to maximize hardware utilization and to use multiple models as part of Neuron Core Pipeline mode, taking advantage of the large on-chip cache on each Inferentia chip. Be sure to read the AWS Neuron SDK Tutorials to learn more!



AWS Outposts Now Available – Order Yours Today!

Post Syndicated from Jeff Barr original

We first discussed AWS Outposts at re:Invent 2018. Today, I am happy to announce that we are ready to take orders and install Outposts racks in your data center or colo facility.

Why Outposts?
This new and unique AWS offering is a comprehensive, single-vendor compute & storage solution that is designed to meet the needs of customers who need local processing and very low latency. You no longer need to spend time creating detailed hardware specifications, soliciting & managing bids from multiple disparate vendors, or racking & stacking individual servers. Instead, you place your order online, take delivery, and relax while trained AWS technicians install, connect, set up, and verify your Outposts.

Once installed, we take care of monitoring, maintaining, and upgrading your Outposts. All of the hardware is modular and can be replaced in the field without downtime. When you need more processing or storage, or want to upgrade to newer generations of EC2 instances, you can initiate the request with a couple of clicks and we will take care of the rest.

Everything that you and your team already know about AWS still applies. You use the same APIs, tools, and operational practices. You can create a single deployment pipeline that target your Outposts and your cloud-based environments, and you can create hybrid architectures that span both.

Each Outpost is connected to and controlled by a specific AWS Region. The region treats a collection of up to 16 racks at a single location as a unified capacity pool. The collection can be associated with subnets of one or more VPCs in the parent region.

Outposts Hardware
The Outposts hardware is the same as what we use in our own data centers, with some additional security devices. The hardware is designed for reliability & efficiency, with redundant network switches and power supplies, and DC power distribution. Outpost racks are 80″ tall, 24″ wide, 48″ deep, and can weigh up to 2000 lbs. They arrive fully assembled, and roll in on casters, ready for connection to power and networking.

To learn more about the Outposts hardware, watch my colleague Anthony Liguori explain it:

Outposts supports multiple Intel®-powered Nitro-based EC2 instance types including C5, C5d, M5, M5d, R5, R5d, G4, and I3en. You can choose the mix of types that is right for your environment, and you can add more later. You will also be able to upgrade to newer instance types as they become available.

On the storage side, Outposts support EBS gp2 (general purpose SSD) storage, with a minimum size of 2.7 TB.

Outpost Networking
Each Outpost has a pair of networking devices, each with 400 Gbps of connectivity and support for 1 GigE, 10 GigE, 40 GigE, and 100 Gigabit fiber connections. The connections are used to host a pair of Link Aggregation Groups, one for the link to the parent region, and another to your local network. The link to the parent region is used for control and VPC traffic; all connections originate from the Outpost. Traffic to and from your local network flows through a Local Gateway (LGW), giving you full control over access and routing. Here’s an overview of the networking topology within your premises:

You will need to allocate a /26 CIDR block to each Outpost, which is advertised as a pair of /27 blocks in order to protect against device and link failures. The CIDR block can be within your own range of public IP addresses, or it can be an RFC 1918 private address plus NAT at your network edge.

Outposts are simply new subnets on an existing VPC in the parent region. Here’s how to create one:

$ aws ec2 create-subnet --vpc-id VVVVVV \
  --cidr-block A.B.C.D/24 \
  --outpost-arn arn:aws:outposts:REGION:ACCOUNT_ID:outpost:OUTPOST_ID 

If you have Cisco or Juniper hardware in your data center, the following guides will be helpful:

CiscoOutposts Solution Overview.

JuniperAWS Outposts in a Juniper QFX-Based Datacenter.

In most cases you will want to use AWS Direct Connect to establish a connection between your Outposts and the parent AWS Region. For more information on this and to learn a lot more about how to plan your Outposts network model, consult the How it Works documentation.

Outpost Services
We are launching with support for Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS), Amazon Virtual Private Cloud, Amazon ECS, Amazon Elastic Kubernetes Service, and Amazon EMR, with additional services in the works. Amazon RDS for PostgreSQL and Amazon RDS for MySQL are available in preview form.

Your applications can also make use of any desired services in the parent region, including Amazon Simple Storage Service (S3), Amazon DynamoDB, Auto Scaling, AWS CloudFormation, Amazon CloudWatch, AWS CloudTrail, AWS Config, Load Balancing, and so forth. You can create and use Interface Endpoints from within the VPC, or you can access the services through the regional public endpoints. Services & applications in the parent region that launch, manage, or refer to EC2 instances or EBS volumes can operate on those objects within an Outpost with no changes.

Purchasing an Outpost
The process of purchasing an Outpost is a bit more involved than that of launching an EC2 instance or creating an S3 bucket, but it should be straightforward. I don’t actually have a data center, and won’t actually take delivery of an Outpost, but I’ll do my best to show you the actual experience!

The first step is to describe and qualify my site. I enter my address:

I confirm temperature, humidity, and airflow at the rack position, that my loading dock can accommodate the shipping crate, and that there’s a clear access path from the loading dock to the rack’s final resting position:

I provide information about my site’s power configuration:

And the networking configuration:

After I create the site, I create my Outpost:

Now I am ready to order my hardware. I can choose any one of 18 standard configurations, with varied amounts of compute capacity and storage (custom configurations are also available), and click Create order to proceed:

The EC2 capacity shown above indicates the largest instance size of a particular type. I can launch instances of that size, or I can use the smaller sizes, as needed. For example, the the capacity of the OR-HUZEI16 configuration that I selected is listed as 7 m5.24xlarge instances and 3 c5.24xlarge instances. I could launch a total of 10 instances in those sizes, or (if I needed lots of smaller ones) I could launch 168 m5.xlarge instances and 72 c5.xlarge instances. I could also use a variety of sizes, subject to available capacity and the details of how the instances are assigned to the hardware.

I confirm my order, choose the Outpost that I created earlier, and click Submit order:

My order will be reviewed, my colleagues might give me a call to review some details, and my Outpost will be shipped to my site. A team of AWS installers will arrive to unpack & inspect the Outpost, transport it to its resting position in my data center, and work with my data center operations (DCO) team to get it connected and powered up.

Once the Outpost is powered up and the network is configured, it will set itself up automatically. At that point I can return to the console and monitor capacity exceptions (situations where demand exceeds supply), capacity availability, and capacity utilization:

Using an Outpost
The next step is to set up one or more subnets in my Outpost, as shown above. Then I can launch EC2 instances and create EBS volumes in the subnet, just as I would with any other VPC subnet.

I can ask for more capacity by selecting Increase capacity from the Actions menu:

The AWS team will contact me within 3 business days to discuss my options.

Things to Know
Here are a couple of other things to keep in mind when thinking about using Outposts:

Availability – Outposts are available in the following countries:

  • North America (United States)
  • Europe (All EU countries, Switzerland, Norway)
  • Asia Pacific (Japan, South Korea, Australia)

Support – You must subscribe to AWS Enterprise Support in order to purchase an Outpost. We will remotely monitor your Outpost, and keep it happy & healthy over time. We’ll look for failing components and arrange to replace them without disturbing your operations.

Billing & Payment Options – You can purchase Outposts on a three-year term, with All Upfront, Partial Upfront, and No Upfront payment options. The purchase price covers all EC2 and EBS usage within the Outpost; other services are billed by the hour, with the EC2 and EBS portions removed. You pay the regular inter-AZ data transfer charge to move data between an Outpost and another subnet in the same VPC, and the usual AWS data transfer charge for data that exits to the Internet across the link to the parent region.

Capacity Expansion – Today, you can group up to 16 racks into a single capacity pool. Over time we expect to allow you to group thousands of racks together in this manner.

Stay Tuned
This is, like most AWS announcements, just the starting point. We have a lot of cool stuff in the works, and it is still Day One for AWS Outposts!



AWS Now Available from a Local Zone in Los Angeles

Post Syndicated from Jeff Barr original

AWS customers are always asking for more features, more bandwidth, more compute power, and more memory, while also asking for lower latency and lower prices. We do our best to meet these competing demands: we launch new EC2 instance types, EBS volume types, and S3 storage classes at a rapid pace, and we also reduce prices regularly.

AWS in Los Angeles
Today we are launching a Local Zone in Los Angeles, California. The Local Zone is a new type of AWS infrastructure deployment that brings select AWS services very close to a particular geographic area. This Local Zone is designed to provide very low latency (single-digit milliseconds) to applications that are accessed from Los Angeles and other locations in Southern California. It will be of particular interest to highly-demanding applications that are particularly sensitive to latency. This includes:

Media & Entertainment – Gaming, 3D modeling & rendering, video processing (including real-time color correction), video streaming, and media production pipelines.

Electronic Design Automation – Interactive design & layout, simulation, and verification.

Ad-Tech – Rapid decision making & ad serving.

Machine Learning – Fast, continuous model training; high-performance low-latency inferencing.

All About Local Zones
The new Local Zone in Los Angeles is a logical part of the US West (Oregon) Region (which I will refer to as the parent region), and has some unique and interesting characteristics:

Naming – The Local Zone can be accessed programmatically as us-west-2-lax-1a. All API, CLI, and Console access takes place through the us-west-2 API endpoint and the US West (Oregon) Console.

Opt-In – You will need to opt in to the Local Zone in order to use it. After opting in, you can create a new VPC subnet in the Local Zone, taking advantage of all relevant VPC features including Security Groups, Network ACLs, and Route Tables. You can target the Local Zone when you launch EC2 instances and other resources, or you can create a default subnet in the VPC and have it happen automatically.

Networking – The Local Zone in Los Angeles is connected to US West (Oregon) over Amazon’s private backbone network. Connections to the public internet take place across an Internet Gateway, giving you local ingress and egress to reduce latency. Elastic IP Addresses can be shared by a group of Local Zones in a particular geographic location, but they do not move between a Local Zone and the parent region. The Local Zone also supports AWS Direct Connect, giving you the opportunity to route your traffic over a private network connection.

Services – We are launching with support for seven EC2 instance types (T3, C5, M5, R5, R5d, I3en, and G4), two EBS volume types (io1 and gp2), Amazon FSx for Windows File Server, Amazon FSx for Lustre, Application Load Balancer, and Amazon Virtual Private Cloud. Single-Zone RDS is on the near-term roadmap, and other services will come later based on customer demand. Applications running in a Local Zone can also make use of services in the parent region.

Parent Region – As I mentioned earlier, the new Local Zone is a logical extension of the US West (Oregon) region, and is managed by the “control plane” in the region. API calls, CLI commands, and the AWS Management Console should use “us-west-2” or US West (Oregon).

AWS – Other parts of AWS will continue to work as expected after you start to use this Local Zone. Your IAM resources, CloudFormation templates, and Organizations are still relevant and applicable, as are your tools and (perhaps most important) your investment in AWS training.

Pricing & Billing – Instances and other AWS resources in Local Zones will have different prices than in the parent region. Billing reports will include a prefix that is specific to a group of Local Zones that share a physical location. EC2 instances are available in On Demand & Spot form, and you can also purchase Savings Plans.

Using a Local Zone
The first Local Zone is available today, and you can request access here:

In early 2020, you will be able opt in using the console, CLI, or by API call.

After opting in, I can list my AZs and see that the Local Zone is included:

Then I create a new VPC subnet for the Local Zone. This gives me transparent, seamless connectivity between the parent zone in Oregon and the Local Zone in Los Angeles, all within the VPC:

I can create EBS volumes:

They are, as usual, ready within seconds:

I can also see and use the Local Zone from within the AWS Management Console:

I can also use the AWS APIs, CloudFormation templates, and so forth.

Thinking Ahead
Local Zones give you even more architectural flexibility. You can think big, and you can think different! You now have the components, tools, and services at your fingertips to build applications that make use of any conceivable combination of legacy on-premises resources, modern on-premises cloud resources via AWS Outposts, resources in a Local Zone, and resources in one or more AWS regions.

In the fullness of time (as Andy Jassy often says), there could very well be more than one Local Zone in any given geographic area. In 2020, we will open a second one in Los Angeles (us-west-2-lax-1b), and are giving consideration to other locations. We would love to get your advice on locations, so feel free to leave me a comment or two!

Now Available
The Local Zone in Los Angeles is available now and you can start using it today. Learn more about Local Zones.



Amazon Redshift Update – Next-Generation Compute Instances and Managed, Analytics-Optimized Storage

Post Syndicated from Jeff Barr original

We launched Amazon Redshift back in 2012 (Amazon Redshift – The New AWS Data Warehouse). With tens of thousands of customers, it is now the world’s most popular data warehouse. Our customers enjoy consistently fast performance, support for complex queries, and transactional capabilities, all with industry-leading price-performance.

The original Redshift model establishes a fairly rigid coupling between compute power and storage capacity. You create a cluster with a specific number of instances, and are committed to (and occasionally limited by) the amount of local storage that is provided with each instance. You can access additional compute power with on-demand Concurrency Scaling, and you can use Elastic Resize to scale your clusters up and down in minutes, giving you the ability to adapt to changing compute and storage needs.

We think we can do even better! Today we are launching the next generation of Nitro-powered compute instances for Redshift, backed by a new managed storage model that gives you the power to separately optimize your compute power and your storage. This launch takes advantage of some architectural improvements including high-bandwidth networking, managed storage that uses local SSD-based storage backed by Amazon Simple Storage Service (S3), and multiple, advanced data management techniques to optimize data motion to and from S3.

Together, these capabilities allow Redshift to deliver 3x the performance of any other cloud data warehouse service, and most existing Amazon Redshift customers using Dense Storage (DS2) instances will get up to 2x better performance and 2x more storage at the same cost.

Among many other use cases, this new combo is a great fit for operational analytics, where much of the workload is focused on a small (and often recent) subset of the data in the data warehouse. In the past, customers would unload older data to other types of storage in order to stay within storage limits, leading to additional complexity and making queries on historical data very complex.

Next-Generation Compute Instances
The new RA3 instances are designed to work hand-in-glove with the new managed storage model. The ra3.16xlarge instances have 48 vCPUs, 384 GiB of Memory, and up to 64 TB of storage. I can create clusters with 2 to 128 instances, giving me over 8 PB of compressed storage:

I can also create a new RA3-powered cluster from a snapshot of an existing cluster, or I can use Classic resize to upgrade my cluster to use the new instance type.

If you have an existing snapshot or a cluster, you can use the Amazon Redshift console to get a recommended RA3 configuration when you restore or resize. You can also get recommendations from the DescribeNodeConfigurationOptions function or the describe-node-configuration-options command.

Managed, Analytics-Optimized Storage
The new managed storage is equally exciting. There’s a cache of large-capacity, high-performance SSD-based storage on each instance, backed by S3, for scale, performance, and durability. The storage system uses multiple cues, including data block temperature, data blockage, and workload patterns, to manage the cache for high performance. Data is automatically placed into the appropriate tier, and you need not do anything special to benefit from the caching or the other optimizations. You pay the same low price for SSD and S3 storage, and you can scale the storage capacity of your data warehouse without adding and paying for additional instances.

Price & Availability
You can start using RA3 instances together with managed storage in all AWS Regions where Redshift is available.



Coming Soon – Graviton2-Powered General Purpose, Compute-Optimized, & Memory-Optimized EC2 Instances

Post Syndicated from Jeff Barr original

We launched the first generation (A1) of Arm-based, Graviton-powered EC2 instances at re:Invent 2018. Since that launch, thousands of our customers have used them to run many different types of scale-out workloads including containerized microservices, web servers, and data/log processing.

The Operating System Vendors (OSV) and Independent Software Vendor (ISV) communities have been quick to embrace the Arm architecture and the A1 instances. You have your pick of multiple Linux & Unix distributions including Amazon Linux 2, Ubuntu, Red Hat, SUSE, Fedora, Debian, and FreeBSD:

You can also choose between three container services (Docker, Amazon ECS, and Amazon Elastic Kubernetes Service), multiple system agents, and lots of developer tools (AWS Developer Tools, Jenkins, and more).

The feedback on these instances has been strong and positive, and our customers have told us that they are ready to use Arm-based servers on their more demanding compute-heavy and memory-intensive workloads.

Today I would like to give you a sneak peek at the next generation of Arm-based EC2 instances. These instances are built on AWS Nitro System and will be powered by the new Graviton2 processor. This is a custom AWS design that is built using a 7 nm (nanometer) manufacturing process. It is based on 64-bit Arm Neoverse cores, and can deliver up to 7x the performance of the A1 instances, including twice the floating point performance. Additional memory channels and double-sized per-core caches speed memory access by up to 5x.

All of these performance enhancements come together to give these new instances a significant performance benefit over the 5th generation (M5, C5, R5) of EC2 instances. Our initial benchmarks show the following per-vCPU performance improvements over the M5 instances:

  • SPECjvm® 2008: +43% (estimated)
  • SPEC CPU® 2017 integer: +44% (estimated)
  • SPEC CPU 2017 floating point: +24% (estimated)
  • HTTPS load balancing with Nginx: +24%
  • Memcached: +43% performance, at lower latency
  • X.264 video encoding: +26%
  • EDA simulation with Cadence Xcellium: +54%

Based on these results, we are planning to use these instances to power Amazon EMR, Elastic Load Balancing, Amazon ElastiCache, and other AWS services.

The new instances raise the already-high bar on AWS security. Building on the existing capabilities of the AWS Nitro System, memory on the instances is encrypted with 256-bit keys that are generated at boot time, and which never leave the server.

We are working on three types of Graviton2-powered EC2 instances (the d suffix indicates NVMe local storage):

General Purpose (M6g and M6gd) – 1-64 vCPUs and up to 256 GiB of memory.

Compute-Optimized (C6g and C6gd) – 1-64 vCPUs and up to 128 GiB of memory.

Memory-Optimized (R6g and R6gd) – 1-64 vCPUs and up to 512 GiB of memory.

The instances will have up to 25 Gbps of network bandwidth, 18 Gbps of EBS-Optimized bandwidth, and will also be available in bare metal form. I will have more information to share with you in 2020.

M6g Preview
We are now running a preview of the M6g instances for testing on non-production workloads; if you are interested, please contact us.


Amazon Braket – Get Started with Quantum Computing

Post Syndicated from Jeff Barr original

Nearly a decade ago I wrote about the Quantum Compute Cloud on April Fool’s Day. The future has arrived and you now have the opportunity to write quantum algorithms and to run them on actual quantum computers. Here’s what we are announcing today:

Amazon Braket – A fully managed service that allows scientists, researchers, and developers to begin experimenting with computers from multiple quantum hardware providers in a single place. Bra-ket notation is commonly used to denote quantum mechanical states, and inspired the name of the service.

AWS Center for Quantum Computing – A research center adjacent to the California Institute of Technology (Caltech) that will bring together the world’s leading quantum computing researchers and engineers in order to accelerate development of quantum computing hardware and software.

Amazon Quantum Solutions LabA new program to connect AWS customers with quantum computing experts from Amazon and a very select set of consulting partners.

What’s Quantum Computing
Ordinary (classical) computers use collections of bits to represent their state. Each bit is definitively 0 or 1, and the number of possible states is 2n if you have n bits. 1 bit can be in either of 2 states, 2 bits can be in any one of 4 states, and so forth. A computer with 1 MiB of memory has 2(8*1048576) states, excluding CPU registers and external storage. This is a large number, but it is finite, and can be calculated.

Quantum computers use a more sophisticated data representation known as a qubit or quantum bit. Each qubit can exist in state 1 or 0, but also in superpositions of 1 and 0, meaning that the qubit simultaneously occupies both states. Such states can be specified by a two-dimensional vector that contains a pair of complex numbers, making for an infinite number of states. Each of the complex numbers is a probability amplitude, basically the odds that the qubit is a 0 or a 1, respectively.

A classical computer can be in just one of those 2n states at a given time, but a quantum computer can occupy all of them in parallel.

If you have been in IT for any length of time, you know that Moore’s Law has brought us to the point where it possible to manufacture memory chips that store 2 tebibytes (as I write this) on a thumb drive. The physical and chemical processes that make this possible are amazing, and well worth studying. Unfortunately, these processes do not apply directly to the manufacture of devices that contain qubits; as I write this, the largest quantum computers contain about 50 qubits. These computers are built on several different technologies, but seem to have two attributes in common: they are scarce, and they must be run in carefully controlled physical environments.

How it Works
Quantum computers work by manipulating the amplitudes of the state vector. To program a quantum computer, you figure out how many qubits you need, wire them together into a quantum circuit, and run the circuit. When you build the circuit, you set it up so that the correct answer is the most probable one, and all the rest are highly improbable. Whereas classical computers use Boolean logic and are built using NOT, OR, and AND gates, quantum computers use superposition and interference, and are built using quantum logic gates with new and exotic names (X, Y, Z, CNOT, Hadamard, Toffoli, and so forth).

This is a very young field: the model was first proposed in the early 1980s, followed shortly by the realization that a quantum computer could perform simulations of quantum mechanical systems that are impossible on a classical computer. Quantum computers have applications to machine learning, linear algebra, chemistry, cryptography, simulations of physics, search, and optimization. For example, Shor’s Algorithm shows how to efficiently factor integers of any size (this video has a really good explanation).

Looking Ahead
Today’s implementations of public key cryptography are secure because factoring large integers is computationally intensive. Depending on key length, the time to factor (and therefore break) keys ranges from months to forever (more than the projected lifetime of our universe). However, when a quantum computer with enough qubits is available, factoring large integers will become instant and trivial. Defining “enough” turns out to be far beyond what I can cover (or fully understand) in this blog post, and brings in to play the difference between logical and physical qubits, noise rates, error correction, and more!

You need to keep this in mind when thinking about medium-term encryption and data protection, and you need to know about post-quantum cryptography. Today, s2n (our implementation of the TLS/SLSL protocols) already includes two different key exchange mechanisms that are quantum-resistant. Given that it takes about a decade for a new encryption protocol to become widely available and safe to use, it is not too soon to look ahead to a time when large-scale quantum computers are available.

Quantum computing is definitely not mainstream today, but that time is coming. It is a very powerful tool that can solve certain types of problems that are difficult or impossible to solve classically. I suspect that within 40 or 50 years, many applications will be powered in part using services that run on quantum computers. As such, it is best to think of them like a GPU or a math coprocessor. They will not be used in isolation, but will be an important part of a hybrid classical/quantum solution.

Here We Are
Our goal is to make sure you know enough about quantum computing to start looking for some appropriate use cases and conducting some tests and experiments. We want to build a solid foundation that is firmly rooted in reality, and to work with you to move into a quantum-powered future.

Ok, with that as an explanation, let’s get into it!

Amazon Braket
This new service is designed to let you get some hands-on experience with qubits and quantum circuits. You can build and test your circuits in a simulated environment and then run them on an actual quantum computer. Amazon Braket is a fully managed AWS service, with security & encryption baked in at each level.

You can access Amazon Braket through a notebook-style interface:

The Python code makes use of the Amazon Braket SDK. You can create a quantum circuit with a single line of code (this is, according to my colleagues, a “maximally entangled Bell state between qubit 0 and qubit 1”):

bell = Circuit().h(0).cnot(0, 1)

And run it with another:

print(, s3_folder).result().measurement_counts())

In addition to the classically-powered simulation environment, Amazon Braket provides access to quantum computers from D-Wave, IonQ, and Rigetti. These devices have a couple of things in common: they are leading-edge tech, they are expensive to build and run, and they generally operate in a very extreme and specialized environment (supercooled or near-vacuum) that must be kept free of electrical, thermal, and magnetic noise. Taken together, I think it is safe to say that most organizations will never own a quantum computer, and will find the cloud-based on-demand model a better fit. It may well be the case that production-scale quantum computers are the first cloud-only technology.

The actual quantum computers are works of art, and I am happy to be able to share some cool pictures. Here’s the D-Wave 2000Q:

The Rigetti 16Q Aspen-4:

And the IonQ linear ion trap:

AWS Center for Quantum Computing
As I noted earlier, quantum computing is still a very young field; there’s a lot that we don’t know, and plenty of room for scientific and technological breakthroughs.

I am pleased to announce that we are forming the AWS Center for Quantum Computing. Located adjacent to the Caltech campus, our goal is to bring the world’s top talent together in order to accelerate development. We will be researching technology that might one day enable quantum computers to be mass-produced, while also working to identify applications that are best solved on quantum computers. Both of these are long-term challenges, and I look forward to watching the progress over the next decade or two.

Amazon Quantum Solutions Lab
We understand that this is a new and intriguing technology, and we know that you want to learn, build your skills, and make some plans to put quantum computing to use.

The Amazon Quantum Solutions Lab will allow you to tap into our own expertise and that of our consulting partners. Our goal is to work with you to find those practical uses, and to help you to build up your own “bench” of qualified quantum developers.

You will also be able to take advantage of research and collaboration opportunities at the Quantum Solutions Lab.

Quantum Computing Resources
Here are some of the reference materials that you might find useful. Some of this will make your head spin, but if I can understand even a little bit of it, then so can you:

The Quantum Computing Party Hasn’t Even Started Yet – A very gentle overview of the field.

Wikipedia – Quantum Computing – A good summary, with lots of links and diagrams.

How Quantum Computers Break Encryption | Shor’s Algorithm Explained – Helpful video. Skip ahead to 8:03 if you want the TL;DR.

Quantum Computation and Quantum Information – The definitive (so they say) textbook on the subject.

Quantum Computing for the Determined – A series of 22 short explanatory videos, starting with The Qubit.

Quantum Computing for the Very Curious – A long-form article by the author of the preceding videos.

Quantum Computing Expert Explains One Concept in 5 Levels of Difficulty – Like the title says, quantum computing explained to 5 different people.

Quantum Supremacy Using a Programmable Supercomputing Processor – An important result, and a major milestone that shows how a quantum computer can outperform a classical one for a particular type of problem. Be sure to read Scott Aaronson’s Supreme Quantum Supremacy FAQ as well.

This is What a 50-qubit Quantum Computer Looks Like – A stunning photo-essay of IBM’s 50-qubit computer.

Shtetl-Optimized – Professor Scott Aaronson has been researching, writing, and blogging about quantum computing for a very long time.



AWS Launches & Previews at re:Invent 2019 – Sunday, December 1st

Post Syndicated from Jeff Barr original

Here’s a summary of the launches and previews that were announced at Midnight Madness!


Here’s an overview of the previews that were announced, along with links that will let you sign up and/or learn more:

Amazon EventBridge Schema Registry – The schema registry stores the structure (schema) of Amazon EventBridge events and maps them to Java, Python, and Typescript bindings so that you can use the events as typed objects. You can add schemas to the registry yourself, or you can enable Schema Discovery to automatically capture and add schemas for all events sent to an event bus. To learn more, read Introducing Amazon EventBridge Schema Registry and Discovery in Preview.

AWS IoT SiteWise Preview – We are expanding the existing AWS IoT SiteWise preview, and are adding some new features. This service helps you to collect and organize data from your factories, wind farms, mines, and other large-scale production facilities & supply chains. You can create a virtual representation of your facility, monitor production performance metrics, and use AWS IoT SiteWise Monitor to visualize the data in real time. Your industrial equipment can communicate with AWS IoT SiteWise through a gateway or through native integration with AWS IoT Core. AWS IoT SiteWise supports OPC-UA and MQTT, along with direct access via the AWS IoT SiteWise API functions. To learn more, read the What’s New.

AWS IoT SiteWise Monitor -This new SaaS application lets you monitor and interact with the data collected and organized by AWS IoT SiteWise. You can visualize equipment data & view dashboards (here’s a sample):

To learn more, read the What’s New.


AWS DeepRacer Update – New Features & New Racing Opportunities

Post Syndicated from Jeff Barr original

I first wrote about AWS DeepRacer at this time last year, and described it as an opportunity for you to get some hands-on experience with Reinforcement Learning (RL). Along with the rest of the AWS team, I believe that you should always be improving your existing skills and building new ones.

We launched the AWS DeepRacer car and the AWS DeepRacer League so that you could have the opportunity to get experience and new skills in a fun, competitive environment. In less than a year, tens of thousands of developers have participated in hands-on and virtual races located all over the world. Their enthusiasm and energy have been inspiring, as has been the creativity. Earlier this month, Jungyoul Ku wrote about his DeepRacer Lap Timer (be sure to check out all of his videos and his code). The DeepRacer Slack Community has over 1000 racers, thanks to the efforts of AWS ML Hero Lyndon Leggate. Another AWS Community Hero, Cyrus Wong, runs the AWS DeepRacer Community Blog.

All of this enthusiasm and energy has spread to our partners and enterprise customers as well. APN Premier Partner Accenture has created one of the World’s Largest Private DeepRacer Leagues, spanning 30 global locations and 17 countries. We have seen that DeepRacer has sparked interest in machine learning from our enterprise customers, and has inspired them to start multiple production-grade ML projects.

Today I would like to tell you about the three ways that we are growing the DeepRacer program. We are adding more chances to compete at AWS events & at your own events, more chances to win, with new races including head-to-head multi-car competitions, and an upgraded DeepRacer car with new sensing capabilities.

Announcing AWS DeepRacer Evo
We are working to make the AWS DeepRacer car even more perceptive and powerful. The upcoming AWS DeepRacer Evo car will include a stereo camera and a Light Detection and Ranging (LIDAR) sensor. The added sensors will enable DeepRacer Evo to skillfully detect and respond to obstacles, including other DeepRacers. This will help you to learn even more about the exciting field of reinforcement learning, which is ideal for use in autonomous driving.

The new sensors will be available soon in virtual form for use in the new My Garage section of the DeepRacer Console. I’ll have more info about our production plans for AWS DeepRacer Evo, including a sensor upgrade kit for your existing DeepRacer car, in early 2020.

If you would like to be notified when the DeepRacer Evo car is available for purchase, sign up here.

New Racing Challenges & Opportunities
We are expanding the DeepRacer League in 2020. We’re adding 8 additional races in 5 countries as part of an expanded AWS Summit presence, and 18 additional virtual races. There will also be a track (and a race) at re:MARS 2020. As a result, you now have 30 opportunities to join us for an in-person AWS DeepRacer League Summit race, along with 24 Virtual Circuit races that you can join from anywhere in the world.

In addition to the existing time trial race, we are adding two new race types to give you some new RL challenges, and to give you the opportunity to experiment with different sensors:

Object Detection & Avoidance – Use the sensors to detect and (hopefully) avoid obstacles.

Head-to-Head Racing – Race against another DeepRacer that is on the same track. Do your best to avoid it while still turning in the best lap time.

Both of these new challenges will require you to construct really good reward functions and to carefully tune your hyperparameters! You will be able to create a customized sensor configuration in the new online Garage:

You will also have the ability to choose your own neural network topology:

Create Your Own Races
We are going to give you the ability to create your own virtual Community Races in the console. You will be able to organize competitions (and track progress) within your company, tech community, neighborhood, or friend list:

AWS DeepRacer at re:Invent
As I write this, the top 64 racers are preparing for the 2019 Championship Cup Knockouts that will take place at re:Invent 2019. Over 650 racers prepared for this race by building & training their models on the Championship Cup Warm-Up, with lap times as low as 5.35 seconds.

If you are planning to attend re:Invent, there’s a lot of DeepRacer action in the works. Here’s an overview:

DeepRacer League – The 22nd and final qualifying race will take place on December 2nd at the Quad in Aria.

DeepRacer Championship Cup at the MGM Grand Garden Arena – Six tracks will be open from Tuesday through Thursday, with time for open-play racing and opportunities for you to get hands-on time with an AWS DeepRacer Evo. The 64 fastest racers from around the world will compete and the fastest 3 will proceed to the on-stage finals at 8 AM on December 5th, before Werner’s keynote. The winner will get to lift the Championship Cup.

DeepRacer Expert Bootcamp – A joint effort by the AWS DeepRacer Community and AWS, this event is for developers who are serious about competing in the upcoming 2020 league.

DeepRacer Workshops – We will be hosting ten introductory workshops and one Under the Hood deep dive.

For more information on all of these events, take a look at the DeepRacer Events at re:Invent page!

AWS DeepRacer in 2020
We have a lot of exciting events planned for 2020, and I’ll share more information as soon as it becomes available. The AWS DeepRacer League will start in March 2020, and will include new tracks and other challenges designed to test your skills.


AWS Load Balancer Update – Lots of New Features for You!

Post Syndicated from Jeff Barr original

The AWS Application Load Balancer (ALB) and Network Load Balancer (NLB) are important parts of any highly available and scalable system. Today I am happy to share a healthy list of new features for ALB and NLB, all driven by customer requests.

Here’s what I have:

  • Weighted Target Groups for ALB
  • Least Outstanding Requests for ALB
  • Subnet Expansion for NLB
  • Private IP Address Selection for Internal NLB
  • Shared VPC Support for NLB

All of these features are available now and you can starting using them today!

It’s time for a closer look…

Weighted Target Groups for ALB
You can now use traffic weights for your ALB target groups; this will be very helpful for blue/green deployments, canary deployments, and hybrid migration/burst scenarios. You can register multiple target groups with any of the forward actions in your ALB routing rules, and associate a weight (0-999) with each one. Here’s a simple last-chance rule that sends 99% of my traffic to tg1 and the remaining 1% to tg2:

You can use this feature in conjunction with group-level target stickiness in order to maintain a consistent customer experience for a specified duration:

To learn more, read about Listeners for Your Load Balancers.

Least Outstanding Requests for ALB
You can now balance requests across targets based on the target with the lowest number of outstanding requests. This is especially useful for workloads with varied request sizes, target groups with containers & other targets that change frequently, and targets with varied levels of processing power, including those with a mix of instance types in a single auto scaling group. You can enable this new load balancing option by editing the attributes of an existing target group:

Enabling this option will disable any slow start; to learn more, read about ALB Routing Algorithms.

Subnet Expansion Support for NLB
You now have the flexibility to add additional subnets to an existing Network Load Balancer. This gives you more scaling options, and allows you to expand into newly opened Availability Zones while maintaining high availability. Select the NLB, and click Edit subnets in the Actions menu:

Then choose one or more subnets to add:

This is a good time to talk about multiple availability zones and redundancy. Since you are adding a new subnet, you want to make sure that you either have targets in it, or have cross-zone load balancing enabled.

Private IP Address Selection for Internal NLB
You can now select the private IPv4 address that is used for your internal-facing Network Load Balancer, on a per-subnet basis. This gives you additional control over network addressing, and removes the need to manually ascertain addresses and configure them into clients that do not support DNS-based routing:

You can also choose your own private IP addresses when you add additional subnets to an existing NLB.

Shared VPC Support for NLB
You can now create NLBs in shared VPCs. Using NLBs with VPC sharing, you can route traffic across subnets in VPCs owned by a centrally managed account in the same AWS Organization. You can also use NLBs to create an AWS PrivateLink service, which will enable users to privately access your services in the shared subnets from other VPCs or on-premises networks, without using public IPs or requiring the traffic to traverse the internet.



New – Use Tag Policies to Manage Tags Across Multiple AWS Accounts

Post Syndicated from Jeff Barr original

Shortly after we launched EC2, customers started asking for ways to identify, classify, or categorize their instances. We launched tagging for EC2 instances and other EC2 resources way back in 2010, and have added support for many other resource types over the years. We added the ability to tag instances and EBS volumes at creation time a few years ago, and also launched tagging APIs and a Tag Editor. Today, tags serve many important purposes. They can be used to identify resources for cost allocation, and to control access to AWS resources (either directly or via tags on IAM users & roles). In addition to these tools, we have also provided you with comprehensive recommendations on Tag Strategies, which can be used as the basis for the tagging standards that you set up for your own organization.

Beyond Good Intentions
All of these tools and recommendations create a strong foundation, and you might start to use tags with only the very best of intentions. However, as Jeff Bezos, often reminds us, “Good intentions don’t work, but mechanisms do.” Standardizing on names, values, capitalization, and punctuation is a great idea, but challenging to put in to practice. When tags are used to control access to resources or to divvy up bills, small errors can create big problems!

Today we are giving you a mechanism that will help you to implement a consistent, high-quality tagging discipline that spans multiple AWS accounts and Organizational Units (OUs) within an AWS Organization. You can now create and apply Tag Policies and apply them to any desired AWS accounts or OUs within your Organization, or to the the entire Organization. The policies at each level are aggregated into an effective policy for an account.

Each tag policy contains a set of tag rules. Each rule maps a tag key to the allowable values for the key. The tag policies are checked when you perform operations that affect the tags on an existing resource. After you set up your tag policies, you can easily discover tagged resources that do not conform.

Creating Tag Policies
Tag Policies are easy to use. I start by logging in to the AWS account that represents my Organization, and ensure that it has Tag policies enabled in the Settings:

Then I click Policies and Tag policies to create a tag policy for my Organization:

I can see my existing policies, and I click Create policy to make another one:

I enter a name and a description for my policy:

Then I specify the tag key, indicate if capitalization must match, and optionally enter a set of allowable values:

I have three options at this point:

Create Policy – Create a policy that advises me (via a report) of any noncompliant resources in the Root, OUs, and accounts that I designate.

Add Tag Key – Add another tag key to the policy.

Prevent Noncompliant Operations – Strengthen the policy so that it enforces the proper use of the tag by blocking noncompliant operations. To do this, I must also choose the desired resource types:

Then I click Create policy, and I am ready to move ahead. I select my policy, and can then attach it to the Root, or to any desired OUs or Accounts:

Checking Policy Compliance
Once I have created and attached a policy, I can visit the Tag policies page in the Resource Groups console to check on compliance:

I can also download a compliance report (CSV format), or request that a fresh one be generated:

Things to Know
Here are a couple of things to keep in mind:

Policy Inheritance – The examples above used the built-in inheritance system: Organization to OUs to accounts. I can also fine-tune the inheritance model in order to add or remove acceptable tag values, or to limit the changes that child policies are allowed to make. To learn more, read How Policy Inheritance Works.

Tag Remediation – As an account administrator, I can use the Resource Groups console to view the effective tag policy (after inheritance) so that I can take action to fix any non-compliant tags.

Tags for New Resources – I can use Org-level Service Control Policies or IAM policies to prevent the creation of new resources that are not tagged in accord with my organization’s internal standards (see Require a Tag Upon Resource Creation for an example policy).

Access – This new feature is available from the AWS Management Console, AWS Command Line Interface (CLI), and through the AWS SDKs.

Available Now
You can use Tag Policies today in all commercial AWS Regions, at no extra charge.


Welcome to AWS IoT Day – Eight Powerful New Features

Post Syndicated from Jeff Barr original

Just as we did for the recent AWS Storage Day, we are making several pre-re:Invent announcements related to AWS IoT. Here’s what I’ve got for you today:

Secure Tunneling – You can set up and use secure tunnels between devices, even if they are behind restrictive network firewalls.

Configurable Endpoints – You can create multiple AWS IoT endpoints within a single AWS account, and set up a unique feature configuration on each one.

Custom Domains for Configurable Endpoints – You can register your own domains and server certificates and use them to create custom AWS IoT Core endpoints.

Enhanced Custom Authorizers – You can now use callbacks to invoke your own authentication and authorization code for MQTT connections.

Fleet Provisioning – You can onboard large numbers of IoT devices to the cloud, providing each one with a unique digital identity and any required configuration on its first connection to AWS IoT Core.

Alexa Voice Service (AVS) Integration – You can reduce the cost of producing an Alexa built-in device by up to 50% and bring Alexa to devices that have very limited amounts of local processing power and storage.

Container Support for AWS IoT Greengrass – You can now deploy, run, and manage Docker containers and applications on your AWS IoT Greengrass-enabled devices. You can deploy containers and Lambda functions on the same device, and you can use your existing build tools and processes for your IoT work. To learn more, read about the Docker Application Deployment Connector.

Stream Manager for AWS IoT Greengrass – You can now build AWS IoT Greengrass applications that collect, process, and export streams of data from IoT devices. Your applications can do first-tier processing at the edge, and then route all or selected data to an Amazon Kinesis Data Stream or AWS IoT Analytics for cloud-based, second-tier processing. To learn more, read AWS IoT Greengrass Adds Docker Support and Streams Management at the Edge and Manage Data Streams on the AWS IoT Greengrass Core.

Let’s dive into these powerful new features!

Secure Tunneling
This feature addresses a very common customer request: the need to access, troubleshoot, and fix IoT devices that are behind a restrictive firewall. This feature is of special relevance to medical devices, utility meters, and specialized hardware with an IoT aspect.

You can set up a secure tunnel on port 443 that uses TLS 1.2 encryption, and then use a local proxy to move commands and data across the tunnel. There are three elements to this feature:

Management APIs – A new set of APIs allow you to open (OpenTunnel), close (CloseTunnel), list (ListTunnels), and describe (DescribeTunnels) secure tunnels. Opening a tunnel generates a tunnel id and a pair of client access tokens: one for the source device and another for the destination device.

Local Proxy – A proxy that runs on both ends of the connection, available [[here]] in open source form. For IoT-registered devices, the client access token is passed via MQTT to the device, which launches a local proxy on each device to initiate a connection to the tunneling service. The client access token and tunnel id are used to authenticate the connection for each source and destination device to the tunneling service.

Tunneling Service – This service implements the tunnel, and connects the source and destination devices.

I can use the AWS IoT Console to create and manage tunnels. I click on Manage and Tunnels, then Open New:

I give my tunnel a description, select a thing, configure a timeout, add a tag, and click Open New:

Then I download the client access tokens for the source and destination:

Custom Domains for Configurable Endpoints
This feature gives you the ability to create custom AWS IoT Core endpoints, each with their own DNS CNAME and server certificate. This allows you to keep your brand identity without any software updates.

To learn more, read Custom Domains.

Configurable Endpoints
This feature gives you additional control of your AWS IoT Endpoints by enabling you to customize aspects such as domain and authentication mechanism as well as create multiple endpoints in the same account. This allows you to migrate to AWS IoT while keeping your existing endpoints (perhaps hardwired into devices already out in the field) unchanged and maintaining backwards compatibility with hard-to-update devices in the field.

To learn more, read Configurable Endpoints.

Enhanced Custom Authorizers
This feature allows you to use our own identity and access management implementation to authenticate and authorize traffic to and from your IoT devices. It works with all protocols supported by AWS IoT Core, with support for identities based on a bearer token or on a username/password pair. The enhancement supports custom authentication & authorization over MQTT connections, and also includes simplified token passing for HTTP and WSS connections.

To learn more, read Custom Authorizers.

Fleet Provisioning
This feature makes it easy for you to onboard large fleets of IoT devices to AWS IoT Core. Instead of spending time and resources to uniquely configure each IoT devices at the time of manufacturing, you can now use AWS IoT Core’s fleet provisioning feature to get your generic devices uniquely configured when the device makes its first connection to AWS IoT Core. The configuration can include X.509 certificates, MQTT client identity, serial numbers, and so forth. Fleet Provisioning uses JSON templates that contain device-side configuration, cloud-side configuration, and a proof-of-trust criterion. Trust can be based on an attestable entity such as a bootstrap X.509 certificate, or a local connection to a branded mobile app or onboarding beacon.

To learn more, read the Fleet Provisioning Developer Guide.

Alexa Voice Service (AVS) Integration
This feature lowers the cost of producing an Alexa built-in device up to 50% by offloading compute & memory intensive audio workloads from a physical device to a new virtual Alexa built-in device in the cloud. This lets you integrate AVS on devices with less than 1 MB of RAM and ARM Cortex ‘M’ class microcontrollers (including the new NXP MCU-Based Solution for Alexa Voice Service) and brings Alexa to products such as light switches, thermostats, and small appliances. The devices can take advantage of the new AWS IoT Core features listed above, as well as existing AWS IoT features such as Over the Air (OTA) updates.

To learn more, read Introducing Alexa Voice Service (AVS) Integration for AWS IoT Core.