Евгений

Если это все шаги которые вы проделали, значит вы забыли открыть доступ по порту 80 к вашему инстансу.
По умолчанию, открыт только ssh\rdp доступ - вы настраивали это правило когда запускали инстанс руками. Скорее всего прокликали и не заметили, хоть там
и предлагается не открывать на 0.0.0.0/0.
Откройте список инстансов, выберите внизу в свойствах его security group
Откройте ее, выберите inbound
Добавьте правило доступа для порта 80 (есть темплейт "http") и требуемого диапазона IP адресов в формате CIDR - есть возможность выбрать "my ip" и доступ ограничится только для вашего выходного IP адреса у вашего провайдера.
По идее, лучше всего будет отредактировать правило для 22-го порта и выбрать там my ip.

Описанное выше - не единственная точка, которую нужно проверить.
Другие варианты:
локальный файрвол на машине
AWS Network ACL
недоступность IP адреса из вашей страны (в России РКН еще не все разблокировал)

1. AMI
Все плюсы и минусы вам расписали.
2. S3 bucket
Поддерживает шифрование, в том числе и клиентским(вашим) ключом - вы можете свободно положить в приватный бакет всю необходимую секретную информацию и простым aws s3 cp в юзердате всё получить.
Обновление сертификатов и конфигов, соответственно, просто перезаливкой в бакет и пересозданием инстансов ASG
Это вместо некоего веб хранилища.
3. SSM parameters
Можно перед развертыванием ASG инициализировать параметры вашего окружения, вплоть до сертификатов в зашифрованных ключах SSM и при развертывании забирать значения из SSM
Более сложно чем бакет, поскольку предназначается для кросс-датацентрового обмена секретами.

В вашем случае наилучшим решением будет s3 бакет, а самым простым и быстрым в реализации - AMI
Для того чтоюы не передавать access key и secret key для работы с амазоном в юзердате - используйте aws instance profile с нужными инстансу политиками.

Если есть сомнения в безопасности - значит надо настраивать дополнительный уровень :D
AWS предоставляет два уровня безопасности в VPC :
Network ACL и Security Groups
Первые служат для ограничения доступа между подсетями, вторые - между сетевыми интерфейсами в VPC
Несмотря на то, что Между ними есть довольно сильная разница в поведении\применении (описана в таблице docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC... ) выполняют они примерно одну и ту же функцию.
Как дополнительная возможность безопасности(рекомендуемая AWS в вышеуказанной статье) - внутренний firewall вашей OS может закрыть link-local( 169.254.x.x) и трафик на первые 4 адреса вашего VPC (внутренний функционал AWS, этот трафик даже не отслеживается с помошью flow logs, не то что контролируется).

Однако же, рекомендуется firewall внутри инстанса все же настраивать соответственно вашим правилам.
Безопасности мало не бывает, а для того чтобы правила на всех слоях безопаности соответствовали - используйте IAAC.

Ах да, ответ на вопрос : Достаточно надёжны.

Лучше описать вашу "более сложную топологию" и проблемы с которыми столкнулись.
Как правило, если в дефолт VPC у вас все завелось, то при поднятии VPN хоста в паблик подсети вашего VPC доступ внутрь VPC работать будет. Проблемы могут быть в маршрутизации, доступе(SecurityGroup\NetworkACL) и других особенностях организации вашего VPC.

Если у вас внутри вашего VPC только linux хосты - лучше не исполmзуйте VPN для администрирования. Рекомендованное решение - бастион.
Для доступа ваших пользователей внутрь VPC пока только VPN.

lightsail, как можно догадаться по названию, это упрощенный(легкий) интерфейс над вычислительными - Elastic Compute Cloud (EC2) сервисами. И немного более дешевый в связи с тем, что контроля вам дают мало. Однако он сразу реализует некоторые паттерны и наборы сервисов для быстрого старта. Это - путь стартапов.
Lightsail, насколько я помню, запускается в "VPC по умолчанию" которым управляет AWS и где все сервера живут в публичной подсети, что небезопасно.

Та схема которую вы хотите, наверное, реализуется lightsail-ом, но для большего контроля все таки рекомендуется организовать свой VPC (Virtual Private Cloud) - компонент сетевых сервисов AWS.
В вашем случае потребуется что-то вроде(для оценки стоимости) :

1. Балансировщик :
- ALB\ELB сервис (отдельный прайсинг). HA сервиса обеспечивает AWS
или
- два инстанса нужного вам балансировщика (Nginx, HAProxy и другие). HA и прочая обеспечиваете вы.

2. N бэкендов нужного типа (смотрите стоимость конкретного инстанса соответствующего вашим потребностям)

3. реплицируемые базы :
- вы можете взять 2 инстанса нужной мощности(платите за инстансы) и настроить все сами
или
- взять RDS (отдельный сервис, другой прайсинг) нужной базы где HA и обслуживанием будет заниматься AWS для вас, предоставляя вам эндпойнт для подключения с серверов.

4. Файловое хранилище. Тут интереснее
Если у вас Windows : вам понадобятся два инстанса для обеспечения отказоустойчивости и HA
Если у вас *nix : вы можете сделать так же как с WIndows или взять EFS (отдельный сервис, где вы платите за занятое место) который высокодоступен и может быть подключен к разным *nix инстансам одновременно.

5. Внутренности VPC
VPC организуется так же как и любая сеть в железном эквиваленте.
Подсети - приватные, публичные
Настройка роутинга для публичных подсетей, для приватных подсетей через NAT инстанс\сервис
NAT инстанс или сервис
VPN инстанс или бастион (для доступа к инстансам в приватной подсети)

Вот тут вы уже можете подсчитать во сколько обойдется примерно владение только инстансами и необходимыми сервисами.
Сколько у вас будет непредвиденных расходов на передачу данных и тп. - вы сможете увидеть только по результатам билинга за первый месяц.

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

При запуске инстанса (руками, через веб консоль) вам предлагалось в том числе и настроить SecurityGroup: настройки правил доступа c определенных мест по определенным портам (и делают строгое предупреждение, если вы оставляете в группе безопасности источник 0.0.0.0/0)
Вы настроили для вашего IP адреса/подсети разрешения доступа к 8080-му порту?