Вопросы Теги

Хост Bastion с высокой доступностью - лучшие практики, ELB, EIP?

В настоящее время я пытаюсь найти хорошую конфигурацию для обеспечения высокой доступности хоста Bastion. Я хочу достичь следующих целей:

  1. Хосты-бастионы должны выдерживать отказ зоны доступности и отказ экземпляра ec2. Небольшое время простоя (несколько минут) может быть приемлемым. Хост Bastion в группе автоматического масштабирования в двух зонах доступности, ELB перед группой автоматического масштабирования.

    Эта установка имеет несколько преимуществ:

    • Простота настройки с использованием CloudFormation
    • Группы автоматического масштабирования могут использоваться в двух зонах доступности. чтобы гарантировать доступность
    • Не учитывается ограничение EIP для учетных записей

    У него также есть некоторые недостатки:

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

    Очевидное другое решение - использовать ElasticIP, который, как я вижу, имеет несколько недостатков:

    • Я могу (очевидно) не присоединять EIP к группе автоматического масштабирования напрямую
    • Если не использовать группы автоматического масштабирования, я должен установить что-то, что запускает новые хосты-бастионы EC2, если старые не работают, например, используя AWS Лямбда. Это добавляет дополнительную сложность.
    • Когда EIP присоединяется к группе автоматического масштабирования вручную, при отказе зоны доступности EIP отключается и не присоединяется повторно к новому экземпляру. Опять же, это можно решить, запустив программу (на экземпляре или AWS Lambda), которая повторно присоединяет EIP к экземпляру. Опять же, это добавляет дополнительную сложность.

    Каковы лучшие практики для экземпляров SSH с высоким уровнем доступности, то есть хостов-бастионов?

6
задан 23 December 2016 в 14:32
1 ответ

Похоже, что требование заключается в обеспечении функциональности бастиона по самой низкой разумной цене с RTO, скажем, 5 минут. RPO не применимо, так как это фактически прокси без гражданства, который можно легко перестроить.

У меня был бы бастионный хост, определенный как AMI или скрипт CloudFormation (AMI быстрее), внутри группы автомасштабирования с min/max/target set to 1. У меня не было бы балансировщика нагрузки, так как, насколько я вижу, в этом нет необходимости. Этот экземпляр будет зарегистрирован в Route53 с публичным именем домена, так что даже если этот экземпляр изменится, вы сможете получить к нему доступ, и это должно устранить предупреждения SSH. Я мог бы начать с одного экземпляра в каждой подсети, но я, вероятно, отключил бы его, если бы он был достаточно надежным - так и должно быть.

Развертывание бастионных хостов в CloudFormation описано Amazon здесь. На Amazon есть руководство по лучшей практике здесь. Вы не должны обращаться к внутренним ресурсам, используя их эластичные IP, так как они являются публичными IP и трафик к ним тарифицируется, в то время как частный IP трафик не тарифицируется. Доменные имена дешевле. Это может быть связано с настройкой скрипта CloudFormation

.
4
ответ дан 3 December 2019 в 00:35

Теги

Похожие вопросы