aws-api-gateway - CloudFormation堆栈资源依赖性问题: API Gateway Deployment + UsagePlan

Question

我正在开发 CloudFormation 模板来部署 API Gateway 资源，但在部署 (AWS::ApiGateway::Deployment) 和UsagePlan 资源方面遇到问题。这有点像先有鸡还是先有蛋的情况。

在UsagePlan中，我指定了ApiStage的配置，这意味着我需要首先创建部署资源。但是，当我尝试删除堆栈时，UsagePlan 失败，因为相应的阶段仍连接到UsagePlan。

我有一个关于UsagePlan的DependsOn语句(UsagePlan取决于部署)。这使得堆栈的创建不会出现问题。但由于此 DependsOn 语句，它强制UsagePlan 在删除操作时首先删除。这会导致错误。

请参阅下面的相关代码摘录。

谁有办法解决这个问题吗？我不可能是第一个偶然发现这一点的人!

谢谢!

"UppRestApiDeployment": {
  "Type": "AWS::ApiGateway::Deployment",
  "Properties": {
    "Description": "Upp Rest API Deployment",
    "RestApiId": {
      "Ref": "UppRestApi"
    },
    "StageName": {
      "Ref": "StackIdentifier"
    },
    "StageDescription": {
      "CacheClusterEnabled": false,
      "CacheClusterSize": "0.5",
      "CacheDataEncrypted": false,
      "CacheTtlInSeconds": 10,
      "CachingEnabled": false,
      "DataTraceEnabled": false,
      "LoggingLevel": "ERROR",
      "MetricsEnabled": true,
      "StageName": {
        "Ref": "StackIdentifier"
      },
      "Description": {
        "Fn::Sub": "${StackIdentifier} Stage"
      },
      "ThrottlingBurstLimit": 2000,
      "ThrottlingRateLimit": 1000,
      "Variables": {
        "lambdaAlias": {
          "Ref": "StackIdentifier"
        }
      }
    }
  }
},
"UppApiUsagePlan": {
  "Type": "AWS::ApiGateway::UsagePlan",
  "Properties": {
    "ApiStages": [
      {
        "ApiId": {
          "Ref": "UppRestApi"
        },
        "Stage": {
          "Ref": "StackIdentifier"
        }
      }
    ],
    "Description": "Upp Rest API Usage Plan to Prevent Overage Charges",
    "Quota": {
      "Limit": 5000,
      "Period": "MONTH"
    },
    "Throttle": {
      "BurstLimit": 200,
      "RateLimit": 100
    },
    "UsagePlanName": {
        "Fn::Sub": "${StackIdentifier}_UppApiUsagePlan"
    }
  },
  "DependsOn": [
    "UppRestApiDeployment"
  ]
}

Answer 1

UsagePlan 可以在多个 API 中重复使用。因此，理想情况下，我们建议您为每个 API 使用不同的 CloudFormation 堆栈，并为UsagePlan 使用不同的 CloudFormation 堆栈。这样，您就可以删除 API，而无需删除使用计划，也不会陷入此依赖性问题。