개요

이 문서에서는 CloudFront, Lambda@Edge 및 AWS WAF와 같은 AWS 엣지 서비스의 구성을 변경하기 위한 모범 사례를 간략하게 설명합니다. 이러한 변경에는 CloudFront 함수 코드 업데이트, Lambda@Edge 함수의 런타임 수정, CloudFront에 새 캐시 동작 추가, WAF 규칙 업데이트, HTTP/3와 같은 새로운 CloudFront 기능 활성화 등이 포함될 수 있습니다. 구성이 비교적 정적이고 단순하고, 수동 관리를 위한 UI를 선호한다면 AWS Console을 사용할 수 있습니다. 그러나 더 복잡한 설정의 경우 CI/CD 파이프라인을 활용하여 제어된 방식으로 구성 변경 및 코드 업데이트를 배포하는 것이 좋습니다.

CI/CD 파이프라인

코드형 인프라(IaaC)

CI/CD 파이프라인은 개발 속도를 높이고, 코드 품질을 높이고, 자동화를 통해 인적 오류를 줄임으로써 소프트웨어 릴리스 주기를 개선합니다. CI/CD 파이프라인 내에서 코드형 인프라(IaC)를 사용하여 CloudFront와 같은 AWS 엣지 서비스와 엣지 기능을 관리할 수 있습니다. 엣지 리소스는 API(예: CloudFront의 API), AWS CLI 또는 상위 수준의 추상화 도구[예: CloudFormation, Terraform, AWS Cloud Development Kit(CDK)]를 사용하여 배포할 수 있습니다.

CDK 기반 IaC

CloudFormation을 기반으로 하는 CDK는 프로그래밍 언어를 사용하여 AWS 리소스를 배포할 수 있는 최고 수준의 추상화를 제공합니다. 예를 들어 다음 세 줄의 JavaScript 코드는 CloudFront를 오리진으로 사용하는 S3 버킷을 배포할 수 있습니다.

const myBucket = new s3.Bucket(this, 'myBucket');
new cloudfront.Distribution(this, 'myDist', {
  defaultBehavior: { origin: new origins.S3Origin(myBucket) },
});

CDK 구문 라이브러리에서 CDK 코드에 포함하여 재사용할 수 있는 구문을 확인하세요.

배포 및 오케스트레이션

CI/CD 파이프라인에는 코드(CDK 코드, 엣지 함수 코드)를 저장하기 위한 AWS CodeCommit과 같은 리포지토리, 인프라를 배포하기 위한 AWS CodeDeploy와 같은 도구, 파이프라인 단계를 관리하기 위한 AWS CodePipeline과 같은 오케스트레이션 도구가 필요합니다. 이 블로그 게시물에서는 AWS 개발자 도구를 사용하여 CloudFront용 CI/CD 파이프라인을 구현하는 방법을 보여 주지만, 선호하는 CI/CD 도구를 사용할 수도 있습니다. AWS 엣지 서비스용 CI/CD 파이프라인을 구축할 때는 다음과 같은 제한 사항을 고려하세요.

  • CloudFront, CloudFront Functions, 리전별 AWS WAF WebACL은 모든 AWS 리전에서 배포할 수 있습니다.
  • Lambda@Edge, CloudFront용 WAF WebACL은 버지니아 북부의 us-east-1 리전에서만 구축할 수 있습니다.
  • Firewall Manager 관리자 AWS 계정에 Firewall Manager 정책이 배포되어야 합니다.

테스트 및 스테이징

다양한 수준에서 엣지 구성을 테스트할 수 있습니다. 먼저 테스트 계정에서 AWS WAF WebACL을 사용하여 CloudFront 배포와 같은 인프라를 복제할 수 있습니다. 개발 단계에서 수행되거나 프로덕션으로 전환하기 전에 자동화된 기능 테스트를 실행하기 위해 수행될 수 있습니다. 참고로 동일한 CNAME를 CloudFront 배포 두 개에 사용할 수는 없습니다. 따라서 CI/CD 단계를 기반으로 CloudFront 리소스의 CNAME 구성을 구분해야 합니다. 예를 들어 개발 단계에는 CloudFront의 도메인 이름(예: xyz.cloudfront.net)을 사용하고, 스테이징에는 전용 CNAME(예: staging.www.example.com)을 사용하고, 마지막으로 프로덕션 배포에는 퍼블릭 CNAME(예: www.example.com)을 사용할 수 있습니다. 스테이징 단계에서 AWS WAF를 사용하여 특정 IP에 대한 액세스를 제한하는 등 보안 제어를 단계별로 구분할 수도 있습니다.

새 구성이 테스트를 통과한 후에는 CloudFront의 지속적 배포 기능을 통해 canary 릴리스 접근 방식을 구현하여 트래픽의 작은 부분에 대해 프로덕션 변경 사항을 테스트할 수 있습니다. 이 기능을 사용하면 프로덕션 배포의 다른 구성을 만들 수 있으며, 글로벌 트래픽의 일부만 전송할 수 있습니다. 트래픽을 새 구성으로 라우팅하는 방법에는 두 가지가 있습니다. 합성 테스트에 유용한 특정 요청 헤더를 사용하거나 가중치 기반 정책을 사용하여 구성 가능한 비율의 트래픽을 새 구성으로 라우팅하고 고정성을 활성화하는 옵션이 있습니다. 이 기능의 현재 버전에서는 CloudFront 구성 파라미터의 일부에 대해서만 변경 사항을 테스트할 수 있습니다. 이 기능을 사용하여 테스트할 수 있는 내용을 더 잘 이해하려면 설명서를 읽어보세요.

동적 구성

여러 팀이 CloudFront 구성을 변경하지만 한 팀이 모든 팀의 CI/CD 파이프라인을 관리하는 시나리오를 생각해 보세요. 예를 들어 여러 팀이 개별 마이크로서비스를 관리하고, 모두 단일 CloudFront 배포로 호스팅되는 기본 도메인에 API를 노출합니다. 각 팀이 CloudFront 배포의 전체 구성에 액세스하는 것이 허용되면 잘못된 변경 사항이 하나만 있어도 그 영향의 범위가 넓어집니다. 반대로 CI/CD 팀만 CloudFront 배포를 변경하도록 허용하면 개발 속도가 저하되고 릴리스 수명 주기에 병목 현상이 발생합니다. 이 경우 각 마이크로서비스 팀이 소유한 부분 구성을 기반으로 구성을 동적으로 생성하는 것이 좋습니다. 간단한 구현으로 각 팀은 S3 버킷에 호스팅된 텍스트 기반 파일에서 자신의 경로 구성(캐싱, 엣지 함수 등)을 관리합니다. CI/CD 파이프라인에서 다른 부분 구성 파일을 사용하여 최종 CloudFront 구성을 동적으로 생성하는 추가 단계를 도입할 수 있습니다.

AWS WAF 및 AWS Shield 배포

Shield 및 WAF 서비스는 앞서 설명한 것과 동일한 도구를 사용하여 CI/CD 파이프라인에서 배포할 수 있습니다.

하지만 다음과 같은 이점을 위해 AWS Firewall Manager를 사용하여 WAF 규칙 및 Shield 보호를 배포하는 것이 좋습니다.

  • 중앙 보안 거버넌스의 시행을 용이하게 합니다(예: 애플리케이션 팀이 관리하는 규칙을 조합하여 중앙 규칙 배포).
  • 배포 속도가 더 빠르며 이는 AWS WAF를 사용하여 심각한 취약성을 패치하는 데 매우 중요합니다.
  • 여러 계정과 이기종 CI/CD 파이프라인(예: 인수를 통해 상속된 것) 전반에 걸쳐 배포를 간소화합니다. 그러나 이 접근 방식에서 드리프트 감지 기능이 있는 CI/CD 파이프라인을 사용하는 경우에는 드리프트를 관리해야 합니다.

또한 CI/CD 파이프라인을 사용하여 관리자 계정에서 Firewall Manager 정책을 변경할 수 있으며, 이 정책은 OLX의 데모에서처럼 Firewall Manager에 의해 AWS 조직 전체에 배포됩니다.

다양한 전략을 사용하여 WAF 규칙을 프로덕션 환경에 안전하게 배포할 수 있습니다. 카운트 모드에서 기존 WebACL에 새 규칙을 추가한 다음 차단 모드로 변경할 수 있습니다. 그러나 이 접근 방식을 사용할 때는 WebACL의 최대 WCU에 주의를 기울여야 합니다. 또 다른 접근 방식은 스테이징 WebACL에 변경 사항을 배포하고 스테이징 환경에서 변경 사항을 테스트하는 것입니다.

리소스

이 페이지의 내용이 도움이 되었나요?

 피드백