Claude API authentifizieren: Key, Bedrock, Vertex, Foundry

Die vier Authentifizierungswege der Claude API

Bei der Authentifizierung der Claude API gibt es eine zentrale Entscheidung: Welche Zugangsdaten stellt Ihr Client über das Netzwerk bereit? Dafür gibt es vier Möglichkeiten. Sie sind keine Varianten desselben Mechanismus. Die direkte Anthropic API sendet einen statischen Schlüssel in einem x-api-key-Header. Amazon Bedrock signiert jede Anfrage mit AWS-Anmeldedaten. In dieser Konfiguration gibt es an keiner Stelle einen Anthropic-Schlüssel. Google Cloud sendet ein kurzlebiges Google-Zugriffstoken. Microsoft Foundry verwendet entweder einen von Azure ausgestellten Schlüssel oder ein Microsoft-Entra-Token.

Diese Anleitung beschreibt die Einbindung eines SDK (Software Development Kit) in einen Dienst, der auf einem Linux-Server läuft. Wenn Sie stattdessen das Claude Code-Befehlszeilentool konfigurieren, unterscheiden sich Variablen und Ablauf: siehe Claude Code auf Bedrock oder Vertex verweisen. Wenn der Dienst noch nicht existiert, erstellen Sie ihn zuerst mit eine erste Claude-API-Anwendung auf einem VPS und kehren Sie anschließend für die Zugangsdaten hierher zurück.

Alle folgenden Angaben wurden im August 2026 mit der Plattformdokumentation von Anthropic abgeglichen. Modellbezeichnungen, Preise, SDK-Versionen und Endpunktstrukturen ändern sich regelmäßig. Deshalb verweist diese Anleitung für diese Angaben auf die Seiten der jeweiligen Anbieter, anstatt Werte auszugeben, die schnell veralten.

Route 1: ein Anthropic API key

Dies ist der direkte Weg und der einzige, bei dem Anthropic das Secret ausstellt. Anfragen gehen an den Messages-Endpunkt auf dem API-Host von Anthropic. Jede Anfrage enthält drei Header.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Ersetzen Sie MODEL_ID durch eine aktuelle Kennung aus der Modellübersicht von Anthropic. Eine erfolgreiche Antwort ist JSON und enthält ein content-Array sowie ein usage-Objekt. Ein falscher oder abgelaufener Key führt zu HTTP 401 mit authentication_error. Ein fehlender anthropic-version-Header ist ein separater Fehler, weil dieser Header bei jeder Anfrage erforderlich ist. Die SDKs setzen ihn für Sie.

Die Client-Erstellung ist bei dieser Variante am kürzesten, weil nichts erstellt werden muss. Jedes offizielle SDK liest ANTHROPIC_API_KEY selbstständig aus der Umgebung.

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

Es lohnt sich, die Modellkennung neben dem Key in der Umgebung zu speichern. Modellnamen ändern sich nach einem Zeitplan, den Sie nicht steuern können. Ein Redeployment des Codes, nur um eine Zeichenfolge zu ändern, ist vermeidbare Arbeit.

Keys werden in der Console erstellt. Dort wählen Sie bei der Erstellung eine Ablaufdauer aus: 3 Stunden, 1 Tag, 7 Tage oder 30 Tage, eine benutzerdefinierte Dauer oder Never. Die Ablaufdauer wird bei der Erstellung festgelegt und kann später nicht geändert werden. Anthropic benachrichtigt den Ersteller des Keys per E-Mail, bevor ein langlebiger Key abläuft. Bei einem Key mit kurzer Laufzeit wird jedoch überhaupt keine Warn-E-Mail versendet. Ein abgelaufener Key liefert 401 und kann nicht reaktiviert werden. Die Lösung ist daher immer ein neuer Key.

Bei der direkten API wählen Sie keine Region aus. Die Abrechnung erfolgt direkt über Ihre Anthropic-Organisation. Mit Workspaces können Sie einen Key auf ein Projekt beschränken. So lässt sich am zuverlässigsten feststellen, wie viel ein einzelner Dienst ausgibt. Die Berechnung hinter dieser Abrechnung wird unter dem Vergleich der API-Preise pro Token mit einem Abonnement erläutert.

Eine weitere Option gehört hierher, weil sie das statische Secret vollständig entfernt. Workload Identity Federation ermöglicht es einem Workload, bei POST /v1/oauth/token ein OpenID-Connect-(OIDC-)Token eines bereits vertrauenswürdigen Identity Providers gegen ein kurzlebiges Anthropic-Token einzutauschen. Das SDK erneuert dieses Token vor seinem Ablauf. Es wird niemals eine sk-ant-api...-Zeichenfolge erstellt oder irgendwo kopiert. Dieser Ansatz eignet sich für Kubernetes, GitHub Actions und Cloud-VMs, die bereits eine Plattformidentität besitzen. Ein gewöhnlicher VPS hat in der Regel keinen solchen Issuer. Auf diesem System ist ein API key in einer Datei daher die sachliche Lösung. Der restliche Leitfaden geht entsprechend davon aus.

Route 2: AWS-Anmeldedaten für Amazon Bedrock

Für Bedrock benötigen Sie überhaupt keinen Anthropic-Schlüssel. Das SDK signiert jede HTTP-Anfrage mit AWS Signature Version 4 (SigV4) unter Verwendung gewöhnlicher AWS-Anmeldedaten. AWS entscheidet, ob diese Identität das Modell aufrufen darf.

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity gibt die Kontonummer und den ARN (Amazon Resource Name) der Identität aus, auf die Ihre Anmeldedaten aufgelöst werden. Führen Sie den Befehl aus, bevor Sie etwas anderes tun. Wenn er fehlschlägt, schlägt auch der Claude-Aufruf fehl, weil das SDK dieselbe Kette durchläuft: zuerst die Konstruktorargumente, dann die Umgebungsvariablen AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN und AWS_REGION, anschließend die AWS-Konfigurationsdatei und den restlichen Standardmechanismus (SSO, übernommene Rollen, die ECS-Task-Rolle und der Instance Metadata Service).

Bei der Client-Erstellung ändern sich die Klasse und ein Argument.

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

Die Region ist hier keine reine Formalität. Bedrock-Endpunkte gelten jeweils für eine Region, der Modellzugriff wird in der AWS-Konsole pro Region freigeschaltet, und die Region ist Bestandteil der SigV4-Signatur. Eine für eine Region berechnete Signatur wird daher von einer anderen Region abgelehnt. Setzen Sie AWS_REGION explizit in der Dienstumgebung. Anthropic dokumentiert, dass der AnthropicBedrock-Client AWS_REGION ausliest und bei einem nicht gesetzten Wert auf us-east-1 zurückfällt. Für die Region liest er ~/.aws/config nicht aus. Deshalb kann die AWS CLI auf demselben System Claude-Modelle erfolgreich auflisten, während Ihr Python-Prozess fehlschlägt: Die CLI hat Ihre Konfigurationsdatei gelesen, der Client jedoch nicht.

Auf einer EC2-Instanz weisen Sie eine IAM-Rolle (Identity and Access Management) zu. Es wird kein Geheimnis auf der Festplatte gespeichert, weil der Instance Metadata Service dem SDK temporäre Anmeldedaten übergibt. Ein VPS außerhalb von AWS verfügt weder über eine Instance-Rolle noch über einen Metadata Service. Sie müssen dann zwischen dem langfristig gültigen Zugriffsschlüsselpaar eines IAM-Benutzers, das auf dem System liegt und derselben Kategorie von Geheimnissen wie ein Anthropic-Schlüssel angehört, und einer Föderation wählen: Authentifizieren Sie sich bei Ihrem Identity Provider, rufen Sie AWS STS (Security Token Service) auf und verwenden Sie die dabei zurückgegebenen temporären Anmeldedaten. Bedrock akzeptiert über AWS_BEARER_TOKEN_BEDROCK außerdem ein Bearer-Token. Dieses ist laut Dokumentation auf 12 Stunden begrenzt und wird von AWS als am wenigsten bevorzugter Weg beschrieben.

Die Abrechnung erfolgt über Ihr AWS-Konto und nicht über Anthropic. Das ist normalerweise der eigentliche Grund für diese Variante. Regionale Endpunkte haben gegenüber dem globalen Endpunkt einen Aufschlag von 10 %, wie im August 2026 dokumentiert. Einen Bedrock-Fehler sollten Sie kennen, weil er wie ein Berechtigungsproblem aussieht, aber keines ist: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. Das ist ein Routing-Problem des Modells. Eine Änderung der Anmeldedaten behebt es nicht.

Route 3: Google-Anmeldedaten auf Vertex AI

Google Cloud verwendet Application Default Credentials (ADC), eine festgelegte Suchreihenfolge, die die Google-Authentifizierungsbibliotheken verwenden, um Anmeldedaten zu finden, ohne dass Sie diese angeben müssen. ADC prüft zuerst GOOGLE_APPLICATION_CREDENTIALS, danach die von gcloud auth application-default login geschriebene Datei und anschließend das Dienstkonto, das über den Metadatenserver zugewiesen ist.

pip install -U "anthropic[vertex]"
gcloud auth application-default login

Auf einer Workstation schreibt dieser Login $HOME/.config/gcloud/application_default_credentials.json, und Sie sind fertig. Auf einem Server ist dies jedoch das falsche Werkzeug, weil die darin gespeicherten Anmeldedaten einer Person gehören und mit deren Konto ungültig werden. Außerhalb von Google Cloud gibt es ebenfalls keinen Metadatenserver. ADC fällt daher auf GOOGLE_APPLICATION_CREDENTIALS zurück, das auf eine Schlüsseldatei eines Dienstkontos verweist. Diese JSON-Datei ist ein langlebiges Geheimnis und muss genau so behandelt werden, wie später in diesem Leitfaden beschrieben. Innerhalb von Google Cloud weisen Sie der VM ein Dienstkonto zu. Dann gibt es keine Datei, die geschützt werden muss.

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

Wenn Sie unterhalb des SDK direkt HTTP verwenden, ändern sich zwei Dinge. Die Modellkennung wandert aus dem Anforderungstext in den URL-Pfad. anthropic_version wandert aus dem Header in den Text und muss dort vertex-2023-10-16 enthalten. Das Anmeldetoken ist ein gewöhnliches Google-Zugriffstoken.

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Die Region ist ein eigenständiges Argument. global führt für eine bessere Verfügbarkeit ein dynamisches Routing durch. us und eu sind Bezeichner für mehrere Regionen. Ein Name wie us-east5 legt dagegen eine einzelne Region fest. Endpunkte für mehrere Regionen und regionale Endpunkte kosten 10% mehr als globale Endpunkte, wie im August 2026 dokumentiert. Die Abrechnung erfolgt über das Google-Cloud-Projekt. Kontingente und Rechnungen werden daher von Google verwaltet.

Route 4: Microsoft Foundry ist der Azure-Weg

Wenn Sie auf Azure nach Claude gesucht haben, ist dies der gesuchte Abschnitt. Ein unterstützter Weg ist verfügbar. Claude läuft in Microsoft Foundry (früher Azure AI Foundry) und wird über den Azure Marketplace in Claude Consumption Units abgerechnet. Sie erstellen eine Foundry-Ressource, stellen darin ein Claude-Modell bereit und rufen einen von Azure gehosteten Endpunkt unter https://{resource}.services.ai.azure.com/anthropic/v1/* auf.

Es funktionieren zwei Anmeldeinformationen. Die erste ist ein von Azure ausgestellter Schlüssel aus der Registerkarte Details der Bereitstellung im Foundry-Portal. Sie wird in einem api-key- oder x-api-key-Header übertragen. Die zweite ist ein Microsoft Entra-Token. Dieses ist auf einem Server die bessere Wahl, weil dann die rollenbasierte Zugriffskontrolle von Azure festlegt, wer den Endpunkt aufrufen darf.

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Das Feld model enthält den Namen Ihrer Bereitstellung, nicht eine Modellkennung. Standardmäßig stimmen beide überein. Sie stimmen nicht mehr überein, sobald Sie selbst einen Namen für eine Bereitstellung festlegen. Das ist die häufigste Ursache für einen Deployment not found-Fehler bei einer ansonsten korrekten Anfrage. Die Python- und TypeScript-SDKs lesen ANTHROPIC_FOUNDRY_API_KEY und ANTHROPIC_FOUNDRY_RESOURCE aus der Umgebung. Foundry wird nicht von jedem SDK unterstützt: Laut Dokumentation vom August 2026 gilt dies für C#, Java, PHP, Python und TypeScript. Die Go- und Ruby-SDKs benötigen dagegen den generischen Client, der auf die Foundry-Basis-URL zeigt.

Diese Umgehung hat eine wichtige Stolperfalle. Wenn ANTHROPIC_API_KEY weiterhin in der Umgebung gesetzt ist, übernimmt der generische Client diesen Wert und sendet Ihren Anthropic-Schlüssel an einen Microsoft-Endpunkt. Entfernen Sie die Variable aus der Umgebung oder deaktivieren Sie die Umgebungsdefaults im Client. Entra-Token laufen nach etwa einer Stunde ab. Ein langfristig laufender Prozess muss sie daher erneuern, statt ein Token beim Start einmalig einzulesen.

Wie lange ist das Anmeldemittel auf Ihrem Server gültig?

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

Dies sind die von den jeweiligen Anbietern veröffentlichten Obergrenzen und Standardwerte, abgerufen im August 2026, keine Messwerte. Sie sind aus einem Grund relevant: Sie zeigen, wie lange ein offengelegtes Anmeldemittel noch funktioniert, während Sie erst feststellen, dass es offengelegt wurde. Die kurzlebigen Tokens am unteren Ende des Diagramms sind jeweils 1 Stunde gültig. Das SDK erneuert sie automatisch. Die kurze Gültigkeitsdauer verursacht daher keinen zusätzlichen Betriebsaufwand. Eine angenommene Rolle ist 12 Stunden gültig. Ein mit der Voreinstellung für 30 Tage erstellter Schlüssel bleibt 720 Stunden gültig. Dabei handelt es sich um das Anmeldemittel, das einen Monat lang in einer Datei auf Ihrem Server liegt.

Wo die Zugangsdaten auf einem VPS liegen

Legen Sie das Geheimnis in einer Datei ab, die nur root lesen kann, und lassen Sie es von systemd an den Prozess übergeben. Dieser Ansatz bleibt unabhängig von jeder SDK-Version bestehen. Es lohnt sich daher, ihn einmal korrekt umzusetzen.

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

Die Datei enthält einfache KEY=value-Zeilen. Keine export-Zeichen, keine Anführungszeichen und keine Shell-Syntax, weil systemd die Datei selbst auswertet, statt sie über eine Shell auszuführen.

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd liest EnvironmentFile= als root ein, bevor es zu User=claudeapp wechselt. Das Dienstkonto benötigt daher keinen Lesezugriff auf die Datei. Der Modus 600 mit root als Eigentümer ist ausreichend. Deshalb setzt der Befehl install oben die Datei entsprechend. Starten Sie den Dienst mit sudo systemctl enable --now claude-app. Prüfen Sie anschließend mit systemctl status claude-app, ob die Unit den Zustand active (running) erreicht hat, statt in einer Neustartschleife zu laufen.

Vier Dinge sollten Sie aus jeweils einem überprüfbaren Grund vermeiden:

• Schreiben Sie den Schlüssel nicht mit Environment= direkt in die Unit-Datei. Eine Unit unter /etc/systemd/system ist für alle Benutzer lesbar. Daher gibt systemctl cat claude-app das Geheimnis an jeden lokalen Benutzer aus.
• Committen Sie die Datei nicht. .gitignore hält eine neue Datei aus einem Commit heraus, bewirkt aber nichts bei einer bereits committeten Datei, weil die Git-Historie alles behält, was ihr übergeben wurde.
• Bauen Sie das Geheimnis nicht in ein Container-Image ein. ENV-Zeilen und --build-arg-Werte werden in den Image-Layern gespeichert, und docker history --no-trunc gibt sie wieder aus. Das Löschen der Datei in einem späteren Layer entfernt sie nicht aus einem früheren Layer. Übergeben Sie Geheimnisse stattdessen zur Laufzeit mit --env-file oder über eine eingebundene Datei.
• Betrachten Sie die Prozessumgebung gegenüber root nicht als privat. sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ gibt den Schlüssel wieder aus. Das Ziel besteht darin, das Geheimnis von jedem anderen Konto auf dem Server fernzuhalten, nicht von root. root kann es unabhängig von Ihrer Vorgehensweise lesen.

Dieser letzte Punkt definiert die Grenze dessen, was dieser Ansatz leistet. Eine Umgebungsvariable ist ein geeigneter Container für ein Geheimnis, wenn nur der Dienst und root darauf zugreifen können. Sie ist der falsche Container, wenn der Prozess Code ausführt, den Sie nicht selbst geschrieben haben. Alles, was der Prozess ausführen kann, kann auch seine eigene Umgebung lesen. Geheimnisse außerhalb der Reichweite eines KI-Agenten halten behandelt diesen Fall. Dabei handelt es sich um ein anderes Problem mit einer anderen Lösung.

Wie rotiere ich den Schlüssel ohne Ausfall?

Rotieren Sie zuerst nach vorn und widerrufen Sie den alten Schlüssel zuletzt.

1. Erstellen Sie den neuen Schlüssel in der Console im selben Workspace wie den alten.
2. Schreiben Sie ihn mit sudoedit in /etc/claude-app/env.
3. Führen Sie sudo systemctl restart claude-app aus.
4. Vergewissern Sie sich, dass der Dienst Anfragen beantwortet, und widerrufen Sie anschließend den alten Schlüssel in der Console.

EnvironmentFile wird beim Start der Unit gelesen. Ein laufender Prozess behält daher den Wert, den er beim Start erhalten hat. systemctl daemon-reload liest die Unit-Dateien erneut ein, ändert aber nicht die Umgebung eines laufenden Prozesses. Nur ein Neustart übernimmt den neuen Schlüssel. Wenn Sie den Schlüssel bereits in Schritt 1 statt in Schritt 4 widerrufen, entsteht ein Ausfall bis zu Schritt 3.

Bei den drei anderen Verfahren erfolgt die Rotation beim Anbieter. Ein IAM-Benutzer unterstützt gleichzeitig zwei aktive Zugriffsschlüssel. Erstellen Sie daher den zweiten Schlüssel, verteilen Sie ihn und löschen Sie anschließend den ersten. Ein Google-Servicekonto-Schlüssel wird auf dieselbe Weise rotiert. Ein Foundry-Schlüssel wird im Portal neu generiert. Dadurch wird der alte Schlüssel sofort ungültig. Schreiben Sie deshalb den neuen Wert, bevor Sie klicken. Entra-Token und föderierte Anthropic-Token müssen überhaupt nicht rotiert werden. Das ist das stärkste Argument dafür, sie zu verwenden, wenn dies möglich ist.

Setzen Sie in der Console außerdem ein Ausgabenlimit für den Workspace. Ein offengelegter Schlüssel verursacht zuerst Kosten, bevor er zu einem anderen Problem wird. Wie Sie die Ausgaben eines Agents auf einem VPS begrenzen erläutert die entsprechenden Einstellungen.

Warum gibt mein Client 401 oder 403 zurück?

401 mit authentication_error bei der direkten API. Der Schlüssel ist falsch, widerrufen oder abgelaufen. Das Ablaufdatum wird häufig übersehen, weil sich der Code nicht geändert hat und die Anfrage am Vortag noch funktioniert hat. Prüfen Sie die Spalte für das Ablaufdatum des Schlüssels in der Console. Alternativ können Sie expires_at über die Admin API auslesen. Bei Schlüsseln ohne Ablaufdatum ist der Wert null.

Das SDK ignoriert Ihre Federation-Konfiguration und verwendet stattdessen einen Schlüssel. ANTHROPIC_API_KEY und ANTHROPIC_AUTH_TOKEN stehen in der Reihenfolge der Anmeldeinformationen vor Federation. Daher überdeckt jeder dieser Werte die Federation-Konfiguration. Besonders wichtig ist dabei: Eine als leerer String exportierte Variable belegt ihren Platz weiterhin. Dadurch authentifiziert ANTHROPIC_API_KEY="" das SDK mit einem leeren Schlüssel, anstatt zur nächsten Option überzugehen. Verwenden Sie unset ANTHROPIC_API_KEY.

401 mit der unveränderten Meldung Authentication failed bei Federation. Diese Meldung ist absichtlich für alle möglichen Ursachen identisch. Dadurch kann ein Aufrufer die Konfiguration Ihrer Regeln nicht anhand des Fehlertexts ermitteln. Der tatsächliche Grund wird auf der Seite mit dem Authentifizierungsverlauf in der Console aufgezeichnet. Beginnen Sie dort, statt das Problem anhand des JWT zu vermuten.

403 bei Foundry. Das Token wurde erfolgreich authentifiziert, aber Ihrem Azure-Konto fehlt eine Rolle, die den Aufruf erlaubt. Weisen Sie der Identität, die die Anfrage stellt, eine Azure-RBAC-Rolle wie Foundry User (formerly Azure AI User) oder Cognitive Services User zu.

Beliebiger Fehler bei Bedrock. Führen Sie aws sts get-caller-identity zunächst als Servicebenutzer aus. Der Befehl zeigt, ob auf dem System überhaupt nutzbare AWS-Anmeldeinformationen vorhanden sind. Dadurch lässt sich ein Problem mit den Anmeldeinformationen von einem Problem beim Modellzugriff oder einer falschen Region unterscheiden. Der Modellzugriff wird in der AWS-Konsole für jede Region einzeln gewährt. Es ist daher leicht möglich, den Zugriff in einer Region zu aktivieren und anschließend eine andere Region aufzurufen.

FAQ

Benötige ich einen Anthropic-API-Schlüssel, um Claude mit Bedrock oder Vertex zu verwenden?

Nein. Bei Amazon Bedrock signiert das SDK jede Anfrage mit AWS-Anmeldedaten über SigV4. Bei Google Cloud sendet es ein Google-Zugriffstoken, das über Application Default Credentials ermittelt wird. In keiner der beiden Konfigurationen gibt es ein von Anthropic ausgestelltes Geheimnis. Die Nutzung wird stattdessen dem Cloud-Konto und nicht Anthropic in Rechnung gestellt. Deshalb ist ein in ANTHROPIC_API_KEY hinterlegter Anthropic-Schlüssel auf diesen Hosts ebenfalls ein Sicherheitsrisiko: Ein generischer Client, der auf einen Cloud-Endpunkt zeigt, sendet ihn ohne Weiteres dorthin.

Ist Claude in Azure verfügbar?

Ja, über Microsoft Foundry, ehemals Azure AI Foundry. Sie erstellen eine Foundry-Ressource, stellen darin ein Claude-Modell bereit und rufen https://{resource}.services.ai.azure.com/anthropic/v1/messages entweder mit einem von Azure ausgestellten Schlüssel in einem api-key-Header oder mit einem Microsoft Entra Bearer-Token auf. Die Nutzung wird über den Azure Marketplace in Claude Consumption Units abgerechnet. Das Feld model im Anfrage-Body muss den Namen Ihrer Bereitstellung enthalten. Dieser entspricht dem Modellbezeichner nur so lange, bis Sie eine Bereitstellung umbenennen.

Wo sollte ich den Claude-API-Schlüssel auf einem Linux-Server speichern?

In einer Datei, die root gehört und den Modus 600 hat. Laden Sie sie über EnvironmentFile= in eine systemd-Unit. systemd liest diese Datei als root ein, bevor es zum User= der Unit wechselt. Das Dienstkonto benötigt daher keinen Zugriff auf die Datei. Speichern Sie den Schlüssel nicht im Repository und nicht direkt in der Unit-Datei. Diese ist für alle Benutzer lesbar und wird von systemctl cat ausgegeben. Speichern Sie ihn außerdem nicht in Container-Image-Layern, da docker history --no-trunc alle Werte ausgibt, die mit ENV oder --build-arg gesetzt wurden.

Warum gibt meine Claude-API-Anfrage plötzlich 401 zurück, obwohl ich nichts geändert habe?

Die häufigste Ursache ist ein Schlüssel, der das bei seiner Erstellung festgelegte Ablaufdatum erreicht hat. Das Ablaufdatum wird bei der Erstellung festgelegt und kann danach nicht mehr geändert werden. Kurzlebige Schlüssel laufen ohne Warn-E-Mail ab. Ein abgelaufener Schlüssel kann nicht reaktiviert werden. Erstellen Sie daher einen Ersatzschlüssel, schreiben Sie ihn in die Umgebungsdatei, starten Sie den Dienst neu und widerrufen Sie den alten Schlüssel anschließend. Wenn der Schlüssel definitiv noch gültig ist, prüfen Sie, ob ein veralteter Anmeldedatensatz ihn überschreibt: Ein auf eine leere Zeichenfolge gesetztes ANTHROPIC_API_KEY hat weiterhin Vorrang vor jeder anderen Quelle für Anmeldedaten.