v AWS CDK 2 개발자 안내서입니다. 이전 CDK v1은 2022년 6월 1일에 유지 관리에 들어갔으며 2023년 6월 1일에 지원이 종료되었습니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

를 사용한 클라우드 인프라 개발 및 배포 모범 사례 AWS CDK

AWS CDK개발자 또는 관리자는를 사용하여 지원되는 프로그래밍 언어를 사용하여 클라우드 인프라를 정의할 수 있습니다. CDK 애플리케이션은 API, 데이터베이스 및 모니터링 리소스와 같은 논리 단위로 구성되어야 하며, 선택적으로 자동 배포를 위한 파이프라인이 있어야 합니다. 다음을 포함한 구문으로 논리 단위를 구현해야 합니다.

스택은 이러한 논리 단위의 배포 모델을 정의합니다. CDK의 개념에 대한 보다 자세한 소개는 시작하기 AWS CDK 섹션을 참조하세요.

에는 고객과 내부 팀의 요구 사항과 복잡한 클라우드 애플리케이션의 배포 및 지속적인 유지 관리 중에 자주 발생하는 장애 패턴을 신중하게 고려하는 것이 AWS CDK 반영됩니다. 장애는 구성 변경과 같이 완전히 테스트되지 않은 애플리케이션의 ‘대역 외’ 변경과 관련이 있는 경우가 많습니다. 따라서 비즈니스 로직뿐만 아니라 인프라 및 구성까지 코드에 전체 애플리케이션이 정의된 모델을 AWS CDK 중심으로를 개발했습니다. 이러한 방식으로 제안된 변경 사항을 신중하게 검토하고, 프로덕션 환경과 유사한 환경에서 다양한 수준으로 종합적으로 테스트하고, 문제가 발생하면 완전히 롤백할 수 있습니다.

배포 시는 다음을 포함하는 클라우드 어셈블리를 AWS CDK 합성합니다.

CDK를 사용하면 애플리케이션의 기본 버전 관리 브랜치에 있는 모든 커밋이 애플리케이션의 완전하고 일관되며 배포 가능한 버전을 나타낼 수 있습니다. 그러면 변경 사항이 있을 때마다 애플리케이션을 자동으로 배포할 수 있습니다.

이면의 철학은 권장 모범 사례로 AWS CDK 이어지며,이 모범 사례는 네 가지 광범위한 범주로 나뉩니다.

조직 모범 사례

AWS CDK 채택 초기 단계에서는 조직의 성공을 설정하는 방법을 고려하는 것이 중요합니다. 전문가로 구성된 팀에서 회사의 다른 팀원들이 CDK를 도입할 때 이들을 교육하고 안내하도록 하는 것이 가장 좋습니다. 이 팀의 규모는 소규모 회사의 경우 1~2명에서 대규모 회사의 본격적인 클라우드 혁신 센터(CCoE)까지 다양할 수 있습니다. 이 팀은 회사의 클라우드 인프라에 대한 표준과 정책을 설정하고, 개발자 교육과 멘토링을 담당합니다.

CCoE는 클라우드 인프라에 사용해야 하는 프로그래밍 언어에 대한 지침을 제공할 수 있습니다. 세부 정보는 조직마다 다르지만 좋은 정책은 개발자가 회사의 클라우드 인프라를 이해하고 유지할 수 있도록 하는 데 도움이 됩니다.

또한 CCoE는 조직 단위를 정의하는 "랜딩 존"을 생성합니다 AWS. 랜딩 존은 모범 사례 블루프린트를 기반으로 사전 구성된 안전하고 확장 가능한 다중 계정 AWS 환경입니다. 랜딩 존을 구성하는 서비스를 함께 연결하기 위해 단일 사용자 인터페이스에서 전체 다중 계정 시스템을 구성하고 관리하는 AWS Control Tower를 사용할 수 있습니다.

개발 팀은 자체 계정을 테스트에 사용하고 필요에 따라 이러한 계정에 새 리소스를 배포할 수 있어야 합니다. 개별 개발자는 이러한 리소스를 자체 개발 워크스테이션의 익스텐션으로 취급할 수 있습니다. 그런 다음 CDK Pipelines을 사용하여 CI/CD 계정을 통해 AWS CDK 애플리케이션을 테스트, 통합 및 프로덕션 환경(각각 자체 AWS 리전 또는 계정에서 격리됨)에 배포할 수 있습니다. 이는 개발자의 코드를 조직의 정식 리포지토리에 병합하여 수행됩니다.

코딩 모범 사례

이 섹션에서는 AWS CDK 코드를 구성하는 모범 사례를 제공합니다. 다음 다이어그램은 팀과 해당 팀의 코드 리포지토리, 패키지, 애플리케이션 및 construct 라이브러리 간의 관계를 보여줍니다.

간단하게 시작하고 필요할 때만 복잡성 추가

대부분 모범 사례의 기본 원칙은 더 이상 단순할 수 없을 만큼 가능한 한 단순하게 유지하는 것입니다. 요구 사항에 따라 더 복잡한 솔루션이 필요할 때만 복잡성을 더하세요. 를 사용하면 필요에 따라 코드를 리팩터링하여 새 요구 사항을 지원할 AWS CDK수 있습니다. 가능한 모든 시나리오를 미리 설계할 필요는 없습니다.

AWS Well-Architected 프레임워크와 일치

AWS Well-Architected 프레임워크는 구성 요소를 요구 사항에 따라 함께 제공하는 코드, 구성 및 AWS 리소스로 정의합니다. 구성 요소는 대개 기술 소유권의 단위이며 각기 분리되어 있습니다. 워크로드라는 용어는 비즈니스 가치를 제공하는 일련의 구성 요소를 가리키는 데 사용됩니다. 워크로드는 일반적으로 비즈니스 및 기술 책임자가 언급하는 수준의 디테일에 해당합니다.

AWS CDK 애플리케이션은 AWS Well-Architected Framework. AWS CDK apps에서 정의한 구성 요소에 매핑되며, 이는 Well-Architected 클라우드 애플리케이션 모범 사례를 코드화하고 제공하는 메커니즘입니다. AWS CodeArtifact등의 아티팩트 리포지토리를 통해 구성 요소를 재사용 가능한 코드 라이브러리로 생성하고 공유할 수도 있습니다.

모든 애플리케이션이 단일 리포지토리의 단일 패키지로 시작

단일 패키지는 AWS CDK 앱의 진입점입니다. 여기서 애플리케이션의 다양한 논리 단위를 어떻게 어디에 배포할지 정의합니다. 애플리케이션을 배포하기 위한 CI/CD 파이프라인도 정의합니다. 앱의 구문이 솔루션의 논리 단위를 정의합니다.

여러 애플리케이션에서 사용하는 구문에는 추가 패키지를 사용합니다. 공유 구문에는 자체 수명 주기 및 테스트 전략도 있어야 합니다. 동일한 리포지토리의 패키지 간 종속성은 리포지토리의 빌드 도구로 관리됩니다.

가능하지만, 특히 자동 배포 파이프라인을 사용하는 경우 동일한 리포지토리에 여러 애플리케이션을 두는 것은 권장하지 않습니다. 이렇게 하면 배포 중 변경 사항의 ’폭발 반경’이 늘어납니다. 리포지토리에 여러 애플리케이션이 있는 경우, 한 애플리케이션을 변경하면 다른 애플리케이션의 배포가 트리거됩니다. 다른 애플리케이션이 변경되지 않은 경우도 마찬가지입니다. 또한 한 애플리케이션이 중단되면 다른 애플리케이션이 배포되지 않습니다.

코드 수명 주기 또는 팀 소유권에 따라 리포지토리로 코드 이동

여러 애플리케이션에서 패키지가 사용되기 시작하면 패키지를 자체 리포지토리로 이동합니다. 이렇게 하면 패키지를 사용하는 애플리케이션 빌드 시스템에서 참조할 수 있으며 애플리케이션 수명 주기와 관계없이 주기에 따라 업데이트할 수도 있습니다. 그러나 처음에는 모든 공유 구문을 하나의 리포지토리에 넣는 것이 합리적일 수 있습니다.

또한 여러 팀에서 패키지 작업을 하는 경우 패키지를 자체 리포지토리로 이동합니다. 이렇게 하면 액세스 제어를 시행하는 데 도움이 됩니다.

리포지토리 경계를 넘어 패키지를 사용하려면 NPM, PyPI 또는 Maven Central과 유사하지만 조직 내부에 있는 프라이빗 패키지 리포지토리가 필요합니다. 또한 패키지를 빌드 및 테스트하고 프라이빗 패키지 리포지토리에 게시하는 릴리스 프로세스가 필요합니다. CodeArtifact는 대부분의 인기 프로그래밍 언어에 대한 패키지를 호스팅할 수 있습니다.

패키지 리포지토리의 패키지에 대한 종속성은 TypeScript나 JavaScript 애플리케이션의 경우 NPM과 같은 언어의 패키지 관리자에 의해 관리됩니다. 패키지 관리자는 빌드가 반복 가능한지 확인하는 데 도움이 됩니다. 패키지 관리자는 애플리케이션이 의존하는 모든 패키지의 특정 버전을 기록하여 이를 수행합니다. 또한 이러한 종속성을 제어된 방식으로 업그레이드할 수 있습니다.

공유 패키지에는 다른 테스트 전략이 필요합니다. 단일 애플리케이션의 경우 애플리케이션을 테스트 환경에 배포하고 여전히 작동하는지 확인하는 것으로 충분할 수 있습니다. 그러나 공유 패키지는 일반에 공개되는 것처럼 사용 중인 애플리케이션과 독립적으로 테스트해야 합니다. 조직에서 일부 공유 패키지를 실제로 일반에 공개하도록 선택할 수 있습니다.

구문은 임의로 간단할 수도 있고 복잡할 수도 있다는 점에 유의하세요. Bucket은 구문이지만 CameraShopWebsite도 구문일 수 있습니다.

인프라 및 런타임 코드가 동일한 패키지에 있음

인프라 배포를 위한 AWS CloudFormation 템플릿을 생성하는 것 외에도는 Lambda 함수 및 Docker 이미지와 같은 런타임 자산을 AWS CDK 번들링하여 인프라와 함께 배포합니다. 이를 통해 인프라를 정의하는 코드와 런타임 로직을 구현하는 코드를 단일 구문으로 결합할 수 있습니다. 이렇게 하는 것이 가장 좋은 방법입니다. 이 두 종류의 코드는 별도의 리포지토리나 패키지에 있을 필요가 없습니다.

두 종류의 코드를 함께 발전시키려면 인프라와 로직을 포함하여 기능을 완전히 설명하는 독립형 구문을 사용합니다. 독립형 구문을 사용하면 두 종류의 코드를 따로 테스트하고, 프로젝트 간에 코드를 공유 및 재사용하고, 모든 코드를 동기화하여 버전을 관리할 수 있습니다.

구문 모범 사례

이 섹션에는 구문 개발을 위한 모범 사례가 포함되어 있습니다. 구문은 리소스를 캡슐화하는 재사용 가능하고 구성 가능한 모듈입니다. 이는 AWS CDK 앱의 구성 요소입니다.

구문으로 모델링, 스택으로 배포

스택은 배포 단위로, 스택의 모든 항목이 함께 배포됩니다. 따라서 여러 AWS 리소스에서 애플리케이션의 상위 수준 논리 단위를 빌드할 때 각 논리 단위를가 Construct아닌 로 나타냅니다Stack. 다양한 배포 시나리오에 맞게 구문을 구성하고 연결하는 방법을 설명하는 데만 스택을 사용하세요.

예를 들어 논리 단위 중 하나가 웹 사이트인 경우 이를 구성하는 구문(예: Amazon S3 버킷, API Gateway, Lambda 함수 또는 Amazon RDS 테이블)은 단일 상위 구문으로 구성되어야 합니다. 그런 다음 배포를 위해 하나 이상의 스택에서 해당 구문을 인스턴스화해야 합니다.

빌드에 구문을 사용하고 배포에 스택을 사용하면 인프라의 재사용 가능성과 배포 방식의 유연성이 향상됩니다.

환경 변수가 아닌 속성 및 메서드로 구성

구문과 스택 내부의 환경 변수 조회는 일반적인 안티 패턴입니다. 구문과 스택 모두 속성 객체를 허용하여 코드에서 완전한 구성이 가능하도록 해야 합니다. 그렇지 않으면 코드가 실행될 시스템에 대한 종속성이 발생하여 추적하고 관리해야 하는 구성 정보가 더 많이 생성됩니다.

일반적으로 환경 변수 조회는 AWS CDK 앱의 최상위 수준으로 제한되어야 합니다. 또한 개발 환경에서 실행하는 데 필요한 정보를 전달하는 데에도 사용되어야 합니다. 자세한 내용은 의 환경 AWS CDK 단원을 참조하십시오.

인프라 유닛 테스트

모든 환경에서 빌드 시 전체 유닛 테스트를 일관되게 실행하려면 합성 중 네트워크 조회를 피하고 모든 프로덕션 스테이지를 코드로 모델링합니다. 이러한 모범 사례는 나중에 다룹니다. 단일 커밋에서 항상 동일한 템플릿이 생성되는 경우 작성한 유닛 테스트를 신뢰하여 생성된 템플릿이 예상한 대로 표시되는지 확인할 수 있습니다. 자세한 내용은 AWS CDK 애플리케이션 테스트 단원을 참조하십시오.

상태 저장 리소스의 논리적 ID를 변경하지 않음

리소스의 논리적 ID를 변경하면 다음 배포 시 리소스가 새 리소스로 교체됩니다. 데이터베이스 및 S3 버킷과 같은 상태 저장 리소스 또는 Amazon VPC와 같은 영구 인프라의 경우 대개 이를 원하지 않습니다. ID가 변경될 수 있는 AWS CDK 코드 리팩터링에 주의하십시오. 상태 저장 리소스의 논리적 ID가 정적으로 유지되는지 확인하는 유닛 테스트를 작성합니다. 논리적 ID는 구문을 인스턴스화할 때 지정하는 id와 구문 트리에서 구문의 위치에서 파생됩니다. 자세한 내용은 논리적 ID 단원을 참조하십시오.

구문으로는 규정 준수에 부족

많은 엔터프라이즈 고객은 L2 구문(기본값 및 모범 사례가 내장된 개별 AWS 리소스를 나타내는 '큐레이션된' 구문)에 대한 자체 래퍼를 작성합니다. 이러한 래퍼는 정적 암호화 및 특정 IAM 정책과 같은 보안 모범 사례를 시행합니다. 예를 들어, 일반적인 Amazon S3 Bucket 구문 대신 애플리케이션에서 사용하는 MyCompanyBucket을 생성할 수 있습니다. 이 패턴은 소프트웨어 개발 수명 주기 초기에 보안 지침을 표시하는 데 유용하지만, 이를 유일한 시행 수단으로 의존해서는 안 됩니다.

대신 서비스 제어 정책 및 권한 경계와 같은 AWS 기능을 사용하여 조직 수준에서 보안 가드레일을 적용합니다. 배포 전에 인프라 요소의 보안 속성에 대한 어설션을 만들려면 측면 및 AWS CDK 또는 CloudFormation Guard와 같은 도구를 사용하세요. 가장 잘하는 것에 AWS CDK 를 사용합니다.

마지막으로 자체 "L2+" 구문을 작성하면 개발자가 Construct Hub의 AWS Solutions Constructs 또는 타사 구문과 같은 AWS CDK 패키지를 활용하지 못할 수 있습니다. 이러한 패키지는 일반적으로 표준 AWS CDK 구문을 기반으로 빌드되므로 래퍼 구문을 사용할 수 없습니다.

애플리케이션 모범 사례

이 섹션에서는 구문을 결합하여 리소스 연결 방법을 정의하여 AWS CDK 애플리케이션을 작성하는 방법을 AWS 설명합니다.

합성 시 의사 결정

AWS CloudFormation 에서는 배포 시(Conditions, { Fn::If }및 사용Parameters) 결정을 내릴 수 있고 에서는 이러한 메커니즘에 대한 일부 액세스 권한을 AWS CDK 부여하지만 사용하지 않는 것이 좋습니다. 사용할 수 있는 값의 유형과 해당 값에 대해 수행할 수 있는 연산의 유형은 범용 프로그래밍 언어에서 사용할 수 있는 것에 비해 제한적입니다.

대신 프로그래밍 언어의 if 문 및 기타 기능을 사용하여 AWS CDK 애플리케이션에서 인스턴스화할 구문과 같은 모든 결정을 내리세요. 예를 들어 목록을 반복하고 목록의 각 항목의 값을 사용하여 구문을 인스턴스화하는 일반적인 CDK 관용은 AWS CloudFormation 표현식을 사용할 수 없습니다.

AWS CloudFormation 가 언어 대상이 아닌 강력한 클라우드 배포에 AWS CDK 사용하는 구현 세부 정보로 취급합니다. TypeScript 또는 Python에서 AWS CloudFormation 템플릿을 쓰지 않고 CloudFormation을 배포에 사용하는 CDK 코드를 쓰고 있습니다.

물리적 이름이 아닌 생성된 리소스 이름 사용

이름은 귀중한 리소스입니다. 각 이름은 한 번만 사용할 수 있습니다. 따라서 테이블 이름이나 버킷 이름을 인프라와 애플리케이션에 하드 코딩하는 경우 동일한 계정에서 해당 인프라 부분을 두 번 배포할 수 없습니다. 여기서 말하는 이름은 예를 들어 Amazon S3 버킷 구문의 bucketName 속성에서 지정하는 이름입니다.

더 큰 문제는 교체가 필요한 리소스를 변경할 수 없다는 것입니다. Amazon DynamoDB 테이블의 KeySchema와 같은 리소스 생성 시에만 속성을 설정할 수 있는 경우 해당 속성은 변경할 수 없습니다. 이 속성을 변경하려면 새 리소스가 필요합니다. 하지만 새 리소스의 이름이 같아야 진정한 교체가 가능합니다. 하지만 기존 리소스가 해당 이름을 사용하는 동안에는 동일한 이름을 가질 수 없습니다.

더 좋은 방법은 가능한 한 적은 이름을 지정하는 것입니다. 리소스 이름을 생략하면 AWS CDK 가 문제를 일으키지 않는 방식으로 리소스 이름을 생성합니다. 테이블이 리소스라고 가정해 보겠습니다. 그런 다음 생성된 테이블 이름을 AWS Lambda 함수에 환경 변수로 전달할 수 있습니다. AWS CDK 애플리케이션에서 테이블 이름을 로 참조할 수 있습니다table.tableName. 또는 시작 시 Amazon EC2 인스턴스에서 구성 파일을 생성하거나 AWS Systems Manager Parameter Store에 실제 테이블 이름을 기록하여 애플리케이션에서 읽을 수 있습니다.

필요한 장소가 다른 AWS CDK 스택이라면 훨씬 더 간단합니다. 한 스택이 리소스를 정의하고 다른 스택이 리소스를 사용해야 한다고 가정하면 다음이 적용됩니다.

제거 정책 및 로그 보존 정의

는 사용자가 생성한 모든 것을 유지하는 정책으로 기본 설정하여 데이터가 손실되지 않도록 하려고 AWS CDK 시도합니다. 예를 들어 데이터가 포함된 리소스(예: Amazon S3 버킷 및 데이터베이스 테이블)에 대한 기본 제거 정책은 스택에서 리소스가 제거될 때 해당 리소스를 삭제하지 않는 것입니다. 대신 리소스는 스택에서 고립됩니다. 마찬가지로 CDK의 기본값은 모든 로그를 영구적으로 유지하는 것입니다. 프로덕션 환경에서 이러한 기본값으로 인해 실제로 필요하지 않은 대량의 데이터가 빠르게 저장되고 해당 AWS 요금이 청구될 수 있습니다.

각 프로덕션 리소스에 대해 이러한 정책이 어떤 것이 되기를 원하는지 신중하게 고려하고 그에 따라 지정합니다. 측면 및 AWS CDK를 사용하여 스택의 제거 및 로깅 정책을 검증합니다.

배포 요구 사항에 따라 애플리케이션을 여러 스택으로 구분합니다.

애플리케이션에 필요한 스택 수에 대한 어렵고 빠른 규칙은 없습니다. 일반적으로 배포 패턴에 대한 결정을 기반으로 합니다. 다음 지침에 유의하세요.

비결정적 동작을 방지하기 위해 cdk.context.json 커밋

결정성은 성공적인 AWS CDK 배포의 핵심입니다. AWS CDK 앱은 지정된 환경에 배포할 때마다 기본적으로 동일한 결과를 가져야 합니다.

AWS CDK 앱은 범용 프로그래밍 언어로 작성되므로 임의 코드를 실행하고, 임의 라이브러리를 사용하고, 임의 네트워크 호출을 수행할 수 있습니다. 예를 들어 AWS SDK를 사용하여 앱을 합성하는 동안 AWS 계정에서 일부 정보를 검색할 수 있습니다. 이렇게 하면 cdk synth를 실행할 때마다 추가 자격 증명 설정 요구 사항, 지연 시간 증가, 아무리 작더라도 실패할 가능성이 있다는 점을 인식합니다.

합성 중에는 AWS 계정이나 리소스를 수정하지 마세요. 앱을 합성해도 부작용이 없어야 합니다. 인프라 변경은 AWS CloudFormation 템플릿이 생성된 후에 배포 단계에서만 이루어져야 합니다. 이렇게 하면 문제가 발생하면가 변경 사항을 자동으로 롤백할 AWS CloudFormation 수 있습니다. AWS CDK 프레임워크 내에서 쉽게 변경할 수 없는 변경을 수행하려면 사용자 지정 리소스를 사용하여 배포 시 임의의 코드를 실행합니다.

엄격하게 읽기 전용인 직접 호출도 반드시 안전한 것은 아닙니다. 네트워크 직접 호출에서 반환되는 값이 변경되면 어떻게 되는지 고려합니다. 인프라의 어떤 부분에 영향을 미치나요? 이미 배포된 리소스는 어떻게 되나요? 다음은 값이 갑자기 변경되면 문제가 발생할 수 있는 두 가지 예시 상황입니다.

몇 달 또는 몇 년 동안 성공적으로 배포한 후 AWS변경 사항이 발생할 수 있으므로 이러한 상황은 치명적일 수 있습니다. 갑자기 배포가 ‘이유 없음’으로 실패하고 오래전에 수행한 작업과 이유를 잊어버렸습니다.

다행히 에는 비결정적 값의 스냅샷을 기록하는 컨텍스트 공급자라는 메커니즘이 AWS CDK 포함되어 있습니다. 이를 통해 향후 합성 작업은 처음 배포할 때와 정확히 동일한 템플릿을 생성할 수 있습니다. 새 템플릿의 유일한 변경 사항은 사용자가 코드에서 변경한 사항입니다. 구문의 .fromLookup() 메서드를 사용하면 직접 호출의 결과가 cdk.context.json에 캐시됩니다. 나중 CDK 앱을 실행할 때 동일한 값을 사용할 수 있도록 나머지 코드와 함께 버전 관리에 이를 커밋해야 합니다. CDK Toolkit에는 컨텍스트 캐시를 관리하는 명령이 포함되어 있으므로 필요할 때 특정 항목을 새로 고칠 수 있습니다. 자세한 내용은 컨텍스트 값 및 AWS CDK 단원을 참조하십시오.

네이티브 CDK 컨텍스트 공급자가 없는 일부 값(출처 AWS 또는 다른 곳)이 필요한 경우 별도의 스크립트를 작성하는 것이 좋습니다. 스크립트는 값을 검색하여 파일에 작성한 다음 CDK 앱에서 해당 파일을 읽어야 합니다. 일반 빌드 프로세스의 일부가 아닌 저장된 값을 새로 고치려는 경우에만 스크립트를 실행합니다.

가 역할 및 보안 그룹을 AWS CDK 관리하도록 허용

AWS CDK 구문 라이브러리의 grant() 편의 방법을 사용하면 최소 범위 권한을 사용하여 한 리소스에 대한 액세스 권한을 다른 리소스에 부여하는 AWS Identity and Access Management 역할을 생성할 수 있습니다. 예를 들어, 다음 줄을 생각해 보세요.

amzn-s3-demo-bucket.grantRead(myLambda)

이 한 줄은 Lambda 함수의 역할(사용자를 위해 생성됨)에 정책을 추가합니다. 이 역할과 정책은 작성할 필요가 없는 12줄 이상의 CloudFormation입니다. 는 함수가 버킷에서 읽는 데 필요한 최소 권한만 AWS CDK 부여합니다.

개발자가 항상 보안 팀에서 생성한 사전 정의된 역할을 사용해야 하는 경우 AWS CDK 코딩이 훨씬 더 복잡해집니다. 팀은 애플리케이션을 설계하는 방법에 많은 유연성을 잃을 수 있습니다. 더 나은 대안은 서비스 제어 정책과 권한 경계를 사용하여 개발자가 가드레일 내에 있도록 하는 것입니다.

코드의 모든 프로덕션 스테이지 모델링

기존 AWS CloudFormation 시나리오에서 목표는 파라미터화된 단일 아티팩트를 생성하여 해당 환경에 고유한 구성 값을 적용한 후 다양한 대상 환경에 배포할 수 있도록 하는 것입니다. CDK에서는 해당 구성을 소스 코드에 빌드할 수 있으며 빌드해야 합니다. 프로덕션 환경에 대한 스택을 생성하고 다른 각 스테이지에 대해 별도의 스택을 생성합니다. 그런 다음 코드에 각 스택의 구성 값을 입력합니다. Secrets Manager 및 Systems Manager Parameter Store와 같은 서비스를 사용하여 해당 리소스의 이름 또는 ARN을 사용하여 소스 제어에 체크인하지 않으려는 민감한 값을 확인합니다.

애플리케이션을 합성할 때 cdk.out 폴더에 생성된 클라우드 어셈블리에는 각 환경에 대한 별도의 템플릿이 포함됩니다. 전체 빌드는 결정적입니다. 애플리케이션에는 out-of-band 변경 사항이 없으며 지정된 커밋은 항상 정확히 동일한 AWS CloudFormation 템플릿과 함께 제공되는 자산을 생성합니다. 따라서 유닛 테스트의 안정성이 훨씬 향상됩니다.

모두 측정

사람의 개입 없이 완전 연속 배포 목표를 달성하려면 높은 수준의 자동화가 필요합니다. 이러한 자동화는 광범위한 모니터링으로만 가능합니다. 배포된 리소스의 모든 측면을 측정하려면 지표, 경보 및 대시보드를 생성합니다. CPU 사용량 및 디스크 공간 등을 측정하는 데 멈추지 마세요. 또한 비즈니스 지표를 기록하고 이러한 측정값을 사용하여 롤백과 같은 배포 결정을 자동화하세요. 의 대부분의 L2 구문 AWS CDK 에는 dynamodb.Table 클래스의 메서드와 같은 지표를 생성하는 데 도움이 되는 편의 metricUserErrors() 메서드가 있습니다.