Claude API kimlik doğrulama yöntemleri ve kurulum rehberi

Dört Claude API kimlik doğrulama yolu

Claude API kimlik doğrulaması tek bir karara dayanır: istemcinizin ağ üzerinden hangi kimlik bilgisini gönderdiği. Bunun dört farklı yanıtı vardır ve bunlar tek bir mekanizmanın türevleri değildir. Doğrudan Anthropic API, bir x-api-key başlığında statik bir anahtar gönderir. Amazon Bedrock, her isteği AWS kimlik bilgileriyle imzalar ve bu kurulumda hiçbir Anthropic anahtarı bulunmaz. Google Cloud, kısa ömürlü bir Google erişim belirteci (access token) gönderir. Microsoft Foundry ise Azure tarafından verilmiş bir anahtar veya Microsoft Entra belirteci kullanır.

Bu kılavuz, bir Linux sunucusunda çalışan bir servise SDK (yazılım geliştirme kiti) entegre etmek içindir. Eğer bunun yerine Claude Code komut satırı aracını yapılandırıyorsanız, değişkenler ve akış farklıdır: Claude Code'u Bedrock veya Vertex'e yönlendirme bölümüne bakın. Servis henüz mevcut değilse, önce bir VPS üzerinde ilk Claude API uygulaması ile oluşturun ve kimlik bilgisi için buraya geri dönün.

Aşağıdaki her şey, Ağustos 2026 itibarıyla Anthropic platform belgeleriyle doğrulanmıştır. Model tanımlayıcıları, fiyatlar, SDK sürümleri ve uç nokta yapıları sürekli değiştiğinden, bu kılavuz güncelliğini yitirebilecek değerleri yazdırmak yerine ilgili sağlayıcı sayfalarına bağlantı vermektedir.

Yol 1: Bir Anthropic API anahtarı

Bu doğrudan yoldur ve Anthropic'in gizli anahtarı sağladığı tek yöntemdir. İstekler, Anthropic'in API sunucusundaki Messages uç noktasına gönderilir ve her istek üç başlık taşır.

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"}]}'

MODEL_ID kısmını, Anthropic'in model genel bakış sayfasındaki güncel bir tanımlayıcı ile değiştirin. Sağlıklı bir yanıt, bir content dizisi ve bir usage nesnesi içeren JSON formatındadır. Hatalı veya süresi dolmuş bir anahtar, authentication_error ile birlikte HTTP 401 hatası döndürür. Eksik bir anthropic-version başlığı ayrı bir hata türüdür; çünkü bu başlık her istekte zorunludur ve SDK'lar bunu sizin yerinize ayarlar.

İstemci oluşturma işlemi, dört yol arasındaki en kısa olanıdır çünkü oluşturulacak bir şey yoktur. Tüm resmi SDK'lar, ANTHROPIC_API_KEY değerini ortam değişkenlerinden otomatik olarak okur.

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)

Model tanımlayıcısını anahtarın yanında ortam değişkenlerinde tutmak faydalıdır. Model isimleri sizin kontrolünüz dışında belirli bir takvimle değişir; sadece bir dizgeyi düzenlemek için kodu yeniden dağıtmak kaçınılabilir bir iştir.

Anahtarlar, oluşturulma anında bir geçerlilik süresi seçtiğiniz Console üzerinden oluşturulur: 3 saat, 1 gün, 7 gün veya 30 gün gibi hazır seçenekler, özel bir süre veya Asla seçeneği mevcuttur. Geçerlilik süresi oluşturma anında sabittir ve daha sonra değiştirilemez. Anthropic, uzun ömürlü bir anahtarın süresi dolmadan önce anahtarı oluşturan kişiye e-posta gönderir, ancak kısa ömürlü bir anahtarın süresi herhangi bir uyarı e-postası olmaksızın dolar. Süresi dolmuş bir anahtar 401 hatası döndürür ve yeniden etkinleştirilemez; bu nedenle çözüm her zaman yeni bir anahtar oluşturmaktır.

Doğrudan API kullanımında seçilecek bir bölge yoktur ve fatura doğrudan Anthropic organizasyonunuza yansıtılır. Çalışma alanları (Workspaces), bir anahtarı tek bir projeyle sınırlandırır; bu, tek bir servisin ne kadar harcama yaptığını görmenin en temiz yoludur. Faturanın hesaplanmasıyla ilgili detaylar için token başına API fiyatlandırmasının abonelikle karşılaştırması bölümüne bakın.

Buraya bir seçenek daha eklenmelidir çünkü bu seçenek statik gizli anahtarı tamamen ortadan kaldırır. İş Yükü Kimlik Federasyonu (Workload Identity Federation), bir iş yükünün halihazırda güvendiğiniz bir kimlik sağlayıcısından aldığı OpenID Connect (OIDC) belirtecini, POST /v1/oauth/token adresinde kısa ömürlü bir Anthropic belirteci ile takas etmesine olanak tanır ve SDK, bu belirteci süresi dolmadan önce yeniler. Hiçbir yerde sk-ant-api... dizgesi oluşturulmaz veya kopyalanmaz. Bu yöntem; halihazırda bir platform kimliği taşıyan Kubernetes, GitHub Actions ve bulut sanal makineleri için uygundur. Standart bir VPS genellikle böyle bir sağlayıcıya sahip değildir; bu nedenle bu tür bir sunucuda bir dosyada tutulan API anahtarı en gerçekçi çözümdür ve bu kılavuzun geri kalanı bu yaklaşımı temel alır.

Yol 2: Amazon Bedrock üzerinde AWS kimlik bilgileri

Bedrock üzerinde herhangi bir Anthropic anahtarı tutmazsınız. SDK, her HTTP isteğini standart AWS kimlik bilgileriyle AWS Signature Version 4 (SigV4) kullanarak imzalar; AWS, çağrıyı yapan tarafın modeli çalıştırıp çalıştıramayacağına karar verir.

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

aws sts get-caller-identity, kimlik bilgilerinizin çözümlendiği kimliğin hesap numarasını ve ARN (Amazon Resource Name) bilgisini yazdırır. Bunu diğer her şeyden önce çalıştırın. Eğer bu başarısız olursa, Claude çağrısı da başarısız olacaktır; çünkü SDK aynı zinciri izler: önce kurucu argümanlar, ardından AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN ve AWS_REGION ortam değişkenleri, daha sonra AWS yapılandırma dosyası ve standart zincirin geri kalanı (SSO, üstlenilen roller, ECS görev rolü, örnek meta veri servisi).

İstemci oluşturma aşamasında değişen tek şey sınıf ve bir argümandır.

from anthropic import AnthropicBedrock

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

Bölge (region) burada sadece bir süsleme değildir. Bedrock uç noktaları bölge bazlıdır, model erişimi AWS konsolunda bölge bazlı olarak tanımlanır ve bölge, SigV4 imzasının bir parçasıdır; dolayısıyla bir bölge için hesaplanan imza, başka bir bölge tarafından reddedilir. AWS_REGION değerini servis ortamında açıkça ayarlayın. Anthropic, AnthropicBedrock istemcisinin AWS_REGION değerini okuduğunu, ayarlanmadığında us-east-1 değerine geri döndüğünü ve bölge için ~/.aws/config değerini okumadığını belirtir. AWS CLI'ın Python sürecinizin başarısız olduğu aynı makinede Claude modellerini başarıyla listeleyebilmesinin nedeni budur: CLI yapılandırma dosyanızı okur, ancak istemci okumaz.

Bir EC2 örneğinde bir IAM (kimlik ve erişim yönetimi) rolü eklersiniz ve hiçbir gizli anahtar diske yazılmaz; çünkü örnek meta veri servisi SDK'ya geçici kimlik bilgileri sağlar. AWS dışındaki bir VPS'in ne örnek rolü ne de meta veri servisi vardır. Bu durumda, makinede duran ve Anthropic anahtarıyla aynı sınıfta bir gizli bilgi olan IAM kullanıcısına ait uzun ömürlü erişim anahtarı çifti ile federasyon arasında seçim yaparsınız: kimlik sağlayıcınızda kimlik doğrulaması yapın, AWS STS (güvenlik belirteç servisi) çağrısı yapın ve döndürdüğü geçici kimlik bilgilerini kullanın. Bedrock ayrıca AWS_BEARER_TOKEN_BEDROCK aracılığıyla bir taşıyıcı belirteç (bearer token) kabul eder; bu yöntem 12 saatlik bir üst sınırla belgelenmiştir ve AWS tarafından en az tercih edilen yol olarak tanımlanır.

Fatura, Anthropic yerine AWS hesabınıza yansıtılır ki genellikle buraya gelmenizin asıl nedeni de budur. Ağustos 2026 itibarıyla belgelendiği üzere, bölgesel uç noktalar küresel uç noktaya göre %10 oranında daha maliyetlidir. Bir Bedrock hatası, izin sorunu gibi göründüğü için tanınmaya değerdir ancak değildir: 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. Bu bir model yönlendirme sorunudur ve hiçbir kimlik bilgisi değişikliği bunu düzeltmeyecektir.

Yol 3: Vertex AI üzerinde Google kimlik bilgileri

Google Cloud, Google kimlik doğrulama kütüphanelerinin bir kimlik bilgisi belirtmenize gerek kalmadan bulması için izlediği sabit bir arama sırası olan Application Default Credentials (ADC) kullanır. ADC önce GOOGLE_APPLICATION_CREDENTIALS öğesini, ardından gcloud auth application-default login tarafından yazılan dosyayı, son olarak da metadata sunucusu aracılığıyla eklenen servis hesabını kontrol eder.

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

Bir iş istasyonunda bu oturum açma işlemi $HOME/.config/gcloud/application_default_credentials.json dosyasını yazar ve işlem tamamlanır. Bir sunucuda bu yanlış araçtır, çünkü depoladığı kimlik bilgisi bir insana aittir ve o kişinin hesabı ile birlikte sona erer. Google Cloud dışında bir metadata sunucusu da yoktur, bu nedenle ADC, bir servis hesabı anahtar dosyasına işaret eden GOOGLE_APPLICATION_CREDENTIALS değişkenine düşer. Bu JSON dosyası uzun ömürlü bir gizli bilgidir ve bu kılavuzun ilerleyen bölümlerinde açıklanan şekilde ele alınması gerekir. Google Cloud içinde ise, sanal makineye (VM) bir servis hesabı atayın; böylece korunması gereken bir dosya kalmaz.

from anthropic import AnthropicVertex

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

SDK'nın altına inip doğrudan HTTP kullanırsanız iki şey değişir. Model tanımlayıcısı istek gövdesinden çıkar ve URL yoluna taşınır; anthropic_version ise başlıktan çıkar ve vertex-2023-10-16 değerini okuması gereken gövdeye taşınır. Kimlik bilgisi, standart bir Google erişim belirtecidir (access token).

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"}]}'

Bölge (region) birinci sınıf bir argümandır. global kullanılabilirlik için dinamik olarak yönlendirme yapar, us ve eu çoklu bölge tanımlayıcılarıdır ve us-east5 gibi bir isim tek bir bölgeyi sabitler. Ağustos 2026'da belgelendiği üzere, çoklu bölge ve bölgesel uç noktalar global uç noktalardan %10 daha maliyetlidir. Faturalandırma Google Cloud projesi üzerinden yürütülür, bu nedenle kota ve faturalar Google'a aittir.

Rota 4: Microsoft Foundry, Azure rotasıdır

Azure üzerinde Claude araması yaptıysanız, aradığınız bölüm burasıdır ve desteklenen bir rota mevcuttur. Claude, Microsoft Foundry (eski adıyla Azure AI Foundry) içerisinde çalışır ve Azure Marketplace üzerinden Claude Consumption Units (Claude Tüketim Birimleri) ile faturalandırılır. Bir Foundry kaynağı oluşturur, içerisine bir Claude modeli dağıtır ve https://{resource}.services.ai.azure.com/anthropic/v1/* adresindeki Azure barındırmalı uç noktayı çağırırsınız.

İki kimlik bilgisi türü kullanılabilir. Birincisi, Foundry portalındaki dağıtımın Details sekmesinden alınan ve api-key veya x-api-key başlığı ile gönderilen, Azure tarafından verilmiş bir anahtardır. İkincisi ise Microsoft Entra belirtecidir; bu, sunucu tarafında daha iyi bir tercihtir çünkü Azure rol tabanlı erişim denetimi (RBAC), uç noktayı kimin çağırabileceğini yönetir.

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"}]}'

model alanı, model tanımlayıcısını değil, dağıtım adınızı taşır. Varsayılan olarak ikisi eşleşir; ancak bir dağıtımı kendiniz adlandırdığınız anda eşleşme bozulur. Bu durum, aksi takdirde doğru olan bir istekte Deployment not found hatasının alınmasının yaygın nedenidir. Python ve TypeScript SDK'ları, ANTHROPIC_FOUNDRY_API_KEY ve ANTHROPIC_FOUNDRY_RESOURCE değerlerini ortam değişkenlerinden okur. Foundry desteği her SDK'da bulunmaz: Ağustos 2026 itibarıyla belgelendiği üzere C#, Java, PHP, Python ve TypeScript dillerini kapsar; Go ve Ruby SDK'ları ise genel istemcinin Foundry temel URL'sine yönlendirilmesini gerektirir.

Bu geçici çözümün riskli bir tarafı vardır. Eğer ANTHROPIC_API_KEY ortam değişkeninde tanımlı kalmaya devam ederse, genel istemci bunu algılar ve Anthropic anahtarınızı bir Microsoft uç noktasına gönderir. Değişkeni kaldırın veya istemci üzerindeki ortam varsayılanlarını devre dışı bırakın. Entra belirteçleri yaklaşık bir saat sonra geçerliliğini yitirir; bu nedenle uzun süre çalışan bir sürecin, başlangıçta bir kez almak yerine belirteçleri yenilemesi gerekir.

Sunucunuzdaki kimlik bilgileri ne kadar süre geçerli kalır?

[
  {
    "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
  }
]

Bunlar, her sağlayıcı tarafından yayınlanan ve Ağustos 2026 itibarıyla okunan üst sınırlar ve varsayılan değerlerdir; ölçülmüş veriler değildir. Bu değerler tek bir nedenden dolayı önemlidir: sızdırılan bir kimlik bilgisinin, siz sızıntıyı fark edene kadar ne kadar süreyle çalışmaya devam edeceğini gösterirler. Tablonun alt kısmındaki kısa ömürlü belirteçlerin (token) her biri 1 saat geçerlidir ve SDK bunları otomatik olarak yenilediği için bu kısa ömür size operasyonel bir yük getirmez. Üstlenilen bir rol (assumed role) 12 saatlik bir süreye sahiptir. 30 günlük ön ayarla oluşturulan bir anahtar 720 saat boyunca geçerli kalır; sunucunuzdaki bir dosyada bir ay boyunca duran kimlik bilgisi işte budur.

VPS üzerinde kimlik bilgisi konumu

Gizli veriyi yalnızca root kullanıcısının okuyabileceği bir dosyaya yerleştirin ve systemd'nin bunu sürece iletmesini sağlayın. Bu yöntem her SDK sürümünden daha uzun ömürlüdür, bu nedenle bir kez ve doğru şekilde yapmaya değer.

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

Dosya düz KEY=value satırları içerir. export, tırnak işaretleri veya shell sözdizimi kullanmayın; çünkü systemd bunu bir shell üzerinden çalıştırmak yerine doğrudan kendisi ayrıştırır.

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, EnvironmentFile= dosyasını root yetkileriyle okur ve ardından User=claudeapp kullanıcısına geçiş yapar; bu sayede servis hesabının dosyaya okuma erişimine sahip olması gerekmez. root sahipliğinde 600 modu yeterlidir; yukarıdaki install komutunun bu şekilde ayarlanmasının nedeni budur. Servisi sudo systemctl enable --now claude-app ile başlatın ve ardından systemctl status claude-app komutuyla birimin döngüsel olarak yeniden başlamak yerine active (running) durumuna ulaştığını doğrulayın.

Kaçınmanız gereken dört durum ve her birinin kendi başınıza kontrol edebileceğiniz bir nedeni vardır:

• Anahtarı birim dosyası içinde Environment= ile yazmayın. /etc/systemd/system altındaki bir birim dosyası herkes tarafından okunabilir, bu nedenle systemctl cat claude-app komutu gizli veriyi herhangi bir yerel kullanıcıya açık eder.
• Dosyayı commit etmeyin. .gitignore yeni bir dosyanın commit edilmesini engeller ancak halihazırda commit edilmiş bir dosya için bir şey yapmaz; çünkü git geçmişi kendisine verilen her şeyi saklar.
• Dosyayı container imajının içine gömmeyin. ENV satırları ve --build-arg değerleri imaj katmanlarına kaydedilir ve docker history --no-trunc bunları geri yazdırır. Dosyayı sonraki bir katmanda silmek, önceki katmanlardan silinmesini sağlamaz. Gizli verileri çalışma zamanında --env-file veya mount edilmiş bir dosya aracılığıyla iletin.
• Süreç ortamını root kullanıcısından gizli tutmaya çalışmayın. sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ anahtarı geri yazdırır. Amaç, gizli veriyi root dışındaki diğer tüm hesaplardan korumaktır; root kullanıcısı ne yaparsanız yapın dosyayı okuyabilir.

Bu son nokta, bu tasarımın size sağladığı korumanın sınırını belirler. Yalnızca servisin ve root kullanıcısının okuyabildiği bir ortam değişkeni, gizli veri için uygun bir kaptır. Ancak süreç sizin yazmadığınız bir kod çalıştırıyorsa bu yanlış bir yöntemdir; çünkü sürecin yürütebildiği her şey kendi ortam değişkenlerini de okuyabilir. Gizli verileri bir yapay zeka aracının erişiminden uzak tutmak konusu bu durumu ele alır; bu, farklı bir çözümü olan farklı bir sorundur.

Kesinti yaşamadan anahtar rotasyonu nasıl yapılır?

Önce yeni anahtarı ekleyin, ardından eskisini iptal edin.

1. Konsol üzerinden, eski anahtar ile aynı çalışma alanında yeni anahtarı oluşturun.
2. /etc/claude-app/env dosyasına sudoedit ile yazın.
3. sudo systemctl restart claude-app komutunu çalıştırın.
4. Servisin isteklere yanıt verdiğini doğrulayın, ardından Konsol üzerinden eski anahtarı iptal edin.

EnvironmentFile birim başladığında okunur, bu nedenle çalışan bir süreç başlatıldığı anda kendisine verilen değeri korur. systemctl daemon-reload birim dosyalarını yeniden okur ancak çalışan bir sürecin ortam değişkenlerine dokunmaz; bu nedenle yeni anahtarın devreye girmesi için yeniden başlatma gereklidir. 4. adım yerine 1. adımda iptal işlemi yapmak, 3. adıma kadar sürecek bir kesintiye neden olur.

Diğer üç yöntem sağlayıcı tarafında rotasyon gerektirir. Bir IAM kullanıcısı aynı anda iki aktif erişim anahtarını destekler; bu yüzden ikinciyi oluşturun, dağıtın ve ardından ilkini silin. Google servis hesabı anahtarı da aynı şekilde rotasyona tabi tutulur. Foundry anahtarı portal üzerinden yeniden oluşturulur ve bu işlem eskisini anında geçersiz kılar; bu nedenle tıklamadan önce yeni değeri kaydedin. Entra belirteçleri ve federasyon Anthropic belirteçleri hiçbir rotasyon gerektirmez; mümkün olan yerlerde bunları kullanmak en güvenli yöntemdir.

Konsoldayken çalışma alanı için bir harcama limiti belirleyin. Sızdırılmış bir anahtar, başka herhangi bir sorun yaratmadan önce maliyetli bir soruna dönüşür; bir VPS üzerindeki ajanın harcama limitini belirleme rehberi, bu kontrollerin nasıl yapılacağını adım adım açıklar.

İstemcim neden 401 veya 403 hatası döndürüyor?

Doğrudan API üzerinde authentication_error ile 401 hatası. Anahtar hatalı, iptal edilmiş veya süresi dolmuş olabilir. Kod değişmediği ve istek dün çalıştığı için genellikle gözden kaçan durum sürenin dolmasıdır. Konsol üzerindeki anahtarın süre sütununu kontrol edin veya süresi olmayan anahtarlar için null değerini döndüren Admin API üzerinden expires_at verisini okuyun.

SDK, federasyon yapılandırmanızı yok sayıyor ve bunun yerine bir anahtar kullanıyor. ANTHROPIC_API_KEY ve ANTHROPIC_AUTH_TOKEN, kimlik bilgisi öncelik sıralamasında federasyonun üzerinde yer alır; bu nedenle her ikisi de federasyonu gölgeler. Bunun kritik noktası şudur: boş bir dizge olarak dışa aktarılan bir değişken yine de kendi yerini işgal eder, bu yüzden ANTHROPIC_API_KEY="" kullanımı SDK'nın federasyona geçmek yerine boş bir anahtarla kimlik doğrulaması yapmasına neden olur. Bunun yerine unset ANTHROPIC_API_KEY kullanın.

Federasyon üzerinde Authentication failed mesajı ile 401 hatası. Bu mesaj, bir çağrı yapanın hata metnini okuyarak kural yapılandırmanızı analiz etmesini engellemek amacıyla her olası neden için kasıtlı olarak aynı tutulmuştur. Asıl neden, Konsol'daki kimlik doğrulama geçmişi sayfasında kayıtlıdır. JWT üzerinde tahminde bulunmak yerine işe oradan başlayın.

Foundry üzerinde 403 hatası. Belirteç kimlik doğrulaması başarılı oldu ancak Azure hesabınız çağrıya izin veren bir role sahip değil. İsteği yapan kimliğe Foundry User (eski adıyla Azure AI User) veya Cognitive Services User gibi bir Azure RBAC rolü atayın.

Bedrock ile ilgili herhangi bir hata. Öncelikle servis kullanıcısı olarak aws sts get-caller-identity komutunu çalıştırın. Bu komut, sunucuda kullanılabilir AWS kimlik bilgilerinin olup olmadığını yanıtlar; böylece kimlik bilgisi sorunu ile model erişim sorunu veya bölge uyuşmazlığı birbirinden ayrılmış olur. Model erişimi AWS konsolunda bölge bazlı verilir ve bir bölgede etkinleştirilip diğerinden çağrı yapılması kolayca gerçekleşebilir.

FAQ

Bedrock veya Vertex üzerinde Claude kullanmak için Anthropic API anahtarına ihtiyacım var mı?

Hayır. Amazon Bedrock üzerinde SDK, her isteği SigV4 kullanarak AWS kimlik bilgileriyle imzalar; Google Cloud üzerinde ise Application Default Credentials aracılığıyla bulunan bir Google erişim belirteci gönderir. Her iki kurulumda da Anthropic tarafından verilmiş bir gizli anahtar bulunmaz ve kullanım ücreti Anthropic yerine bulut hesabına yansıtılır. ANTHROPIC_API_KEY içinde bırakılan bir Anthropic anahtarının bu ana bilgisayarlarda bir güvenlik riski oluşturmasının nedeni de budur: bir bulut uç noktasına yönlendirilen genel bir istemci, anahtarı oraya göndermekten çekinmeyecektir.

Claude Azure üzerinde mevcut mu?

Evet, eski adıyla Azure AI Foundry olan Microsoft Foundry aracılığıyla kullanılabilir. Bir Foundry kaynağı oluşturup içine bir Claude modeli dağıtmalı ve https://{resource}.services.ai.azure.com/anthropic/v1/messages üzerinden, ya Azure tarafından verilmiş bir anahtarı api-key başlığında ya da bir Microsoft Entra taşıyıcı belirteci (bearer token) kullanarak çağrı yapmalısınız. Kullanım ücretleri Azure Marketplace üzerinden Claude Consumption Units cinsinden faturalandırılır. İstek gövdesindeki model alanı, dağıtım adınızı içermelidir; bu ad, siz dağıtımı yeniden adlandırana kadar model tanımlayıcısı ile aynıdır.

Claude API anahtarını bir Linux sunucusunda nerede saklamalıyım?

root kullanıcısına ait, 600 izinlerine sahip ve bir systemd ünitesinde EnvironmentFile= aracılığıyla yüklenen bir dosyada saklanmalıdır. systemd, üniteyi User= kullanıcısına geçirmeden önce dosyayı root olarak okur, bu nedenle servis hesabının dosyaya erişim iznine ihtiyacı yoktur. Anahtarı depodan, herkes tarafından okunabilir olan ve systemctl cat ile yazdırılan ünite dosyasının kendisinden ve docker history --no-trunc komutu ENV veya --build-arg ile ayarlanan her şeyi yazdırdığı için container imaj katmanlarından uzak tutun.

Claude API isteğim hiçbir şey değişmediği halde neden 401 hatası döndürmeye başladı?

En yaygın neden, oluşturulurken belirlenen son kullanma tarihine ulaşan bir anahtardır. Son kullanma süresi oluşturma aşamasında belirlenir, sonradan düzenlenemez ve kısa ömürlü anahtarlar herhangi bir uyarı e-postası gönderilmeden sona erer. Süresi dolmuş bir anahtar yeniden etkinleştirilemez; bu nedenle yeni bir anahtar oluşturun, ortam dosyasına yazın, servisi yeniden başlatın ve ardından eski anahtarı iptal edin. Anahtarın güncel olduğundan eminseniz, eski bir kimlik bilgisinin onu gölgede bırakıp bırakmadığını kontrol edin: boş bir dizgeye ayarlanmış ANTHROPIC_API_KEY, diğer tüm kimlik bilgisi kaynaklarına göre önceliklidir.