Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Globale regionsübergreifende Inferenz

Globale regionsübergreifende Inferenz erweitert regionsübergreifende Inferenz über geografische Grenzen hinaus und ermöglicht die Weiterleitung von Inferenzanfragen an unterstützte Unternehmen weltweit. AWS-Regionen

Vorteile globaler regionsübergreifender Inferenz

Die globale regionsübergreifende Inferenz für das Anthropic Claude Sonnet 4.5-Modell bietet die folgenden Vorteile gegenüber einem geografischen regionsübergreifenden Inferenzprofil:

Überlegungen zur globalen regionsübergreifenden Inferenz

Beachten Sie die folgenden Informationen zur globalen regionsübergreifenden Inferenz:

IAM-Richtlinienanforderungen für globale regionsübergreifende Inferenz

Um die globale regionsübergreifende Inferenz für Ihre Benutzer zu ermöglichen, müssen Sie eine dreiteilige IAM-Richtlinie auf die Rolle anwenden. Im Folgenden finden Sie ein Beispiel für eine IAM-Richtlinie zur detaillierten Steuerung. Sie können die Beispielrichtlinie durch die Richtlinie ersetzen, <REQUESTING REGION> in der AWS-Region Sie arbeiten.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.<MODEL NAME>"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "<REQUESTING REGION>"
                }
            }
        },
        {
            "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:<REQUESTING REGION>::foundation-model/<MODEL NAME>"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "<REQUESTING REGION>",
                    "bedrock:InferenceProfileArn": "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.<MODEL NAME>"
                }
            }
        },
        {
            "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:::foundation-model/<MODEL NAME>"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "unspecified",
                    "bedrock:InferenceProfileArn": "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.<MODEL NAME>"
                }
            }
        }
    ]
}

Der erste Teil der Richtlinie gewährt Zugriff auf das regionale Inferenzprofil in Ihrer Anfrage. AWS-Region Der zweite Teil bietet Zugriff auf die regionale FM-Ressource. Der dritte Teil gewährt Zugriff auf die globale FM-Ressource, wodurch die regionsübergreifende Routing-Funktion aktiviert wird.

Nehmen Sie bei der Implementierung dieser Richtlinien alle drei Ressourcennamen (ARNs) von Amazon Resource Names (ARNs) in Ihre IAM-Kontoauszüge auf:

Für den globalen FM-ARN ist kein AWS-Region OD-Konto angegeben, was beabsichtigt und für die regionsübergreifende Funktionalität erforderlich ist.

Deaktivieren Sie die globale regionsübergreifende Inferenz

Sie können zwischen zwei Hauptansätzen wählen, um Ablehnungsrichtlinien für globale CRIS für bestimmte IAM-Rollen zu implementieren, die jeweils unterschiedliche Anwendungsfälle und Auswirkungen haben:

Bei der Implementierung von Ablehnungsrichtlinien ist es wichtig zu verstehen, dass globales CRIS das Verhalten des aws:RequestedRegion Feldes verändert. Traditionelle AWS-Region Ablehnungsrichtlinien, die StringEquals Bedingungen mit bestimmten AWS-Region Namen verwenden, wie "aws:RequestedRegion": "us-west-2" zum Beispiel, funktionieren bei globalem CRIS nicht erwartungsgemäß. Der Dienst setzt dieses Feld auf und global nicht auf das eigentliche Ziel AWS-Region. Wie bereits erwähnt, "aws:RequestedRegion": "unspecified" führt dies jedoch zum Ablehnungseffekt.

Anforderungen der Service Control Policy für globale regionsübergreifende Inferenz

Für globale regionsübergreifende Inferenzen gilt: Wenn die Sicherheitsrichtlinie Ihres Unternehmens SCPs verwendet, um ungenutzte Regionen zu blockieren, müssen Sie Ihre regionsspezifischen SCP-Bedingungen aktualisieren, um den Zugriff mit zuzulassen. "aws:RequestedRegion": "unspecified" Diese Bedingung ist spezifisch für die globale regionsübergreifende Inferenz von Amazon Bedrock und stellt sicher, dass Anfragen an alle unterstützten Handelsregionen weitergeleitet werden können. AWS

Das folgende SCP-Beispiel blockiert alle AWS API-Aufrufe außerhalb der genehmigten Regionen und erlaubt gleichzeitig globale regionsübergreifende Inferenzrufe von Amazon Bedrock, die als Region für das globale Routing verwendet werden: "unspecified"

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideApprovedRegions",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "us-east-1",
                        "us-east-2",
                        "us-west-2",
                        "unspecified"
                    ]
                }
            }
        }
    ]
}

Deaktivieren Sie die globale regionsübergreifende Inferenz

Unternehmen, die Anforderungen an den Speicherort von Daten oder die Einhaltung von Vorschriften haben, sollten prüfen, ob die globale regionsübergreifende Inferenz ihrem Compliance-Rahmen entspricht, da Anfragen möglicherweise in anderen unterstützten kommerziellen Regionen bearbeitet werden. AWS Um die globale regionsübergreifende Inferenz explizit zu deaktivieren, implementieren Sie die folgende SCP-Richtlinie:

{
    "Effect": "Deny",
    "Action": "bedrock:*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:RequestedRegion": "unspecified"
        },
        "ArnLike": {
            "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*"
        }
    }
}

Dieser SCP lehnt explizit die globale regionsübergreifende Inferenz ab, da die "aws:RequestedRegion" is "unspecified" - und die "ArnLike" Bedingung auf Inferenzprofile mit dem Präfix im ARN abzielen. global

AWS Implementierung des Control Towers

Von der manuellen Bearbeitung der vom AWS Control Tower verwalteten SCPs wird dringend abgeraten, da dies zu Abweichungen führen kann. Verwenden Sie stattdessen die von Control Tower bereitgestellten Mechanismen, um diese Ausnahmen zu verwalten. Zu den Kernprinzipien gehört entweder die Erweiterung vorhandener Kontrollen zur Verweigerung von Regionen oder die Aktivierung von Regionen und die anschließende Anwendung einer benutzerdefinierten, bedingten Sperrrichtlinie.

Eine ausführliche, schrittweise Anleitung zur Implementierung regionsübergreifender Inferenz mit Control Tower finden Sie im Blogbeitrag Enable Amazon Bedrock Cross-Regional Inference in Umgebungen mit mehreren Konten. Dazu gehören die Erweiterung vorhandener Region Deny SCPs, die Aktivierung verweigerter Regionen mit benutzerdefinierten SCPs und die Verwendung von Customizations for AWS Control Tower (CfCT) zur Bereitstellung benutzerdefinierter SCPs als Infrastruktur als Code.

Erhöhung des Anforderungslimits für globale regionsübergreifende Inferenzen

Wenn Sie globale CRIS-Inferenzprofile verwenden, können Sie globales CRIS aus über 20 unterstützten Quellen verwenden. AWS-Regionen Dies ist ein globales Limit. Um Kontingente für globale regionsübergreifende Inferenzprofile anzuzeigen, zu verwalten oder zu erhöhen, verwenden Sie die Service Quotas Console oder AWS CLI in der angeforderten Quelle. AWS-Region

Gehen Sie wie folgt vor, um eine Erhöhung des Limits anzufordern:

Berücksichtigen Sie bei der Berechnung Ihrer erforderlichen Kontingenterhöhung die Burndown-Rate. Die Burndown-Rate ist die Rate, mit der Eingabe- und Ausgangstoken in die Token-Quotennutzung für das Drosselungssystem umgewandelt werden. Die folgenden Modelle haben eine 5-fache Burn-Down-Rate für Output-Token (1 Output-Token verbraucht 5 Tokens aus Ihren Kontingenten):

Bei allen anderen Modellen beträgt die Burndown-Rate 1:1 (1 Ausgabetoken verbraucht 1 Token aus Ihrem Kontingent). Für Eingabe-Token beträgt das Verhältnis von Token zu Quote 1:1. Die Gesamtzahl der Tokens pro Anfrage wird wie folgt berechnet:

Input token count + Cache write input tokens + (Output token count x Burndown rate)

Verwenden Sie globale regionsübergreifende Inferenz

Um globale regionsübergreifende Inferenz mit Claude Sonnet 4.5 von Anthropic zu verwenden, müssen Entwickler die folgenden wichtigen Schritte ausführen:

Globale regionsübergreifende Inferenz wird unterstützt für:

Implementieren Sie globale regionsübergreifende Inferenz

Die Implementierung globaler regionsübergreifender Inferenz mit Claude Sonnet 4.5 von Anthropic ist unkompliziert und erfordert nur wenige Änderungen an Ihrem vorhandenen Anwendungscode. Das Folgende ist ein Beispiel dafür, wie Sie Ihren Code in Python aktualisieren können:

import boto3
import json
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
model_id = "global.anthropic.claude-sonnet-4-5-20250929-v1:0"  
response = bedrock.converse(
    messages=[{"role": "user", "content": [{"text": "Explain cloud computing in 2 sentences."}]}],
    modelId=model_id,
)

print("Response:", response['output']['message']['content'][0]['text'])
print("Token usage:", response['usage'])
print("Total tokens:", response['usage']['totalTokens'])