{"slug": "aws-kms-vs-azure-vs-google-kms-1-keys-pqc-2026", "title": "AWS KMS vs Azure vs Google KMS: $1 Keys, PQC [2026]", "summary": "AWS Key Management Service added ML-KEM support on October 26, 2026, covering all three FIPS 203 parameter sets (ML-KEM-512, ML-KEM-768 and ML-KEM-1024) through new Encapsulate and Decapsulate operations, with private keys held in HSMs validated to FIPS 140-3 Level 3, according to Daily AWS. AWS lists a customer-managed KMS key at $1 per month, prorated hourly, with the first and second key rotations each adding $1 per month, while Azure and Google pricing for post-quantum operations was not published in any official source reviewed on November 3. TechInformed's October 30 report noted that existing applications will not use the new keys until developers change their code, and that the feature is separate from an earlier AWS hybrid post-quantum method that protects the connection to KMS itself.", "body_md": "AWS Key Management Service added ML-KEM support on October 26, 2026, covering all three FIPS 203 parameter sets (ML-KEM-512, ML-KEM-768 and ML-KEM-1024) through new `Encapsulate` and `Decapsulate` operations, according to [Daily AWS](https://www.daily-aws.com/headlines/20261026/). The private keys sit in HSMs validated to FIPS 140-3 Level 3. For anyone weighing AWS KMS vs Azure Key Vault vs Google Cloud KMS, that release moves the argument away from IAM models and toward post-quantum readiness.\n\nThe three providers have taken different paths. AWS shipped a key-encapsulation primitive that lets your own systems agree on a shared secret with a key the service protects. Google reportedly put quantum-safe signatures first and kept its ML-KEM work in preview. Microsoft put AES key wrapping in public preview for Key Vault Premium on August 5, a post-quantum-oriented step that stops short of new key types.\n\nThe size penalty is the first cost anyone notices. Post-quantum public keys and ciphertexts run far larger than their elliptic-curve cousins, a trade-off laid out in the breakdown of [RSA vs ML-KEM key sizes](https://shattered.io/rsa-vs-ml-kem-post-quantum-encryption-2026/). Managed key services absorb some of that pain, but your application code and your network paths still feel it.\n\nPrice is the other concrete number. AWS lists a customer-managed KMS key at $1 per month, prorated hourly, and the first and second key rotations each add $1 per month. Azure and Google pricing for post-quantum operations was not published in any official source reviewed on November 3, so the cost side of this comparison leans on arithmetic from AWS list prices and on structure rather than rates for the other two.\n\nDon't miss new tech stories on Google\n\nAdd Shattered once in the Google app and our stories show up in your news suggestions.\n\n[Add now](https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F)\n\n## What AWS Shipped on October 26 and Why Key Management Is the Next Post-Quantum Fight\n\nThe AWS announcement covers one specific job. ML-KEM is a key-encapsulation mechanism, so it does not encrypt your data and it does not sign anything. One party uses a public key to generate a shared secret plus a blob of data to send across. The other party hands that blob to the service, which uses the matching private key to recover the same secret. The secret never travels over the wire, and the private key never leaves the HSM.\n\nTechInformed, in its [October 30 report on the launch](https://techinformed.com/aws-kms-adds-quantum-resistant-key-exchange/), stressed the practical catch. Existing applications will not use the new keys until developers change their code. The report also separated the new feature from an earlier AWS addition, a hybrid post-quantum method that protects the connection to KMS itself when clients support it. Those are two different protections. One secures the pipe to the key service, and the other lets your own systems derive quantum-resistant shared secrets.\n\nThat distinction matters for how you read vendor claims. A provider that says its key service is quantum-safe might mean the TLS handshake to its API, the algorithms you can create keys with, or the algorithms protecting its internal storage. These are three separate questions. Ask each one separately when you compare AWS, Azure and Google.\n\nKey management is where the harvest now, decrypt later threat bites hardest. An attacker who records encrypted traffic today and stores it can wait for a capable quantum computer. Data that must stay confidential for ten or twenty years, such as health records, source code, financial archives and government data, needs a key-establishment method that survives that wait. The wrapping keys held in a key service often protect exactly those long-lived assets.\n\nSignatures face a different clock. A forged signature only hurts when a verifier trusts it, so the urgency tracks the lifetime of the thing being signed. Firmware, code-signing roots and certificate authorities live for years, which is why Google reportedly led with signatures and why AWS published separate guidance on ML-DSA for software supply chains in October. Teams comparing signature algorithms can read the [ML-DSA vs SLH-DSA](https://shattered.io/ml-dsa-vs-slh-dsa-2026/) trade-offs before choosing a managed key type.\n\nOne more point frames the rest of this piece. A cloud key service bundles four things: the algorithms it can hold, the hardware that protects the private halves, the access model that decides who can call it, and the bill. Post-quantum support touches the first two directly. It touches the third through new IAM actions and policies, and it touches the fourth through request pricing that AWS has not yet spelled out for the new operations.\n\n## AWS KMS vs Azure Key Vault vs Google Cloud KMS: Specs at a Glance\n\nEvery cell traces to an official or fetched page available on November 3, 2026. A cell marked *Not captured* means the sources reviewed did not establish the point, not that the feature is missing. Google’s cells are thinnest because no official Cloud KMS pricing or documentation page came back in the research pass.\n\n| Attribute | AWS KMS | Azure Key Vault | Google Cloud KMS | \n|---|---|---|---|\n| Official name | AWS Key Management Service | Azure Key Vault and Azure Key Vault Managed HSM | Cloud Key Management Service (Cloud KMS) | \n| Resource model | Customer-managed, AWS-managed and AWS-owned keys | Vaults and Managed HSM pools | Not captured | \n| HSM-backed keys | ML-KEM private keys held in FIPS 140-3 Level 3 validated HSMs | Vaults hold software or HSM-backed keys, Managed HSM pools hold HSM-backed keys only | Not captured | \n| Single-tenant HSM option | AWS pricing page example uses 2 HSMs at $1.60 per HSM per hour | Managed HSM, described as fully managed, highly available and single-tenant | Not captured | \n| ML-KEM key encapsulation | Supported in all three parameter sets | No confirmed ML-KEM key type in the documentation reviewed | Reports conflict on preview versus general availability | \n| KEM operations | Encapsulate and Decapsulate | Not captured | Not captured | \n| Regional limits on ML-KEM | All KMS Regions except UAE, Bahrain and China | Not applicable | Not captured | \n| Customer-managed key price | $1 per key per month, prorated hourly | No official price captured | No official price captured | \n| Key rotation charge | $1 per month each for the first and second rotations | Additional cost per scheduled rotation, documented October 29 | Not captured | \n| Free request tier | 20,000 requests per month, asymmetric operations excluded | Not captured | Not captured | \n| Access-control default | Not captured | Azure RBAC for new vaults created with API version 2026-02-01 | Not captured | \n| Documented RSA key sizes | Not captured | 2,048, 3,072 and 4,096 bits in managed-disk customer-managed-key scenarios | Not captured | \n| Rename or retirement | None confirmed | None confirmed | None confirmed | \n\nThree patterns jump out. AWS is the only provider with a dated, official, general-availability ML-KEM release in the sources reviewed. Azure’s documentation still describes RSA-based key handling and, per the pages fetched, does not list finalized post-quantum key algorithms. And Google’s position cannot be pinned down from official pages alone, which is itself a finding for anyone building a procurement checklist.\n\nNaming also matters here. Microsoft sells the vault product and the Managed HSM product under related names, and its wider portfolio includes Azure Cloud HSM and Azure Payment HSM, which bill at fixed hourly rates rather than by transaction, according to Microsoft’s overview. Teams that treat Key Vault as one SKU tend to misprice it. The Azure line item you pay depends on the container type, the tier and the key protection level.\n\n## Post-Quantum Support, Provider by Provider\n\nEach provider answers the same question differently: what can a customer actually do with a managed key today that survives a quantum adversary? The answers split along key establishment, signatures and key wrapping.\n\n### AWS KMS: ML-KEM Keys Are Live, Signing Guidance Is Out\n\nAWS holds the clearest official position. ML-KEM-512, ML-KEM-768 and ML-KEM-1024 arrived on October 26, with an update to the announcement on October 29. The service restricts the feature in three places: the UAE, Bahrain and China Regions. Everywhere else KMS operates, the new key type is available.\n\nBeyond the keys themselves, AWS says that services such as CloudFront, IAM, KMS and S3 use hybrid key establishment that combines ECDH with ML-KEM. That claim appears in a single source, so treat it as AWS’s own description of its endpoints rather than a measured result. It pairs with the hybrid protection for KMS API connections that TechInformed described.\n\nOn signatures, AWS published a two-part series on quantum-resistant signing on October 12. Part 1 builds a software supply chain with ML-DSA, and Part 2 shows how to enforce an ML-DSA algorithm policy with service control policies and IAM. One AWS comparison page also lists ML-DSA among the algorithms KMS supports. Another source stops short of confirming that ML-DSA signing keys reached general availability as a KMS feature, so check the current key-spec list in the console before you plan around it.\n\nOne gap remains. The announcement as reviewed shows no ML-KEM-specific price. Asymmetric operations already fall outside the 20,000-request free tier, so expect ML-KEM calls to bill from the first request. Confirm the rate on the pricing page before you forecast.\n\n### Azure Key Vault: AES Key Wrapping in Preview, No Confirmed PQC Key Types\n\nMicrosoft’s most relevant change landed on August 5, 2026. A post on the Microsoft Tech Community’s post-quantum crypto blog announced AES key wrapping (AES-KW) in public preview for Azure Key Vault Premium. The idea is to wrap keys with a symmetric algorithm instead of RSA, which sidesteps the quantum weakness of RSA key wrapping. The post says AES-128 is not recommended for this scenario, so plan on 256-bit keys. If you need a refresher on that choice, the [AES-128 vs AES-256](https://shattered.io/aes-128-vs-aes-256-2026/) comparison covers the speed and approval trade-offs.\n\nThis is not the same thing as ML-KEM support. The Key Vault key documentation, updated at the end of October, defines quantum-resistant and post-quantum concepts but does not list generally available ML-KEM, ML-DSA or SLH-DSA key types. The same documentation still cites RSA key sizes of 2,048, 3,072 and 4,096 bits in managed-disk customer-managed-key scenarios. Microsoft also tells customers that post-quantum protection of data on the wire requires TLS 1.3 with hybrid groups, which is a client and server matter rather than a vault feature.\n\nAzure has other deadlines to watch. Control-plane API versions older than 2026-02-01 are scheduled to stop working on February 27, 2027, as [Brandligo’s Key Vault profile](https://www.brandligo.com/companies/microsoft/products/azure-key-vault) notes, and data-plane APIs are not affected. Azure RBAC became the default access model for newly created vaults on the newer API. Teams with old automation should check their templates now.\n\n### Google Cloud KMS: Signatures First, with Conflicting Reports on ML-KEM\n\nGoogle’s story rests on reports the research pass could not tie to an official Cloud KMS page, so each claim below carries a hedge. One account says Google announced general availability of quantum-safe digital signatures in Cloud KMS on July 28, 2026, including ML-DSA and SLH-DSA, with the announcement updated on October 30. The listed variants include SLH-DSA-SHA2-128s plus ML-DSA-44, ML-DSA-65 and ML-DSA-87.\n\nThe same account puts ML-KEM-based key encapsulation in preview, and says quantum-safe key import for software keys entered preview on August 20 using a hybrid HPKE-based transit envelope. Cloud KMS PQC insights, a posture-monitoring feature, reportedly reached general availability the same day, and Google described a roadmap that targets migration by 2029.\n\nA second reading conflicts. It says an official roadmap update dated August 11 and refreshed October 31 describes ML-KEM, ML-DSA and SLH-DSA all as generally available in Cloud KMS. Both cannot be right about ML-KEM. Until Google’s own documentation settles the point on the day you read it, assume signatures are the safe bet and verify KEM availability in the console for your Region before committing.\n\n## How ML-KEM Key Encapsulation Works Inside a Managed Key Service\n\nA key-encapsulation mechanism swaps the familiar encrypt-a-key flow for a two-step agreement. In classic envelope encryption you ask the service to encrypt a data key with a wrapping key. With a KEM you never choose the secret. The Encapsulate step generates a fresh shared secret and a ciphertext that only the private-key holder can open. The Decapsulate step turns that ciphertext back into the same secret.\n\nThe managed-service version keeps the private half inside the HSM boundary. Your application can run Encapsulate anywhere that holds the public key, since public keys need no secrecy. Only the Decapsulate call must reach the service, and every call is an IAM-governed, loggable event. That gives you an audit trail for each moment someone recovers a secret, which a public-key library on a laptop cannot offer.\n\n```\n# Pseudocode: key agreement with a KMS-held ML-KEM key\n# Sender side (any system that holds the public key)\nshared_secret, ciphertext = ML_KEM_Encapsulate(public_key)\ndata_key = KDF(shared_secret, context=\"orders-db-v1\")\nencrypted_blob = AEAD_Encrypt(data_key, plaintext)\nsend(ciphertext, encrypted_blob)\n\n# Receiver side (private key never leaves the KMS HSM)\nshared_secret = KMS.Decapsulate(key_id, ciphertext)\ndata_key = KDF(shared_secret, context=\"orders-db-v1\")\nplaintext = AEAD_Decrypt(data_key, encrypted_blob)\n```\n\nReal deployments rarely use a KEM alone. The common pattern is hybrid: run a classical exchange such as X25519 and ML-KEM side by side, then feed both secrets into one key-derivation function. If either algorithm survives, the derived key survives. NIST’s transition plan explicitly supports this phased approach, where classical elliptic-curve cryptography runs alongside post-quantum algorithms at first. For the network-protocol side of that design, see how [X25519 and P-256 pair with hybrid groups](https://shattered.io/x25519-vs-p-256-2026/) in TLS.\n\nWhat does not change is the symmetric layer. Bulk data still gets encrypted by an AEAD cipher under a 256-bit key, and HMAC keys still authenticate messages. The KEM only replaces how two parties agree on that symmetric key. This is why migration plans usually start at the key-establishment layer and leave the data encryption path alone.\n\nPerformance deserves a caveat. A KMS Decapsulate call is a network round trip to a regional endpoint, not a local CPU operation. Latency will depend on your Region, your connection reuse and the service’s own queueing. No independent benchmark of managed ML-KEM latency was available on November 3, so the later section on measurement gives a plan for producing your own numbers.\n\n## Pricing: What the Public Numbers Show\n\nAWS publishes the most legible price card of the three. Azure bills by transactions, tier and hardware protection. Google describes pay-as-you-go pricing in general terms, but the research pass returned no official Cloud KMS rate table. Here is what is confirmed.\n\n| Price item | AWS KMS | Azure Key Vault | Google Cloud KMS | \n|---|---|---|---|\n| Customer-managed key | $1 per key per month, prorated hourly | No official price captured | No official price captured | \n| First and second rotation | $1 per month each, later rotations add nothing | Extra charge per scheduled rotation, amount not captured | Not captured | \n| AWS-managed and AWS-owned key storage | No charge | Not applicable | Not applicable | \n| Key scheduled for deletion | No monthly charge while in that state | Not captured | Not captured | \n| External key store key | $1 per key per month, normal request pricing | Not captured | Not captured | \n| Free requests | 20,000 per month, some asymmetric and key-pair operations excluded | Not captured | Not captured | \n| Request rate in AWS worked examples | $0.03 per 10,000 requests, and a $0.15 per 10,000 example for another request type | Transaction charges plus tier- and hardware-dependent fees | Usage-based, rates not captured | \n| Dedicated HSM example | 2 HSMs at $1.60 per HSM per hour in the AWS pricing example | Not captured | Not captured | \n| ML-KEM-specific price | None stated in the announcement | Not applicable | Not captured | \n\nTwo reading tips apply. First, AWS prorates hourly, so a key you create and delete inside a day costs a fraction of the monthly figure. Second, the free tier excludes some asymmetric operations. Because ML-KEM is asymmetric, do not assume your first 20,000 requests cover Encapsulate and Decapsulate traffic.\n\nSecrets storage is a separate bill. Teams that keep application secrets in a managed secret store pay per secret and per API call on top of key charges, and the [AWS Secrets Manager pricing comparison](https://shattered.io/aws-secrets-manager-pricing-vs-vault-key-vault-openbao-infisical-2026/) shows how that line item stacks against Vault, Key Vault, OpenBao and Infisical. Budget both lines before you decide where keys should live.\n\n## Cost Model: What AWS KMS Bills in Six Scenarios\n\nOnly AWS publishes enough list-price detail to model. Applying AWS’s confirmed rates ($1 per key per month, $1 per month for each of the first two rotations, 20,000 free requests and $0.03 per 10,000 requests in AWS’s worked example) to realistic fleets gives the figures in the table. They are arithmetic, not a quote, and asymmetric or ML-KEM operations may bill differently.\n\n| Scenario | Inputs | Calculation | Monthly cost | \n|---|---|---|---|\n| Small team | 10 customer-managed keys, no rotation | 10 x $1 | $10.00 | \n| Rotation-heavy fleet | 40 keys, each rotated twice | 40 x ($1 + $1 + $1) | $120.00 | \n| AWS pricing-page example | 2,010,000 requests | 199 x $0.03 after 20,000 free | $5.97 | \n| Mid-size application | 40 keys rotated twice, plus 5,000,000 requests | $120 + request charges at $0.03 per 10,000 requests after the 20,000 free requests | $134.94 | \n| High-volume API | 20,000,000 requests | 1,998 x $0.03 | $59.94 | \n| CloudHSM-backed store | 2 HSMs for 31 days | 2 x $1.60 x 24 x 31 | $2,380.80 | \n\nThe pattern is plain. For most teams, the key count and rotation policy dominate the bill, and request volume only matters at tens of millions of calls. The one budget shock is dedicated hardware. A CloudHSM-backed custom key store needs at least two HSMs, billed separately from KMS, on top of the $1 per key charge for each customer-managed key.\n\nPost-quantum keys will change the request line before they change the key line. A design that calls Decapsulate for every incoming message produces far more asymmetric requests than a design that decapsulates once per session and caches the derived key. Since the free tier excludes some asymmetric operations, session-level key agreement can cut the bill by orders of magnitude at scale. Treat connection reuse and short-lived derived keys as cost controls, not just performance tricks.\n\nRotation policy deserves a second look. Every key you rotate twice costs $3 per month instead of $1, and AWS stops adding the charge after the second rotation. A fleet that rotates yearly for a decade pays the rotation surcharge for only the first two cycles. Azure documents an additional cost for each scheduled rotation instead, so a migration between the two clouds can flip your rotation economics in either direction. Model your own schedule on both pricing pages before you move.\n\n## Security and Compliance Posture: HSMs, Regions and Access Models\n\nHardware assurance is the first filter for regulated buyers. AWS states that ML-KEM private keys live in HSMs validated to FIPS 140-3 Level 3. Microsoft reportedly updated its Managed HSM and Key Vault Premium HSM fleet to FIPS 140-3 Level 3 validated firmware, with documentation refreshed on October 29. Google’s equivalent claim was not captured from an official page. If your auditor asks for the validation certificate, request it from the provider rather than relying on a blog summary.\n\nRegional coverage is the second filter. AWS excludes the UAE, Bahrain and China Regions from ML-KEM support. A company with data-residency rules in the Gulf or on the Chinese mainland cannot use the new key type there yet. Those teams should plan a fallback, such as performing key agreement in an approved Region and keeping classical wrapping in the excluded one, and then document the exception for compliance review.\n\nAccess models differ more than most comparisons admit. New Azure vaults created on API version 2026-02-01 default to Azure RBAC, so permissions follow the same role assignments as the rest of the subscription. AWS pairs key policies with IAM, which means a key can carry its own resource policy that stands apart from account-level roles. Neither model is better in the abstract. The risk lies in migrating a policy design from one to the other without translating the trust boundaries.\n\nExternal key stores add a third control option. AWS lists external key store keys at the same $1 per key per month with normal request pricing, which lets an organization keep the root of trust outside AWS. That design suits teams under sovereignty rules, though it adds latency and an availability dependency on your own infrastructure. Post-quantum operations in an external store depend on what your external HSM supports, not on what AWS announced.\n\nLogging completes the picture. Every Decapsulate call, signing call or rotation event should reach an immutable audit log, and your detection rules should flag unusual bursts of asymmetric requests. A sudden spike in Decapsulate calls from a new principal is a stronger signal of misuse than a spike in symmetric decrypts, because asymmetric calls are rarer in normal operation. Build that alert before you enable the key type in production.\n\n## NIST IR 8547 Deadlines and What They Mean for Cloud Key Services\n\nNIST finalized IR 8547, Transition to Post-Quantum Cryptography Standards, on October 27, 2026, one day after the AWS release. [Quantum Computing Report](https://quantumcomputingreport.com/nist-releases-final-ir-8547-establishing-definitive-post-quantum-cryptography-transition-timeline-and-deprecation-schedules/) summarized the schedule. Quantum-vulnerable public-key algorithms face deprecation after 2030 and disallowance under NIST standards after 2035. For federal high-value systems, reports put the key-establishment migration deadline at December 31, 2030 and the digital-signature deadline at December 31, 2031.\n\nThe covered algorithms include RSA, ECDSA, EdDSA, Diffie-Hellman and ECDH. The three post-quantum standards, published in August 2024, supply the replacements: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. The full timeline appears in the write-up of [NIST IR 8547 and the 2035 disallowance date](https://shattered.io/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-pqc-replacements-2026/).\n\nKey establishment comes first on the calendar. That ordering favors the AWS approach, since ML-KEM is the replacement for the exchanges that harvest-now attacks target. A buyer on a 2030 key-establishment deadline has roughly four years of runway, and the first two should go to inventory and testing. Signature migration gets one extra year, which gives Google’s signature-first path a reasonable footing for firmware and code-signing workloads.\n\nNIST guidance binds federal systems directly. Private companies inherit it through contracts, audit frameworks and customer questionnaires, so a vendor that cannot show a post-quantum plan may start losing deals before any law forces the issue. Readers who followed the earlier draft can compare it with the final text in the [IR 8547 final vs draft](https://shattered.io/nist-ir-8547-final-vs-draft-post-quantum-cryptography-2026/) analysis.\n\nThe roadmap also tolerates hybrids. NIST supports a phased migration in which classical elliptic-curve cryptography runs alongside post-quantum algorithms at first. That means a cloud provider does not need to drop RSA or ECDH to be compliant today. It needs to offer post-quantum options and a believable path to switch. Judge the three providers on that path, including dated releases, preview-to-general-availability timelines and documented algorithm policies.\n\n## Real-World Examples: Where Managed Keys and Post-Quantum Work Show Up\n\nAnnouncements from the three months before November 3 show where managed keys already sit inside production services and how post-quantum work is spreading beyond the key services themselves.\n\n**1. Amazon OpenSearch Service, October 12.** AWS added index-level encryption that uses a separate customer-managed KMS key for each index, for domains running OpenSearch 3.3 or later in the listed Regions. The feature carries no extra charge beyond normal KMS and OpenSearch fees. A per-index key means one compromised or revoked key affects one index, and it also multiplies your key count, so check the $1 per key math before enabling it widely.\n\n**2. Amazon Transcribe.** Customer-managed key support arrived for custom vocabularies, vocabulary filters and custom language models in all Regions where Transcribe runs. Teams that must prove key ownership for speech data gain a control here, and it shows how managed keys spread into AI-adjacent services.\n\n**3. SageMaker MLflow Apps, August 24.** SageMaker added customer-managed key support for encrypting MLflow App data. Experiment metadata can include parameters and dataset paths that some organizations treat as sensitive, so key control has value even for tracking data.\n\n**4. IAM Identity Center, August 7.** AWS added a one-click multi-Region option for new organization instances, and the associated customer-managed multi-Region KMS key incurs standard KMS charges. This is a clean example of a managed key hiding behind a convenience setting and still showing up on the bill.\n\n**5. Software supply chain signing on AWS, October 12.** The two-part ML-DSA series walks through building an ML-DSA root of trust and enforcing an algorithm policy with service control policies and IAM. Teams that sign build artifacts have the most to gain, because a signature produced today can be checked years from now.\n\n**6. Amazon MSK, announced in the AWS November 2 digest.** AWS said MSK Provisioned clusters can now enforce TLS 1.3 through named security policies, which it framed as enabling stronger encryption and post-quantum readiness. TLS 1.3 is the base layer that hybrid post-quantum groups need, so this is groundwork rather than a post-quantum feature by itself.\n\n**8. Services and training deals, October 28.** SAIC announced a quantum-solutions portfolio that includes post-quantum migration services, and SpecterAI Quantum Security and HPT signed an implementation roadmap for migration services and training in Vietnam. Consulting capacity is forming around the 2030 deadlines, which matters if your team lacks cryptography staff.\n\n## Use-Case Recommendations: Which Service Fits Which Team\n\nNo single winner covers every workload. Seven common situations map to different winners, based on what was confirmed on November 3, 2026.\n\n**1. AWS-native workloads with long-lived confidentiality needs.** Choose AWS KMS. ML-KEM-768 or ML-KEM-1024 keys are available today, the private keys stay in FIPS 140-3 Level 3 HSMs, and every Decapsulate call lands in your audit logs. Pair the new key type with a hybrid design so that a classical exchange still protects the session if a flaw ever surfaces in the new algorithm.\n\n**2. Azure-centered organizations with RSA-wrapped keys.** Stay on Key Vault Premium and test AES key wrapping in the public preview in a non-production vault. Preview features carry no production commitment, so keep RSA wrapping as the fallback and write down the date you plan to revisit. Meanwhile, move any automation off control-plane API versions older than 2026-02-01 before February 27, 2027.\n\n**3. Code-signing, firmware and certificate workloads.** Look hard at Google Cloud KMS. Reports say its ML-DSA and SLH-DSA signatures reached general availability in July, and signatures protect the longest-lived trust anchors. Verify the current key-algorithm list in your own project first, then pick the signature family. In practice, ML-DSA suits high-volume signing and SLH-DSA suits conservative, low-volume roots.\n\n**4. Multi-cloud estates.** Avoid forcing one provider’s key model onto the others. Use each cloud’s native service for workloads that live there, and share a thin abstraction layer in your application code so that the algorithm choice is configuration, not code. The same thinking applies to compute, as the [AWS Lambda, Azure Functions and Cloud Run](https://shattered.io/aws-lambda-vs-azure-functions-vs-cloud-run-2026/) price gap shows. A single standard across clouds usually costs more than it saves.\n\n**5. Data-residency-bound operators in the Gulf and mainland China.** AWS ML-KEM is unavailable in the UAE, Bahrain and China Regions. Plan a classical fallback with a documented exception, and track the provider’s roadmap monthly. Azure and Google teams in the same markets should ask account managers for written Region availability before assuming parity.\n\n**6. Small teams watching the bill.** A handful of customer-managed keys costs a few dollars a month on AWS, so the post-quantum upgrade itself will not strain a startup budget. The real cost is engineering time. Start with the one data flow that carries your longest-lived secrets and ignore the rest until your tooling matures.\n\n**7. Teams needing dedicated hardware.** Compare Azure Managed HSM, which Microsoft describes as single-tenant, against an AWS CloudHSM-backed custom key store. AWS’s pricing example runs $2,380.80 for two HSMs over 31 days, before any request charges. Get a written quote from each vendor, because the Azure and Google rates were not captured from official pages.\n\n## Migration Guide: Moving from RSA and ECDH Key Handling to ML-KEM\n\nA post-quantum migration succeeds or fails on inventory and sequencing, not on algorithm choice. The ten steps fit any of the three clouds, with AWS-specific notes where the ML-KEM release changes the plan.\n\n1. **Inventory every use of public-key cryptography.** List each place your systems use RSA, ECDH, ECDSA or Diffie-Hellman, including TLS terminators, VPNs, code signing, SSH, document signing and key-wrapping calls into your key service. Record the algorithm, key size, owner and the data lifetime it protects.\n2. **Rank by confidentiality lifetime.** Data that must stay secret past 2035 goes first, because harvest-now attacks target exactly those flows. Short-lived session data can wait.\n3. **Add an abstraction layer.** Wrap your KMS calls behind an interface that takes an algorithm name from configuration. This crypto-agility step costs little and pays off whenever a standard shifts.\n4. **Check Region and feature coverage.** On AWS, confirm the target Region supports ML-KEM, remembering the UAE, Bahrain and China exclusions. On Azure and Google, confirm the current status of each feature in the console, since preview and general availability differ.\n5. **Create test keys in a non-production account.** Try each parameter set your compliance team might approve. AWS exposes ML-KEM-512, ML-KEM-768 and ML-KEM-1024, and larger sets trade bigger messages for a higher security category.\n6. **Build the hybrid exchange.** Combine a classical shared secret with the ML-KEM secret in one key-derivation step. The[ML-KEM vs X25519 comparison for TLS 1.3](https://shattered.io/ml-kem-vs-x25519-tls-1-3-2026/) explains the handshake costs you will see on the wire.\n7. **Measure before you cut over.** Record Decapsulate latency from the Regions you actually run in, plus message-size growth and error rates. Use the plan in the measurement section below.\n8. **Write IAM and key policies for the new operations.** Grant Decapsulate only to the roles that need it, and keep Encapsulate on public-key holders, which need no service permission at all.\n9. **Add monitoring and alerts.** Alert on new principals calling Decapsulate and on request spikes. Feed the logs into your existing detection pipeline.\n10. **Roll out in stages with a rollback path.** Move one service, watch it for a full billing cycle, then expand. Keep classical wrapping available until your audit team signs off on retirement.\n\nBudget two pieces of work that teams often miss. First, client libraries. A KMS that offers ML-KEM does nothing for your app until the SDK and cryptographic library on the other side can run Encapsulate and handle the larger public keys and ciphertexts. Second, storage and protocol limits. Larger objects can break fixed-size database columns, HTTP header limits and token formats, so test the full path and not only the KMS call.\n\nFor Azure teams, the migration shape differs. With AES key wrapping in preview rather than a new key-establishment primitive, the near-term step is moving from RSA-wrapped keys to symmetric wrapping, using 256-bit keys. Keep your RSA material until Microsoft documents general availability, and subscribe to the Key Vault what’s-new page so that you see algorithm announcements the day they land.\n\nFor Google teams, start with signatures. Inventory every signing key that anchors firmware, artifacts or internal certificate authorities, and test the ML-DSA key sizes that fit your throughput. Treat KEM preview features as lab work until Google’s documentation shows general availability for your Region.\n\n## Pros and Cons of Each Service\n\n**AWS KMS pros:**\n\n- Dated, official ML-KEM release covering all three FIPS 203 parameter sets\n- Private keys held in FIPS 140-3 Level 3 validated HSMs\n- Transparent base price of $1 per customer-managed key per month, prorated hourly\n- Free storage for AWS-managed and AWS-owned keys\n- Published ML-DSA signing guidance with policy enforcement through SCPs and IAM\n\n**AWS KMS cons:**\n\n- No ML-KEM in the UAE, Bahrain or China Regions\n- No ML-KEM-specific price stated in the announcement\n- Applications need code changes before they use the new keys\n- Asymmetric operations fall outside part of the free tier\n\n**Azure Key Vault pros:**\n\n- Clear split between vaults and single-tenant Managed HSM pools\n- Azure RBAC as the default model for new vaults on the current API\n- AES key wrapping in public preview for Premium as a post-quantum-oriented step\n- Rotation cost is documented rather than hidden\n\n**Azure Key Vault cons:**\n\n- No confirmed ML-KEM, ML-DSA or SLH-DSA key types in the documentation reviewed\n- Documentation still cites RSA-based key sizes in several scenarios\n- Older control-plane API versions stop working on February 27, 2027\n- Multi-part pricing makes forecasting harder\n\n**Google Cloud KMS pros:**\n\n- Reportedly offers general-availability quantum-safe signatures\n- Reported key import and posture-monitoring features aimed at migration tracking\n- A stated roadmap that targets migration by 2029\n\n**Google Cloud KMS cons:**\n\n- No official page captured to confirm pricing or current algorithm status\n- Conflicting reports on whether ML-KEM is in preview or generally available\n- Smaller body of official public detail than the other two in this research pass\n\n## What the Public Numbers Do Not Show, and How to Measure It Yourself\n\nThree kinds of public evidence exist today, and none of them is a performance benchmark. AWS publishes a price card and a feature announcement. Microsoft publishes documentation and a preview post. Google’s position comes through reports of its own announcements. No independent lab had published latency or throughput results for managed ML-KEM or ML-DSA in a cloud key service by November 3, 2026.\n\nThat gap is normal for a service that launched a week ago. It also means any vendor slide claiming a speed advantage deserves skepticism until you reproduce it. A reliable test takes an afternoon and costs a few dollars of request charges.\n\nRun the test from the Regions where your workloads live, using the same network path your production code uses. Create one key per parameter set, then send several thousand Decapsulate calls at a steady rate and record the median, the 95th percentile and the 99th percentile latency. Repeat at a higher concurrency to find where throttling begins. Record the ciphertext size, the public key size and the HTTP response size so that you can feed them into your capacity plan.\n\nAdd two comparisons for context. First, time a classical RSA or ECDH decrypt against the same service, since the fair question is the delta against what you run today. Second, time the client-side Encapsulate step in your actual library, because that step runs on your CPU and not in the service. Keep the raw logs, and publish the results inside your company so the next team does not repeat the work.\n\nFinally, price what you measured. Multiply the request count from your test by the rates on the provider’s current pricing page, and extrapolate to a month. If the rate for asymmetric operations differs from the $0.03 per 10,000 requests in AWS’s worked example, you will see it in the first invoice, so run the test on a billing account with alerts enabled.\n\n## Verdict: AWS KMS Leads on Verified Post-Quantum Key Establishment\n\nThe takeaway: AWS KMS is the strongest choice today if your priority is quantum-resistant key establishment, because it is the only one of the three with an official, dated and generally available ML-KEM release across all three FIPS 203 parameter sets. It also publishes the clearest price card, $1 per customer-managed key per month with two $1 rotation charges, and it protects private keys in FIPS 140-3 Level 3 HSMs. Its limits are real. Three Region groups are excluded, the ML-KEM request price is unstated, and your code must change before anything benefits.\n\nGoogle Cloud KMS deserves the shortlist spot for signature-heavy workloads. Reports of general-availability ML-DSA and SLH-DSA since July, plus a migration-monitoring feature, suit firmware and certificate teams. The weak point is evidence. Confirm status in the console and in Google’s own documentation before you sign anything, and settle the conflicting reports on ML-KEM in writing with your account team.\n\nAzure Key Vault comes third on post-quantum readiness for now. AES key wrapping in Premium preview is a sensible step away from RSA wrapping, and Managed HSM remains a credible single-tenant option, but the documentation reviewed lists no finalized post-quantum key types. Microsoft Ignite runs November 17 to 20, 2026, and Azure teams should watch it for algorithm announcements. A preview feature is a roadmap signal and not a procurement basis.\n\nFor the wider algorithm picture behind these services, the [ML-KEM, ML-DSA and SLH-DSA comparison](https://shattered.io/ml-kem-ml-dsa-slh-dsa-compared-2026/) covers the standards themselves, and the [cryptography section](https://shattered.io/category/cryptography/) collects the rest of the series. Whichever cloud you run, start the inventory now. NIST’s 2030 key-establishment milestone leaves little slack for a fleet that has never counted its RSA keys.\n\n## Frequently Asked Questions\n\n**Does AWS KMS support ML-KEM?**\n\nYes. AWS added ML-KEM-512, ML-KEM-768 and ML-KEM-1024 support on October 26, 2026, through the Encapsulate and Decapsulate operations. It is available in AWS Regions where KMS runs, except the Middle East (UAE), Middle East (Bahrain) and China Regions.\n\n**Is Azure Key Vault post-quantum safe?**\n\nPartly at best. Microsoft put AES key wrapping into public preview for Key Vault Premium on August 5, 2026, as an alternative to RSA wrapping. The key documentation reviewed does not list generally available ML-KEM, ML-DSA or SLH-DSA key types, so Key Vault is not post-quantum across the board.\n\n**Does Google Cloud KMS offer post-quantum signatures?**\n\nReports say yes. Google reportedly announced general availability of ML-DSA and SLH-DSA signatures in Cloud KMS on July 28, 2026. Reports disagree on whether ML-KEM is in preview or generally available, so check Google’s current documentation for your Region.\n\n**How much does AWS KMS cost?**\n\nAWS lists customer-managed keys at $1 per key per month, prorated hourly. The first and second rotations each add $1 per month. AWS-managed and AWS-owned keys carry no storage charge, and 20,000 requests per month are free, with some asymmetric operations excluded. AWS’s worked example prices requests at $0.03 per 10,000.\n\n**Will my existing applications become quantum-safe automatically?**\n\nNo. TechInformed reported that existing applications will not use the new ML-KEM keys until developers change them. Your code must create or reference the keys, run the key-agreement steps and feed the result into a separate data-encryption process.\n\n**Which ML-KEM parameter set should I choose?**\n\nAWS offers all three sets, and each step up trades bigger keys and ciphertexts for a higher security category. Follow the guidance in your own compliance regime, and test the message-size cost of the larger sets in your real protocol path before you commit.\n\n**When are RSA and elliptic-curve algorithms disallowed?**\n\nNIST’s final IR 8547, published October 27, 2026, deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them under NIST standards after 2035. Reports put federal high-value system deadlines at December 31, 2030 for key establishment and December 31, 2031 for signatures.\n\n**Does ML-KEM replace AES for encrypting data?**\n\nNo. ML-KEM only establishes a shared secret between two parties. A symmetric cipher such as AES-256 in an authenticated mode still encrypts the data itself, using a key derived from that secret.", "url": "https://wpnews.pro/news/aws-kms-vs-azure-vs-google-kms-1-keys-pqc-2026", "canonical_source": "https://shattered.io/aws-kms-vs-azure-key-vault-vs-google-cloud-kms-post-quantum-pricing-2026/", "published_at": "2026-11-03 12:30:54+00:00", "updated_at": "2026-11-03 12:54:05.202395+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-safety"], "entities": ["AWS Key Management Service", "Azure Key Vault", "Google Cloud KMS", "Daily AWS", "TechInformed", "Microsoft", "ML-KEM", "FIPS 140-3"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/aws-kms-vs-azure-vs-google-kms-1-keys-pqc-2026", "markdown": "https://wpnews.pro/news/aws-kms-vs-azure-vs-google-kms-1-keys-pqc-2026.md", "text": "https://wpnews.pro/news/aws-kms-vs-azure-vs-google-kms-1-keys-pqc-2026.txt", "jsonld": "https://wpnews.pro/news/aws-kms-vs-azure-vs-google-kms-1-keys-pqc-2026.jsonld"}}