Я только что прошел через это. Я думаю, что следующее правильно.
AWS SAM - это оболочка вокруг Cloudformation. Таким образом, ваш шаблон SAM на самом деле является шаблоном Cloudformation. Ваш шаблон Cloudformation определяет ваши лямбды и DynamodBet c. Когда вы развертываете на AWS все ваши лямбды и DynamodB go на AWS, и вы можете тестировать в облаке.
Когда вы запускаете AWS SAM локально, вы запускаете свою лямбду локально (в docker контейнер), но он по-прежнему обращается к ресурсам в облаке AWS.
LocalStack имеет интерфейс CloudFormation, поэтому должна быть возможность развернуть файл шаблона CloudFormation. Но я столкнулся с некоторыми проблемами в этом и отказался.
Serverless Framework похож на AWS SAM в том смысле, что это платформа для разработки вашего кода без обслуживания (лямбда) и его развертывания на AWS , Безсерверный имеет свою собственную спецификацию yaml для определения стека. Преобразование из Cloudformation в yaml без сервера - это немного трудоемкий процесс.
Для локального стека существует плагин без сервера. Затем можно развернуть ваш код в localstack. Если перед вашими лямбдами есть API-шлюз, то будет локальный URL, который вы можете нажать, что приведет к запуску ваших лямбд. Это полностью внутри localstack и не использует AWS SAM.
В этот момент вы можете обнаружить, что ваш код все еще работает с реальными AWS сервисами. Таким образом, вам нужно изменить конечную точку-URL, чтобы она указывала локально, как упоминал Эндрю А. Для этого и для того, чтобы ваш код оставался неизменным для тестирования и производства, вы можете использовать переменные среды для каждой из конечных точек службы.
Как упоминает Эндрю А., должна быть возможность запускать код с использованием SAM local, который обращается к ресурсам. предоставлено localstack. Однако, может быть, предпочтительнее использовать один инструмент, если это было сделано в рамках конвейера тестирования.