4-12. 테라폼 - Lambda와 EventBridge 구현하기

테라폼 - Lambda와 EventBridge 구현하기

서버 없이 코드를 실행하고, 이벤트나 일정에 따라 자동으로 호출하기

---

이전 글에서는 Terraform으로 ECS Fargate를 구현하는 방법을 정리했다.

이번 글에서는 AWS의 서버리스 실행 환경인 Lambda와 이벤트 기반 실행을 위한 EventBridge를 Terraform으로 구현해보려 한다.

Lambda는 서버를 직접 만들지 않고 코드를 실행할 수 있는 서비스다.

코드 작성
→ Lambda에 배포
→ 이벤트 발생
→ Lambda 실행

EventBridge는 특정 이벤트나 일정에 따라 Lambda를 실행할 수 있게 해준다.

정해진 시간
→ EventBridge Rule
→ Lambda 실행

예를 들어 매일 새벽 배치 작업을 실행하거나, 5분마다 상태 점검 작업을 수행할 수 있다.

Lambda는 코드를 실행하는 리소스이고, EventBridge는 Lambda를 언제 실행할지 결정하는 트리거 역할을 한다.

---

목차

• 1. Lambda란 무엇인가
• 2. EventBridge란 무엇인가
• 3. Lambda를 만들 때 필요한 요소
• 4. Lambda 실행 Role 만들기
• 5. Lambda 코드 작성과 패키징
• 6. Lambda Function 만들기
• 7. CloudWatch Log Group 만들기
• 8. 환경 변수 설정하기
• 9. EventBridge Rule 만들기
• 10. EventBridge Target 만들기
• 11. Lambda Permission 설정하기
• 12. EventBridge Scheduler는 언제 사용할까?
• 13. 실전 예제: 5분마다 실행되는 Lambda
• 14. 의존성 흐름
• 15. 자주 하는 실수
• 16. 마무리

---

1. Lambda란 무엇인가

Lambda는 AWS의 서버리스 컴퓨팅 서비스다.

EC2처럼 서버를 직접 생성하고 운영하지 않아도, 코드를 업로드하면 AWS가 실행 환경을 관리해준다.

EC2
→ 서버 생성
→ 런타임 설치
→ 애플리케이션 실행
→ 서버 관리 필요

Lambda
→ 코드 업로드
→ 이벤트 발생 시 실행
→ 서버 관리 부담 감소

Lambda는 다음과 같은 작업에 자주 사용된다.

스케줄 배치 작업
이미지 리사이징
S3 업로드 이벤트 처리
간단한 API 처리
EventBridge 이벤트 처리
알림 발송
운영 자동화 작업

Lambda는 항상 실행 중인 서버가 아니라, 이벤트가 발생했을 때 실행되는 함수에 가깝다.

이벤트 발생
→ Lambda 실행
→ 작업 완료
→ 종료

따라서 짧게 실행되는 작업이나 이벤트 기반 작업에 적합하다.

---

2. EventBridge란 무엇인가

EventBridge는 AWS의 이벤트 라우팅 서비스다.

AWS 서비스, 사용자 애플리케이션, SaaS 서비스에서 발생한 이벤트를 받아 특정 대상에게 전달할 수 있다.

Event Source
→ EventBridge
→ Target

Lambda와 함께 사용할 때는 보통 다음 두 가지 방식이 많다.

1. 일정 기반 실행
   예: 5분마다 Lambda 실행

2. 이벤트 기반 실행
   예: 특정 AWS 이벤트 발생 시 Lambda 실행

이번 글에서는 초보자가 이해하기 쉬운 일정 기반 실행을 먼저 다룬다.

rate(5 minutes)
→ EventBridge Rule
→ Lambda

EventBridge에서 Lambda를 호출하려면 세 가지 리소스를 함께 생각해야 한다.

EventBridge Rule
→ 언제 실행할지 정의

EventBridge Target
→ 무엇을 실행할지 정의

Lambda Permission
→ EventBridge가 Lambda를 호출할 수 있도록 허용

---

3. Lambda를 만들 때 필요한 요소

Terraform으로 Lambda를 만들 때는 다음 요소가 필요하다.

구성 요소	Terraform 리소스	역할
Lambda Function	aws_lambda_function	실행할 함수 본체
IAM Role	aws_iam_role	Lambda가 사용할 실행 권한
IAM Policy Attachment	aws_iam_role_policy_attachment	로그 출력 등 기본 권한 연결
Code Package	archive_file	Lambda에 업로드할 zip 파일 생성
Log Group	aws_cloudwatch_log_group	Lambda 로그 저장과 보관 기간 관리
EventBridge Rule	aws_cloudwatch_event_rule	실행 조건 또는 스케줄 정의
EventBridge Target	aws_cloudwatch_event_target	Rule이 호출할 대상 지정
Lambda Permission	aws_lambda_permission	EventBridge가 Lambda를 호출하도록 허용

구조를 단순화하면 다음과 같다.

Lambda 코드
→ Lambda Function
→ EventBridge Rule
→ EventBridge Target
→ Lambda Permission

---

4. Lambda 실행 Role 만들기

Lambda가 실행되려면 IAM Role이 필요하다.

이 Role은 Lambda 서비스가 Assume할 수 있어야 한다.

Lambda Service
→ AssumeRole
→ Lambda Execution Role

Terraform 코드는 다음과 같다.

resource "aws_iam_role" "lambda" {
  name = "${var.project_name}-${var.environment}-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })

  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-lambda-role"
  })
}

여기서 중요한 부분은 다음이다.

Principal = {
  Service = "lambda.amazonaws.com"
}

이 설정은 Lambda 서비스가 이 Role을 사용할 수 있다는 의미다.

Lambda가 CloudWatch Logs에 로그를 남기려면 기본 실행 권한도 필요하다.

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

이 Managed Policy는 Lambda가 CloudWatch Logs에 로그를 쓸 수 있도록 해준다.

Lambda 실행 Role은 Lambda가 실행 중에 사용할 AWS 권한의 기준이 된다.

---

5. Lambda 코드 작성과 패키징

Lambda는 실행할 코드가 필요하다.

예제로 간단한 Python Lambda 코드를 작성해보자.

파일 구조는 다음과 같이 둘 수 있다.

project/
├── main.tf
├── variables.tf
├── outputs.tf
└── lambda_src/
    └── index.py

lambda_src/index.py 파일 내용은 다음과 같다.

import json
import os
from datetime import datetime, timezone

def handler(event, context):
    app_env = os.environ.get("APP_ENV", "dev")

    print("Lambda invoked")
    print("event:", json.dumps(event))

    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "hello from lambda",
            "app_env": app_env,
            "timestamp": datetime.now(timezone.utc).isoformat()
        })
    }

Terraform에서는 이 파일을 zip으로 묶어서 Lambda에 업로드할 수 있다.

이를 위해 archive_file data source를 사용할 수 있다.

data "archive_file" "lambda" {
  type        = "zip"
  source_dir  = "${path.module}/lambda_src"
  output_path = "${path.module}/build/lambda.zip"
}

이 설정은 lambda_src 디렉토리를 zip으로 압축해서 build/lambda.zip 파일을 만든다.

lambda_src/
→ build/lambda.zip

실제 운영에서는 애플리케이션 빌드와 패키징을 CI/CD에서 처리하는 경우가 많다.

하지만 학습용이나 간단한 Lambda는 Terraform의 archive_file로 시작해도 충분하다.

---

6. Lambda Function 만들기

이제 Lambda Function을 만든다.

resource "aws_lambda_function" "app" {
  function_name = "${var.project_name}-${var.environment}-hello"
  role          = aws_iam_role.lambda.arn

  runtime = "python3.12"
  handler = "index.handler"

  filename         = data.archive_file.lambda.output_path
  source_code_hash = data.archive_file.lambda.output_base64sha256

  timeout     = 30
  memory_size = 128

  environment {
    variables = {
      APP_ENV = var.environment
    }
  }

  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-hello-lambda"
  })
}

주요 설정은 다음과 같다.

설정	의미
function_name	Lambda 함수 이름
role	Lambda 실행 Role ARN
runtime	실행 런타임
handler	실행할 함수 진입점
filename	업로드할 zip 파일 경로
source_code_hash	코드 변경 감지를 위한 해시
timeout	최대 실행 시간
memory_size	할당 메모리

source_code_hash는 중요하다.

Lambda zip 파일이 바뀌었을 때 Terraform이 코드 변경을 감지하는 데 사용된다.

코드 변경
→ zip 변경
→ source_code_hash 변경
→ Lambda 코드 업데이트

---

7. CloudWatch Log Group 만들기

Lambda에서 print나 로그를 남기면 CloudWatch Logs로 전송된다.

Lambda가 처음 실행될 때 Log Group이 자동으로 생길 수도 있지만, Terraform으로 직접 만들면 보관 기간을 관리하기 쉽다.

resource "aws_cloudwatch_log_group" "lambda" {
  name              = "/aws/lambda/${aws_lambda_function.app.function_name}"
  retention_in_days = 14

  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-lambda-log-group"
  })
}

retention_in_days는 로그 보관 기간이다.

retention_in_days = 14
→ 로그를 14일 동안 보관

로그 보관 기간을 설정하지 않으면 로그가 계속 쌓여 비용이 증가할 수 있다.

따라서 학습용이나 운영용 모두 Log Group의 보관 기간을 명시하는 것이 좋다.

---

8. 환경 변수 설정하기

Lambda에는 환경 변수를 넣을 수 있다.

환경 변수는 코드에서 환경별 설정값을 읽을 때 유용하다.

environment {
  variables = {
    APP_ENV = var.environment
  }
}

Python 코드에서는 다음처럼 읽을 수 있다.

import os

app_env = os.environ.get("APP_ENV", "dev")

하지만 민감정보를 환경 변수에 직접 넣는 것은 주의해야 한다.

권장하지 않음:
DB_PASSWORD=my-password

권장:
DB_SECRET_NAME=/demo/prod/db/credential

비밀번호나 API Key 같은 값은 Secrets Manager나 SSM Parameter Store에 저장하고, Lambda 환경 변수에는 Secret 이름이나 Parameter 이름만 넣는 방식이 더 안전하다.

Lambda 환경 변수
→ Secret 이름 저장

Lambda 코드
→ Secrets Manager에서 실제 값 조회

---

9. EventBridge Rule 만들기

EventBridge Rule은 Lambda를 언제 실행할지 정의한다.

가장 간단한 예시는 5분마다 실행되는 스케줄이다.

resource "aws_cloudwatch_event_rule" "every_5_minutes" {
  name        = "${var.project_name}-${var.environment}-every-5-minutes"
  description = "Run Lambda every 5 minutes"

  schedule_expression = "rate(5 minutes)"

  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-every-5-minutes"
  })
}

schedule_expression에는 rate 또는 cron 표현식을 사용할 수 있다.

rate(5 minutes)
→ 5분마다 실행

rate(1 hour)
→ 1시간마다 실행

cron(0 18 * * ? *)
→ UTC 기준 매일 18:00 실행

주의할 점은 cron 표현식이 UTC 기준이라는 점이다.

예를 들어 한국 시간 새벽 3시에 실행하려면 UTC로는 전날 18시를 고려해야 한다.

한국 시간 03:00
→ UTC 18:00

---

10. EventBridge Target 만들기

Rule을 만들었다고 해서 Lambda가 자동으로 실행되는 것은 아니다.

Rule이 호출할 대상을 지정해야 한다.

이 역할을 하는 리소스가 EventBridge Target이다.

resource "aws_cloudwatch_event_target" "lambda" {
  rule      = aws_cloudwatch_event_rule.every_5_minutes.name
  target_id = "lambda"
  arn       = aws_lambda_function.app.arn
}

이 코드는 다음 의미다.

every_5_minutes Rule이 실행될 때
→ aws_lambda_function.app Lambda를 호출한다.

여기서 Target은 EventBridge Rule과 Lambda Function을 참조한다.

EventBridge Rule
→ EventBridge Target

Lambda Function
→ EventBridge Target

EventBridge Target에는 input 값을 전달할 수도 있다.

resource "aws_cloudwatch_event_target" "lambda" {
  rule      = aws_cloudwatch_event_rule.every_5_minutes.name
  target_id = "lambda"
  arn       = aws_lambda_function.app.arn

  input = jsonencode({
    source = "eventbridge"
    job    = "sample-scheduled-job"
  })
}

이렇게 하면 Lambda의 event 인자로 해당 JSON이 전달된다.

---

11. Lambda Permission 설정하기

EventBridge Target을 만들었다고 해서 EventBridge가 Lambda를 호출할 수 있는 것은 아니다.

Lambda 쪽에서 EventBridge에게 호출 권한을 허용해야 한다.

Terraform에서는 aws_lambda_permission을 사용한다.

resource "aws_lambda_permission" "allow_eventbridge" {
  statement_id  = "AllowExecutionFromEventBridge"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.app.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.every_5_minutes.arn
}

이 설정은 다음 의미다.

EventBridge Rule이
이 Lambda Function을 호출할 수 있도록 허용한다.

여기서 중요한 부분은 다음이다.

principal  = "events.amazonaws.com"
source_arn = aws_cloudwatch_event_rule.every_5_minutes.arn

principal은 호출 주체가 EventBridge라는 뜻이고, source_arn은 어떤 EventBridge Rule에서 오는 호출을 허용할지 제한하는 값이다.

EventBridge가 Lambda를 호출하려면 Target 설정뿐 아니라 Lambda Permission도 필요하다.

---

12. EventBridge Scheduler는 언제 사용할까?

AWS에는 EventBridge Rule 외에도 EventBridge Scheduler가 있다.

특히 단순 스케줄 실행만 목적이라면 EventBridge Scheduler를 고려할 수 있다.

EventBridge Rule
→ 이벤트 패턴 또는 스케줄 기반 라우팅

EventBridge Scheduler
→ 일정 기반 실행에 특화된 스케줄러

AWS 문서에서도 기존 EventBridge scheduled rules 대신 EventBridge Scheduler 사용을 권장한다고 설명한다.

다만 Terraform 초보 단계에서는 EventBridge Rule, Target, Lambda Permission의 관계를 먼저 이해하는 것이 좋다.

이 구조를 이해하면 Scheduler를 사용할 때도 다음 질문을 쉽게 이해할 수 있다.

누가 Lambda를 호출하는가?
어떤 권한으로 호출하는가?
언제 호출하는가?

---

13. 실전 예제: 5분마다 실행되는 Lambda

이제 지금까지의 내용을 하나로 정리해보자.

구조는 다음과 같다.

EventBridge Rule
→ EventBridge Target
→ Lambda Permission
→ Lambda Function

---

13.1 variables.tf

variable "project_name" {
  description = "Project name"
  type        = string
}

variable "environment" {
  description = "Environment name"
  type        = string
}

variable "aws_region" {
  description = "AWS region"
  type        = string
}

variable "schedule_expression" {
  description = "EventBridge schedule expression"
  type        = string
  default     = "rate(5 minutes)"
}

---

13.2 locals.tf

locals {
  common_tags = {
    Project     = var.project_name
    Environment = var.environment
    ManagedBy   = "terraform"
  }

  function_name = "${var.project_name}-${var.environment}-hello"
}

---

13.3 lambda_src/index.py

import json
import os
from datetime import datetime, timezone

def handler(event, context):
    app_env = os.environ.get("APP_ENV", "dev")

    print("Lambda invoked")
    print("event:", json.dumps(event))

    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "hello from lambda",
            "app_env": app_env,
            "timestamp": datetime.now(timezone.utc).isoformat()
        })
    }

---

13.4 main.tf

data "archive_file" "lambda" {
  type        = "zip"
  source_dir  = "${path.module}/lambda_src"
  output_path = "${path.module}/build/lambda.zip"
}

resource "aws_iam_role" "lambda" {
  name = "${local.function_name}-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })

  tags = merge(local.common_tags, {
    Name = "${local.function_name}-role"
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_lambda_function" "app" {
  function_name = local.function_name
  role          = aws_iam_role.lambda.arn

  runtime = "python3.12"
  handler = "index.handler"

  filename         = data.archive_file.lambda.output_path
  source_code_hash = data.archive_file.lambda.output_base64sha256

  timeout     = 30
  memory_size = 128

  environment {
    variables = {
      APP_ENV = var.environment
    }
  }

  tags = merge(local.common_tags, {
    Name = local.function_name
  })
}

resource "aws_cloudwatch_log_group" "lambda" {
  name              = "/aws/lambda/${aws_lambda_function.app.function_name}"
  retention_in_days = 14

  tags = merge(local.common_tags, {
    Name = "${local.function_name}-log-group"
  })
}

resource "aws_cloudwatch_event_rule" "schedule" {
  name        = "${local.function_name}-schedule"
  description = "Run Lambda by schedule"

  schedule_expression = var.schedule_expression

  tags = merge(local.common_tags, {
    Name = "${local.function_name}-schedule"
  })
}

resource "aws_cloudwatch_event_target" "lambda" {
  rule      = aws_cloudwatch_event_rule.schedule.name
  target_id = "lambda"
  arn       = aws_lambda_function.app.arn

  input = jsonencode({
    source = "eventbridge"
    job    = "sample-scheduled-job"
  })
}

resource "aws_lambda_permission" "allow_eventbridge" {
  statement_id  = "AllowExecutionFromEventBridge"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.app.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.schedule.arn
}

이 구성의 특징은 다음과 같다.

Lambda 실행 Role 생성
Lambda 기본 로그 권한 연결
Lambda 코드 zip 패키징
Lambda Function 생성
CloudWatch Log Group 생성
EventBridge Schedule Rule 생성
EventBridge Target으로 Lambda 연결
Lambda Permission으로 EventBridge 호출 허용

---

13.5 outputs.tf

output "lambda_function_name" {
  description = "Lambda function name"
  value       = aws_lambda_function.app.function_name
}

output "lambda_function_arn" {
  description = "Lambda function ARN"
  value       = aws_lambda_function.app.arn
}

output "eventbridge_rule_name" {
  description = "EventBridge rule name"
  value       = aws_cloudwatch_event_rule.schedule.name
}

output "eventbridge_rule_arn" {
  description = "EventBridge rule ARN"
  value       = aws_cloudwatch_event_rule.schedule.arn
}

---

14. 의존성 흐름

Lambda와 EventBridge를 Terraform으로 구현할 때의 의존성 흐름은 다음과 같다.

Lambda Code / IAM Role
→ Lambda Function
→ EventBridge Target
→ Lambda Permission

이 구조에서 중요한 점은 다음과 같다.

Lambda Function은 코드 zip과 IAM Role을 참조한다.
EventBridge Target은 Rule과 Lambda Function을 참조한다.
Lambda Permission은 EventBridge Rule이 Lambda를 호출할 수 있도록 허용한다.

EventBridge Target은 호출 대상을 지정하고, Lambda Permission은 그 호출을 Lambda가 허용하도록 만든다.

---

15. 자주 하는 실수

15.1 Lambda Permission을 만들지 않음

EventBridge Target을 만들었는데 Lambda가 실행되지 않는다면 Lambda Permission이 빠졌는지 확인해야 한다.

EventBridge Target 있음
Lambda Permission 없음
→ EventBridge가 Lambda 호출 실패

EventBridge가 Lambda를 호출하려면 다음 권한이 필요하다.

principal  = "events.amazonaws.com"
action     = "lambda:InvokeFunction"
source_arn = EventBridge Rule ARN

---

15.2 Handler 이름을 잘못 설정함

Python Lambda에서 handler = "index.handler"라면 다음 의미다.

index.py 파일 안의
handler 함수 실행

파일명이나 함수명이 다르면 Lambda 실행 시 오류가 발생한다.

handler = "index.handler"

필요한 코드:
index.py
def handler(event, context):

---

15.3 source_code_hash를 넣지 않음

source_code_hash를 넣지 않으면 코드 zip이 바뀌어도 Terraform이 변경을 제대로 감지하지 못할 수 있다.

source_code_hash = data.archive_file.lambda.output_base64sha256

Lambda 코드를 Terraform으로 직접 배포한다면 이 값을 넣는 것이 좋다.

---

15.4 CloudWatch Log Group 보관 기간을 설정하지 않음

Lambda 로그는 CloudWatch Logs에 쌓인다.

보관 기간을 설정하지 않으면 로그가 계속 남아 비용이 증가할 수 있다.

resource "aws_cloudwatch_log_group" "lambda" {
  retention_in_days = 14
}

---

15.5 민감정보를 환경 변수에 직접 넣음

Lambda 환경 변수에 DB password나 API key를 직접 넣는 것은 주의해야 한다.

권장하지 않음:
DB_PASSWORD=my-password

권장:
DB_SECRET_NAME=/demo/prod/db/credential

실제 민감정보는 Secrets Manager나 Parameter Store에 저장하고, Lambda는 실행 Role 권한으로 값을 조회하는 구조가 더 안전하다.

---

15.6 cron 시간을 한국 시간으로 착각함

EventBridge cron 표현식은 UTC 기준으로 해석된다.

한국 시간 기준으로 실행 시간을 정할 때는 UTC 변환을 고려해야 한다.

한국 시간 03:00
→ UTC 18:00

시간 기반 작업은 운영에서 실수가 많기 때문에 주석이나 변수 설명에 기준 시간을 명확히 남기는 것이 좋다.

---

15.7 EventBridge Rule과 Scheduler를 혼동함

EventBridge Rule과 EventBridge Scheduler는 모두 일정 실행에 사용할 수 있지만 목적이 조금 다르다.

EventBridge Rule
→ 이벤트 패턴과 스케줄 기반 라우팅에 사용

EventBridge Scheduler
→ 스케줄 실행에 특화된 서비스

스케줄 실행만 필요하다면 EventBridge Scheduler도 고려할 수 있다.

다만 이 글에서는 Lambda, Rule, Target, Permission의 기본 관계를 이해하기 위해 EventBridge Rule 방식을 사용했다.

---

15.8 Terraform으로 복잡한 애플리케이션 빌드까지 처리하려고 함

간단한 Lambda는 archive_file로 패키징해도 된다.

하지만 의존성이 많거나 빌드 과정이 필요한 Lambda는 CI/CD에서 빌드하고, Terraform은 배포 리소스 관리에 집중하는 것이 더 적합할 수 있다.

간단한 예제:
Terraform archive_file 사용 가능

운영 애플리케이션:
CI/CD에서 빌드
Terraform은 Lambda 리소스 관리

---

16. 마무리

이번 글에서는 Terraform으로 Lambda와 EventBridge를 구현하는 방법을 정리했다.

Lambda는 서버를 직접 관리하지 않고 코드를 실행할 수 있는 서비스다.

EventBridge는 일정이나 이벤트에 따라 Lambda를 실행할 수 있게 해준다.

핵심 리소스는 다음과 같다.

aws_iam_role
→ Lambda 실행 Role

aws_lambda_function
→ Lambda 함수 본체

aws_cloudwatch_log_group
→ Lambda 로그 보관

aws_cloudwatch_event_rule
→ 실행 스케줄 또는 이벤트 조건

aws_cloudwatch_event_target
→ 호출 대상 Lambda 지정

aws_lambda_permission
→ EventBridge가 Lambda를 호출할 수 있도록 허용

처음에는 리소스가 많아 보이지만, 역할을 나누어 보면 단순하다.

Lambda
→ 실행할 코드

EventBridge Rule
→ 언제 실행할지

EventBridge Target
→ 무엇을 실행할지

Lambda Permission
→ 호출을 허용할지

---

한 줄 정리

Lambda는 코드를 실행하는 리소스이고, EventBridge는 그 코드를 언제 실행할지 결정하는 트리거다.

---