Евгений Хлебников

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.

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

y0u Ленивый но его ответ самый верный :D
Saboteur чуть-чуть неправ : знак $ на конце имени общей папки означает сокрытие данной папки при просмотре общих папок на вашем компьютере через сеть. Папка при этом не обязательно доступна только администратору.
Скрытые сетевые папки
Вы можете, когда открываете доступ к общей папке в сеть, скрыть её - добавив в название общего ресурса знак $ в конце. Папка при этом будет доступна всем пользователям которым вы укажете, но не будет отображаться в списке общих папок вашего компьютера при просмотре встроенными средствами Windows (Explorer) - пользователи должны знать название ресурса и вводить его руками.
Такое сокрытие не спасет от хитрых линуксоидов, у которых нет соглашения, что папка с $ на конце - скрытая.

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

Отключить : (информация есть в статье) :
в ключе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\AutoShareServer
в Value поставить 0 и перезапустить службу Server.
После изменений, из специальных ресурсов у вас должен остаться только IPC$ и ваши, руками созданные общие ресурсы.

Надо ли отключать?

• Если у вас пользователь Administrator выключен или включен, но под ним никто не работает, и он имеет сложный пароль (вы при этом работаете под пользователем с пониженными правами, а Администратор используется только для установки ПО) то наличие таких общих ресурсов не проблема.
  
  
• Если вы используете пользователя Администратор без пароля для входа в локальную систему, то, если не изменяет память, MS запретило доступ к сетевым папкам с другого компьютера без ввода пароля. То есть это тоже безопасно :D
  
  
• Если же вы работаете на компе под очевидным пользователем(Пользователь Vasya на компьютере Vasya-computer например) с простым паролем и правами администратора то наличие таких сетевых ресурсов как доступ к дискам - проблема. (Если не вспоминать, что при такой ситуации, проблема безопасности вашего компьютера - вы)
  

К WinBlinds-ам упомянутым VoidVolker так же можно добавить www.astonshell.ru/aston2
Это именно шелл, смена оболочки, с которой вы работаете (Windows Explorer как файловый менеджер при этом остается).
На Windows XP всегда использовал блиндсы в связке с астоном : кастомный десктоп с кучей гаджетов и изменение внешнего вида окон Windows

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

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

В каком то виде ваша задача решается вот этой powershell функцией https://github.com/proxb/PowerShell_Scripts/blob/m...
Добавляете в конце вызов типа
Invoke-BalloonTip -Message "Test" -Title "testtitle" -MessageType Warning -Duration 3000

и ставите в шедулер с периодичностью нужной вам приложение "powershell.exe имяскрипта"

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 инстанс или бастион (для доступа к инстансам в приватной подсети)

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

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

get-help get-content -examples
$users = get-content file1.txt
считывает построчно ваш файл в переменную $users
каждую строку из файла можно адресовать по индексу в цикле for
get-help about_for -examples
for ($counter = 0; $counter -le $users.length;$counter +=1;) {write-host $users[$counter] }
Так как у вас файлы c одинаковым количеством строк то $passwords[$counter] даст соответствующий пароль внутри цикла, если считать файл паролей в переменную $passwords

cat /etc/*release | grep PRETTY_NAME
Попробуйте.
Работает на gentoo,centos(redhat) и debian-based.
arch\fedora не имею

к ответу display: block можно добавить (для 10-ки) еще и встроенный в систему менеджер пакетов
Он позволяет использовать пакеты из chocolatey а так же некоторые другие репозитории.
немного подробне вот тут : https://github.com/oneget/oneget
Например, вывод команды find-packageprovider в powershell (windows 10)
> Find-PackageProvider

Name Version Source Summary
---- ------- ------ -------
nuget 2.8.5.208 https://onege... NuGet provider for the OneGet meta-packag
psl 1.0.0.210 https://onege... psl provider for the OneGet meta-package
chocolatey 2.8.5.130 https://onege... ChocolateyPrototype provider for the OneG
NanoServerPackage 1.0.1.0 PSGallery A PackageManagement provider to Discover
GistProvider 0.6 PSGallery Gist-as-a-Package - PackageManagement Po
ChocolateyGet 1.0.0.1 PSGallery An PowerShell OneGet provider that discov
GitHubProvider 0.5 PSGallery GitHub-as-a-Package - PackageManagement P
TSDProvider 0.2 PSGallery PowerShell PackageManager provider to sea
DockerMsftProvider 1.0.0.1 PSGallery PowerShell module with commands for disco
ContainerImage 0.6.4.0 PSGallery This is a PackageManagement provider modu
PowerShellGet 1.1.3.1 PSGallery PowerShell module with commands for disco
MyAlbum 0.1.2 PSGallery MyAlbum provider discovers the photos in
OfficeProvider 1.0.0.1 PSGallery OfficeProvider allows users to install Mi
GitLabProvider 1.3.4 PSGallery GitLab PackageManagement provider
WSAProvider 1.0.0.4 PSGallery Provider to Discover, Install and invento
0install 2.12.1 PSGallery Zero Install is a decentralized cross-pla
AppxGet 0.1.0.1 PSGallery Powershell Package Management (OneGet) Pr
Choco - только один репозиториев доступных.

https://atom.io/packages/atom-package-sync
А вообще вроде бы достаточно синхронизировать папку .atom
из альтернативных решений :
хранить содержимое папки .atom в папке синхронизации вашего облачного провайдера а сама .atom (на windows это c:\users\username\.atom - на linux скорее всего /home/username/.atom) - симлинк.
хранить содержимое папки .atom в репозитории и синкаться с ним

dummyman написал варианты решения проблемы но не написал причины, куда можно посмотреть повнимательнее :
Если до подключения интернет работает а после - нет, значит вы в конфигурации VPN при подключении отдаете неверные DNS сервера с VPN сервера на ваш клиент. Это первый вариант, который можно проверить.
Путь решения описал dummyman :
- Вписать гарантированно работающие DNS серверы в ваш resolv.conf
- использовать dnsmasq и резолвить DNSы только через него, игнорируя приходящие настройки (это, по сути, еще одна программная прослойка которую нужно корректно настроить, поэтому этот путь спорный)
Я бы добавил еще путь "проверить настройки на VPN сервере : что отдается клиенту при подключении в качестве настроек сети(dns серверы)

Второй вариант проблемы - используемые вами до подключения DNS серверы пытаются ходить в интернет через VPN, а VPN им не разрешает по какой-то причине. Здесь только проверка (tracepath до прописанного в конфиге DNS сервера) и после получения результата - корректная настройка того узла где трейс теряется. Или же добавление маршрутов к DNS серверам через ваше интернет подключение, чтобы не ходили DNSы через VPN.

P.S. прочитал комментарии к ответу:

ДНС остался только nameserver 127.0.1.1

Что-то у вас намудрено. Проверьте для начала работоспособность интернета и содержимое /etc/resolv.conf без подключенного VPN.