AWS CloudFormation 모범 사례

모범 사례는 전체 워크플로우에서 보다 효과적이고 안전하게 AWS CloudFormation을 사용할 수 있도록 돕는 권장 사항입니다. 스택을 계획 및 구성하는 방법, 이러한 스택에서 실행되는 리소스 및 소프트웨어 애플리케이션을 형성하는 템플릿을 생성하는 방법 및 스택 및 리소스를 관리하는 방법을 알아봅니다. 다음 모범 사례는 현재 CloudFormation 고객의 실제 경험을 기반으로 합니다.

피드백 루프를 단축하여 전달 속도 개선

CloudFormation 템플릿으로 설명하는 인프라에 대한 피드백 루프를 단축하는 데 도움이 되는 방법과 도구를 채택하세요. 여기에는 워크스테이션에서 템플릿의 초기 린팅 및 테스트 수행이 포함됩니다. 이를 통해 소스 코드 리포지토리에 기여를 제출하기 전에도 잠재적인 구문 및 구성 문제를 발견할 수 있습니다. 이러한 문제를 조기에 발견하면 개발, 품질 보증 및 생산과 같은 공식 수명 주기 환경에 도달하는 것을 방지할 수 있습니다. 이러한 조기 테스트 및 빠른 실패 접근 방식은 재작업 대기 시간을 줄이고, 잠재적 영향 영역을 줄이고, 성공적인 프로비저닝 작업에 대한 신뢰도를 높이는 이점을 제공합니다.

빠른 실패 실행을 달성하는 데 도움이 되는 도구 선택에는 AWS CloudFormation Linter(cfn-lint) 및 TaskCat 명령줄 도구가 포함됩니다. cfn-lint 도구는 AWS CloudFormation 리소스 사양에 대해 CloudFormation 템플릿을 검증할 수 있는 기능을 제공합니다. 여기에는 리소스 속성의 유효한 값 확인과 모범 사례가 포함됩니다. cfn-lint용 플러그인은 여러 코드 편집기에서 사용할 수 있습니다. 이를 통해 편집기 내에서 문제를 시각화하고 직접적인 린터 피드백을 얻을 수 있습니다. 기여를 커밋할 때 템플릿 검증을 수행할 수 있도록 소스 코드 리포지토리의 구성에 cfn-lint를 통합하도록 선택할 수도 있습니다. 자세한 내용은 Git pre-commit validation of AWS CloudFormation templates with cfn-lint를 참조하세요. 초기 린팅을 수행하고 cfn-lint에서 발생할 수 있는 모든 문제를 수정한 후에는 TaskCat을 사용하여 프로그래밍 방식으로 선택한 AWS 리전에 스택을 생성하여 템플릿을 테스트할 수 있습니다. 또한 TaskCat은 선택한 각 리전의 합격/불합격 성적이 포함된 보고서를 생성합니다.

두 도구를 모두 사용하여 피드백 루프를 단축하는 방법을 단계별로 실습해 보려면 AWS CloudFormation Workshop의 Linting and Testing lab을 수행하세요.

수명 주기 및 소유권별로 스택 구성

AWS 리소스의 수명 주기 및 소유권을 사용하면 각 스택에 어떤 리소스가 있어야 하는지 결정하는 데 도움이 됩니다. 처음에는 하나의 스택에 모든 리소스를 넣어 둘 수 있지만 스택의 규모가 커지고 범위가 넓어지면 단일 스택을 관리하는 것이 번거롭고 시간이 오래 걸릴 수 있습니다. 공통 수명 주기 및 소유권으로 리소스를 그룹화하면 소유자는 다른 리소스에 영향을 미치지 않고 고유한 프로세스 및 일정을 사용하여 리소스 세트를 변경할 수 있습니다.

예를 들어 개발자와 엔지니어로 구성된 팀이 로드 밸런서를 지원하는 Amazon EC2 Auto Scaling 인스턴스에서 호스팅되는 웹 사이트를 소유하고 있다고 가정해 보겠습니다. 웹사이트는 자체 수명 주기를 가지고 있고 웹사이트 팀에서 유지하기 때문에 웹사이트 및 해당 리소스에 대한 스택을 생성할 수 있습니다. 이제 웹사이트에서 백엔드 데이터베이스를 사용한다고 가정해 보겠습니다. 여기에서 데이터베이스는 데이터베이스 관리자가 소유하고 유지하는 별도의 스택에 있습니다. 웹사이트 팀 또는 데이터베이스팀은 리소스를 업데이트해야 할 때마다 서로의 스택에 영향을 주지 않고 업데이트할 수 있습니다. 모든 리소스가 단일 스택에 있는 경우 업데이트 조정 및 전달이 어려울 수 있습니다.

스택 구성에 대한 추가 지침을 얻기 위해 다계층 아키텍처 및 서비스 중심 아키텍처(SOA), 이렇게 두 가지 공통 프레임워크를 사용할 수 있습니다.

계층화된 아키텍처는 서로 위에 쌓이는 다중 수평 계층으로 스택을 구성하고, 여기서 각 계층은 바로 아래 계층에 대한 종속성을 갖습니다. 각 계층에는 스택이 하나 이상 있을 수 있지만 각 계층 내에서 스택에는 수명 주기 및 소유권이 유사한 AWS 리소스가 있어야 합니다.

서비스 중심 아키텍처 덕분에 커다란 비즈니스 문제를 관리 가능한 부분으로 구성할 수 있습니다. 이러한 각 부분은 명확하게 정의된 목적을 갖는 서비스로, 독립형 기능 단위를 나타냅니다. 이러한 서비스는 스택에 매핑할 수 있으며 각 스택에는 자체 수명 주기 및 소유권이 있습니다. 이러한 서비스(스택)는 서로 상호 작용할 수 있도록 함께 연결할 수 있습니다.

교차 스택 참조를 사용하여 공유 리소스 내보내기

수명 주기 및 소유권을 기반으로 AWS 리소스를 구성하는 경우 다른 스택에 있는 리소스를 사용하는 스택을 구축하려고 할 수 있습니다. 값을 하드코딩하거나 입력 파라미터를 사용하여 리소스 이름 및 ID를 전달할 수 있습니다. 그러나 이러한 방법을 사용하면 템플릿을 재사용하기 어렵거나 스택을 실행하기 위해 오버헤드가 증가할 수 있습니다. 대신 교차 스택 참조를 사용하여 리소스를 내보내면 내보낸 리소스를 다른 스택에서 사용할 수 있습니다. 스택은 Fn::ImportValue 함수를 사용하여 내보낸 리소스를 호출해 사용할 수 있습니다.

예를 들어 VPC, 보안 그룹 및 서브넷을 포함하는 네트워크 스택이 있을 수 있습니다. 모든 퍼블릭 웹 애플리케이션에서 이러한 리소스를 사용하도록 하려고 합니다. 리소스를 내보내면 퍼블릭 웹 애플리케이션이 있는 모든 스택에서 이러한 리소스를 사용하도록 허용할 수 있습니다. 자세한 내용은 배포된 CloudFormation 스택에서 내보낸 출력 가져오기 단원을 참조하십시오.

모든 리소스 유형에 대한 할당량 확인

스택을 시작하기 전에 AWS 계정 제한에 도달하지 않고 모든 리소스를 생성할 수 있는지 확인합니다. 제한을 초과한 경우 할당량을 늘리거나 추가 리소스를 삭제하기 전까지 CloudFormation에서는 스택을 성공적으로 생성할 수 없습니다. 각 서비스에는 스택을 시작하기 전에 알아두어야 할 다양한 제한이 있을 수 있습니다. 예를 들어 기본적으로 여러분의 AWS 계정에서는 리전당 CloudFormation 스택을 2,000개만 시작할 수 있습니다. 제한 및 기본 제한을 늘리는 방법에 대한 자세한 내용은 AWS 일반 참조의 AWS Service Quotas를 참조하세요.

템플릿을 재사용하여 다양한 환경에서 스택 복제

스택 및 리소스를 설정한 후에 템플릿을 재사용하여 다양한 환경에서 인프라를 복제할 수 있습니다. 예를 들어 변경 사항을 프로덕션에 구현하기 전에 변경 사항을 테스트할 수 있도록 개발, 테스트 및 프로덕션을 위한 환경을 생성할 수 있습니다. 템플릿을 재사용할 수 있도록 하려면 스택 생성 시 스택을 사용자 지정할 수 있도록 파라미터, 매핑 및 조건 섹션을 사용합니다. 예를 들어 개발 환경의 경우 프로덕션 환경에 비해 저렴한 인스턴스 유형을 지정할 수 있지만 다른 모든 구성 및 설정은 동일하게 유지됩니다. 파라미터, 매핑 및 조건에 대한 자세한 내용은 CloudFormation 템플릿 섹션 단원을 참조하십시오.

모듈을 사용하여 리소스 구성 재사용

인프라가 커짐에 따라 각 템플릿에서 동일한 구성 요소를 선언하는 공통 패턴이 나타날 수 있습니다. 모듈을 사용하면 모든 스택 템플릿에 포함하기 위한 리소스 구성을 투명하고 관리가 편리하면서도 반복적으로 패키징할 수 있습니다. 모듈은 공통적 서비스 구성과 모범 사례를 모듈식 맞춤형 구성 요소로 캡슐화하고 스택 템플릿에 포함할 수 있습니다.

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 정의할 때의 모범 사례와 같이 단일 리소스에 이러한 구성 요소를 사용하거나 여러 리소스에 사용하여 애플리케이션 아키텍처의 공통 패턴을 정의할 수 있습니다. 이러한 구성 요소를 다른 모듈에 중첩하여 상위 구성 요소 안에 모범 사례를 포함할 수 있습니다. CloudFormation 모듈은 CloudFormation 레지스트리에서 사용할 수 있으므로 기본 리소스처럼 사용할 수 있습니다. CloudFormation 모듈을 사용하면 모듈 템플릿이 소비 템플릿으로 확장되므로 Ref 또는 Fn::GetAtt를 사용하여 모듈 안의 리소스에 액세스할 수 있습니다. 자세한 내용은 CloudFormation 모듈을 사용하여 템플릿 전체에 포함할 수 있는 재사용 가능한 리소스 구성 생성 단원을 참조하십시오.

AWS 특정 파라미터 유형 사용

템플릿에 기존 AWS별 값(예: 기존 Amazon Virtual Private Cloud ID 또는 Amazon EC2 키 페어 이름)에 대한 입력값이 필요한 경우 AWS별 파라미터 유형을 사용합니다. 예를 들어 파라미터를 AWS::EC2::KeyPair::KeyName 유형으로 지정할 수 있습니다. 이는 스택을 생성한 AWS 계정 및 리전에 있는 기존 키 페어 이름을 가져옵니다. AWS CloudFormation에서는 스택을 생성하기 전에 AWS 특정 파라미터 유형의 값을 신속하게 검증할 수 있습니다. 또한 CloudFormation 콘솔을 사용할 경우 CloudFormation에 유효한 값의 드롭다운 목록이 표시되므로 올바른 VPC ID 또는 키 페어 이름을 조회하거나 기억할 필요가 없습니다. 자세한 내용은 CloudFormation에서 제공하는 파라미터 유형을 사용하여 기존 리소스 및 Systems Manager 파라미터 참조 단원을 참조하십시오.

파라미터 제약 조건 사용

제약 조건을 사용하면 스택을 생성하기 전에 CloudFormation에서 잘못된 값을 포착할 수 있도록 허용되는 입력 값을 설명할 수 있습니다. 최소 길이, 최대 길이 및 허용되는 패턴과 같은 제약 조건을 설정할 수 있습니다. 예를 들어 최소 길이는 8자이고 영숫자만 포함하도록 데이터베이스 사용자 이름값에 대한 제약 조건을 설정할 수 있습니다. 자세한 내용은 CloudFormation 템플릿에 대한 Parameters 섹션 구문 참조 단원을 참조하십시오.

유사 파라미터를 사용하여 이식성 향상

템플릿에서 의사 파라미터를 Ref 및 Fn::Sub와 같은 내장 함수에 대한 인수로 사용할 수 있습니다. 가상 파라미터는 CloudFormation에서 사전 정의된 파라미터입니다. 따라서 템플릿에서 가상 파라미터를 선언할 필요가 없습니다. 내장 함수에서 의사 파라미터를 사용하면 리전 및 계정 간에 스택 템플릿의 이식성이 향상됩니다.

예를 들어, 지정된 리소스 속성에 대해 다른 기존 리소스의 Amazon 리소스 이름(ARN)을 지정해야 하는 템플릿을 생성하려고 한다고 가정해 보겠습니다. 이 경우 기존 리소스는 ARN이 arn:aws:ssm:us-east-1:123456789012:parameter/MySampleParameter인 AWS Systems Manager Parameter Store 리소스입니다. ARN 형식을 대상 AWS 파티션, 리전 및 계정 ID에 맞게 조정해야 합니다. 이러한 값을 하드 코딩하는 대신 AWS::Partition, AWS::Region 및 AWS::AccountId 유사 파라미터를 사용하여 템플릿의 이식성을 높일 수 있습니다. 이 경우 다음 예제에서는 ARN의 요소를 CloudFormation과 연결하는 방법을 보여줍니다. !Sub 'arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/MySampleParameter

다른 예로 여러 스택에서 리소스나 구성을 공유하려고 한다고 가정해 보겠습니다. 이 예에서는 VPC에 대한 서브넷을 생성한 다음 동일한 AWS 계정 및 리전의 다른 스택에서 사용하기 위해 해당 ID를 내보냈다고 가정합니다. 다른 스택에서는 Amazon EC2 인스턴스를 설명할 때 내보낸 서브넷 ID 값을 참조합니다. Export 출력 필드 및 Fn::ImportValue 내장 함수 사용에 대한 자세한 예제는 다른 CloudFormation 스택의 리소스 출력 참조를 참조하세요.

스택 내보내기는 계정 및 리전별로 고유해야 합니다. 따라서 이 경우 AWS::StackName 의사 파라미터를 사용하여 내보내기에 대한 접두사를 생성할 수 있습니다. 스택 이름은 계정 및 리전별로 고유해야 하므로 이 의사 파라미터를 접두사로 사용하면 고유한 내보내기 이름을 가질 가능성이 높아지는 동시에 값을 내보내는 스택 전체에서 재사용 가능한 접근 방식이 장려됩니다. 또는 원하는 접두사를 사용할 수 있습니다.

AWS::CloudFormation::Init를 사용하여 Amazon EC2 인스턴스에서 소프트웨어 애플리케이션 배포

스택을 시작하면 cfn-init 헬퍼 스크립트와 AWS::CloudFormation::Init 리소스를 사용하여 Amazon EC2 인스턴스에서 소프트웨어 애플리케이션을 설치하고 구성할 수 있습니다. AWS::CloudFormation::Init를 사용하여 절차 단계를 스크립팅하지 않고 원하는 구성을 설명할 수 있습니다. 인스턴스를 다시 생성하지 않고 구성을 업데이트할 수도 있습니다. 구성에 문제가 발생한 경우 CloudFormation에서는 문제를 조사하는 데 사용할 수 있는 로그를 생성합니다.

템플릿의 AWS::CloudFormation::Init 리소스에서 설치 및 구성 상태를 지정합니다. cfn-init와 AWS::CloudFormation::Init를 사용하는 방법을 보여주는 연습은 Amazon EC2에 애플리케이션 배포 섹션을 참조하세요.

최신 헬퍼 스크립트 사용

헬퍼 스크립트는 주기적으로 업데이트됩니다. 헬퍼 스크립트를 호출하여 시작된 인스턴스에서 최신 헬퍼 스크립트를 가져왔는지 확인하기 전에 템플릿의 UserData 속성에 다음 명령이 포함되어 있는지 확인합니다.

yum install -y aws-cfn-bootstrap

최신 헬퍼 스크립트 가져오기에 대한 자세한 내용은 CloudFormation 헬퍼 스크립트 참조를 참조하세요.

템플릿을 사용하기 전에 템플릿 확인

템플릿을 사용하여 스택을 생성하거나 업데이트하기 전에 CloudFormation을 사용하여 템플릿을 확인합니다. CloudFormation에서 리소스를 생성하기 전에 템플릿을 확인하면 구문 및 일부 의미 체계 오류(예: 순환 종속성)를 파악할 수 있습니다. CloudFormation 콘솔을 사용하는 경우 입력 파라미터를 지정하면 콘솔에서 자동으로 템플릿을 확인합니다. AWS CLI 또는 CloudFormation API의 경우 validate-template CLI 명령 또는 ValidateTemplate API 작업을 사용합니다.

확인 중에 CloudFormation에서는 먼저 템플릿이 유효한 JSON인지를 확인합니다. 유효한 JSON이 아니면 CloudFormation은 템플릿이 유효한 YAML인지를 확인합니다. 두 확인이 모두 실패한 경우 CloudFormation에서는 템플릿 확인 오류를 반환합니다.

조직 정책 준수를 위한 템플릿 확인

템플릿을 확인하여 조직 정책 지침을 준수하는지 검증할 수도 있습니다. AWS CloudFormation Guard(cfn-guard)는 코드 정책 언어를 제공하여 필수 리소스 구성과 금지된 리소스 구성을 모두 확인할 수 있는 규칙을 정의하는 오픈 소스 명령줄 인터페이스(CLI) 도구입니다. 그런 다음 이러한 규칙에 대해 템플릿을 확인할 수 있습니다. 예를 들어, 관리자는 사용자가 항상 암호화된 Amazon S3 버킷을 생성하도록 보장하는 규칙을 생성할 수 있습니다.

템플릿을 편집하는 동안 cfn-guard를 로컬로 사용하거나 CI/CD 파이프라인의 일부로 자동 사용함으로써 규정 미준수 리소스의 배포를 방지할 수 있습니다.

또한 cfn-guard에는 기존 규정 준수 CloudFormation 템플릿에서 규칙을 추출할 수 있는 기능인 rulegen이 포함되어 있습니다,

자세한 내용은 GitHub에서 cfn-guard 리포지토리를 참조하세요.

AWS CloudFormation을 통해 모든 스택 리소스 관리

스택을 시작한 후에는 CloudFormation 콘솔, API 또는AWS CLI를 사용하여 스택의 리소스를 업데이트합니다. CloudFormation 외부의 스택 리소스는 변경하지 마세요. 변경하면 스택 템플릿과 스택 리소스의 현재 상태 간에 불일치가 발생할 수 있으며 이로 인해 스택을 업데이트하거나 삭제할 경우 오류가 발생할 수 있습니다. 이를 드리프트라고 합니다. CloudFormation 템플릿 외부의 리소스가 변경되고 스택을 업데이트하면 리소스에 직접 적용된 변경 사항이 폐기되고 리소스 구성이 템플릿의 구성으로 되돌아갑니다.

자세한 내용은 드리프트란 무엇인가요? 섹션을 참조하세요.

스택 업데이트에 대한 자세한 내용은 연습: 스택 업데이트 섹션을 참조하십시오.

스택을 업데이트하기 전에 변경 세트 생성

변경 세트를 사용하면 제안된 스택 변경 사항이 구현 전에 실행 중인 리소스에 어떤 영향을 미칠 수 있는지 확인할 수 있습니다. CloudFormation은 변경 세트를 실행할 때까지 스택을 변경하지 않으므로 제안된 변경을 계속 진행할지 아니면 다른 변경 세트를 생성할지 결정할 수 있습니다.

변경 세트를 사용하여 변경 사항이 실행 중인 리소스 특히, 중요 리소스에 미치는 영향을 확인합니다. 예를 들어 Amazon RDS 데이터베이스 인스턴스의 이름을 변경하면 CloudFormation에서는 새 데이터베이스가 생성되고 이전 데이터베이스는 삭제됩니다. 따라서 데이터베이스를 백업하지 않은 경우 이전 데이터베이스의 데이터가 손실됩니다. 변경 세트를 생성하면 변경 사항이 데이터베이스를 대체합니다. 따라서 스택을 업데이트하기 전에 계획을 세우기 좋습니다. 자세한 내용은 변경 세트를 사용하여 CloudFormation 스택 업데이트 단원을 참조하십시오.

스택 정책 사용

스택 정책을 사용하면 리소스 중단 또는 리소스 대체를 일으킬 수 있는 중요 스택 리소스의 의도치 않은 업데이트를 방지할 수 있습니다. 스택 정책은 지정된 리소스에 대해 수행할 수 있는 업데이트 작업을 설명하는 JSON 문서입니다. 중요 리소스가 있는 스택을 생성할 때마다 스택 정책을 지정합니다.

스택을 업데이트하는 동안 업데이트하려는 보호된 리소스를 명시적으로 지정해야 합니다. 그렇지 않으면 보호된 리소스가 변경되지 않습니다. 자세한 내용은 스택 리소스에 대한 업데이트 방지 단원을 참조하십시오.

코드 검토 및 버전 관리를 사용하여 사용자 템플릿 관리

스택 템플릿에서는 속성값과 같은 AWS 리소스의 구성을 설명합니다. 변경 사항을 검토하고 정확한 리소스 기록을 유지하려면 코드 검토 및 버전 관리를 사용합니다. 이러한 방법을 사용하면 템플릿의 여러 버전 간에 변경 사항을 추적할 수 있어 스택 리소스의 변경 사항을 추적할 수 있습니다. 또한 기록을 유지하면 언제든지 스택을 특정 템플릿 버전으로 되돌릴 수 있습니다.

정기적으로 Amazon EC2 인스턴스 업데이트

CloudFormation에서 생성된 모든 Amazon EC2 Windows 인스턴스 및 Amazon EC2 Linux 인스턴스에서 정기적으로 yum update 명령을 실행하여 RPM 패키지를 업데이트합니다. 이렇게 하면 최신 수정 사항 및 보안 업데이트를 받을 수 있습니다.