Как API Gateway взаимодействует с конечной точкой Firehose VP C - PullRequest
1 голос
/ 20 марта 2020

Использование Amazon Kinesis Data Firehose с AWS PrivateLink сообщает Firehose VP C, что конечная точка сохраняет трафик c между VP C и Firehose в пределах AWS.

Вы можете использовать интерфейсную конечную точку VP C, чтобы трафик c между вашим Amazon VP C и Kinesis Data Firehose не выходил из сети Amazon.

Когда API Gateway вызывает PutRecord API Firehose через интеграцию AWS, проходит ли трафик c через конечную точку Firehose VP C или идет в Inte rnet?

Обновления

Представление частных конечных точек Amazon API Gateway показывает диаграмму, где EC2 и Lambda находятся в VP C. «Все общедоступные конечные точки» go для Inte rnet и не уверены, что API Gateway распознает, существует ли частная конечная точка Firehose или нет, и направляет туда трафик c.

enter image description here

1 Ответ

1 голос
/ 26 марта 2020

Пример с DynamoDB и EC2 примерно равен Gateway VP C Конечные точки . Для API Gateway существует нет Gateway VP C Конечная точка. Вместо этого есть Интерфейс VP C Конечные точки (AWS PrivateLink) и Частные интеграции шлюза .

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

Интерфейс VP C Конечная точка для шлюза API

Это позволяет, например, экземпляру EC2 в частной и общедоступной c подсетях получать доступ к вашему шлюзу API через внутреннюю сеть AWS, не переходя через Interent , Чтобы это работало, конечную точку шлюза API необходимо настроить как private.

В этом случае шлюз API работает с кинезисом как обычно. Не нужно ничего делать, кроме как настроить AWS интеграцию для него. Например, частный экземпляр EC2 (в частном порядке su bnet) сможет получить доступ к конечной точке private API-шлюза через интерфейс VP C endpoint и впоследствии получить доступ к Kinesis:

Private EC2 Экземпляр -> Interface VP C Конечная точка для API-шлюза -> API-шлюз (частный) -> Kinesis

Здесь важно знать, что после создания Interface VP C Endpoint для API-шлюза в вашем VP C, вы не сможете подключиться к regional или edge-optimized API-шлюзу даже в общедоступных c su bnet. Только private API-шлюз будет доступен изнутри VP C при наличии интерфейса.

Частная интеграция шлюза

Это позволяет вашей публикации c (то есть regional или edge-optimized) Шлюз API для доступа к частному экземпляру EC2 в частном су bnet. Это делается путем создания (например, внутреннего) NLB в вашем VP C, который вы подключаете к VPC Link, который, в свою очередь, ассоциируется с методом API в шлюзе API.

VPC Link работает на уровне метода, таким образом, ваш API publi c может иметь один метод (например, / private) для доступа к частному экземпляру EC2 через VPCLink, и второй метод (например, / kinesis) для доступа к кинезису, как обычно, с использованием интеграции AWS.

Доступ к частному экземпляру EC2 выглядит следующим образом:

Шлюз API (/ закрытый метод) -> VPCLink -> NLB -> частный экземпляр EC2.

Доступ к Kinesis:

API Gateway (/ kinesis) -> Kinesis (через интеграцию AWS)

Вы также можете настроить частную связь EC2 с Kinesis. В этом случае вам потребуется VP C Конечная точка интерфейса для Kinesis, если вы не используете NAT gateway:

Шлюз API (/ private) -> VPCLink -> NLB -> частный экземпляр EC2 -> Interface VP C Конечная точка для Kinesis -> Kinesis (AWS интеграция)

Надеюсь, это проясняет, как API Gateway и Kinesis могут взаимодействовать.

ps AWS условные обозначения, называя разные вещи аналогичным образом вызывает много головной боли.

...