This Guidance helps you to create an environment where AWS customers can consume an Independent Software Vendor (ISV) Partner’s application within their own Amazon VPC, protecting the customer’s data while also protecting the Partner application’s implementation assets through isolated network access controls and subscription authorization.
Architecture Diagram

Step 1
ISV Partner write and package their model code as a Docker image and push the image into Amazon Elastic Container Registry (Amazon ECR).
Step 2
Partner packages/pushes the image as a machine learning (ML) model for listing on AWS Marketplace.
Step 3
Customer subscribes to the listing on AWS Marketplace.
Step 4
Upon subscription, an Amazon SageMaker instance is provisioned in the customer’s VPC in network isolation mode - along with the model container image and the invocation endpoint.
Step 5
Customer runs the AWS CloudFormation template that deploys the AWS Lambda functions from the zip file located in Amazon Simple Storage Service (Amazon S3) repository.
Step 6
Customer application invokes an Lambda Init endpoint to validate the subscription from the seller.
Step 7
Lambda Authorizer then invokes the Lambda function running in partner’s VPC to return an authorization token that is valid for certain duration.
Step 8
Customer application invokes Lambda request endpoint along with authorization token and the data to be processed.
Step 9
Lambda Authorizer validates the authorization token and forwards the call to the Lambda proxy.
Step 10
The Lambda proxy calls the SageMaker endpoint running in network isolation mode, along with the data to be processed.
Step 11
The SageMaker endpoint returns the response back to the Lambda function along with the processed data.
Step 12
Lambda stores the response in the Amazon S3 bucket for the buyer application to use.
Well-Architected Pillars

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational Excellence
You can make frequent, small, reversible changes by using the version published in the AWS Marketplace listing along with running the AWS CloudFormation script. Billing and logging details are also captured, making it easier to do any ‘post-mortem’ exercises.
-
Security
The seller’s code is running in network isolation mode, with proper separation of duties between buyer and seller applications. The seller data and the model are protected. The buyer does not have any permissions to access the SageMaker instance deployed using AWS Marketplace.
-
Reliability
SageMaker instances can be scaled horizontally, depending on the transaction capacity required by the seller workload.
-
Performance Efficiency
Resource provisioning and management is automated through serverless architecture (Lambda) and provisioning the seller Docker image through AWS Marketplace.
-
Cost Optimization
Expenditure and usage awareness is monitored via AWS Marketplace. The size of the SageMaker instance is based on the capacity needed by the buyer. On demand Lambda cost is based on number of transactions completed by the buyer application, whose usage can be governed in the AWS Cost Explorer by the buyer.
-
Sustainability
Workload is right-sized and implemented with an efficient design to ensure high utilization and to maximize the energy efficiency of the underlying SageMaker instance and its hardware.
Related Content

Deploy embedded services with privacy-safe controls on AWS
Amazon Web Services (AWS) customers across the advertising and marketing industry are seeking to further protect their customers’ information by limiting the movement and sharing of data outside of their control.
This post demonstrates how industry Partners are increasingly seeking to deploy embedded services within trusted compute environments to offer more capabilities for their customers’ AWS data.
Power Identity Translation with LiveRamp in Your VPC
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.