Direct API, Azure or AWS Bedrock: How to compare AI hosting security

Azure or AWS Bedrock may better fit a company's existing access, network, and infrastructure requirements. But using either platform does not automatically make a system safer than using the model provider's direct API. The choice depends on four specific things: which model, where the data is processed, which storage regime applies to that model, and which settings the company can support.

The main condition: it is worth comparing the same task with the same data sensitivity, not brands. The terms of one model do not apply to the entire platform catalog, and storage mode does not mean network isolation.

After the article, you will be able to draw up a matrix of your company's requirements, check three options against the same criteria, and run a test in a trial project. This is a comparison of approaches based on vendor documentation reviewed for this article on October 11, 2026, not an audit of your account. Conditions change, so verify the current terms before deciding.

What requirements determine the choice

The question "which is safer" has no answer until the requirements are stated. Here are seven that usually make the choice.

Geography. Where data is allowed to be processed and stored. These are two different issues: data can be stored in one geography and processed in another. If the company has an obligation to keep the processing in a certain geography, for example in the EU, this point becomes the first filter.

Network. Should traffic to the model go through private network connections, or is public internet with encryption acceptable. For companies with their own cloud network, this is often a critical requirement.

Access. Who issues and revokes keys, how roles are tied to employees, whether a single company identification system is used.

Logs. What actions with the model are recorded, where the logs are stored and who analyzes them. Separately: what logs the supplier keeps and what is recorded in them.

Agreement. What document governs data processing, who is a party to the agreement and whose terms apply to a specific model.

Model set. Is the desired model available on the platform, in the desired region, and in the desired deployment type. Platform catalogs differ, and a new model may appear on one platform earlier than on another.

Operations Team. Who will configure and maintain the environment. A cloud platform provides many controls, but each of them has to be configured, tested and updated by someone.

Direct API

A direct API means that the company works with the model provider directly, without a cloud intermediary. The chain is the shortest: your application and the provider. Let's look at the example of OpenAI according to its documentation on data in the API.

Training. According to the documentation, starting March 1, 2023, data sent to the API is not used to train or improve OpenAI models, unless the client has explicitly agreed to share the data.

Abuse Monitoring Logs. General policy provides up to 30 days of logs by default; the documentation table specifies the terms and exceptions for each endpoint. This does not mean the same term for all objects and functions. They may be kept longer if required by law or if reasonably necessary to protect the Services or third parties.

ZDR and MAM modes. Zero Data Retention and Modified Abuse Monitoring exclude client content from monitoring logs. Both modes require OpenAI's prior approval and acceptance of additional terms; exceptions apply for certain inputs and functions. Documentation also describes Private Retention with PSP and Safety Retention: Customer and model specific conditions may change with prior written notice. Therefore, the actual prescribed regimen is checked, not just the initial approval of the ZDR. Not all API capabilities are supported by ZDR. For example, Assistants, vector stores, files, batch processing, and training tasks are not listed as compatible with ZDR.

Application State. Separate from logs, there is data that is stored to make features work. For example, Responses API responses are stored for at least 30 days by default, while assistants, streams, and vector stores are stored until they are deleted.

Geography. OpenAI offers data storage in multiple regions, with supported regional processing for the study date in the US, Europe (EEA + Switzerland), and the UAE. Availability depends on endpoint, model and mode; settings apply at the project level. Regions outside the US require agreed storage controls and an additional Modified Retention Agreement; UAE requires additional approval.

Which is left up to the company. API key storage, access segregation between teams, custom application logs, network security of servers making requests. Separately, review administrator authentication, application request authorization, network connectivity, and auditing. Having SSO to login to the platform is not the same as authorizing every API call.

Azure

For a company that already maintains access, network and logs in Azure, the advantage of the platform is primarily organizational. The model falls into the same management system that the team already uses. This is an advantage of the company's configuration and processes, not a property of the brand.

Microsoft describes data processing for the models that Azure sells in Microsoft Foundry as follows:

• requests and responses are not available to OpenAI and other model providers sold by Azure;
• they are not used by vendors to improve their models and are not used to train underlying generative models without the client's permission;
• models do not interact with services managed by their providers, such as ChatGPT or the OpenAI API.

Geography of deployment

Here is the most important distinction that is easy to miss. The name of the resource region does not always describe exactly where the data is processed. The documentation distinguishes between three options:

Therefore, for a company with an obligation to process data in the EU, a Global deployment does not meet this requirement, even if the resource is created in the European region. DataZone EU limits processing to EU states, while standard deployment limits it to resource geography. For batch processing, the documentation specifically states that the data is stored in the customer's geography, but processing can occur in any geography where the model is deployed.

Abuse monitoring and stored data

Requests and responses that the monitoring system has flagged as suspicious can be saved for human review. Storage takes place in the geography of the resource. Only authorized Microsoft employees have access through separate secure procedures, and for deployments in the European Economic Area, those employees are located in the EEA. Customers can apply for modified abuse monitoring: if approved, there is no human storage and review, although automated review is possible. The retention period is not specified on this page, the documentation refers to a separate article on abuse monitoring.

Function data is stored separately: history of Responses API messages, assistant streams, saved request-response pairs, downloaded files. They are stored in the client's resource in the same geography and can be deleted by the client. The documentation warns that models and functions in preview may not support all the conditions described.

Bedrock

AWS applies a shared responsibility model to Bedrock. AWS is responsible for protecting the global infrastructure, while the customer controls their content and is responsible for configuring the security of the services they use.

Model Provider Isolation. In each region where Bedrock is available, each model provider has a separate deployment account owned and managed by the Bedrock team. Model providers do not have access to these accounts and therefore, according to the documentation, do not have access to Bedrock logs and customer requests and responses.

Access and Logs. AWS recommends that you grant users only the rights they need to work through IAM Identity Center or IAM, use multi-factor authentication, log activity through CloudTrail, and use TLS: TLS 1.2 is required, TLS 1.3 is recommended. Separately, the documentation warns against entering confidential data into tags and arbitrary text fields, as they may end up in billing or diagnostic logs.

Storage modes depend on the model

The statement "Bedrock never stores requests" cannot be used in general. The current documentation describes several storage modes, and which one works depends on the account settings and the requirements of the specific model.

A few details that change the conclusions:

• The model may require certain mode. Some providers require human verification as a condition of accessing the model. As of 10/11/2026, the documentation calls the following models of Claude Fable 5 and Claude Fable 5.1: under standard conditions, they are not available in none and default modes; separate ZDR admission is possible only after individual approval for account and model. Most other models do not require human verification.
• Priority of settings. The first value other than inherit takes effect, in order: project, region-specific account, model default value. A project level exists for bedrock-mantle; Bedrock Runtime and control plane do not have this concept. The setting does not apply to other regions.
• store=false limit. In default mode, the store=false parameter does not guarantee zero storage. The none mode is documented to prevent long-term storage of these AWS requests and responses. This does not disable your own logs or saves in individual integrations.
• Cross-Region Processing. If cross-region inference is used, the stored data is stored in the region where the request is actually processed.
• How ​​to check and fix. As of the date of research, there is no console interface for this setting, the mode is set via API. The model-specific mode signal is available via the bedrock-mantle API; The Bedrock control plane does not provide such a signal, and the allowed modes can be fixed by the organization's policies through a conditional IAM key.

Comparison matrix

Each line below can be verified by a document or a test. Cells describe what to check, rather than giving a grade.

Study example: two scenarios, one task

Both scenarios are fictional. The task is the same: AI succinctly summarizes customer support requests that contain names and contacts. The sensitivity of the data is the same.

Scenario A. The company already maintains accesses and logs in Azure and has an obligation to process data in the EU. The presence of the Microsoft brand does not solve anything here. Decides the deployment type. Global is not suitable, because processing is possible in any geography where the model is deployed. DataZone EU restricts processing by EU countries. Standard regional deployment limits it to the geography of the resource. Next, the team checks whether the required model is available in the appropriate region and deployment type, whether features that retain data are used, and whether modified abuse monitoring is required. Azure's advantage in this scenario is real, but it comes from the company's existing processes.

Scenario B. There is no cloud team in the company. Azure or Bedrock provide many controls, but each of them must be configured and maintained: roles, network, logs, storage mode policies. Time and money for setup and maintenance are added to the cost of the model. Without a human to handle this, a complex platform may provide less real control than a simpler direct API with regionalized processing. If the requirement strictly limits processing by EU states, the OpenAI Europe region (EEA + Switzerland) does not confirm it by itself. Verification of exact contractual and technical limits is required; the convenience of a direct API does not make up for inappropriate geography.

The conclusion from both scenarios is the same: the right choice is determined by the requirements and resources of the company, not the name of the platform.

Verification procedure

The matrix provides a hypothesis. Confirms its test in a trial project on the same problem and with the same types of data (test, not real).

Model and Region Check that the model you want is available in the right region and deployment type. For Azure, commit the deployment type. For Bedrock, check your region settings; the effective model mode and allowed_modes are also available via bedrock-mantle. For Runtime, consider the API differences and check the validity of the call with a test.

Rights. Create roles with minimum rights: separate for application, separate for administrators. Verify that a worker without the required role cannot call the model or change storage settings.

Deleting. Check what feature data is stored (response history, files, streams, vector stores) and how to delete it. Remove the test objects and check their unavailability in the interface and API. This is a post-deletion access check, not a proof of clearing all backup copies or safety logs: their terms are set by individual terms of the provider.

Audit. Verify that model calls and setting changes are captured in logs that your team actually views.

Availability. Check the limits, delay and behavior when the model is not available in the selected region. If a different region or type of deployment is required to circumvent the restrictions, this changes the geography inference.

What to do in the near future:

1. Write down the seven requirements of the company: geography, network, access, logs, contract, models, team.
2. Select one task with fixed data sensitivity to compare.
3. Fill in the matrix for the three options with direct links to the documentation and the date of inspection.
4. For Azure, fix the deployment type, for Bedrock the storage mode of a specific model, for the direct API you need the modes and region.
5. Take a test in the trial project: model and region, rights, deletion, auditing, accessibility.
6. Document the solution and assign a person to re-check conditions after changes to the models or documentation.

Frequently asked questions