An Australian business already running software on AWS now has another route to OpenAI capabilities: Amazon Bedrock. For its developers, that can change where model requests run and how access and usage are managed.
It is a different proposition from buying ChatGPT for the team. The distinction explains who should care about the announcement and who can comfortably start elsewhere.
What actually became available?
AWS announced a limited preview of OpenAI offerings on Bedrock in April 2026. Its 1 June announcement described specified models and Codex as generally available.
That is useful historical context. Current documentation—not the first preview announcement—should establish which models and features are supported now.
There are three ideas to keep separate:
| Offering | What it provides | Who it is mainly relevant to |
|---|---|---|
| ChatGPT | A hosted assistant product with its own interface and account features | People using an assistant directly |
| Model access through Bedrock | Supported models for applications running requests through AWS | Developers building or operating applications |
| Codex configured for Bedrock | A supported route for coding workflows to use Bedrock model access | Development teams evaluating that configuration |
One arrangement does not automatically include every feature of the others.
Why an existing AWS team might care
Imagine a software business already uses AWS for identity management, infrastructure and billing. Its application needs to summarise approved support documents.
The team can investigate whether adding model access through Bedrock fits its existing operating processes more neatly than introducing a separate provider route.
That is a hypothesis to test. Using a familiar platform may simplify some administration, while the application still needs suitable permissions, data handling, monitoring and a fallback.
For a sole trader who wants help drafting a proposal, a hosted assistant may be the more direct starting point. Building an AWS application is not a prerequisite for exploring AI.
Compatibility has boundaries
OpenAI’s Bedrock guide distinguishes model and endpoint capabilities. Familiar API formats do not establish that every tool or response mode is supported.
The guide currently lists hosted web search for the Mantle endpoint, while hosted file search and image-generation tools are not listed as available through Bedrock. These are examples of why a developer should compare the particular features an application needs.
Treat that comparison as dated information and recheck it before implementation. Model catalogues and endpoint support change.
A useful evaluation records the model ID, endpoint, region and required features together, rather than simply recording “OpenAI on AWS”.
An Australian account does not establish Australian processing
Before using business information, check regional availability and the routing for the exact configuration. An account’s billing address is not evidence of where inference, logs or supporting services operate.
Ask the team managing the application to document those flows. Where residency or contractual requirements matter, confirm them against the intended deployment rather than a general marketing claim.
Compare the complete cost and workflow
List model usage, supporting infrastructure, storage, monitoring and the work required to operate the application. Record billing currency and any relevant Australian-dollar budget assumptions.
If you have an existing AWS agreement, establish how the proposed usage is treated under that agreement. Do not import a claimed commercial benefit from another customer’s contract.
A first developer test can use a fictional document and a single well-defined request. Compare answer quality, errors, latency and usage reporting with your alternative.
The reason to choose this route is a better fit for the application and the team operating it. Broader cloud access is useful because it creates another option—not because it makes every business an AWS AI project.