我正在AWS中制作一个HTTP API。我的大部分逻辑都是在lambda函数中处理的。我使用地形来描述和部署我的基础设施。到目前为止进展顺利。
我有一个单独的项目，有针对CRUD操作的lambdas
GET /journal
POST /journal
GET /journal/{id}
PUT /journal/{id}
DELETE /journal/{id}
代码和基础设施目前都在一个单回购中。
现在是时候为嵌套资源添加端点了
例如。。。
/journals/{id}/sentence/{id}
和
/journals/{id}/sentence/{id}/correction
我真的希望这些子资源的代码和地形在一个单独的项目中，因为它会变得非常非常大。
我真的很难弄清楚如何为API网关制作子资源，这些子资源存在于多个单独部署的项目中。
我希望避免导出api网关资源的ARN并在其他项目中使用它们，因为我认为在单独的部署之间创建依赖关系不是一个好主意。
我真的很高兴听到任何关于如何管理这一问题的建议，因为我相信很多人都面临过这个问题。
是否可以使用route53将域上的所有API调用路由到许多单独的API网关？如果这是可能的，那么这会让生活变得更轻松。我真的很难找到文档或文献来解释除了创建具有单一资源端点的API之外的任何内容。
编辑：我还有一个想法，也许我所有的lambda项目都完全不知道api网关，只是将它们的ARN作为输出导出。然后，我可以有一个完全独立的项目，它定义了整个api网关并创建lambda集成，这些集成只需使用其他项目中函数导出的函数ARN。这将防止每个lambda项目需要引用相应父资源的api_gateway_resource不过我觉得这可能不是个好主意。
我想避免导出api网关资源和在其他项目中使用它们，因为我认为这不是一个好主意在单独的部署之间创建依赖关系。
我不确定那句话。无论采用何种方式，创建API GW的项目和lambda子项目之间都将存在依赖关系。
到目前为止，我理解的问题是你应该朝哪个方向创建这种依赖：
- 导出apigw并在lambda项目中重用它
- 导出lambda并在apigw项目中重用它
我认为lambda在地形项目中被视为独立的基础设施，而不在其中创建任何类型的apigw相关资源是有意义的。首先，因为在这种情况下，它已经对lambda的使用产生了强烈的隐式依赖和约束。其次，你可以这样想：如果你的项目增长越来越多，你需要在API中添加越来越多的lambdas，会怎么样。在这种情况下，您可能不想每次都创建新的方法/资源，在terraform中使用类似for_each的东西并一次性编写代码，并在添加新的lambda时自动创建新的集成可能会更方便。
因此，我会避免第一种选择，而选择第二种选择，从建筑的角度来看，它更干净。所有与API GW有关的内容都在同一个项目中。您的编辑将其指向正确的方向。你可以有一个回购"；基础设施"；(你想怎么称呼它就怎么称呼它(和一个代表"；Lambda"；。您可以将lambda ARN输出为列表(或带有其他关键参数的自定义映射(，并使用apigw项目的远程状态在lambda中循环，并使用for_each在一个位置创建所需的资源。
例如，使用apigw项目的远程状态：
data "terraform_remote_state" "lambda" {
backend = "s3"
config = {
bucket = "my-bucket"
key = "my/key/state/for/lambda"
region = "region"
}
}
并使用这样的输出：
resource "aws_api_gateway_integration" "lambda" {
for_each = data.terraform_remote_state.lambda.outputs.lambdas
...
uri = each.value
}
是否可以使用route53将域上的所有API调用路由到许多独立的API网关？如果这是可能的，那么这就是生活容易多了。
很抱歉，我不确定是否理解这一点，但我仍会尝试详细介绍这个话题。"；链接"；API网关为您提供调用您的API只是一个DNS。当您创建API时，后台AWS会在us-east-1区域为您创建CloudFront分发。您无法通过控制台访问它，因为它由AWS管理。当您将API映射到域名时，实际上您将域映射到API的CloudFront分发版。当您向API添加方法或资源时(这就是您对lambda所做的(，实际上并不是每次都创建新的API。