ChatGPT Enterprise is now available through AWS Marketplace, but buying it through your AWS account does not put the workspace inside your AWS environment or guarantee that all customer data stays on AWS. For German enterprise buyers, the useful change is a procurement route with potentially eligible commitment spend—not a replacement for workspace, residency and connected-tool approval. Obtain the private offer and a feature-specific deployment record before enabling sensitive workflows.
What changed—and what stayed the same
On 9 November 2026, OpenAI announced ChatGPT Enterprise availability through AWS Marketplace. It says customers receive the same models, features and functionality as direct OpenAI customers, with new features released at the same time. The offering brings together ChatGPT, ChatGPT Work, Codex and dots. Eligible customers can also access the Healthcare and Financial Services offerings through this channel; eligibility must be confirmed with the OpenAI or AWS account team.
The AWS Marketplace listing identifies OpenAI as the seller and describes a product experience managed by OpenAI. Purchasing and billing run through Marketplace. This is not an announcement of downloadable weights, a self-hosted ChatGPT edition or an application deployed into the buyer’s own VPC.
There is a practical distinction from Amazon Bedrock. OpenAI describes Bedrock as a route for developers building applications and agents with models, while ChatGPT Enterprise supplies the employee-facing workspace experience. Choosing the Marketplace listing therefore does not specify a Bedrock endpoint for the workspace. Evaluate these as different service architectures, even when both appear in the same cloud budget.
Read the offer before counting commitment savings
The listing offers custom pricing through a private offer, based on requirements and eligibility. There is no public universal seat price in the reviewed listing. It says eligible consumption can count toward an AWS EDP or PPA commitment, subject to the buyer’s agreement. Do not turn that conditional statement into a guaranteed discount or assume every line item qualifies.
Ask the account teams to identify the eligible charges, purchasing account, billing period, commitment treatment, service scope and renewal terms in the actual offer. For an existing direct customer, also establish how the agreement and workspace transition would work; the announcement does not document an automatic migration or permission to cancel existing obligations. Those are unresolved contract questions, not missing engineering steps that can be solved by switching an API key.
The economic comparison should separate software price, commitment utilization and rollout cost. Using committed spend can simplify budget allocation without lowering the quoted service price. Conversely, a cheaper purchasing route is not useful if the required feature cannot satisfy the approved data boundary. The existing supplier control-plane guidance provides the foundation for keeping the commercial supplier record linked to the actual service configuration.
The important sentence beneath “Deployed on AWS”
The Marketplace page carries a “Deployed on AWS” label, but its detailed text explicitly states that purchasing through Marketplace does not guarantee that all customer data remains on AWS infrastructure or within the customer’s AWS environment. It identifies OpenAI as the data processor and says OpenAI engages subprocessors, including AWS. A purchasing badge is therefore not sufficient evidence for a private-network or regional-processing requirement.
OpenAI’s data and inference residency documentation distinguishes storage at rest from GPU execution. Europe, defined there as EEA plus Switzerland, is supported for both, subject to eligibility and configuration. Inference residency requires data residency in the same region. Neither control confines all processing to that region: CPU-based processing, authentication, routing and external integrations can have different boundaries.
This matters for a requirement written as “EU-only processing.” EEA plus Switzerland is not identical to the EU, and GPU residency is not a promise about every processing step. Have privacy and legal specialists assess the required contractual and transfer arrangements. This article provides engineering review criteria, not a legal determination of whether a particular deployment is permitted.
The documentation also lists feature exclusions, including Codex Web, third-party GPTs and features not generally available; it distinguishes Codex Web from the supported Codex app and CLI. Do not extend a workspace-level assurance to every component named in a commercial bundle. Review each intended feature against its current documented coverage. A residency setting for one service must not be borrowed from another, as the Agents API hosting-boundary analysis illustrates for a different product.
A procurement-to-workspace handoff that can be tested
Consider a German engineering department buying seats to review maintenance documents and assist with internal code. This is an illustrative scenario, not a customer implementation report. The commercial owner verifies the private offer. The workspace owner independently verifies the actual workspace ID, storage region, inference region, allowed features and connected apps. Security reviews tool permissions and data categories. Approval is attached to that combination—not merely to an AWS purchase order.
OpenAI documents an administrator check under Workspace settings, General: Data Residency Region and, where shown, a separate Inference Residency Region. These are displays of the configured regions, not controls for changing them. If a value is missing or unclear, obtain clarification rather than treating the purchase location or billing account as a substitute.
Use synthetic documents and a non-production repository for acceptance. Confirm the workspace selected by the test user, then exercise each approved feature. Try a prohibited connector and check that the intended policy blocks it. Record unexpected availability or unsupported features as findings requiring review. A successful chat response proves service access, not where every backend processing step occurred; regional evidence still needs the provider’s documented scope and configuration confirmation.
Decision checklist before accepting the offer
|
Gate |
Evidence to retain |
Do not infer |
|---|---|---|
|
Commercial |
Private offer and eligible charges |
Every charge reduces the commitment |
|
Workspace |
Workspace ID and configured regions |
AWS billing selects the region |
|
Features |
Residency coverage for each feature |
Every bundled feature is covered |
|
Connected apps |
Allowed tools and blocked-path test |
Workspace residency covers third parties |
|
Release |
Named owners and accepted data classes |
Purchase completion authorizes production |
Retain the offer reference, workspace identity, permitted feature list, configuration evidence, test outcomes and named approvers in one handoff record. Minimize captured content: screenshots and logs should not expose confidential prompts or repository material just to demonstrate that a control exists. Reopen review when the workspace configuration, connected apps, feature scope or relevant supplier terms change.
The trade-off is additional coordination between procurement and platform teams. It is justified when the organization would otherwise confuse a successful purchase with permission to use sensitive data. It should not become an unbounded checklist: select one workload and its actual features, then expand only after that boundary is understood.
What the announcement does not establish
The reviewed sources do not establish a universal price, automatic eligibility for every German customer, automatic commitment credit for every charge, or a documented transition path for every existing direct contract. They also do not show that buying through Marketplace improves model latency or quality. This article is a source-based procurement and architecture analysis, not an independent performance benchmark.
The release does provide a concrete new option for AWS-centric buyers. Use it when the commercial terms help and the intended workspace passes the same deployment review you would require for a direct purchase. If your team needs that review, AI implementation consulting can turn one proposed workflow into an explicit service-boundary record and acceptance plan. The next useful artifact is a matched offer-and-workspace approval—not a blanket declaration that AWS billing makes the entire bundle production-ready.
