@alexDXB
AWS engineer

Какие Best practices по применению private zones в сервисе AWS Route53?

Существует автопарк EC2, который должны разговаривать друг с другом внутри инфраструктуры а некоторые тазики еще и отвечать на запросы извне. Вопрос: нужно ли настраивать private zone(aws.local) и цеплять сервисы на сабдомены(ubuntu1.aws.local) для адресации сообщений внутри сети? Как тогда привязать SSL certificate в этом случае чтоб все было секьюрно?
Или достаточно юзать Elastic IP для каждой машинки + AWS Certificate manager + route53(public zone) и все это закрыть секьюрити группами?
  • Вопрос задан
  • 131 просмотр
Решения вопроса 1
@yellowmew
Cloud infrastructure, monitoring engineer. SRE
1.
не совсем ясно как организована ваша инфраструктура
Судя по тому, что у вас есть вариант "назначить публичные IP и рулить публичными ДНС именами" - все располагается в default vpc и это не best practice.
Рекомендуется размещать инстансы, к которым не нужен доступ из интернета (те, которые хостят ваши сервисы, обслуживающие только ваши другие сервисы в том же VPC) в приватных подсетях VPC.
Вообще рекомендуется ВСЕ сервисы размещать в приватных подсетях а доступ из интернета к ним организовывать, используя прокси. AWS предоставляет ALB(ELB\NLB в зависимости от ваших потребностей), или же вы можете поднять свой прокси (HAProxy, NGINX или другие) на ec2 инстансе, расположенном в публичной подсети
2.
Route53 private zone
Если ваши сервисы находятся в приватной подсети и вам необходимо работать с ними по DNS именам: можно регистрировать инстансы в Route53 private zone или же поднять свой приватный DNS на любом ПО которое вы умеете(в таком случае необходима перенастройка параметров VPC в котором вы работаете, чтобы все сервисы могли работать с вашим DNS)
Так же можно использовать service discovery ПО, которое обеспечит разрешение имен DNS (например consul, но это потребует поднятия отдельного сервиса на ec2\ecs для обслуживания service discovery), или использовать service discovery предлагаемый AWS: Cloud Map - он использует route53 private zone для регистрации сервисов и разрешения имен.
3.
Сертификаты
Для сервисов, которые доступны публично - ничего сложного: используйте Certificate Manager для выпуска сертификатов на ALB или же LetsEncrypt если вы используете собственное ПО для прокси
Для сервисов, находящихся в приватных подсетях и недоступных публично:
- Можно забить и работать без TLS - сеть приватная, защищать или не защищать общение между сервисами в приватной подсети зависит от уровня вашей паранойи.
- ACM Private CA про который вы уже знаете
- В случае использования service discovery ПО можно использовать функционал предлагаемый решениями для service mesh, например consul connect service mesh: ваше приложение общается с прокси консула, а тот, обеспечивая TLS между нодами, направляет трафик приложения на нужный сервис

P.S. совершенно неясно зачем в тегах микротик
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@vitaly_il1
DevOps Consulting
Или достаточно юзать Elastic IP для каждой машинки

Независимо от DNS, стоит использовать private адреса - быстрее и дешевле (плата за траффик).
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы