Question

我发现很难理解SAM模板和Cloudformation模板之间的区别。我知道SAM模板可用于定义像Lambda这样的无服务器应用程序，但是它如何使它与Cloudformation模板不同？语法不同吗？我仍然可以在cloudformation模板中指定Lambda定义。所以，我的问题是我为什么要关心SAM？不了解云形成模板是否足够？

Answer 1

从CloudFormation的角度来看，SAM是一种转型。含义：SAM模板在语法上是等效的，但它们允许您更简洁地定义无服务器应用程序。 SAM模板最终在幕后扩展为完整的CFN。如果您已经了解CFN，但想要编写更少的YAML代码，SAM可能对您有益。这个想法是为了减少你的努力。

Answer 2

就像@路易斯·科隆（Luis Colon）所说，SAM是一种转变。意思是，在SAM模板的顶部有一个Transform语句，该语句使CloudFormation知道在此SAM模板上运行固有函数Transform，以将其转换为CloudFormation模板。因此，所有SAM模板最终都将转换为CF模板，但是对于大多数情况下的最终用户而言，仅使用SAM模板就更容易了。例如，对于一个正在创建的具有由新API触发的Lambda的简单应用程序，SAM模板将使您用比CloudFormation更少的行来完成此操作。

为扩展这一点，无服务器框架的行为类似。无服务器旨在跨平台（AWS，Azure等）工作。它的语法看起来与SAM非常相似，并且还将模板转换为目标平台（即AWS）模板的完整版本（即CloudFormation模板）。

Answer 3

SAM 模板是 Cloudformation 的超集。您可以通过 SAM 直接运行 CF 模板，它会起作用。

那么 SAM 带来了什么？举一个小例子，这个 SAM 片段：

Outputs:
  MySqsQueue:
    Description: "SQS Queue ARN"
    Value: !GetAtt MySqsQueue.Arn

在 sam build 步骤中转换为以下 Cloudformation 代码。上面的 SAM 模板不是合法的 Cloudformation。

Outputs:
  MySqsQueue:
    Value: !GetAtt
      - MySqsQueue
      - Arn

差别不大，只是让您了解什么是“转换”。

对于主要处理 Lambda 函数的 SAM（和无服务器框架）用户来说，最有用的转换是能够在 Lambda 函数上定义一个 Events 属性，并让它神奇地作为生成的 API 出现API 网关中的路径。

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: HelloWorldFunction
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get

被转换/扩展为多个 API 网关对象（一个 RestApi、一个部署和一个阶段）。此代码段中使用的 AWS::Serverless::Function 类型不是真正的 Cloudformation 类型 - 您不会在文档中找到它。 SAM 将其扩展为一个 Cloudformation 模板，其中包含一个 AWS::Lambda::Function 对象和 Cloudformation 理解的几个不同的 AWS::ApiGateway::* 对象。

以前，如果您编写纯 Cloudformation，则必须为要创建的每个 API 网关端点一遍又一遍地手动编写所有这些代码。现在您将其定义为 Lambda 函数的一个属性，SAM（或无服务器框架）会处理这些苦差事。

在过去，当我们不得不手动完成所有这些工作时，它完全糟糕。

SAM模板和Cloudformation模板之间的区别

3 个答案: