Amazon RDS Aurora мастер / реплика ограничения доступа

Question

Я использую кластер БД с двумя экземплярами на Amazon RDS Aurora .Один экземпляр - master , другой - только для чтения реплика .Назначение реплики - предоставить стороннему приложению доступ к определенным таблицам базы данных для составления отчетов.Следовательно, средство создания отчетов получает доступ к конечной точке кластера только для чтения, что прекрасно работает.Для обеспечения обслуживания без простоев AWS в любое время продвигает «реплику» в качестве «мастера».Это довольно круто и не влияет на инструмент создания отчетов, поскольку он обращается к конечной точке cluster-ro, которая всегда направляет трафик к правильной (только для чтения) реплике.

Однако это означает, что мне нужно включитьПублично доступный: Да, флаг в обоих экземплярах, так что инструмент отчетности (который находится за пределами VPC) имеет доступ ко всем экземплярам, ​​потому что я не могу предсказать, какой экземпляр станет мастер или реплика, правильно?

Я бы предпочел, чтобы к «главному» экземпляру (независимо от того, какой это экземпляр) можно было получить доступ только изнутри VPC.Как мне этого добиться?

Насколько я понимаю, каждое изменение, которое я делаю в «главном» экземпляре, автоматически выполняется в репликах, включая, например, добавление / удаление групп безопасности.Поэтому, если я открою брандмауэр, чтобы разрешить доступ к репликам для инструмента создания отчетов, те же IP-адреса могут также обращаться к обычной конечной точке и экземпляру кластера (не только к конечной точке cluster-ro).Как я могу предотвратить это?

Answer 1

К сожалению, для этого вам нужно будет создать что-то нестандартное.Вот несколько вариантов, которые следует рассмотреть с точки зрения проектирования:

Кластер Aurora разделяет настройки группы безопасности по всему экземпляру, как вы вызывали.Если вы хотите иметь пользовательские настройки, то вам стоит только создать весь кластер VPC, а затем иметь ALB или прокси-серверы EC2, которые перенаправляют запросы в ваши экземпляры БД.Затем вы можете иметь несколько таких «прокси» и связать отдельные группы безопасности для каждого из них.

Один большой аргумент в архитектуре такого рода заключается в том, что вам нужно быть уверенным, что вы аккуратно позаботились об отказоустойчивости.Ваши прокси-серверы должны всегда общаться с конечными точками кластера, а не с конечными точками экземпляра, поскольку экземпляры могут скрытно переключаться с READER на WRITER.Например, ALB не позволяют создавать прослушиватели, которые пересылают запросы в DNS, они работают только с IP-адресами.Это означает, что вам понадобится дополнительная инфраструктура для мониторинга IP-адресов читателей и писателей и обновления ALB.

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

В той же заметке, почему вы не можете вместо этого использовать пользователей БД с ограниченным чтением и держать кластер общедоступным (конечно, с включенным ssl)?