AWS 환경에서 서버와 애플리케이션을 운영하다 보면 EC2, API Gateway, Lambda, Step Functions, IAM 등 다양한 리소스를 생성하고 관리하게 됩니다.
처음에는 AWS Management Console에서 직접 리소스를 생성해도 큰 문제가 없지만, 관리해야 하는 리소스가 많아지면 어떤 설정이 언제 변경되었는지 확인하기 어려워집니다.
이러한 문제를 해결하기 위해 AWS에서는 CloudFormation을 제공합니다.
CloudFormation을 이해하면 AWS 리소스가 갑자기 변경되거나 삭제되는 것처럼 보이는 상황을 분석하는 데도 도움이 됩니다.
AWS CloudFormation이란?
AWS CloudFormation은 AWS 인프라를 코드로 정의하고 관리할 수 있도록 제공되는 Infrastructure as Code 서비스입니다.
일반적으로 YAML 또는 JSON 형식의 Template을 작성하여 필요한 AWS 리소스를 정의합니다.
예를 들어 다음과 같은 리소스를 코드로 관리할 수 있습니다.
EC2 Instance
Amazon VPC
Security Group
AWS Lambda
Amazon API Gateway
Amazon S3
IAM Role
AWS Step Functions
AWS Console에서 하나씩 직접 생성하는 대신 Template에 원하는 인프라 상태를 정의하고 CloudFormation을 통해 생성하거나 변경하는 방식입니다.
Infrastructure as Code가 필요한 이유
AWS Console을 이용하면 리소스를 간단하게 만들 수 있지만 규모가 커질수록 관리가 복잡해집니다.
예를 들어 API Gateway Resource를 직접 추가하고 Lambda와 Step Functions를 연결했다고 가정해보겠습니다.
이후 다른 사람이 설정을 변경하거나 CloudFormation Stack을 다시 배포하면 기존에 수동으로 추가한 설정과 Template에 정의된 설정 사이에 차이가 발생할 수 있습니다.
Infrastructure as Code를 적용하면 인프라 구성 자체를 코드로 관리할 수 있기 때문에 이러한 문제를 줄일 수 있습니다.
CloudFormation Template과 Stack 구조
CloudFormation에서 가장 중요한 개념은 Template과 Stack입니다.
Template은 AWS 인프라를 어떻게 구성할 것인지 정의한 설계도입니다.
Stack은 해당 Template을 실제 AWS 환경에 적용하여 만들어진 리소스들의 집합입니다.
구조를 간단하게 표현하면 다음과 같습니다.
CloudFormation Template
↓
CloudFormation Stack
↓
API Gateway / Lambda / IAM / S3 / Step Functions
Template을 변경한 후 Stack을 업데이트하면 CloudFormation이 변경 내용을 확인하고 필요한 AWS 리소스를 생성하거나 수정합니다.
SAM과 CloudFormation의 관계
AWS SAM(Serverless Application Model)을 사용하는 경우 CloudFormation과의 관계를 이해하는 것이 중요합니다.
SAM은 Serverless Application을 보다 간단하게 정의하기 위한 Framework이며 실제 배포 과정에서는 SAM Template이 CloudFormation으로 변환되어 AWS 리소스가 생성됩니다.
따라서 SAM CLI로 관리하는 Lambda나 API Gateway 역시 결국 CloudFormation Stack의 영향을 받게 됩니다.
예를 들어 SAM Template에서 API Gateway를 관리하면서 AWS Console에서 특정 Resource나 Method를 별도로 추가하면 코드로 관리되는 구성과 수동으로 만든 구성이 혼재할 수 있습니다.
이러한 환경에서는 이후 배포나 Stack 변경 과정에서 예상하지 못했던 리소스 변경이 발생할 수 있으므로 주의해야 합니다.
API Gateway Resource가 사라진다면 확인할 부분
API Gateway Resource나 Method가 예상하지 못하게 사라진다면 단순히 다시 생성하기보다 어떤 서비스 또는 사용자가 삭제했는지 먼저 확인하는 것이 좋습니다.
첫 번째는 CloudFormation Stack Events입니다.
CloudFormation Console에서 해당 Stack을 선택하고 Events를 확인하면 리소스 생성, 업데이트, 삭제 과정에서 어떤 작업이 수행되었는지 확인할 수 있습니다.
두 번째는 CloudTrail입니다.
CloudTrail에서는 AWS API 호출 기록을 확인할 수 있습니다.
API Gateway Resource 삭제가 의심된다면 DeleteResource와 관련된 이벤트를 확인하여 삭제 요청이 발생했는지 살펴볼 수 있습니다.
세 번째는 SAM Template입니다.
API Gateway가 SAM으로 관리되고 있다면 수동으로 생성한 Resource와 Method가 Template 또는 OpenAPI 정의에 포함되어 있는지 확인해야 합니다.
CloudFormation Drift란?
CloudFormation에서 중요하게 알아두어야 하는 개념 중 하나가 Drift입니다.
Drift는 CloudFormation Template에 정의된 상태와 실제 AWS 환경의 리소스 상태가 달라진 상황을 의미합니다.
예를 들어 Template에서는 특정 설정으로 API Gateway를 관리하고 있는데 AWS Console에서 직접 설정을 변경하면 Template과 실제 환경 사이에 차이가 발생할 수 있습니다.
이 때문에 CloudFormation으로 관리되는 리소스는 가능하면 Console에서 직접 변경하기보다 Template을 수정하고 배포하는 방식으로 관리하는 것이 좋습니다.
AWS 리소스를 안정적으로 관리하는 방법
CloudFormation이나 SAM을 사용하는 환경에서는 관리 방식을 하나로 통일하는 것이 중요합니다.
API Gateway는 SAM으로 관리하고 일부 Resource는 Console에서 직접 생성하는 식으로 구성하면 처음에는 편리할 수 있습니다.
하지만 운영 기간이 길어질수록 어떤 리소스가 CloudFormation에서 관리되고 어떤 리소스가 수동으로 관리되는지 구분하기 어려워집니다.
가능하면 다음과 같은 구조가 좋습니다.
SAM 또는 CloudFormation Template 작성
↓
Git 등으로 코드 변경 이력 관리
↓
CloudFormation Stack 배포
↓
AWS Resource 생성 및 변경
↓
CloudTrail과 Stack Events를 통한 변경 추적
이렇게 구성하면 문제가 발생했을 때 원인을 추적하기도 훨씬 쉬워집니다.
API Gateway와 Step Functions 연동도 코드로 관리해야 할까?
가능하면 함께 관리하는 것이 좋습니다.
API Gateway Resource와 Method뿐 아니라 Step Functions Integration, IAM Role 등 관련 설정까지 SAM 또는 CloudFormation에 포함하면 전체 구조를 하나의 코드에서 확인할 수 있습니다.
특히 운영 환경에서는 Console에서 직접 설정하는 방식보다 IaC 기반으로 관리하는 편이 재현성과 변경 이력 관리 측면에서 유리합니다.
마무리
AWS CloudFormation은 AWS 리소스를 단순히 생성하는 서비스가 아니라 인프라 전체를 코드로 관리하기 위한 핵심 서비스입니다.
특히 SAM CLI를 사용하고 있다면 SAM과 CloudFormation이 별개의 관리 시스템이라고 생각하기보다 SAM 배포 과정에서 CloudFormation이 사용된다는 구조를 함께 이해해야 합니다.
API Gateway Resource가 예상하지 못하게 변경되거나 삭제되는 문제가 있다면 CloudFormation Stack Events, CloudTrail, SAM Template을 순서대로 확인해보는 것이 좋습니다.
AWS 인프라 규모가 커질수록 Console에서 직접 리소스를 관리하는 방식보다는 CloudFormation과 같은 Infrastructure as Code 방식을 적용하는 것이 안정적인 운영에 도움이 됩니다.