@sander92 https://github.com/localstack/localstack

нет глупых вопросов, есть глупые ответы

и у меня уже работает ci/cd в github actions, там все просто

Я и не говорил что твои вопросы глупые, я говорю что возможно у тебя не хватит компетенции сделать нормальный CI/CD самому.

проблема только с aws и typescript, так как всех тех фичешек которые есть в java тут нет, и база еще находится удаленно,
от сюда и идут такие вопросы, в java есть test containers

aws это экосистема если делать авс правильно, соответственно и смены парадигм кодинга и мышления не избежать.

Ребята, заканчивайте. @sander92 @vlade11115
Предупреждаю, потом сутки read-only.

@VictorOps спасибо

Я не понимаю, за что? Вроде просто общаюсь и рассказываю как делают там где я видел.

я просто вопросы спрашиваю, мне ребята помогают

Не уходите в компетенции. Давайте больше развернутых вопросов и ответов. Иначе - недопонимание задач/вопросов/ответов и порождение флейма.

Покажи где был флейм или недопонимание между мной и @sander92?
У него весьма общий вопрос про тестирование в контексте AWS, и в AWS есть несколько удобных подходов как это делать, про которые мы и говорим.

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

Две лямбды не обязательно два микросервиса. Например степфункции это N лямбд, но выступают они как единое целое.
Довольно редко у меня нужно тестировать именно лямбду. Тестируем рест апи, например. Например это api gw который старутет step function execution, и отдаёт его id.
В ступфункции у тебя 3 лямбды (все цифры вымышленные).
И ты хочешь протестовать.
1.  Ты пишешь юнит тесты на каждый юнит твего кода. Эти юнит тесты не ходят в бд, а делают бизнес логику. Условно говоря их можно запустить в принципе без AWS, даём параметры на вход и проверяем вывод. Лямбды же просто вызывают эти юниты (это рекомендация от AWS, но точную ссылку не найду сейчас).
2. Ты пишешь интеграционные тесты, которые например вызывают твой сервис по HTTP API. Юнит на это не напишешь, так как учавствовать будут не твои сервисы а сервисы AWS (в нашем случае API GW и StepFunctions). И ты проверяешь что тебе id вернулся, и ходишь с ним в твой ендпоинт для получения результата.
Тесты из пункта 2 гоняются на отдельном сендбоксе или дев/тест стенде, названий много суть одна. В совсем вырожденном идеальном мире ты дропаешь всю инфраструктуру своего аккаунта,  и деплоишь её заново на каждый прогон тестов. Мы например чуть упростили и дропаем накатываем стеки не на каждый прогон тестов а раз в некоторое время.
Итого тесты из пункта 1 можно запускать откуда угодно. А тесты из пункта 2 ты в принципе не можешь запустить вне своего облачного провайдера. В этом удобство и недостаток облаков, вендор лок. С этим можно бороться но это отдельная тема для обсуждения.
И в тестах 1 и в тестах 2 нужны контракты между сторонами, это да.

Насколько плоха идея в новом проекте отказаться от VPC пиринга и прочих заморочек в пользу  ipv6 во всех VPC?

а как ipv6 меняет отношение к vpc peering и прочим заморочкам?

тем что там всё плоско и можно на acl вырулить. не надо выделять подсети для пиринга, не нужны внутренние балансеры

ну чтоб между разными VPC соединение установить - пиринг же нужен все равно? dual stack или как там это все называется

в том то и дело что нет, никаких NAT, любая сеть может любую сеть дёрнуть если ACL пропустит