Евгений

Powershell сейчас не под рукой но выглядеть скрипт должен как то так:

$file = 'ваш файл'
$newfile = 'другой файл'
$keyword = 'parametr'
(get-content $file -raw) -split "\n\n" | foreach {
    $firststring = $_ -split '\n' | select -first 1
    if $firststring -like $keyword { add-content $newfile $_}
}

здесь точно напутано с экранированием спец. символов, а так же не сделаны некоторые обработки для отсутствующих файлов и много чего еще. Дорабатывайте на здровье :D

Powershell

Set-Location c:/temp
$groups = (Get-ChildItem A*).Name | group-object -property {$_.Substring(30,$_.Length -37)} -ashashtable -asstring
$groups.Keys | foreach-object { 
    $folder=$_; $groups[$folder] | foreach-object {
                  new-item -itemtype file -path "$folder/$_" -force
                  move-item -path $_ -destination "$folder/$_" -force
     }
}

Если нужен однострочник

cd c:/temp;$g=(dir A*).Name | group {$_.Substring(30,$_.Length -37)} -AHT -asstring;$g.keys | %{$f=$_;$g[$f] | %{ni -type file -path $f/$_ -force; mv $_ $f/$_ -force}}

Однострочник можно, взяв в одинарные кавычки, передать параметром в powershell.exe, если вам надо было бы использовать этот функционал в уже написанных cmd скриптах.
Но вообще не надо откапывать стюардессуиспользовать cmd для скриптов. Используйте powershell \ python

пример:
https://stackoverflow.com/questions/41789176/how-t...
Если кратко алгоритм:
1. выясняем размер размер zip файла
2. читаем несколько байт из zip файла по известному адресу для того чтобы выяснить расположение и размер листинга файлов в zip файле
3. читаем несколько байт из zip файла с листингом файлов
4. создаем свой пустой zip файл вставляя туда полученные байты по нужным адресам.
функциями работы с zip выдаем список файлов

P.S. скрипт писал не я, но пару лет назад тоже решал подобную задачу.
"Спасение" тут - это чтение части файла, которое позволяет S3 и знание формата zip
В комментариях к ответу на SO написано про ограничения в размере zip в 4Гб - я не сталкивался и задачу по обходу проблемы не решал.

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. совершенно неясно зачем в тегах микротик