AWS API Gateway для обслуживания статического содержимого из S3 Bucket

Question

Я хочу обслуживать свои лямбда-микросервисы через API-шлюз, что, похоже, не является большой проблемой.

Каждый из моих микросервисов имеет спецификацию JSON-Schema предоставленного ресурса. Поскольку это статический файл, я хотел бы обслуживать его из ведомого S3 , а не запускать функцию лямбда для его обслуживания.

Так что пока

GET,POST,PUT,DELETE http://api.domain.com/ressources 

должны быть направлены на лямбда-функции. Я хочу

GET http://api.domain.com/ressources/schema 

для обслуживания моего schema.json от S3.

Мой наивный первый подход состоял в том, чтобы настроить ресурс и методы для «/ v1/contract/schema - GET - Integration Request» и настроить его на поведение в качестве прокси-сервера HTTP с URL-адресом конечной точки, прямо указывающим на контракты JSON-Schema. Я получаю ошибку 500 - Internal Server.

    Execution log for request test-request 
Fri Nov 27 09:24:02 UTC 2015 : Starting execution for request: test-invoke-request 
Fri Nov 27 09:24:02 UTC 2015 : API Key: test-invoke-api-key 
Fri Nov 27 09:24:02 UTC 2015 : Method request path: {} 
Fri Nov 27 09:24:02 UTC 2015 : Method request query string: {} 
Fri Nov 27 09:24:02 UTC 2015 : Method request headers: {} 
Fri Nov 27 09:24:02 UTC 2015 : Method request body before transformations: null 
Fri Nov 27 09:24:02 UTC 2015 : Execution failed due to configuration error: Invalid endpoint address 

Я на полном неправильном пути или просто пропущу некоторые конфигурации?

Answer 1

К сожалению, существует ограничение при использовании TestInvoke с прокси-сервером API для доступа к Amazon S3 (и некоторым другим услугам AWS) в том же регионе. Это не будет иметь место после развертывания, но если вы хотите протестировать с консоли, вам нужно будет использовать ведро в другом регионе.

Мы знаем об этой проблеме, но я не могу согласиться, когда эта проблема будет решена.

Answer 2

В одной из моих установок я установил дистрибутив CloudFront перед как шлюзом API, так и ведром S3, которые оба сконфигурированы как источники.

В основном я использовал его, чтобы иметь возможность использовать сертификат SSL, выданный менеджером сертификатов AWS, который может быть установлен только на автономных дистрибутивах CloudFront, а не на API-шлюзах.

Answer 3

У меня была аналогичная ошибка, но по совершенно другой причине: если имя байта s3 содержит период (например, в data.example.com или аналогичный), запрос прокси-сервера будет выдаваться с сертификационной проблемой ssl!