AWS Lambda's Self-Managed Code Storage Lifts the Account Quota, Not the Function Size Limit

Self-Managed Code Storage란 무엇인가

AWS Lambda가 Self-Managed Code Storage 기능을 출시했다. 기존에는 Lambda 배포 패키지를 AWS가 관리하는 내부 스토리지에 업로드해야 했고, 리전당 코드 스토리지 쿼터(기본 75GB)라는 제약이 존재했다. 이번 기능을 통해 고객이 소유한 S3 버킷을 직접 참조하여 배포 패키지를 관리할 수 있게 되었다.

가장 눈에 띄는 변화는 리전당 코드 스토리지 쿼터 제한이 사실상 제거된다는 점이다. 관리형 기본 한도도 기존 75GB에서 300GB로 4배 상향됐다. 함수 수가 많거나 배포 패키지가 무거운 엔터프라이즈 환경에서는 쿼터 초과로 인해 배포가 실패하는 상황을 종종 겪었는데, 이 문제가 구조적으로 해소된다.

실무에서 주의해야 할 제약 사항

기능 자체는 반갑지만, 몇 가지 중요한 제약을 명확히 이해해야 실수를 방지할 수 있다.

함수별 패키지 크기 제한은 그대로 유지된다. 압축 기준 50MB, 비압축 기준 250MB 제한은 변경되지 않았다. 스토리지 쿼터 문제와 함수 크기 문제는 별개임을 혼동하지 말아야 한다.
S3 객체를 교체해도 자동으로 반영되지 않는다. 동일한 S3 키에 새 패키지를 업로드하더라도, 반드시 UpdateFunctionCode API를 명시적으로 호출해야 Lambda가 변경 사항을 인식한다.
Terraform 프로바이더 지원이 아직 없다. IaC(Infrastructure as Code) 워크플로우를 Terraform으로 구성한 팀은 당장 활용하기 어렵고, 공식 enhancement request가 열려 있는 상태이므로 지원 시점을 별도로 트래킹해야 한다.

# S3에 새 패키지 업로드 후, 반드시 UpdateFunctionCode 호출 필요
aws lambda update-function-code \
  --function-name my-function \
  --s3-bucket my-deployment-bucket \
  --s3-key packages/my-function.zip

배포 파이프라인 설계 관점에서의 시사점

이번 변경은 단순한 쿼터 상향 이상의 의미를 갖는다. S3를 중심으로 한 배포 아티팩트 관리 전략이 Lambda와 더 자연스럽게 통합될 수 있게 되었다. 예를 들어 S3 버킷에 버전 관리를 활성화해두면 특정 배포 버전으로의 롤백이 S3 객체 수준에서 추적 가능해지고, 보존 정책이나 액세스 로그도 팀의 기존 S3 운영 체계 안에서 일관되게 관리할 수 있다.

다만 UpdateFunctionCode 호출을 파이프라인에서 빠뜨리는 실수가 발생하기 쉬운 구조이므로, CI/CD 스텝을 명시적으로 분리하고 검증 단계를 추가하는 것이 좋다. S3 업로드와 Lambda 코드 갱신을 원자적으로 묶는 파이프라인 설계가 필요하다.

# GitHub Actions 예시 (핵심 스텝만)
- name: Upload to S3
  run: aws s3 cp build/function.zip s3://my-deployment-bucket/packages/function.zip

- name: Update Lambda Function Code
  run: |
    aws lambda update-function-code \
      --function-name my-function \
      --s3-bucket my-deployment-bucket \
      --s3-key packages/function.zip

정리

리전당 코드 스토리지 쿼터가 실질적으로 제거되어, 다수의 Lambda 함수를 운영하는 환경에서 배포 실패 위험이 줄어든다.
S3 객체 갱신만으로는 Lambda가 자동 반영하지 않으므로, UpdateFunctionCode 호출을 배포 파이프라인에 반드시 포함해야 한다.
Terraform 지원이 아직 없으므로, IaC 기반 팀은 공식 지원 일정을 모니터링하며 도입 시점을 판단해야 한다.