Лучшая практика: NAT vs ElasticIP

Question

У меня есть две базовые настройки для веб-приложений, которые находятся за ELB на веб-сервисе Amazon.

Layout A:

 +-----+           
    +---+ ELB +----+         
    | +-----+ |         
    |    |         
    |    |         
+---v-----+ +-----v---+   +---------------+ 
| EC2/EIP | | EC2/EIP +----+----> | HTTP RESPONSE | 
+---------+ +---------+ |  +---------------+ 
          |       
          |  +------------------+ 
          +----> | EXTERNAL WEBSITE | 
          |  +------------------+ 
          |       
          |  +-----+    
          +----> | API |    
            +-----+    

Компоновка B:

 +-----+            
    +---+ ELB +----+           
    | +-----+ |           
    |    |           
    |    |           
+--v--+  +--v--+ +-----+   +---------------+ 
| EC2 |  | EC2 +--+ NAT +--+----> | HTTP RESPONSE | 
+-----+  +-----+ +-----+ |  +---------------+ 
           |       
           |  +------------------+ 
           +----> | EXTERNAL WEBSITE | 
           |  +------------------+ 
           |       
           |  +-----+    
           +----> | API |    
             +-----+    

Я считаю, что обе архитектуры имеют свои плюсы и минусы:

Layout A:

• ли веб-сервер отправить HTTP-ответ обратно в ELB? если он идет напрямую к пользователю, будет ли он получать отклики производительности?
• Если я ограничиваю исходящий трафик для порта Http только в группе безопасности, существует ли еще угроза безопасности?

Схема Б:

• представляет эту конструкцию, создавая еще один слой точки отказа (NAT)?
• Будет ли это работать для связи Oauth?
• Может ли он работать с сторонними инструментами CI и Orchestration (jenkins, chef)?

Оба дизайна работают хорошо, но какой дизайн является наилучшей практикой для инфраструктуры, учитывающей производительность и безопасность.

благодаря

Answer 1

Короткий ответ, что в обоих случаях трафик, который попадает в ELB собирается обратно через УДР.

Для макета A: для запросов, которые возникают через ELB, только входящий порт имеет отношение к SG.
для других вещей, которые происходят в случаях EC2 и сделать трафик с внешним миром вам нужно будет открыть порты, что услуги используют

Для макета B:
да NAT является единственной точкой отказа. Если вы его потеряете, вы теряете связь с внешним миром.
Да. для внешнего мира трафик будет отображаться как исходный в ящике NAT.

Обычно (при нормальной настройке) для входящих запросов к вашему обслуживанию вы проходите через ELB.
для трафика, который должен выйти на улицу и происходит в VPC, вы проходите через NAT. для устранения одной точки сбоев у вас есть возможность установки NAT высокой доступности, или если вы запускаете многопользовательский режим, и приложение предназначено для поддержки отказов в области, вам просто нужно контролировать и устранять сбои в работе NAT.

Большое преимущество использования NAT заключается в том, что не всем машинам, которым требуется внешний трафик, необходимо иметь EIP, а также устройство NAT может запускать защищенное изображение. Вы в основном устанавливаете четкую границу для своего VPC, и вы можете лучше ее защитить.