[{"data":1,"prerenderedAt":210},["ShallowReactive",2],{"content-guides-building-serverless-applications-with-terraform-10-appendix-A-EventBridge":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":23,"contributorPaths":24,"menuType":29,"contentName":30,"slug":31,"readingTime":32,"menu":33,"nextDocItem":194,"previousDocItem":171},"\u003Cp>In previous chapters, you learned the foundational steps of constructing a serverless application using infrastructure as code (IaC). In this appendix, you learn how to use EventBridge as part of your serverless applications and use event-driven architecture (EDA) primitives.\u003C\u002Fp>\n\u003Cp>In many scenarios, developers design applications to respond to events. Amazon EventBridge Event Bus is a serverless event bus that helps you receive, filter, transform, route, and deliver events to over 200 targets. In this chapter you learn how to route different event types to a variety of AWS targets. \u003C\u002Fp>\n\u003Ch3>AWS Health Events\u003C\u002Fh3>\n\u003Cp>Documentation for AWS Health states the following\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>You can use Amazon EventBridge to detect and react to AWS Health events. Then, based on rules that you create, EventBridge invokes one or more target actions when an event matches the values that you specify in a rule.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>AWS delivers events from services to the default EventBridge bus. You can add a routing rule for that bus looking for events originating from the \u003Ccode>aws.health\u003C\u002Fcode> source and configure sending those events to different AWS targets. \u003C\u002Fp>\n\u003Cp>Using the same directory structure as in previous chapters.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">├── main.tf\n├── modules\n│   └── eb\n│       └── eb-aws-health\n│           ├── cloudwatch-logs-target.tf\n│           ├── main.tf\n│           ├── outputs.tf\n│           ├── sns-target.tf\n│           └── versions.tf\n├── outputs.tf\n├── providers.tf\n├── variables.tf\n└── versions.tf\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>In your \u003Ccode>.\u002Fmain.tf\u003C\u002Fcode> file add the new module reference:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-hcl\">module "eb_rule_aws_health" {\n  source = ".\u002Fmodules\u002Feb\u002Feb-aws-health"\n  providers = {\n    aws = aws.use1\n  }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Configure the EventBridge resources in the \u003Ccode>.\u002Fmodules\u002Feb\u002Feb-aws-health\u002Fmain.tf\u003C\u002Fcode> file.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-hcl\"># Captures events sent to the default eventbridge bus from AWS Health\nresource "aws_cloudwatch_event_rule" "eb_rule_aws_health" {\n    name = "CaptureAWSHealthEvents"\n    description = "AWS Health Events"\n\n    event_pattern = jsonencode({\n        source = [\n            "aws.health"\n            ]\n        })\n}\n\n# Define a target for event delivery \nresource "aws_cloudwatch_event_target" "send-to-cw-logs" {\n    rule = aws_cloudwatch_event_rule.eb_rule_aws_health.name\n    arn = aws_cloudwatch_log_group.awshealth.arn\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The \u003Ccode>source\u003C\u002Fcode> property in the above snippet enables the rule to only match events coming from AWS Health, after which events are sent to CloudWatch Logs.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-json\">{\n  "source": ["aws.health"]\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>For event delivery to work, you need to define IAM policies. You also need to define the log retention perior for the target CloudWatch Logs group. \u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-hcl\">resource "aws_cloudwatch_log_group" "awshealth" {\n  name              = "\u002Faws\u002Fevents\u002Fhealth\u002Flogs"\n  retention_in_days = 7\n}\n\ndata "aws_iam_policy_document" "awshealth" {\n  statement {\n    effect = "Allow"\n    actions = [\n      "logs:CreateLogStream"\n    ]\n\n    resources = [\n      "${aws_cloudwatch_log_group.awshealth.arn}:*"\n    ]\n\n    principals {\n      type = "Service"\n      identifiers = [\n        "events.amazonaws.com",\n        "delivery.logs.amazonaws.com"\n      ]\n    }\n  }\n  statement {\n    effect = "Allow"\n    actions = [\n      "logs:PutLogEvents"\n    ]\n\n    resources = [\n      "${aws_cloudwatch_log_group.awshealth.arn}:*:*"\n    ]\n\n    principals {\n      type = "Service"\n      identifiers = [\n        "events.amazonaws.com",\n        "delivery.logs.amazonaws.com"\n      ]\n    }\n\n    condition {\n      test     = "ArnEquals"\n      values   = [aws_cloudwatch_event_rule.eb_rule_aws_health.arn]\n      variable = "aws:SourceArn"\n    }\n  }\n}\n\nresource "aws_cloudwatch_log_resource_policy" "awshealth" {\n  policy_document = data.aws_iam_policy_document.awshealth.json\n  policy_name     = "awshealth-eb-log-publishing-policy"\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Run \u003Ccode>terraform apply\u003C\u002Fcode> to apply the updates. With this IaC configuration applied, you see AWS Health events in your CloudWatch Logs. In addition to sending events to CloudWatch, you can also deliver them via email by using Amazon SNS, or start a serverless workflow by invoking a Lambda function or executing a Step Functions state machine. \u003C\u002Fp>\n\u003Cp>The following JSON snippet illustrates a sample AWS Health event received through EventBridge. \u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-json\">{\n    "version": "0",\n    "id": "34afc3ea-e5dd-e2fa-cdf6-e5d1781dd41b",\n    "detail-type": "AWS Health Event",\n    "source": "aws.health",\n    "account": "123456789001",\n    "time": "2024-06-04T07:20:41Z",\n    "region": "us-west-2",\n    "resources": [\n        "prodSearch01-infra"\n    ],\n    "detail": {\n        "eventArn": "arn:aws:health:us-west-2::event\u002FES\u002F**REDACTED**",\n        "service": "ES",\n        "eventTypeCode": "AWS_ES_SERVICE_SOFTWARE_UPDATE_AVAILABLE",\n        "eventTypeCategory": "accountNotification",\n        "eventScopeCode": "ACCOUNT_SPECIFIC",\n        "communicationId": "**REDACTED**",\n        "startTime": "Tue, 4 Jun 2024 07:16:05 GMT",\n        "lastUpdatedTime": "Tue, 4 Jun 2024 07:20:01 GMT",\n        "statusCode": "open",\n        "eventRegion": "us-west-2",\n        "eventDescription": [\n            {\n                "language": "en_US",\n                "latestDescription": "A new service software update OpenSearch_2_11_R20240502-P2 is available **REDACTED**"\n            }\n        ],\n        "affectedEntities": [\n            {\n                "entityValue": "prodSearch01-infra",\n                "status": "IMPAIRED",\n                "lastUpdatedTime": "Tue, 4 Jun 2024 07:20:01 GMT"\n            }\n        ],\n        "affectedAccount": "123456789001",\n        "page": "1",\n        "totalPages": "1"\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Adding custom filtering and routing\u003C\u002Fh2>\n\u003Cp>Now that you understand the format of the event, you can add custom filtering and routing in your EventBridge Rules to route them to the correct target. For example, you want to monitor for Amazon Relational Database Service (RDS) deprecation notifications and send emails to the DBA team so that they can plan and schedule the major version upgrades. You can use \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fhealth\u002Flatest\u002Fug\u002Faws-health-planned-lifecycle-events.html#planned-lifecycle-event-notifications\">Planned lifecycle events for AWS Health\u003C\u002Fa> to route important events to targets.\u003C\u002Fp>\n\u003Cp>The following code snippets shows how to implement custom filtering and routing described above.\u003C\u002Fp>\n\u003Cp>Configure the SNS topic:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-hcl\">resource "aws_sns_topic" "notify_dbas" {\n  name = "notify-dba-team"\n}\n\nresource "aws_sns_topic_policy" "default" {\n  arn    = aws_sns_topic.notify_dbas.arn\n  policy = data.aws_iam_policy_document.sns_topic_policy.json\n}\n\ndata "aws_iam_policy_document" "sns_topic_policy" {\n  statement {\n    effect  = "Allow"\n    actions = ["SNS:Publish"]\n\n    principals {\n      type        = "Service"\n      identifiers = ["events.amazonaws.com"]\n    }\n\n    resources = [aws_sns_topic.notify_dbas.arn]\n  }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Then create an EventBridge target and rule resources. \u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-hcl\"># Define SNS topic created above as EventBridge event target\nresource "aws_cloudwatch_event_target" "sns_notify_dba" {\n  rule      = aws_cloudwatch_event_rule.eb_rule_aws_health_rds_events.name\n  target_id = "NotifyDBAs"\n  arn       = aws_sns_topic.notify_dbas.arn\n}\n\n# Capture events sent to the default EventBridge bus \n# from AWS Health for RDS updates, and notify the DBA team \n# over SNS.\nresource "aws_cloudwatch_event_rule" "eb_rule_aws_health_rds_events" {\n  name = "CaptureAWSHealthEvents_AWS_RDS_PLANNED_LIFECYCLE_EVENT"\n  description = "AWS RDS Lifecycle events"\n\n  event_pattern = jsonencode({\n    source = [\n        "aws.health"\n        ],\n    detail = {\n        eventTypeCode = ["AWS_RDS_PLANNED_LIFECYCLE_EVENT"]\n    }\n  })\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Now the DBA team is notified via SNS for important RDS events, such as major version upgrades or deprecation notices.\u003C\u002Fp>\n\u003Ch2>Conclusion\u003C\u002Fh2>\n\u003Cp>This module shows how to use Terraform to capture events from AWS Health and route them to different targets. Using this pattern you can drive important events to different targets, and respond to events in a meaningful way. This technique can be applied for operational events, such as alerts or tickets, as well as business use cases, such as order-placed or shipment-delivered. \u003C\u002Fp>\n\u003Cp>Using the patterns described above you can build your own event-driven architectures to cover a variety of operational and business use cases.  \u003C\u002Fp>\n\u003Cp>Learn more about using EventBridge by following the \u003Ca href=\"https:\u002F\u002Fcatalog.us-east-1.prod.workshops.aws\u002Fworkshops\u002F63320e83-6abc-493d-83d8-f822584fb3cb\u002Fen-US\">Building event-driven architectures on AWS workshop\u003C\u002Fa>.\u003C\u002Fp>\n",{"title":6,"order":7,"authors":8,"resources":12},"10. Appendix A - Amazon EventBridge",10,[9,10,11],"Anton Aleksandrov","Debasis Rath","Luis Cerezo",[13,17,20],{"link":14,"text":15,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Fcloudwatch_event_bus","aws_cloudwatch_event_bus Terraform resource","Documentation",{"link":18,"text":19,"type":16},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fhealth\u002Flatest\u002Fug\u002Fcloudwatch-events-health.html","Monitoring AWS Health events with Amazon EventBridge",{"link":21,"text":22,"type":16},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fhealth\u002Flatest\u002Fug\u002Faws-health-planned-lifecycle-events.html#planned-lifecycle-event-notifications","Planned lifecycle events for AWS Health - What should I expect when I receive a planned lifecycle event notification?","In previous chapters, you learned the foundational steps of constructing a serverless application using infrastructure as code (IaC). In this appendix, you learn how to use EventBridge as part of your serverless applications and use event-driven architecture (EDA) primitives.\n\nIn many scenarios, developers design applications to respond to events. Amazon EventBridge Event Bus is a serverless event bus that helps you receive, filter, transform, route, and deliver events to over 200 targets. In this chapter you learn how to route different event types to a variety of AWS targets. \n\n### AWS Health Events\n\nDocumentation for AWS Health states the following\n\n> You can use Amazon EventBridge to detect and react to AWS Health events. Then, based on rules that you create, EventBridge invokes one or more target actions when an event matches the values that you specify in a rule.\n\nAWS delivers events from services to the default EventBridge bus. You can add a routing rule for that bus looking for events originating from the `aws.health` source and configure sending those events to different AWS targets. \n\nUsing the same directory structure as in previous chapters.\n\n```bash\n├── main.tf\n├── modules\n│   └── eb\n│       └── eb-aws-health\n│           ├── cloudwatch-logs-target.tf\n│           ├── main.tf\n│           ├── outputs.tf\n│           ├── sns-target.tf\n│           └── versions.tf\n├── outputs.tf\n├── providers.tf\n├── variables.tf\n└── versions.tf\n```\n\nIn your `.\u002Fmain.tf` file add the new module reference:\n\n```hcl\nmodule \"eb_rule_aws_health\" {\n  source = \".\u002Fmodules\u002Feb\u002Feb-aws-health\"\n  providers = {\n    aws = aws.use1\n  }\n}\n```\n\nConfigure the EventBridge resources in the `.\u002Fmodules\u002Feb\u002Feb-aws-health\u002Fmain.tf` file.\n\n```hcl\n# Captures events sent to the default eventbridge bus from AWS Health\nresource \"aws_cloudwatch_event_rule\" \"eb_rule_aws_health\" {\n    name = \"CaptureAWSHealthEvents\"\n    description = \"AWS Health Events\"\n\n    event_pattern = jsonencode({\n        source = [\n            \"aws.health\"\n            ]\n        })\n}\n\n# Define a target for event delivery \nresource \"aws_cloudwatch_event_target\" \"send-to-cw-logs\" {\n    rule = aws_cloudwatch_event_rule.eb_rule_aws_health.name\n    arn = aws_cloudwatch_log_group.awshealth.arn\n}\n```\n\nThe `source` property in the above snippet enables the rule to only match events coming from AWS Health, after which events are sent to CloudWatch Logs.\n\n\n```json\n{\n  \"source\": [\"aws.health\"]\n}\n```\n\nFor event delivery to work, you need to define IAM policies. You also need to define the log retention perior for the target CloudWatch Logs group. \n\n```hcl\nresource \"aws_cloudwatch_log_group\" \"awshealth\" {\n  name              = \"\u002Faws\u002Fevents\u002Fhealth\u002Flogs\"\n  retention_in_days = 7\n}\n\ndata \"aws_iam_policy_document\" \"awshealth\" {\n  statement {\n    effect = \"Allow\"\n    actions = [\n      \"logs:CreateLogStream\"\n    ]\n\n    resources = [\n      \"${aws_cloudwatch_log_group.awshealth.arn}:*\"\n    ]\n\n    principals {\n      type = \"Service\"\n      identifiers = [\n        \"events.amazonaws.com\",\n        \"delivery.logs.amazonaws.com\"\n      ]\n    }\n  }\n  statement {\n    effect = \"Allow\"\n    actions = [\n      \"logs:PutLogEvents\"\n    ]\n\n    resources = [\n      \"${aws_cloudwatch_log_group.awshealth.arn}:*:*\"\n    ]\n\n    principals {\n      type = \"Service\"\n      identifiers = [\n        \"events.amazonaws.com\",\n        \"delivery.logs.amazonaws.com\"\n      ]\n    }\n\n    condition {\n      test     = \"ArnEquals\"\n      values   = [aws_cloudwatch_event_rule.eb_rule_aws_health.arn]\n      variable = \"aws:SourceArn\"\n    }\n  }\n}\n\nresource \"aws_cloudwatch_log_resource_policy\" \"awshealth\" {\n  policy_document = data.aws_iam_policy_document.awshealth.json\n  policy_name     = \"awshealth-eb-log-publishing-policy\"\n}\n```\nRun `terraform apply` to apply the updates. With this IaC configuration applied, you see AWS Health events in your CloudWatch Logs. In addition to sending events to CloudWatch, you can also deliver them via email by using Amazon SNS, or start a serverless workflow by invoking a Lambda function or executing a Step Functions state machine. \n\nThe following JSON snippet illustrates a sample AWS Health event received through EventBridge. \n\n```json\n{\n    \"version\": \"0\",\n    \"id\": \"34afc3ea-e5dd-e2fa-cdf6-e5d1781dd41b\",\n    \"detail-type\": \"AWS Health Event\",\n    \"source\": \"aws.health\",\n    \"account\": \"123456789001\",\n    \"time\": \"2024-06-04T07:20:41Z\",\n    \"region\": \"us-west-2\",\n    \"resources\": [\n        \"prodSearch01-infra\"\n    ],\n    \"detail\": {\n        \"eventArn\": \"arn:aws:health:us-west-2::event\u002FES\u002F**REDACTED**\",\n        \"service\": \"ES\",\n        \"eventTypeCode\": \"AWS_ES_SERVICE_SOFTWARE_UPDATE_AVAILABLE\",\n        \"eventTypeCategory\": \"accountNotification\",\n        \"eventScopeCode\": \"ACCOUNT_SPECIFIC\",\n        \"communicationId\": \"**REDACTED**\",\n        \"startTime\": \"Tue, 4 Jun 2024 07:16:05 GMT\",\n        \"lastUpdatedTime\": \"Tue, 4 Jun 2024 07:20:01 GMT\",\n        \"statusCode\": \"open\",\n        \"eventRegion\": \"us-west-2\",\n        \"eventDescription\": [\n            {\n                \"language\": \"en_US\",\n                \"latestDescription\": \"A new service software update OpenSearch_2_11_R20240502-P2 is available **REDACTED**\"\n            }\n        ],\n        \"affectedEntities\": [\n            {\n                \"entityValue\": \"prodSearch01-infra\",\n                \"status\": \"IMPAIRED\",\n                \"lastUpdatedTime\": \"Tue, 4 Jun 2024 07:20:01 GMT\"\n            }\n        ],\n        \"affectedAccount\": \"123456789001\",\n        \"page\": \"1\",\n        \"totalPages\": \"1\"\n    }\n}\n```\n\n## Adding custom filtering and routing\n\nNow that you understand the format of the event, you can add custom filtering and routing in your EventBridge Rules to route them to the correct target. For example, you want to monitor for Amazon Relational Database Service (RDS) deprecation notifications and send emails to the DBA team so that they can plan and schedule the major version upgrades. You can use [Planned lifecycle events for AWS Health](https:\u002F\u002Fdocs.aws.amazon.com\u002Fhealth\u002Flatest\u002Fug\u002Faws-health-planned-lifecycle-events.html#planned-lifecycle-event-notifications) to route important events to targets.\n\nThe following code snippets shows how to implement custom filtering and routing described above.\n\nConfigure the SNS topic:\n\n```hcl\nresource \"aws_sns_topic\" \"notify_dbas\" {\n  name = \"notify-dba-team\"\n}\n\nresource \"aws_sns_topic_policy\" \"default\" {\n  arn    = aws_sns_topic.notify_dbas.arn\n  policy = data.aws_iam_policy_document.sns_topic_policy.json\n}\n\ndata \"aws_iam_policy_document\" \"sns_topic_policy\" {\n  statement {\n    effect  = \"Allow\"\n    actions = [\"SNS:Publish\"]\n\n    principals {\n      type        = \"Service\"\n      identifiers = [\"events.amazonaws.com\"]\n    }\n\n    resources = [aws_sns_topic.notify_dbas.arn]\n  }\n}\n```\n\nThen create an EventBridge target and rule resources. \n\n```hcl\n# Define SNS topic created above as EventBridge event target\nresource \"aws_cloudwatch_event_target\" \"sns_notify_dba\" {\n  rule      = aws_cloudwatch_event_rule.eb_rule_aws_health_rds_events.name\n  target_id = \"NotifyDBAs\"\n  arn       = aws_sns_topic.notify_dbas.arn\n}\n\n# Capture events sent to the default EventBridge bus \n# from AWS Health for RDS updates, and notify the DBA team \n# over SNS.\nresource \"aws_cloudwatch_event_rule\" \"eb_rule_aws_health_rds_events\" {\n  name = \"CaptureAWSHealthEvents_AWS_RDS_PLANNED_LIFECYCLE_EVENT\"\n  description = \"AWS RDS Lifecycle events\"\n\n  event_pattern = jsonencode({\n    source = [\n        \"aws.health\"\n        ],\n    detail = {\n        eventTypeCode = [\"AWS_RDS_PLANNED_LIFECYCLE_EVENT\"]\n    }\n  })\n}\n```\n\nNow the DBA team is notified via SNS for important RDS events, such as major version upgrades or deprecation notices.\n\n## Conclusion\n\nThis module shows how to use Terraform to capture events from AWS Health and route them to different targets. Using this pattern you can drive important events to different targets, and respond to events in a meaningful way. This technique can be applied for operational events, such as alerts or tickets, as well as business use cases, such as order-placed or shipment-delivered. \n\nUsing the patterns described above you can build your own event-driven architectures to cover a variety of operational and business use cases.  \n\nLearn more about using EventBridge by following the [Building event-driven architectures on AWS workshop](https:\u002F\u002Fcatalog.us-east-1.prod.workshops.aws\u002Fworkshops\u002F63320e83-6abc-493d-83d8-f822584fb3cb\u002Fen-US).\n",[25,26,27,28],"content\u002Fcontributors\u002Fanton-aleksandrov.json","content\u002Fcontributors\u002Fdebasis-rath.json","content\u002Fcontributors\u002Fmatt-ridehalgh.json","content\u002Fcontributors\u002Fluis-cerezo.json","LIST","Building Serverless Applications with Terraform","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F10-appendix-A-EventBridge","5 min",[34],{"title":35,"content":36},"Guide",[37,56,72,87,106,119,134,155,171,186,194],{"title":38,"order":39,"authors":40,"resources":41,"time":52,"path":53,"id":54,"link":55},"1. Introduction",1,[9,10],[42,46,49],{"link":43,"text":44,"type":45},"https:\u002F\u002Faws.amazon.com\u002Fserverless\u002Fsam\u002F","AWS Serverless Application Model (SAM)","link",{"link":47,"text":48,"type":45},"https:\u002F\u002Faws.amazon.com\u002Fcdk\u002F","AWS Cloud Development Kit (CDK)",{"link":50,"text":51,"type":45},"https:\u002F\u002Fwww.terraform.io\u002F","Hashicorp Terraform","4 min","01-introduction","01-introduction.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F01-introduction",{"title":57,"order":58,"authors":59,"resources":60,"time":68,"path":69,"id":70,"link":71},"2. Solution Overview",2,[9,10],[61,62,65],{"link":50,"text":51,"type":45},{"link":63,"text":64,"type":45},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fcli\u002Flatest\u002Fuserguide\u002Fgetting-started-install.htm","AWS CLI",{"link":66,"text":67,"type":45},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fiam\u002F","AWS IAM","3 min","02-solution-overview","02-solution-overview.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F02-solution-overview",{"title":73,"order":74,"authors":75,"resources":77,"time":52,"path":84,"id":85,"link":86},"3. S3 buckets",3,[9,10,76],"Matt Ridehalgh",[78,81],{"link":79,"text":80,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs","AWS Terraform Provider",{"link":82,"text":83,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Fs3_bucket","aws_s3_bucket","03-s3-buckets","03-s3-buckets.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F03-s3-buckets",{"title":88,"order":89,"authors":90,"resources":91,"time":52,"path":103,"id":104,"link":105},"4. Lambda functions",4,[9,10],[92,93,96,99],{"link":79,"text":80,"type":16},{"link":94,"text":95,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Flambda_function","aws_lambda_function",{"link":97,"text":98,"type":16},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fserverless-application-model\u002Flatest\u002Fdeveloperguide\u002Fterraform-support.html","AWS SAM Terraform support",{"link":100,"text":101,"type":102},"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fbuilding-serverless-applications-with-terraform\u002Fblob\u002Fmain\u002Flambdas\u002Fgreetings_lambda\u002Findex.mjs","index.mjs","Sample","04-lambda-functions","04-lambda-functions.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F04-lambda-functions",{"title":107,"order":108,"authors":109,"resources":110,"time":52,"path":116,"id":117,"link":118},"5. API Gateway",5,[9,10],[111,112,115],{"link":79,"text":80,"type":16},{"link":113,"text":114,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Fapi_gateway_rest_api","aws_api_gateway_rest_api",{"link":97,"text":98,"type":16},"05-api-gateway","05-api-gateway.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F05-api-gateway",{"title":120,"order":121,"authors":122,"resources":123,"time":52,"path":131,"id":132,"link":133},"6. Asynchronous processing",6,[9,10],[124,125,128],{"link":79,"text":80,"type":16},{"link":126,"text":127,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Fsqs_queue","aws_sqs_queue",{"link":129,"text":130,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Flambda_event_source_mapping","aws_lambda_event_source_mapping","06-async-processing","06-async-processing.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F06-async-processing",{"title":135,"order":136,"authors":137,"resources":138,"time":32,"path":152,"id":153,"link":154},"7. Observability",7,[9,10],[139,140,143,146,149],{"link":79,"text":80,"type":16},{"link":141,"text":142,"type":16},"https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Flambda-monitoring.html","Lambda function observability, monitoring, and troubleshooting",{"linke":144,"text":145,"type":16},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fapigateway\u002Flatest\u002Fdeveloperguide\u002Frest-api-monitor.html","Monitoring API Gateway REST API",{"link":147,"text":148,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Fapi_gateway_account","aws_api_gateway_account",{"link":150,"text":151,"type":16},"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fhashicorp\u002Faws\u002Flatest\u002Fdocs\u002Fresources\u002Fapi_gateway_stage","aws_api_gateway_stage","07-observability","07-observability.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F07-observability",{"title":156,"order":157,"authors":158,"resources":159,"time":167,"path":168,"id":169,"link":170},"8. Modularizing your IaC projects",8,[9,10],[160,161,164],{"link":79,"text":80,"type":16},{"link":162,"text":163,"type":16},"https:\u002F\u002Fdeveloper.hashicorp.com\u002Fterraform\u002Flanguage\u002Fmodules","Terraform Modules",{"link":165,"text":166,"type":102},"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fbuilding-serverless-applications-with-terraform","Sample project source code","8 min","08-modularizing-your-iac-projects","08-modularizing-your-iac-projects.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F08-modularizing-your-iac-projects",{"title":172,"order":173,"authors":174,"resources":175,"time":182,"path":183,"id":184,"link":185},"9. Summary and next steps",9,[9,10],[176,177,179,181],{"link":79,"text":80,"type":16},{"link":178,"text":51,"type":16},"https:\u002F\u002Fdeveloper.hashicorp.com\u002Fterraform",{"link":43,"text":180,"type":16},"AWS SAM",{"link":165,"text":166,"type":102},"2 min","09-summary","09-summary.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F09-summary",{"title":6,"order":7,"authors":187,"resources":188,"time":32,"path":192,"id":193,"link":31},[9,10,11],[189,190,191],{"link":14,"text":15,"type":16},{"link":18,"text":19,"type":16},{"link":21,"text":22,"type":16},"10-appendix-A-EventBridge","10-appendix-A-EventBridge.md",{"title":195,"order":196,"authors":197,"resources":198,"time":52,"path":207,"id":208,"link":209},"10. Appendix B - AWS Step Functions",11,[9,10,11],[199,202,204],{"link":200,"text":201,"type":16},"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fdevops\u002Fbest-practices-for-writing-step-functions-terraform-projects\u002F","Best Practices for Writing Step Functions Terraform Projects",{"link":14,"text":203,"type":16},"cloudwatch_event_bus terraform resource",{"link":205,"text":206,"type":16},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fstep-functions\u002Flatest\u002Fdg\u002Fconcepts-amazon-states-language.html","Amazon States Language","10-appendix-B-SFN","10-appendix-B-SFN.md","\u002Fcontent\u002Fguides\u002Fbuilding-serverless-applications-with-terraform\u002F10-appendix-B-SFN",1792665264538]