Choose a Cloud Provider

Four Ways to Reach the Same Model

Claude can be reached through the direct Anthropic API, Amazon Bedrock, Google Cloud's Vertex AI, and Microsoft Foundry. The model behind each path is the same family, and the Messages API is the same interface, so the choice is rarely about the quality of the answers. It is about the constraints around the application: where its data may be processed, which cloud the organization already pays for, which features it needs first, and how its teams prefer to manage access and billing.

This lesson sets out those constraints as criteria, shows how to turn them into a decision that can be explained and revisited, and warns about the choices that look attractive but cause trouble later. The decision is worth making deliberately, because switching platforms later means changing clients, identifiers, credentials, and tests.

The Criteria

Five questions usually decide the matter, and they should be answered in this order:

The order reflects how hard each constraint is. A residency rule cannot be traded away, a feature gap can be planned around, and a price difference is usually small compared with the cost of a second identity system.

Features Are Not Uniform

The feature set can differ by platform and by date. A tool, a beta option, or a newer model may be available on the direct API before it reaches a cloud, or on one cloud before another. The documentation for each platform carries a feature table, and it should be read for every capability the application depends on, rather than assumed from the direct API's documentation.

The practical consequence is a checklist. For each feature the application needs, the team confirms availability on each candidate platform, and records the answer with its date. A platform that lacks one required feature is not automatically wrong, but it must be excluded for the features that depend on that one.

A Decision Function

A decision written as code can be reviewed, tested, and rerun when constraints change. The function below applies the criteria in order. It takes a profile of the application, and returns the platform with a stated reason, so the outcome can be explained to anyone who asks:

"""choose_provider.py: apply the selection criteria in order, and explain the result."""

PLATFORM_CLOUD = {"direct": "none", "bedrock": "aws", "vertex": "gcp", "foundry": "azure"}


def recommend(profile: dict) -> tuple[str, str]:
    candidates = ["direct", "bedrock", "vertex", "foundry"]

    residency = profile.get("residency_platforms")
    if residency:
        candidates = [p for p in candidates if p in residency]
        if not candidates:
            return "none", "no platform meets the residency requirement"
        if len(candidates) == 1:
            return candidates[0], "only platform in the residency set"

    gaps = profile.get("unsupported", {})
    candidates = [p for p in candidates
                  if not (profile.get("features", set()) & gaps.get(p, set()))]
    if not candidates:
        return "none", "no platform supports every required feature"

    cloud = profile.get("existing_cloud")
    if cloud:
        for platform in candidates:
            if PLATFORM_CLOUD[platform] == cloud:
                return platform, f"uses the existing commitment on {cloud}"

    return candidates[0], "direct API: simplest path when no cloud constraint applies"


if __name__ == "__main__":
    scenarios = {
        "cloud commitment": {"existing_cloud": "aws", "features": {"tool_search"}},
        "no constraints": {"features": {"computer_use"}, "unsupported": {"bedrock": {"computer_use"}}},
        "residency": {"residency_platforms": {"vertex"}, "features": set()},
    }
    for name, profile in scenarios.items():
        platform, reason = recommend(profile)
        print(f"{name}: {platform} ({reason})")

Output:

cloud commitment: bedrock (uses the existing commitment on aws)
no constraints: direct (direct API: simplest path when no cloud constraint applies)
residency: vertex (only platform in the residency set)

How It Works

1. The residency rule runs first and can remove every candidate. When the required platforms are known, only those remain, and the function explains when none qualifies.
2. Feature gaps remove platforms next. A platform is dropped when it lacks any feature the application needs, which is how a missing capability becomes a visible exclusion rather than a surprise later.
3. The existing cloud commitment decides among what remains. The first remaining platform on the organization's cloud is chosen, and the reason says so.
4. The default is the direct API, because it is the simplest path with no cloud dependency, and a cloud should be chosen only when a constraint asks for it.
5. Every result carries a reason. A decision that cannot be explained cannot be audited, and the reasons make it possible to see which criterion decided each case.

Revisiting the Decision

Constraints change. A new residency rule, a new cloud agreement, or a feature that arrives on one platform can all reverse an earlier choice. The decision function is a record of the reasoning at one moment, and it should be rerun when the profile changes, with the old and new outcomes compared. A change in the outcome is a signal to plan a migration, which involves the client, identifiers, credentials, and tests from the lessons that follow.

Avoiding Premature Choices

A common mistake is to choose the cloud before the requirements are known, usually because it is familiar. The decision then becomes a justification rather than a comparison. Writing the criteria down first, and checking each candidate against them, keeps the choice honest, even when the answer happens to be the one the team expected.

Summary

The four paths reach the same model, and the choice depends on the application's constraints: residency rules, existing cloud commitments, feature availability, operations, and cost, in that order of weight. Features differ across platforms and over time, so each required feature must be checked on each candidate. A decision written as code, which applies the criteria in order and states its reasons, is easy to review and to revisit. The next lesson turns to the practical question of how a team configures each provider's client once it has chosen.