AWS prescriptive-guidance documentation change
Summary
Updated SageMaker branding (removed 'AI' suffix), fixed broken links, removed outdated topics section, corrected apostrophes, and updated blog post references.
Security assessment
Changes are primarily cosmetic (branding updates, typo fixes) and structural (removing obsolete topics section). No security vulnerabilities, patches, or weaknesses are mentioned. Deployment strategies discussed (blue/green, canary) focus on reliability and risk mitigation but aren't new security features.
Diff
diff --git a/prescriptive-guidance/latest/ml-operations-planning/deployment.md b/prescriptive-guidance/latest/ml-operations-planning/deployment.md index de72243b0..5edf5d85e 100644 --- a//prescriptive-guidance/latest/ml-operations-planning/deployment.md +++ b//prescriptive-guidance/latest/ml-operations-planning/deployment.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Planning for successful MLOps](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Planning for successful MLOps](introduction.html) @@ -15,11 +14,0 @@ Follow the best practices in this section to help address these challenges. -###### Topics - - * Automate the deployment cycle - - * Choose a deployment strategy - - * Consider your inference requirements - - - - @@ -30 +19 @@ The training and deployment process should be entirely automated to prevent huma -[Amazon SageMaker AI Pipelines](https://aws.amazon.com/sagemaker/pipelines/) and [AWS CodePipeline](https://aws.amazon.com/codepipeline/) help create CI/CD pipelines for ML projects. One of the advantages of using a CI/CD pipeline is that all code that is used to ingest data, train a model, and perform monitoring can be version controlled by using a tool such as [Git](https://git-scm.com/). Sometimes you have to retrain a model by using the same algorithm and hyperparameters, but different data. The only way to verify that you’re using the correct version of the algorithm is to use source control and tags. You can use the [default project templates](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-projects-templates-sm.html) provided by SageMaker AI as a starting point for your MLOps practice. +[Amazon SageMaker Pipelines](https://aws.amazon.com/sagemaker/pipelines/) and [AWS CodePipeline](https://aws.amazon.com/codepipeline/) help create CI/CD pipelines for ML projects. One of the advantages of using a CI/CD pipeline is that all code that is used to ingest data, train a model, and perform monitoring can be version controlled by using a tool such as [Git](https://git-scm.com/). Sometimes you have to retrain a model by using the same algorithm and hyperparameters, but different data. The only way to verify that you're using the correct version of the algorithm is to use source control and tags. You can use the [default project templates](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-projects-templates-sm.html) provided by SageMaker as a starting point for your MLOps practice. @@ -36 +25 @@ Part of the job of the CI/CD pipeline is to perform tests on what it is building -The extensive use of CI/CD pipelines also supports pull requests, which help prevent human error. When you use pull requests, every code change must be reviewed and approved by at least one other team member before it can go to production. Pull requests are also useful for identifying code that doesn’t adhere to business rules and for spreading knowledge within the team. +The extensive use of CI/CD pipelines also supports pull requests, which help prevent human error. When you use pull requests, every code change must be reviewed and approved by at least one other team member before it can go to production. Pull requests are also useful for identifying code that doesn't adhere to business rules and for spreading knowledge within the team. @@ -44 +33 @@ MLOps deployment strategies include blue/green, canary, shadow, and A/B testing. -Blue/green deployments are very common in software development. In this mode, two systems are kept running during development: blue is the old environment (in this case, the model that is being replaced) and green is the newly released model that is going to production. Changes can easily be rolled back with minimum downtime, because the old system is kept alive. For more in-depth information about blue/green deployments in the context of SageMaker, see the blog post [Safely deploying and monitoring Amazon SageMaker AI endpoints with AWS CodePipeline and AWS CodeDeploy](https://aws.amazon.com/blogs/machine-learning/safely-deploying-and-monitoring-amazon-sagemaker-endpoints-with-aws-codepipeline-and-aws-codedeploy/) on the AWS Machine Learning blog. +Blue/green deployments are very common in software development. In this mode, two systems are kept running during development: blue is the old environment (in this case, the model that is being replaced) and green is the newly released model that is going to production. Changes can easily be rolled back with minimum downtime, because the old system is kept alive. For more in-depth information about blue/green deployments in the context of SageMaker, see the blog post [Safely deploying and monitoring Amazon SageMaker endpoints with AWS CodePipeline and AWS CodeDeploy](https://aws.amazon.com/blogs/machine-learning/safely-deploying-and-monitoring-amazon-sagemaker-endpoints-with-aws-codepipeline-and-aws-codedeploy/) on the AWS Machine Learning blog. @@ -48 +37 @@ Blue/green deployments are very common in software development. In this mode, tw -Canary deployments are similar to blue/green deployments in that both keep two models running together. However, in canary deployments, the new model is rolled out to users incrementally, until all traffic eventually shifts over to the new model. As in blue/green deployments, risk is mitigated because the new (and potentially faulty) model is closely monitored during the initial rollout, and can be rolled back in case of issues. In SageMaker AI, you can specify initial traffic distribution by using the [InitialVariantWeight](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sagemaker-endpointconfig-productionvariant.html) API. +Canary deployments are similar to blue/green deployments in that both keep two models running together. However, in canary deployments, the new model is rolled out to users incrementally, until all traffic eventually shifts over to the new model. As in blue/green deployments, risk is mitigated because the new (and potentially faulty) model is closely monitored during the initial rollout, and can be rolled back in case of issues. In SageMaker, you can specify initial traffic distribution by using the [InitialVariantWeight](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sagemaker-endpointconfig-productionvariant.html) API`.` @@ -54 +43 @@ You can use shadow deployments to safely bring a model to production. In this mo -Shadow mode is useful when you don't need any user inference feedback. You can assess the quality of predictions by performing error analysis and comparing the new model with the old model, and you can monitor the output distribution to verify that it is as expected. To see how to do shadow deployment with SageMaker AI, see the blog post [Deploy shadow ML models in Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/deploy-shadow-ml-models-in-amazon-sagemaker/) on the AWS Machine Learning blog. +Shadow mode is useful when you don't need any user inference feedback. You can assess the quality of predictions by performing error analysis and comparing the new model with the old model, and you can monitor the output distribution to verify that it is as expected. To see how to do shadow deployment with SageMaker, see the blog post [Deploy shadow ML models in Amazon SageMaker](https://aws.amazon.com/blogs/machine-learning/deploy-shadow-ml-models-in-amazon-sagemaker/) on the AWS Machine Learning blog. @@ -64 +53 @@ A/B testing also helps gauge the business impact of model staleness and drift. T -For more information about how to perform A/B testing with SageMaker AI, see the blog post [A/B Testing ML models in production using Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/a-b-testing-ml-models-in-production-using-amazon-sagemaker/) on the AWS Machine Learning blog. +For more information about how to perform A/B testing with Sage Maker, see the blog post [A/B Testing ML models in production using Amazon SageMaker](https://aws.amazon.com/blogs/machine-learning/a-b-testing-ml-models-in-production-using-amazon-sagemaker/) on the AWS Machine Learning blog. @@ -68 +57 @@ For more information about how to perform A/B testing with SageMaker AI, see the -With SageMaker AI, you can choose the underlying infrastructure to deploy your model in different ways. These inference invocation capabilities support different use cases and cost profiles. Your options include real-time inference, asynchronous inference, and batch transform, as discussed in the following sections. +With SageMaker, you can choose the underlying infrastructure to deploy your model in different ways. These inference invocation capabilities support different use cases and cost profiles. Your options include real-time inference, asynchronous inference, and batch transform, as discussed in the following sections. @@ -72 +61 @@ With SageMaker AI, you can choose the underlying infrastructure to deploy your m -[Real-time inference](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints.html) is ideal for inference workloads where you have real-time, interactive, low-latency requirements. You can deploy your model to SageMaker AI hosting services and get an endpoint that can be used for inference. These endpoints are fully managed, support automatic scaling (see [Automatically scale Amazon SageMaker AI models](https://docs.aws.amazon.com/sagemaker/latest/dg/endpoint-auto-scaling.html)), and can be deployed in multiple [Availability Zones](https://docs.aws.amazon.com/sagemaker/latest/dg/instance-types-az.html). +[Real-time inference](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints.html) is ideal for inference workloads where you have real-time, interactive, low-latency requirements. You can deploy your model to SageMaker hosting services and get an endpoint that can be used for inference. These endpoints are fully managed, support automatic scaling (see [Automatically scale Amazon SageMaker models](https://docs.aws.amazon.com/sagemaker/latest/dg/endpoint-auto-scaling.html)), and can be deployed in multiple [Availability Zones](https://docs.aws.amazon.com/sagemaker/latest/dg/instance-types-az.html). @@ -74 +63 @@ With SageMaker AI, you can choose the underlying infrastructure to deploy your m -If you have a deep learning model built with Apache MXNet, PyTorch, or TensorFlow, you can also use [Amazon SageMaker AI Elastic Inference (EI)](https://docs.aws.amazon.com/sagemaker/latest/dg/ei.html). With EI, you can attach fractional GPUs to any SageMaker AI instance to accelerate inference. You can select the client instance to run your application and attach an EI accelerator to use the correct amount of GPU acceleration for your inference needs. +If you have a deep learning model built with Apache MXNet, PyTorch, or TensorFlow, you can also use [Amazon SageMaker Elastic Inference (EI)](https://docs.aws.amazon.com/sagemaker/latest/dg/ei.html). With EI, you can attach fractional GPUs to any SageMaker instance to accelerate inference. You can select the client instance to run your application and attach an EI accelerator to use the correct amount of GPU acceleration for your inference needs. @@ -76 +65 @@ If you have a deep learning model built with Apache MXNet, PyTorch, or TensorFlo -Another option is to use [multi-model endpoints](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html), which provide a scalable and cost-effective solution to deploying large numbers of models. These endpoints use a shared serving container that is enabled to host multiple models. Multi-model endpoints reduce hosting costs by improving endpoint utilization compared with using single-model endpoints. They also reduce deployment overhead, because SageMaker AI manages loading models in memory and scaling them based on traffic patterns. +Another option is to use [multi-model endpoints](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html), which provide a scalable and cost-effective solution to deploying large numbers of models. These endpoints use a shared serving container that is enabled to host multiple models. Multi-model endpoints reduce hosting costs by improving endpoint utilization compared with using single-model endpoints. They also reduce deployment overhead, because SageMaker manages loading models in memory and scaling them based on traffic patterns. @@ -78 +67 @@ Another option is to use [multi-model endpoints](https://docs.aws.amazon.com/sag -For additional best practices for deploying ML models in SageMaker AI, see [Deployment best practices](https://docs.aws.amazon.com/sagemaker/latest/dg/best-practices.html) in the SageMaker AI documentation. +For additional best practices for deploying ML models in SageMaker, see [Deployment best practices](https://docs.aws.amazon.com/sagemaker/latest/dg/best-practices.html) in the SageMaker documentation. @@ -82 +71 @@ For additional best practices for deploying ML models in SageMaker AI, see [Depl -[Amazon SageMaker AI Asynchronous Inference](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference.html) is a capability in SageMaker AI that queues incoming requests and processes them asynchronously. This option is ideal for requests with large payload sizes up to 1 GB, long processing times, and near real-time latency requirements. Asynchronous inference enables you to save on costs by automatically scaling the instance count to zero when there are no requests to process, so you pay only when your endpoint is processing requests. +[Amazon SageMaker Asynchronous Inference](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference.html) is a capability in SageMaker that queues incoming requests and processes them asynchronously. This option is ideal for requests with large payload sizes up to 1 GB, long processing times, and near real-time latency requirements. Asynchronous inference enables you to save on costs by automatically scaling the instance count to zero when there are no requests to process, so you pay only when your endpoint is processing requests.