On this page · 11 sections
Summary. AWS announced customer managed key encryption for SageMaker MLflow on 24 August 2026, using AWS KMS, with the key required in the same AWS account and Region as the MLflow App and only symmetric KMS keys supported. The announcement calls it generally available "in all AWS Regions where MLflow App is available". The documentation lists exactly 16 such Regions. MLflow Tracking Servers, the older surface, run in every commercial Region where Amazon SageMaker Studio runs except China, and get no customer managed key at all. Four Regions where tracking servers exist only through the AWS CLI, including Asia Pacific (Hyderabad), have no MLflow App and therefore no path to CMK. The two surfaces also differ by MLflow version: apps run MLflow 3.10, tracking servers top out at MLflow 3.0. A customer managed key costs $1 per key version per month plus $0.03 per 10,000 requests in us-east-1.
What AWS shipped
The What's New entry of 24 August 2026 is four sentences long. SageMaker MLflow can now encrypt data with a customer managed key through AWS KMS, so an organisation manages its own key material and gets CloudTrail records of data access for audit. AWS states two constraints in the announcement itself: the key must be created in the same AWS account and Region as your MLflow App, and only symmetric AWS KMS keys are supported.
Then the availability line: "This feature is generally available in all AWS Regions where MLflow App is available."
That sentence carries the whole story, because it silently names one of the two MLflow surfaces AWS runs.
Two MLflow products, one of which gets the key
SageMaker AI has an MLflow Tracking Server and an MLflow App, and the documentation treats them as separate offerings with separate Region lists, separate version tables and separate setup pages. AWS is clear about which one it wants you on: "MLflow Apps are the latest managed MLflow offering on SageMaker and should be preferred over existing MLflow Tracking Servers."
There is no published deprecation date for tracking servers. Customer managed keys are now the first hard compliance reason to move.
| Property | MLflow App | MLflow Tracking Server |
|---|---|---|
| Customer managed key encryption | Yes, from 24 August 2026 | Not offered |
| MLflow version | 3.10, Python 3.10 or later | 3.0, 2.16 or 2.13; Python 3.9 or 3.8 or later |
| Region availability | 16 named AWS Regions | All commercial Regions with SageMaker Studio except China |
| CLI-only Regions | None listed | Europe (Zurich), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Canada West (Calgary) |
| Sizing controls | Not exposed; version auto-updates to latest supported | Small, Medium, Large by --tracking-server-size |
| AWS position | "should be preferred" | "existing" |
The version gap is the part that will surprise people. MLflow Apps run MLflow 3.10. Tracking servers offer MLflow 3.0 as their latest, with 2.16 and 2.13 still selectable. A team that adopted a tracking server on MLflow 2.13 and never moved is now ten upstream minor versions behind the surface that receives the security feature.
The 16 Regions, and the four that cannot follow
MLflow Apps are documented in these Regions: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm) and South America (Sao Paulo).
Sixteen. Read that against the tracking server line, which covers all commercial Regions where SageMaker Studio is available except China, and the gap is large. There is no GovCloud entry and no China entry on either list for MLflow Apps.
The sharpest case is the four Regions where AWS documents tracking servers as available "using only the AWS CLI": Europe (Zurich), Asia Pacific (Hyderabad), Asia Pacific (Melbourne) and Canada West (Calgary). None of the four appears on the MLflow App list. A team that put its experiment tracking in one of those Regions for data-residency reasons cannot get a customer managed key without changing Region, which for a residency-driven deployment is the one change it cannot make.
Why the metadata store is the point
The reason CMK matters more for MLflow than it does for a generic service sits in the architecture. AWS documents an MLflow Tracking Server as three components: compute, backend metadata storage, and artifact storage. The compute and the backend metadata store are hosted in the SageMaker AI service account. Only the artifact store, an Amazon S3 bucket, lives in your own AWS account.
So the part you already control with your own bucket policy and your own S3 encryption is the artifacts. The part you do not control is the run metadata: run IDs, start and end times, parameters and metrics. On a tracking server, that data sits in AWS's account under AWS-managed encryption, and there is no customer managed key option to change it.
If your security review has ever asked who holds the key for experiment metadata, that is the question this launch answers, and it answers it only for MLflow Apps.
What it costs
Prices below come from the AWS Price List API for us-east-1 and were retrieved on 25 August 2026.
| Meter | Price, us-east-1 | Note |
|---|---|---|
| Customer managed KMS key | $1 per key version per month | Each rotation creates a new key version |
| KMS symmetric requests | $0.03 per 10,000 requests | Encrypt, decrypt and GenerateDataKey calls |
| KMS asymmetric requests | $0.15 per 10,000 requests | Not applicable; MLflow accepts symmetric keys only |
| KMS RSA 2048 requests | $0.03 per 10,000 requests | Not applicable here |
The direct cost is small. Automatic key rotation is what to watch, because each rotation creates a key version and the $1 charge is per key version per month, not per key.
Who is affected, and how to tell if it is you
Run aws sagemaker list-mlflow-tracking-servers in each Region you use. Every result is an MLflow deployment that cannot take a customer managed key today.
Then check three things before you plan a migration.
Your Region. If it is not one of the 16 above, the migration is a Region move as well as a product move, and the residency question comes first.
Your MLflow client version. Apps run MLflow 3.10 against Python 3.10 or later. If your training images pin MLflow 2.13 and Python 3.8, the client upgrade is the real work, not the app creation.
Your artifact volume. SageMaker AI MLflow has a 200 MB download size limit, documented on the same page, and that limit applies to how you get artifacts back out. Size your migration around it rather than discovering it mid-copy.
One more operational note that has nothing to do with this launch and everything to do with planning around it: AWS documents that tracking servers are launched in a single availability zone within their Region. If you are already carrying that single-AZ exposure, the move to an app is worth doing on its own terms.
India-specific considerations
Asia Pacific (Mumbai) is on the MLflow App list, so an Indian team can get a customer managed key with training data and experiment metadata in-country. Asia Pacific (Hyderabad) is not on the list, and is one of the four Regions where tracking servers are CLI-only. A Hyderabad deployment has no CMK path without moving to Mumbai.
That distinction matters under the Digital Personal Data Protection Act 2023 for anyone whose experiment metadata carries identifiers, because run parameters and metrics are not always as anonymous as they look. Where a data protection impact assessment names key custody as a control, the honest answer on a tracking server today is that the key is AWS-managed and the metadata store is in AWS's account. At roughly Rs 88 to the dollar, the key itself is about Rs 88 a month per key version, so cost is not the obstacle. Region and product surface are.
What is still unknown
AWS has not published an end-of-support date for MLflow Tracking Servers, only the recommendation to prefer apps. It has not said whether CMK will be backported to tracking servers, and the wording of the announcement suggests it will not. There is no documented migration tool between the two surfaces, no stated timeline for the four CLI-only Regions to receive MLflow Apps, and no published statement on whether an existing MLflow App can have a key attached after creation or must be recreated. Treat the last one as a create-time decision until AWS documents otherwise.
FAQ
How eCorpIT can help
The decision here is not really about a key. It is whether to move experiment tracking to a newer managed surface, in a Region that may not be the one you chose, with a client-library upgrade attached. eCorpIT designs and runs MLOps platforms on AWS, and our engineering organisation is CMMI Level 5 and ISO 27001:2022 certified. If experiment metadata falls inside your compliance scope, book an MLflow migration review and we will map your tracking servers, Regions and client versions against the app requirements. Teams building the capability internally can also hire AI engineers to own it.
References
- SageMaker MLflow now supports customer managed keys, AWS What's New, 24 August 2026.
- Machine learning experiments using Amazon SageMaker AI with MLflow, Amazon SageMaker AI Developer Guide.
- MLflow App Setup, Amazon SageMaker AI Developer Guide.
- MLflow Tracking Servers, Amazon SageMaker AI Developer Guide.
- AWS Price List API, AWS KMS offer file, retrieved 25 August 2026.
- MLflow 3.10 release, MLflow project.
- MLflow 3.0 release, MLflow project.
- MLflow 2.13 release, MLflow project.
- MLflow tracking and tracking servers, MLflow documentation.
- MLflow backend stores, MLflow documentation.
- Supported Regions and quotas for Amazon SageMaker AI, Amazon SageMaker AI Developer Guide.
- Set up IAM permissions for MLflow, Amazon SageMaker AI Developer Guide.
Related reading: Ray on SageMaker HyperPod and its five extra add-ons, SageMaker container caching and cold starts, SageMaker inference recommendations and benchmark cost, and AI compute capacity planning.
Last updated: 25 August 2026.
