Должны ли зоны доступности услуг VP C соответствовать зонам конечных точек VP C? - PullRequest
0 голосов
/ 05 февраля 2020

Я настраиваю конечную точку VP C для соответствующей конечной точки службы VP C.

  • Наше приложение вызывает нисходящий сервис, используя имя c, не определенное регионом или зоной (направленное на VPCe).

  • На VPCe установлено 3 подсети приложений (что соответствует 3 зонам доступности us-west-2a, -2b, -2 c).

  • Служба, которую мы вызываем, поддерживает только 2 зоны доступности (us-west-2a, -2b).

  • При создании конечной точки (через CloudFormation) я получаю следующую ошибку:

    The VPC endpoint service com.amazonaws.vpce.us-west-2.vpce-svc-01234567890123456 does not support the availability zone of the subnet: subnet-0abcdef0123456789. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameter; Request ID: ...)

(Где это su bnet в AZ us-west-2 c)

В чем здесь проблема?

Я не могу обойтись без этого su bnet, не запретив нашему приложению в этом AZ использовать VPCe, верно?

Похоже, AWS ожидает, что клиент и сервисные AZ будут совпадать ? Должно быть, я что-то неправильно понимаю. Не ожидал бы, что это будет так жестко. (Например, если service us-west-2c падает, запросы от client us-west-2c должны go до service us-west-2a или -2b. В этом весь смысл AZ, верно?)

1 Ответ

0 голосов
/ 06 февраля 2020

Провел еще несколько исследований и обнаружил:

  • Правильные su bnet не могут быть определены автоматически.
  • Зоны производителя / потребителя действительно должны match.
  • Экран создания конечной точки консоли AWS create VP C может использоваться для проверки доступных сервисных AZ.
  • Не должно быть проблем при обмене данными с client us-west-2c на client VPCe in us-west-2a до тех пор, пока группа безопасности VPCe допускает это .

Решение должно включать ручную проверку поддерживаемых зон доступности в службе.

...