All posts by Shaun Ray

NEW – Machine Learning algorithms and model packages now available in AWS Marketplace

Post Syndicated from Shaun Ray original

At AWS, our mission is to put machine learning in the hands of every developer. That’s why in 2017 we launched Amazon SageMaker. Since then it has become one of the fastest growing services in AWS history, used by thousands of customers globally. Customers using Amazon SageMaker can use optimized algorithms offered in Amazon SageMaker, to run fully-managed MXNet, TensorFlow, PyTorch, and Chainer algorithms, or bring their own algorithms and models. When it comes to building their own machine learning model, many customers spend significant time developing algorithms and models that are solutions to problems that have already been solved.


Introducing Machine Learning in AWS Marketplace

I am pleased to announce the new Machine Learning category of products offered by AWS Marketplace, which includes over 150+ algorithms and model packages, with more coming every day. AWS Marketplace offers a tailored selection for vertical industries like retail (35 products), media (19 products), manufacturing (17 products), HCLS (15 products), and more. Customers can find solutions to critical use cases like breast cancer prediction, lymphoma classifications, hospital readmissions, loan risk prediction, vehicle recognition, retail localizer, botnet attack detection, automotive telematics, motion detection, demand forecasting, and speech recognition.

Customers can search and browse a list of algorithms and model packages in AWS Marketplace. Once customers have subscribed to a machine learning solution, they can deploy it directly from the SageMaker console, a Jupyter Notebook, the SageMaker SDK, or the AWS CLI. Amazon SageMaker protects buyers data by employing security measures such as static scans, network isolation, and runtime monitoring.

The intellectual property of sellers on the AWS Marketplace is protected by encrypting the algorithms and model package artifacts in transit and at rest, using secure (SSL) connections for communications, and ensuring role based access for deployment of artifacts. AWS provides a secure way for the sellers to monetize their work with a frictionless self-service process to publish their algorithms and model packages.


Machine Learning category in Action

Having tried to build my own models in the past, I sure am excited about this feature. After browsing through the available algorithms and model packages from AWS Marketplace, I’ve decided to try the Deep Vision vehicle recognition model, published by Deep Vision AI. This model will allow us to identify the make, model and type of car from a set of uploaded images. You could use this model for insurance claims, online car sales, and vehicle identification in your business.

I continue to subscribe and accept the default options of recommended instance type and region. I read and accept the subscription contract, and I am ready to get started with our model.

My subscription is listed in the Amazon SageMaker console and is ready to use. Deploying the model with Amazon SageMaker is the same as any other model package, I complete the steps in this guide to create and deploy our endpoint.

With our endpoint deployed I can start asking the model questions. In this case I will be using a single image of a car; the model is trained to detect the model, maker, and year information from any angle. First, I will start off with a Volvo XC70 and see what results I get:


{'result': [{'mmy': {'make': 'Volvo', 'score': 0.97, 'model': 'Xc70', 'year': '2016-2016'}, 'bbox': {'top': 146, 'left': 50, 'right': 1596, 'bottom': 813}, 'View': 'Front Left View'}]}

My model has detected the make, model and year correctly for the supplied image. I was recently on holiday in the UK and stayed with a relative who had a McLaren 570s supercar. The thought that crossed my mind as the gulf-wing doors opened for the first time and I was about to be sitting in the car, was how much it would cost for the insurance excess if things went wrong! Quite apt for our use case today.


{'result': [{'mmy': {'make': 'Mclaren', 'score': 0.95, 'model': '570S', 'year': '2016-2017'}, 'bbox': {'top': 195, 'left': 126, 'right': 757, 'bottom': 494}, 'View': 'Front Right View'}]}

The score (0.95) measures how confident the model is that the result is right. The range of the score is 0.0 to 1.0. My score is extremely accurate for the McLaren car, with the make, model and year all correct. Impressive results for a relatively rare type of car on the road. I test a few more cars given to me by the launch team who are excitedly looking over my shoulder and now it’s time to wrap up.

Within ten minutes, I have been able to choose a model package, deploy an endpoint and accurately detect the make, model and year of vehicles, with no data scientists, expensive GPU’s for training or writing any code. You can be sure I will be subscribing to a whole lot more of these models from AWS Marketplace throughout re:Invent week and trying to solve other use cases in less than 15 minutes!

Access for the machine learning category in AWS Marketplace can be achieved through the Amazon SageMaker console, or directly through AWS Marketplace itself. Once an algorithm or model has been successfully subscribed to, it is accessible via the console, SDK, and AWS CLI. Algorithms and models from the AWS Marketplace can be deployed just like any other model or algorithm, by selecting the AWS Marketplace option as your package source. Once you have chosen an algorithm or model, you can deploy it to Amazon SageMaker by following this guide.


Availability & Pricing

Customers pay a subscription fee for the use of an algorithm or model package and the AWS resource fee. AWS Marketplace provides a consolidated monthly bill for all purchased subscriptions.

At launch, AWS Marketplace for Machine Learning includes algorithms and models from Deep Vision AI Inc, Knowledgent, RocketML, Sensifai, Cloudwick Technologies, Persistent Systems, Modjoul, H2Oai Inc, Figure Eight [Crowdflower], Intel Corporation, AWS Gluon Model Zoos, and more with new sellers being added regularly. If you are interested in selling machine learning algorithms and model packages, please reach out to [email protected]



New – AWS Elemental MediaConnect for ingestion and distribution of video in the cloud.

Post Syndicated from Shaun Ray original

Before AWS, I worked at an organization that owned and operated their own sports TV channel that provided content by aggregating tens of venues worth of local sports feeds into one 24 hour TV channel. The infrastructure and logistics of operating a broadcast grade network on this scale were immense, and it always proved difficult and expensive to change and maintain.

This was not a localized problem, as media companies and aggregators face similar challenges with their own broadcast infrastructure. Consolidating feeds from the non-urban area via satellite trucks, distribute video streams to multiple regions and countries, all while maintaining reliability and broadcast capability is still a difficult task and requires capital investment.


Introducing AWS Elemental MediaConnect

AWS Elemental MediaConnect is a new service that makes it easy for broadcasters and other premium video customers to reliably ingest live video into the cloud and securely transmit it to multiple destinations through the AWS global network. AWS Elemental MediaConnect gives customers the reliability, security, and visibility that they are used to with satellite transmission, with the flexibility and cost-effective economics only possible with an internet-based transmission. It lets any customer, from a small video producer covering a local sporting event to a national broadcast television network with multiple 24×7 live TV channels, reliably ingest their content from sources outside the AWS cloud (like a sporting venue or a TV studio), and securely transmit it to multiple destinations with broadcast-grade reliability and operational visibility. These destinations can be a customer’s own AWS-based video processing systems or a destination on the internet.


What you need to know:

Broadcast Reliability – AWS Elemental MediaConnect is engineered to meet broadcast level reliability with optimizations to reduce jitter and buffering. MediaConnect solves this by offering customers a choice of video transmission protocols (like Real-Time Transport Protocol (RTP), RTP with forward error correction (FEC), and the Zixi protocol) that are used by video professionals to ensure reliability. MediaConnect uses the low latency, high bandwidth AWS global network to distribute and replicate feeds between AWS regions.

Industry-Grade Security – MediaConnect supports broadcasters’ requirements for security. It provides the option to encrypt streams using standard AES-256 encryption and stores keys securely using AWS Secrets Manager. Together with the replication feature of MediaConnect, which allows users to create multiple outputs, customers can securely syndicate their content to distributors inside and outside AWS.

Visibility & Operations – Finally, AWS Elemental MediaConnect gives video professionals visibility into the health of their content streams. With MediaConnect, they track the health of their mission-critical streams using a combination of quality of service (QoS) alarms, and real-time signal telemetry, with no additional setup. Furthermore, MediaConnect is tightly integrated with other AWS Elemental Media Services and CloudWatch, allowing for easy creation of dashboards and alarming.


AWS Elemental MediaConnect in Action

Today I will be setting up ShaunTV, a global video on demand platform just for me. I will be using a live feed from an on-premises media encoder that I wish to ingest into the cloud and distribute to multiple regions. This is similar to a traditional media broadcaster or regional aggregator who does this across several feeds. Getting started is as simple as creating a new video feed and connecting it to AWS Elemental MediaConnect.


Using the console, I create a new flow, where I define my ingest options. In this case, the AWS Elemental team are providing me with a video feed from one of their on-premises encoders. I choose a standard source and select the ingestion protocol. Zixi protocol is a commercial video distribution format that is used widely in the media industry and will be our source format for today. Providing a whitelisted CIDR block allows me to restrict access to my MediaConnect ingestion point.

From here I can choose to provide a decryption key, which will allow me to decode an encrypted stream. In this case, my stream is not encrypted and I continue to create the flow.

Next step is to turn on the flow and start receiving video! Now I want to do two things; using the built-in integration with other AWS services, I will connect my MediaConnect stream to AWS Elemental MediaLive which provides encoding to use with end device for my video feed. Second, I want to distribute my video from Europe (Dublin) to the US (Oregon) region so I can make ShaunTV global!

Granting entitlements allows me to generate an ARN (AWS Resource Number) that I can use to share with other AWS accounts which are hosted in the same region as our MediaConnect endpoint. I am using the same account, so we proceed to build a new flow using the entitled source option.

My ARN is now populated in my new flow, and I can push the flow live to watch my video in the US or distribute it to other AWS Elemental Services. You then send a single video stream to the ingest point, and MediaConnect will automatically replicate it to each of the specified destinations. You have access to real-time metrics from the ingest point, it’s easy to reroute flows on the fly from the AWS console or the MediaConnect API. We could distribute the video to many regions, on-premises locations, or third-party AWS accounts. We could build an entire video on demand platform with the other AWS Elemental Services. Unfortunately, space is limited and so is time with AWS re:Invent already underway, so I leave it to you to experiment from here!

Availability and Pricing

There are no upfront fees or minimum commitments; pay for data transferred using AWS Elemental MediaConnect plus an hourly price for each running flow. Available in 8 regions: US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), EU (Frankfurt, and EU (Ireland) regions.

NEW – AWS Marketplace makes it easier to govern software procurement with Private Marketplace

Post Syndicated from Shaun Ray original

Over six years ago, we launched AWS Marketplace with the ambitious goal of providing users of the cloud with the software applications and infrastructure they needed to run their business. Today, more than 200,000 AWS active customers are using software from AWS Marketplace from categories such as security, data and analytics, log analysis and machine learning. Those customers use over 650 million hours a month of Amazon EC2 for products in AWS Marketplace and have more than 950,000 active software subscriptions. AWS Marketplace offers 35 categories and more than 4,500 software listings from more than 1,400 Independent Software Vendors (ISVs) to help you on your cloud journey, no matter what stage of adoption you are up to.

Customers have told us that they love the flexibility and myriad of options that AWS Marketplace provides. Today, I am excited to announce we are offering even more flexibility for AWS Marketplace with the launch of Private Marketplace from AWS Marketplace.

Private Marketplace is a new feature that enables you to create a custom digital catalog of pre-approved products from AWS Marketplace. As an administrator, you can select products that meet your procurement policies and make them available for your users. You can also further customize Private Marketplace with company branding, such as logo, messaging, and color scheme. All controls for Private Marketplace apply across your entire AWS Organizations entity, and you can define fine-grained controls using Identity and Access Management for roles such as: administrator, subscription manager and end user.

Once you enable Private Marketplace, users within your AWS Organizations redirect to Private Marketplace when they sign into AWS Marketplace. Now, your users can quickly find, buy, and deploy products knowing they are pre-approved.


Private Marketplace in Action

To get started we need to be using a master account, if you have a single account, it will automatically be classified as a master account. If you are a member of an AWS Organizations managed account, the master account will need to enable Private Marketplace access. Once done, you can add subscription managers and administrators through AWS Identity and Access Management (IAM) policies.


1- My account meets the requirement of being a master, I can proceed to create a Private Marketplace. I click “Create Private Marketplace” and am redirected to the admin page where I can whitelist products from AWS Marketplace. To grant other users access to approve products for listing, I can use AWS Organizations policies to grant the AWSMarketplaceManageSubscriptions role.

2- I select some popular software and operating systems from the list and add them to Private Marketplace. Once selected we can now see our whitelisted products.

3- One thing that I appreciate, and I am sure that the administrators of their organization’s Private Marketplace will, is some customization to bring the style and branding inline with the company. In this case, we can choose the name, logo, color, and description of our Private Marketplace.

4- After a couple of minutes we have our freshly minted Private Marketplace ready to go, there is an explicit step that we need to complete to push our Private Marketplace live. This allows us to create and edit without enabling access to users.


5 -For the next part, we will switch to a member account and see what our Private Marketplace looks like.

6- We can see the five pieces of software I whitelisted and our customizations to our Private Marketplace. We can also see that these products are “Approved for Procurement” and can be subscribed to by our end users. Other products are still discoverable by our users, but cannot be subscribed to until an administrator whitelists the product.



Users in a Private Marketplace can launch products knowing that all products in their Private Marketplace comply with their company’s procurement policies. When users search for products in Private Marketplace, they can see which products are labeled as “Approved for Procurement” and quickly filter between their company’s catalog and the full catalog of software products in AWS Marketplace.


Pricing and Availability

Subscription costs remain the same as all products in AWS Marketplace once consumed. Private Marketplace from AWS Marketplace is available in all commercial regions today.




New – AWS Global Accelerator for Availability and Performance

Post Syndicated from Shaun Ray original

Having previously worked in an area where regulation required us to segregate user data by geography and abide by data sovereignty laws, I can attest to the complexity of running global workloads that need infrastructure deployed in multiple countries. Availability, performance, and failover all become a yak shave as you expand past your original data center. Customers have told us that they need to run in multiple regions, whether it is for availability, performance or regulation. They love that they can template their workloads through AWS CloudFormation, replicate their databases with Amazon DynamoDB Global Tables and deploy serverless workloads with AWS SAM. All of these capabilities can be executed in minutes and provide a global experience for your audience. Customers have also told us that they love the regional isolation that AWS provides to reduce blast radius and increase availability, but they would like some help with stitching together other parts of their applications.


Introducing AWS Global Accelerator

That’s why I am pleased to announce AWS Global Accelerator, a network service that enables organizations to seamlessly route traffic to multiple regions and improve availability and performance for their end users. AWS Global Accelerator uses AWS’s vast, highly available and congestion-free global network to direct internet traffic from your users to your applications running in AWS regions. With AWS Global Accelerator, your users are directed to your workload based on their geographic location, application health, and weights that you can configure. AWS Global Accelerator also allocates static Anycast IP addresses that are globally unique for your application and do not change, thus removing the need to update clients as your application scales. You can get started by provisioning your Accelerator and associating it with your applications running on: Network Load Balancers, Application Load Balancers, or Elastic IP addresses. AWS Global Accelerator then allocates two static Anycast IP addresses from the AWS network which serve as an entry point for your workloads. AWS Global Accelerator supports both TCP and UDP protocols, health checking of your target endpoints and will route traffic away from unhealthy applications. You can use an Accelerator in one or more AWS regions, providing increased availability and performance for your end users. Low-latency applications typically used by media, financial, and gaming organizations will benefit from Accelerator’s use of the AWS global network and optimizations between users and the edge network.

Image 1 – How it Works

Here’s what you need to know:

Static Anycast IPs – Global Accelerator uses Static IP addresses that serve as a fixed entry point to your applications hosted in any number of AWS Regions. These IP addresses are Anycast from AWS edge locations, meaning that these IP addresses are announced from multiple AWS edge locations, enabling traffic to ingress onto the AWS global network as close to your users as possible. You can associate these addresses to regional AWS resources or endpoints, such as Network Load Balancers, Application Load Balancers, and Elastic IP addresses. You don’t need to make any client-facing changes or update DNS records as you modify or replace endpoints. An Accelerator’s IP addresses are static and will serve as the front door for your user-facing applications.

AWS’s Global Network – Traffic routed through Accelerator traverses the well monitored, congestion free, redundant AWS global network (instead of the public internet). Clients route to the optimal region based on client location, health-checks, and configured weights. Traffic will enter through an AWS edge location that is advertising an Accelerator’s Anycast IP addresses, from where the request will be routed through an optimized path towards the application.

Client State – AWS Global Accelerator enables you to build applications that keep state as an essential requirement. Stateful applications route users to the same endpoint, after their initial connection. Global Accelerator achieves this through setting the SourceIP of the client requester as the identifier for maintaining state, irrespective of the port and protocol.


AWS Global Accelerator in Action

To get familiar with AWS Global Accelerator’s features I am going to use two EC2 hosted WordPress deployments that are behind an Application Load Balancer. To test the global nature of AWS Global Accelerator, I have deployed our application to Singapore and Tokyo regions. Image 3 illustrates our happy path. Traffic is sent from our client to the nearest edge location via the two Anycast IP address that the edge location is advertising. Our request routes through the AWS global network to the Accelerator which selects the closest healthy endpoint group. An Application Load Balancer terminates our request and passes it to the WordPress instance where our content is served from.

Image 2 – User Flow


I’ve created two content servers using the instructions found here. I have changed the home banners for the regions we will be serving our content from so that I can identify which path I am routed through. With our content servers created we build an Application Load Balancer for each and wait for them to become healthy and in-service.

Image 3 – Shaun’s Global Website

Creating the Global Accelerator is as simple as choosing a name, specifying the listener type (port 80 and TCP for WordPress) and creating some endpoint groups for each region. Let’s configure a listener for our Accelerator that clients connect to once onboard the edge network. As we are serving HTTP traffic, port 80 is a natural choice. I have enabled client affinity using SourceIP which redirects our test clients to the same region and application once they have connected for the first time.


Endpoint groups are targets for our Accelerator, by default each group has a traffic dial of 100. Turning down the traffic dial allows redirection of clients to other endpoint groups or another AWS region, handy for performing maintenance or dealing with an unexpected traffic surge. For our experiment, I choose the Tokyo and Singapore region with the default dial of 100.

Image 4 – Configuring endpoint groups

Health checks are a powerful tool that can be used either in a simple configuration or provide deep application awareness. Today I am serving a simple website using the default HTTP health check, polling for a 200 OK HTTP on the default path. To complete our configuration we need to populate our endpoint groups with the Application Load Balancers we created earlier.

Image 5 – Adding our ALB’s to an Endpoint Group

With everything configured we can start routing traffic through our two Anycast IP addresses assigned by the Accelerator. This can be done with your browser, an HTTP client or curl. As I want to test a global audience, I will use a proxy to set my location through various locations across Asia, America, and Europe to see how our traffic is routed.

Image 6 – Requests being distributed to our global website.

One of the most powerful features of AWS Global Accelerator is the ability to fail between regions in less than a minute. I’ve set up a load test to hit the site with 100 requests per second and will turn off the Singapore server to test how fast our traffic is routed through to our Tokyo endpoint.

Traffic starts routing through our Accelerator at 03:15, at 3:30 I shut down the Singapore instance. At 3:31 Tokyo has already processed close to 4,000 requests and is serving all the traffic. At 3:35 I enable the Singapore server. Because of the health check warm up (90 seconds), we don’t start seeing recovery until 3:38. If I had configured a more aggressive health check we would fail and recover within five minutes!

Availability and Pricing

In AWS Global Accelerator, you are charged for each accelerator that is deployed and the amount of traffic in the dominant direction that flows through the accelerator. An accelerator is the resource you create to direct traffic to optimal endpoints over the AWS global network. Customers will typically set up one accelerator for each application, but more complex applications may require more than one accelerator. For every accelerator that is running, you are charged a fixed hourly fee and an incremental charge over your standard Data Transfer rates, also called a Data Transfer-Premium fee (DT-Premium). DT-Premium is calculated every hour on the dominant direction of your traffic, i.e. inbound traffic to your application or outbound traffic from your application to your users on the internet.

Fixed fee: For every full or partial hour when an accelerator runs in your account, you are charged $0.025.
Data Transfer-Premium fee (DT-Premium): This is a rate per gigabyte of data transferred over the AWS network. The DT-Premium rate depends on the AWS Region (source) that serves the request and the AWS edge location (destination) where the responses are directed. You will only be charged DT-Premium in the dominant data transfer direction.

Destination (AWS edge locations)


(AWS Regions)

NA$ 0.015 /GB$ 0.015 /GB$ 0.035 /GB
EU$ 0.015 /GB$ 0.015 /GB$ 0.043 /GB
APAC$ 0.012 /GB$ 0.043 /GB$ 0.010 /GB

AWS Global Accelerator is available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) and Asia Pacific (Singapore).

New – Amazon Route 53 Resolver for Hybrid Clouds

Post Syndicated from Shaun Ray original

I distinctly remember the excitement I felt when I created my first Virtual Private Cloud (VPC) as a customer. I had just spent months building a similar environment on-premises and had been frustrated at the complicated setup. One of the immediate benefits that the VPC provided was a magical address at where our EC2 instances sent Domain Name Service (DNS) queries. It was reliable, scaled with our workloads, and resolved both public and private domains without any input from us.


Like a lot of customers, we connected our on-premises environment with our AWS one via Direct Connect (DX), leading to cases where DNS names required resolution across the connection. Back then we needed to build DNS servers and provide forwarders to achieve this. That’s why today I am very excited to announce Amazon Route 53 Resolver for Hybrid Clouds. It’s a set of features that enable bi-directional querying between on-premises and AWS over private connections.


Before I dive into the new functionality, I would like to provide a shout out to our old faithful .2 resolver. As part of our announcement today I would like to let you know that we have officially named the .2 DNS resolver – Route 53 Resolver, in honor of the trillions of queries the service has resolved on behalf of our customers. Route 53 Resolver continues to provide DNS query capability for your VPC, free of charge. To support DNS queries across hybrid environments, we are providing two new capabilities: Route 53 Resolver Endpoints for inbound queries and Conditional Forwarding Rules for outbound queries.


Route 53 Resolver Endpoints

Inbound query capability is provided by Route 53 Resolver Endpoints, allowing DNS queries that originate on-premises to resolve AWS hosted domains. Connectivity needs to be established between your on-premises DNS infrastructure and AWS through a Direct Connect (DX) or a Virtual Private Network (VPN). Endpoints are configured through IP address assignment in each subnet for which you would like to provide a resolver.


Conditional Forwarding Rules

Outbound DNS queries are enabled through the use of Conditional Forwarding Rules. Domains hosted within your on-premises DNS infrastructure can be configured as forwarding rules in Route 53 Resolver. Rules will trigger when a query is made to one of those domains and will attempt to forward DNS requests to your DNS servers that were configured along with the rules. Like the inbound queries, this requires a private connection over DX or VPN.


When combined, these two capabilities allow for recursive DNS lookup for your hybrid workloads. This saves you from the overhead of managing, operating and maintaining additional DNS infrastructre while operating both environments.


Route 53 Resolver in Action

1. Route 53 Resolver for Hybrid Clouds is region specific, so our first step is to choose the region we would like to configure our hybrid workloads. Once we have selected a region, we choose the query direction – outbound, inbound or both.


2. We have selected both inbound and outbound traffic for this workload. First up is our inbound query configuration. We enter a name and choose a VPC. We assign one or more subnets from within the VPC (in this case we choose two for availability). From these subnets we can assign specific IP addresses to use as our endpoints, or let Route 53 Resolver assign them automatically.

3. We create a rule for our on-premises domain so that workloads inside the VPC can route DNS queries to your DNS infrastructure. We enter one or more IP addresses for our on-premises DNS servers and create our rule.

4. Everything is created and our VPC is associated with our inbound and outbound rules and can start routing traffic. Conditional Forwarding Rules can be shared across multiple accounts using AWS Resource Access Manager.

Availability and Pricing

Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that. Route 53 Resolver for Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.