AWS S3: Wiadro, do którego próbujesz uzyskać dostęp, musi zostać zaadresowane przy użyciu określonego punktu końcowego

Próbuję usunąć przesłane pliki graficzne za pomocą AWS-SDK-Core Ruby Gem.

Mam następujący kod:

require 'aws-sdk-core'

def pull_picture(picture)
    Aws.config = {
        :access_key_id => ENV["AWS_ACCESS_KEY_ID"],
        :secret_access_key => ENV["AWS_SECRET_ACCESS_KEY"],
        :region => 'us-west-2'
    }

    s3 = Aws::S3::Client.new

    test = s3.get_object(
        :bucket => ENV["AWS_S3_BUCKET"],
        :key => picture.image_url.split('/')[-2],   
    )
end

Jednak pojawia się następujący błąd:

Wiadro, do którego próbujesz uzyskać dostęp, musi zostać zaadresowane przy użyciu określonego punktu końcowego. Wyślij wszystkie przyszłe żądania do tego punktu końcowego.

Wiem, że region jest poprawny, ponieważ jeśli go zmienię us-east-1, pojawi się następujący błąd:

Podany klucz nie istnieje.

Co robię tutaj źle?

Wydaje się prawdopodobne, że ten segment został utworzony w innym regionie, tj. IE nie us-west-2. To jedyny raz, kiedy widziałem: „Wiadro, do którego próbujesz uzyskać dostęp, musi zostać rozwiązane przy użyciu określonego punktu końcowego. Wyślij wszystkie przyszłe żądania do tego punktu końcowego”.

US Standard to us-east-1

Sprawdź lokalizację swojego segmentu w konsoli, a następnie użyj tego jako odniesienia do którego punktu końcowego użyć: http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region

us-west-2Wystąpił podobny błąd, ponieważ segment był w regionie, a wzorzec adresu URL zawierał nazwę segmentu na ścieżce. Raz zmieniłem wzorzec adresu URL, aby nazwa wiadra była poddomeną adresu URL, aby pobrać pliki i zadziałało.

Na przykład był poprzedni adres URL

https://s3.amazonaws.com/bucketname/filePath/filename

Potem zastąpiłem to jako

https://bucketname.s3.amazonaws.com/filePath/filename

W przypadku wielu pakietów API S3 (ostatnio miałem ten problem, pakiet npm s3 ) możesz napotkać problemy, w których zakłada się, że region jest standardem amerykańskim, a wyszukiwanie według nazwy będzie wymagało jawnego zdefiniowania regionu, jeśli zdecydujesz się na hostowanie segmentu poza tym regionem.

Podczas tworzenia S3Client można określić mapowanie punktu końcowego do określonego regionu. Jeśli domyślnie, s3.amazonaws.comzostanie utworzony segment, w us-east-1którym znajduje się Północna Wirginia.

Więcej szczegółów na temat punktów końcowych i regionów S3 w dokumentach AWS: http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region .

Tak więc zawsze upewnij się o punkcie końcowym / regionie podczas tworzenia S3Client i uzyskaj dostęp do zasobów S3 przy użyciu tego samego klienta w tym samym regionie.

Jeśli segment jest tworzony z konsoli AWS S3, sprawdź region z konsoli dla tego segmentu, a następnie utwórz klienta S3 w tym regionie, używając szczegółów punktu końcowego wspomnianych w powyższym łączu.

Żadna z powyższych odpowiedzi nie rozwiązała mojego problemu.

Powyższe odpowiedzi są prawdopodobnie bardziej prawdopodobną przyczyną Twojego problemu, ale mój problem polegał na tym, że użyłem niewłaściwej nazwy segmentu. To była prawidłowa nazwa wiadra, to po prostu nie było moje wiadro.

Wiadro, na które wskazałem, znajdowało się w innym regionie niż moja funkcja lambda, więc sprawdź nazwę swojego wiadra!

Dla ppl, którzy wciąż napotykają ten problem, spróbuj dodać s3_host w następujący sposób do skrótu konfiguracji

   :storage => :s3,
   :s3_credentials => {:access_key_id => access key,
   :secret_access_key => secret access key},
   :bucket => bucket name here,
   :s3_host_name => s3-us-west-1.amazonaws.com or whatever comes as per your region}.

To rozwiązało problem.

Wystąpił ten błąd, gdy próbowałem uzyskać dostęp do nieistniejącego segmentu.

Przez pomyłkę zamieniłem zmienną ścieżki na zmienną nazwy segmentu, więc nazwa segmentu miała wartość ścieżki do pliku. Może więc dwukrotnie sprawdź, czy nazwa segmentu ustawiona na żądanie jest poprawna.

Miałem ten sam błąd. Wystąpiło to, gdy klient s3 został utworzony z innym punktem końcowym niż ten, który został skonfigurowany podczas tworzenia segmentu.

• KOD BŁĘDU - Wiadro zostało skonfigurowane z regionem EAST.

s3Client = Nowy AmazonS3Client (AWS_ACCESS_KEY, AWS_SECRET_KEY, RegionEndpoint.USWest2)

• NAPRAWIĆ

s3Client = Nowy AmazonS3Client (AWS_ACCESS_KEY, AWS_SECRET_KEY, RegionEndpoint. USEast1 )

Napotkałem ten sam problem. Po wielu zmaganiach odkryłem, że prawdziwy problem dotyczy zależności com.amazonaws. Po dodaniu zależności ten błąd zniknął.

Mieszkam w Wielkiej Brytanii. Próbowałem w regionie „us-west-2”. Przekierowano więc do „eu-west-2”. Prawidłowy region dla S3 to „eu-west-2”

Wystąpiło to dla mnie, gdy miałem źródłowe ograniczenie IP dotyczące zasad używanych przez użytkownika (klucz dostępu / klucz tajny) do tworzenia segmentu s3. Moje IP było dokładne - ale z jakiegoś powodu nie działało i dawało ten błąd.

Po długich poszukiwaniach znalazłem działające rozwiązanie. Problem był spowodowany błędem region-code.

poniżej znajduje się lista kodów regionu, ustaw odpowiedni, a Twój problem zostanie rozwiązany.

Code                         Name
US East (Ohio)               us-east-2

US East (N. Virginia)       us-east-1

US West (N. California)     us-west-1

US West (Oregon)            us-west-2

Asia Pacific (Hong Kong)    ap-east-1

Asia Pacific (Mumbai)       ap-south-1

Asia Pacific (Osaka-Local)  ap-northeast-3

Asia Pacific (Seoul)        ap-northeast-2

Asia Pacific (Singapore)    ap-southeast-1

Asia Pacific (Sydney)       ap-southeast-2

Asia Pacific (Tokyo)        ap-northeast-1

Canada (Central)            ca-central-1

Europe (Frankfurt)          eu-central-1

Europe (Ireland)            eu-west-1

Europe (London)             eu-west-2

Europe (Paris)             eu-west-3

Europe (Stockholm)         eu-north-1

Middle East (Bahrain)      me-south-1

South America (São Paulo)   sa-east-1

Możesz znaleźć swój kod regionu po kliknięciu prawym przyciskiem myszy nazwę wiadra.

Aby wyświetlić szczegóły trybu Kliknij

Napotkałem ten problem podczas używania innego profilu AWS. Widziałem błąd, gdy korzystałem z konta z uprawnieniami administratora, więc możliwość problemów z uprawnieniami wydawała się mało prawdopodobna.

To naprawdę mój wkurzający zwierzak, że AWS jest tak podatna na wysyłanie komunikatów o błędach, które mają tak niewielką korelację z wymaganymi działaniami, z perspektywy użytkownika.