DynamoDB ResourceNotFoundException

TL;DR — DynamoDB, istemcinizin yöneltildiği bölgede/hesapta adlandırdığınız tabloyu (ya da indeksi) bulamıyor. Tablo adında bir yazım hatası, yanlış region ya da farklı bir hesap için kimlik bilgileri olup olmadığını kontrol edin. Tablonun gerçekten gitmiş olması neredeyse hiç değildir.

Ne anlama gelir

ResourceNotFoundException: Requested resource not found: Table: <table-name> not found

# on DynamoDB Local:
ResourceNotFoundException: Cannot do operations on a non-existent table

İlki, canlı hizmetin döndürdüğüdür — aradığı tabloyu adıyla verir. İkincisi, DynamoDB Local'in döndürdüğüdür ve onu görmek, AWS ile değil emülatörle konuştuğunuzun güvenilir bir işaretidir. Her iki durumda da işlem, bu istemcinin bakış açısından var olmayan bir tabloyu ya da indeksi hedefledi — tablo adı + AWS bölgesi + hesap (kimlik bilgileri) kombinasyonu. Üçünün de hizalanması gerekir. DynamoDB onu HTTP durum kodu 400 ile döndürür ve yeniden denenebilir değildir — adı, bölgeyi ya da kimlik bilgilerini düzeltene kadar (ya da tablo oluşturmayı bitirene kadar: CREATING durumunda çok erken bir tablo da bu hatayı döndürebilir) aynı istek başarısız olmaya devam eder.

Neden olur

Bölge uyuşmazlığı — tablo us-east-1'de ama istemci varsayılan olarak us-west-2'ye gelir (ya da bölge ayarlanmamış, dolayısıyla SDK farklı bir varsayılan seçer).
Yanlış tablo adı — bir yazım hatası, yanlış büyük/küçük harf (web hizmetinde adlar büyük/küçük harfe duyarlıdır) ya da ortam-önekli bir ad (prod-Orders ile Orders).
Yanlış hesap — kimlik bilgileri, tablonun sahibi olandan farklı bir AWS hesabına çözümleniyor.
Var olmayan ya da henüz ACTIVE olmayan bir indeksi sorgulamak (bir GSI hâlâ geri dolduruyor) — API referansı, "durumu ACTIVE olmayabilir" olan "var olmayan bir tablo ya da indeks"e dikkat çeker.
Tablo gerçekten silindi ya da boş başlayan DynamoDB Local'e yöneltilmişsiniz.

Nasıl düzeltilir

İstemcide bölgeyi açıkça sabitleyin ve tablonun yaşadığı yerle eşleştiğini doğrulayın.
Tam tablo adını doğrulayın — o bölgedeki tabloları listeleyin (aws dynamodb list-tables --region <r>) ve adı birebir kopyalayın.
Kimlik bilgilerinin sahip hesaba çözümlendiğini doğrulayın (aws sts get-caller-identity).
Çağrı IndexName kullanıyorsa indeks adını + durumunu kontrol edin (DescribeTable → GSI ACTIVE olmalı).

Örnek

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

// Pin the region so the client can't silently target the wrong one:
const client = new DynamoDBClient({region: 'us-east-1'});

SSS

DynamoDB'de ResourceNotFoundException'ı nasıl düzeltirim? Tablo adı, AWS bölgesi ve hesabın (kimlik bilgileri) hepsinin hizalandığını kontrol edin: istemcide bölgeyi açıkça sabitleyin, tam adı doğrulamak için o bölgedeki tabloları listeleyin ve kimlik bilgilerinin aws sts get-caller-identity ile sahip hesaba çözümlendiğini doğrulayın.

ResourceNotFoundException tablomun silindiği anlamına mı gelir? Nadiren. Genellikle istemcinin yanlış yere baktığı anlamına gelir — bir bölge uyuşmazlığı, tablo adında bir yazım hatası ya da yanlış büyük/küçük harf ya da farklı bir hesap için kimlik bilgileri. Ayrıca var olmayan ya da henüz ACTIVE olmayan bir indeksi sorguladığınızda ya da boş başlayan DynamoDB Local'e yöneldiğinizde de tetiklenir.

DynoTable workbench

DynoTable kenar çubuğunda etkin profil ve bölgeye ilişkin tabloları listeler. eğer bir tablosu eksikse profili onaylamak için ⌘P tuşuna basın ve sekmedeki bölge — buradaki uyumsuzluk, bu hatanın en yaygın nedenidir Uygulama. ⌘K → Tabloyu ada göre aç tam tabloyu yazmanıza olanak tanır ListTables reddedildiğinde veya liste bir tablo önekine göre filtrelendiğinde ad. DynamoDB Yerel'e karşı http://localhost:8000 uç noktasına sahip bir profil ekleyin ve eşleşen yer tutucu kimlik bilgileri (Connect to DynamoDB Local) — Yerel, sen tablolar oluşturana kadar boş başlar.

İlgili hatalar

ResourceInUseException — tersi: tablo zaten var.
Yapılandırmada bölge eksik
Güvenlik belirteci geçersiz
Öğrenin: Running DynamoDB Local — Local boş başlar; hangi uç noktada olduğunuzu bilin.

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.