AWS Bedrock and Other Cloud Providers

Mistral’s Cloud Ecosystem

Beyond Azure and Google Cloud, Mistral models are available on several other platforms. This lesson covers AWS Bedrock in detail because it is the most common alternative and differs the most from what you have learned so far. It then briefly covers integrations with Snowflake Cortex, IBM watsonx, and Outscale.

AWS Bedrock

Amazon Bedrock is AWS’s managed service for foundation models. It exposes a unified API in front of multiple providers—Anthropic, Meta, Mistral, and others—handling billing, security, and compliance through AWS. For teams already using AWS, this means Mistral models operate within the same IAM scope, use the same CloudWatch logs, and appear on the same bill as the rest of your infrastructure.

Regarding the catalog, Bedrock provides access to the following models. The exact list depends on your region and changes with new releases; the Model Access page in the console is the source of truth.

Prepare Access

You must meet four conditions before making your first call:

1. An AWS account with access to a region that supports Bedrock
2. An IAM principal with bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream permissions
3. AWS CLI configured and boto3 installed
4. Enable Mistral models in the Bedrock console (Model Access)

pip install boto3>=1.34.131
aws configure  # Enter your credentials

The second permission is the one people often forget: a principal with only bedrock:InvokeModel works in synchronous mode but fails on the first streaming call. Step 4 is similar to enabling models in Google’s Model Garden: until you unlock the model in Model Access, no IAM permission will work.

Call a Model with boto3

Here is the major difference from Azure and Vertex: on Bedrock, you do not use the Mistral SDK. Everything goes through the native AWS SDK, boto3, using the converse() API common to all providers on the platform.

import boto3
import json

client = boto3.client('bedrock-runtime', region_name='us-west-2')

response = client.converse(
    modelId="mistral.mistral-large-2512-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "What are the advantages of a serverless architecture on AWS?"}]
        }
    ],
    inferenceConfig={
        "temperature": 0.3,
        "maxTokens": 1024
    }
)

texte = response["output"]["message"]["content"][0]["text"]
print(texte)

Streaming follows the same logic, using converse_stream() and looping over stream events. Note that you must check for the contentBlockDelta key: the Bedrock stream also carries block start and end events, which contain no text.

response = client.converse_stream(
    modelId="mistral.mistral-large-2512-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Describe the Lambda + API Gateway architecture."}]
        }
    ],
    inferenceConfig={"temperature": 0.3, "maxTokens": 1024}
)

for event in response["stream"]:
    if "contentBlockDelta" in event:
        texte = event["contentBlockDelta"]["delta"].get("text", "")
        print(texte, end="", flush=True)

If you port code written for the direct Mistral API, expect four differences. First, content is no longer a string but an array of {"text": "..."} objects. Second, modelId follows the AWS format mistral.{model}-v{version}:{number}: unlike the -latest aliases in the direct API, you pin a specific version and must update it manually. Third, inference parameters are grouped in a separate inferenceConfig object instead of being passed at the top level. Finally, no Mistral SDK is involved: responses are boto3 dictionaries, not typed models, hence the key-based access shown above.

Snowflake Cortex

Snowflake integrates Mistral models, including Mistral Large, directly into its data platform via Cortex AI. The main advantage is simple: your data never leaves Snowflake. Calling the model becomes a SQL function invoked within a query, right next to the table you want to enrich.

-- Direct use in a SQL query
SELECT SNOWFLAKE.CORTEX.COMPLETE(
  'mistral-large',
  'Summarize this financial report in three key points.'
) AS resume;

Imagine a table with thousands of reports: instead of exporting content to a Python script, calling the API, and reimporting the results, you write a query that directly produces the summary column. This is the obvious choice when your data pipeline already lives in Snowflake and governance rules forbid any data egress.

IBM watsonx

IBM watsonx.ai offers Mistral models, including Mistral Large, in its catalog. Access happens through the watsonx API using IBM Cloud credentials: you instantiate a ModelInference object, passing the model ID, your credentials, and the target project. Note the regional URL in the example—it determines where inference runs, a detail to verify if you have data residency requirements.

from ibm_watsonx_ai import Credentials
from ibm_watsonx_ai.foundation_models import ModelInference

model = ModelInference(
    model_id="mistralai/mistral-large",
    credentials=Credentials(url="https://eu-de.ml.cloud.ibm.com", api_key="..."),
    project_id="your-project-id"
)

response = model.generate_text("Explain the data mesh concept.")

Outscale, the French Sovereign Cloud

Outscale, a French sovereign cloud qualified SecNumCloud, also offers Mistral models. For public sector, defense, or healthcare organizations subject to strict regulatory constraints, this option guarantees that both data and processing remain in France. In these contexts, this is the only criterion that matters: qualification takes precedence over integration convenience or developer experience.

Choose the Right Provider

The choice almost never depends on the models themselves, since the same ones are widely available across platforms. It depends on where your data lives, your contract, and your compliance obligations.

A useful rule of thumb: start with the direct API to validate that the model meets your needs, then migrate to your ecosystem’s provider when the project moves to production. Application code changes little; most of the work involves authentication and model naming.

Check Before Deployment

Cloud provider model IDs are versioned and change with each generation (mistral.mistral-large-2512-v1:0 on Bedrock, for example). Before wiring up a deployment, verify the exact value in the provider console: it is the source of truth, and an outdated ID produces an access error that is hard to diagnose.

Key Takeaways

• AWS Bedrock uses boto3 and the converse() API—not the Mistral SDK
• Bedrock message format differs slightly (content as an array of objects)
• Snowflake Cortex integrates Mistral directly into SQL queries
• IBM watsonx and Outscale offer alternatives for specific needs
• Choose your provider based on your existing cloud ecosystem and regulatory constraints