AWS CDK v2 개발자 안내서입니다. 구형 CDK v1은 2022년 6월 1일에 유지 보수에 들어갔고 2023년 6월 1일에 지원이 종료되었습니다.

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

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

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

스택은 이러한 논리 유닛의 배포 모델을 정의합니다. CDK의 기본 개념에 대한 자세한 소개는 를 참조하십시오. 시작하기 AWS CDK

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

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

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

이를 뒷받침하는 철학은 권장 모범 사례로 AWS CDK 이어지며, 이를 크게 네 가지 범주로 나누었습니다.

조직 모범 사례

AWS CDK 도입 초기 단계에서는 조직을 성공으로 이끄는 방법을 고려하는 것이 중요합니다. CDK를 채택하는 과정에서 회사의 나머지 구성원을 교육하고 안내할 책임이 있는 전문가 팀을 두는 것이 가장 좋습니다. 이 팀의 규모는 소규모 회사의 경우 한두 명에서 대규모 회사의 본격적인 Cloud Center of Excellence (CCoE) 에 이르기까지 다양할 수 있습니다. 이 팀은 회사의 클라우드 인프라에 대한 표준과 정책을 수립하고 개발자를 교육하고 멘토링하는 일을 담당합니다.

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

CCoE는 또한 조직 단위를 정의하는 “랜딩 존 (landing zone)" 을 생성합니다. AWS Landing Zone은 모범 사례 청사진을 기반으로 사전 구성되고 안전하며 확장 가능한 다중 계정 AWS 환경입니다. Landing Zone을 구성하는 서비스를 통합하려면 단일 사용자 인터페이스에서 전체 다중 계정 시스템을 구성하고 관리하는 방법을 사용할 AWS Control Tower수 있습니다.

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

코딩 모범 사례

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

간단하게 시작해서 필요할 때만 복잡성을 더하세요.

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

AWS Well-Architected 프레임워크에 맞춰 조정

AWS Well-Architected 프레임워크는 구성 요소를 요구 사항에 부합하는 코드, 구성 AWS 및 리소스로 정의합니다. 구성 요소는 종종 기술 소유권의 단위이며 다른 구성 요소와 분리됩니다. 워크로드라는 용어는 함께 비즈니스 가치를 제공하는 구성 요소 집합을 식별하는 데 사용됩니다. 워크로드는 일반적으로 비즈니스 및 기술 리더가 소통하는 세부 수준입니다.

AWS CDK 응용 프로그램은 AWS Well-Architected 프레임워크에 정의된 구성 요소에 매핑됩니다. AWS CDK 앱은 Well-Architected 클라우드 애플리케이션 모범 사례를 체계화하고 제공하는 메커니즘입니다. 다음과 같은 아티팩트 리포지토리를 통해 구성 요소를 재사용 가능한 코드 라이브러리로 만들고 공유할 수도 있습니다. AWS CodeArtifact

모든 애플리케이션은 단일 리포지토리의 단일 패키지로 시작됩니다.

단일 패키지는 AWS CDK 앱의 진입점입니다. 여기서는 애플리케이션의 다양한 논리 유닛을 배포하는 방법과 위치를 정의합니다. 또한 애플리케이션을 배포하기 위한 CI/CD 파이프라인을 정의합니다. 앱 구조는 솔루션의 논리적 단위를 정의합니다.

둘 이상의 응용 프로그램에서 사용하는 구문에는 추가 패키지를 사용하십시오. (또한 공유 구조에는 고유한 수명 주기 및 테스트 전략이 있어야 합니다.) 동일한 리포지토리에 있는 패키지 간의 종속성은 리포지토리의 빌드 도구를 통해 관리됩니다.

가능하긴 하지만, 특히 자동화된 배포 파이프라인을 사용하는 경우에는 여러 애플리케이션을 동일한 리포지토리에 두지 않는 것이 좋습니다. 이렇게 하면 배포 중 변경 사항의 “폭발 반경”이 늘어납니다. 저장소에 여러 응용 프로그램이 있는 경우 다른 응용 프로그램이 변경되지 않았더라도 한 응용 프로그램을 변경하면 다른 응용 프로그램도 배포됩니다. 또한 한 응용 프로그램이 손상되면 다른 응용 프로그램을 배포할 수 없습니다.

코드 수명 주기 또는 팀 소유권을 기반으로 코드를 리포지토리로 이동합니다.

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

또한 여러 팀에서 작업하는 경우 패키지를 자체 저장소로 옮기세요. 이렇게 하면 액세스 제어를 강화하는 데 도움이 됩니다.

여러 리포지토리에서 패키지를 사용하려면 NPM 또는 Maven Central과 비슷하지만 조직 내부에 있는 개인 패키지 리포지토리가 필요합니다. PyPi 또한 패키지를 빌드하고 테스트하여 개인 패키지 저장소에 게시하는 릴리스 프로세스도 필요합니다. CodeArtifact가장 많이 사용되는 프로그래밍 언어의 패키지를 호스팅할 수 있습니다.

패키지 저장소의 패키지 종속성은 해당 언어의 패키지 관리자 (예: NPM for TypeScript 또는 JavaScript application) 에서 관리합니다. 패키지 관리자는 빌드가 반복 가능한지 확인하는 데 도움을 줍니다. 애플리케이션이 사용하는 모든 패키지의 특정 버전을 기록하여 이를 수행합니다. 또한 제어된 방식으로 이러한 종속성을 업그레이드할 수 있습니다.

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

구문은 임의로 단순하거나 복잡할 수 있다는 점을 염두에 두세요. BucketA는 구조이지만 구조체일 CameraShopWebsite 수도 있습니다.

인프라 및 런타임 코드는 동일한 패키지에 있습니다.

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

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

모범 사례 구축

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

구문을 이용한 모델링, 스택으로 배포

스택은 배포 단위입니다. 스택의 모든 항목이 함께 배포됩니다. 따라서 여러 AWS 리소스에서 애플리케이션의 상위 수준 논리 유닛을 구축할 때는 각 논리 유닛을 a가 아닌 Constructa로 표현해야 합니다. Stack 스택은 다양한 배포 시나리오에서 구문을 구성하고 연결하는 방법을 설명하는 용도로만 사용하십시오.

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

구축용 구성과 배포용 스택을 사용하면 인프라의 재사용 가능성을 높이고 배포 방식을 보다 유연하게 조정할 수 있습니다.

환경 변수가 아닌 속성과 메서드를 사용하여 구성합니다.

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

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

인프라를 단위 테스트하세요.

모든 환경에서 빌드 시 전체 유닛 테스트 세트를 일관되게 실행하려면 합성 중에 네트워크 조회를 피하고 모든 프로덕션 단계를 코드로 모델링하세요. (이러한 모범 사례는 나중에 설명합니다.) 단일 커밋으로 인해 항상 동일한 템플릿이 생성되는 경우 생성된 템플릿이 예상대로 표시되는지 확인하기 위해 작성하는 단위 테스트를 신뢰할 수 있습니다. 자세한 설명은 테스트 구성 섹션을 참조하세요.

스테이트풀 리소스의 논리적 ID는 변경하지 마세요.

리소스의 논리 ID를 변경하면 다음 배포 시 리소스가 새 리소스로 교체됩니다. 데이터베이스 및 S3 버킷과 같은 스테이트풀 리소스나 Amazon VPC와 같은 영구 인프라의 경우 이는 거의 필요하지 않습니다. ID를 변경할 수 있는 AWS CDK 코드 리팩토링에 주의하십시오. 스테이트풀 리소스의 논리적 ID가 정적으로 유지되는지 확인하는 단위 테스트를 작성하세요. 논리적 ID는 구문을 인스턴스화할 때 id 지정한 값과 구문 트리에서의 구문 위치에서 파생됩니다. 자세한 설명은 논리적 ID 섹션을 참조하세요.

구문은 규정을 준수하기에 충분하지 않습니다.

많은 기업 고객이 L2 구성 (기본 제공 기본 제공 및 모범 사례로 개별 AWS 리소스를 나타내는 “큐레이션된” 구조) 에 대한 자체 래퍼를 작성합니다. 이러한 래퍼는 정적 암호화 및 특정 IAM 정책과 같은 보안 모범 사례를 적용합니다. 예를 들어, 일반적인 Amazon S3 Bucket 구조 대신 생성하여 애플리케이션에서 사용할 수 있습니다. MyCompanyBucket 이 패턴은 소프트웨어 개발 수명 주기 초기에 보안 지침을 제시하는 데 유용하지만, 이를 유일한 적용 수단으로 삼지는 마십시오.

대신 서비스 제어 정책 및 권한 경계와 같은 AWS 기능을 사용하여 조직 수준에서 보안 가드레일을 적용하십시오. 배포 속성 전에 CloudFormation Guard와 같은 도구를 사용하여 인프라 요소의 보안 속성을 확인해 보세요. 가장 AWS CDK 효과적인 용도로 사용하세요.

마지막으로, 직접 “L2+” 구문을 작성하면 개발자가 AWS 솔루션 구문 또는 Construct Hub의 타사 구문과 같은 AWS CDK 패키지를 활용하지 못할 수 있다는 점을 염두에 두세요. 이러한 패키지는 일반적으로 표준 구문을 기반으로 구축되며 AWS CDK 래퍼 구문을 사용할 수 없습니다.

애플리케이션 모범 사례

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

통합 시점에 결정을 내리세요.

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

대신 프로그래밍 언어의 if 명령문 및 기타 기능을 사용하여 AWS CDK 응용 프로그램에서 인스턴스화할 구문과 같은 모든 결정을 내려보세요. 예를 들어, 목록을 반복하고 목록에 있는 각 항목의 값으로 구문을 인스턴스화하는 일반적인 CDK 관용구는 표현식을 사용해서는 불가능합니다. AWS CloudFormation

강력한 클라우드 배포에 AWS CDK 사용하는 구현 세부 AWS CloudFormation 정보로 취급할 뿐, 언어 대상으로 취급하지 마십시오. 여러분은 TypeScript Python이나 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 상응하는 요금이 빠르게 저장될 수 있습니다.

각 프로덕션 리소스에 적용할 정책을 신중하게 고려하고 그에 따라 정책을 지정하세요. 스택의 제거 및 로깅 정책을 검증하는 속성 데 사용합니다.

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

애플리케이션에 필요한 스택 수에 대한 엄격한 규칙은 없습니다. 일반적으로 배포 패턴을 기반으로 결정을 내리게 됩니다. 다음 지침을 염두에 두십시오.

비결정적 행동을 cdk.context.json 피하겠다고 약속하세요.

결정성은 성공적인 배포의 핵심입니다. AWS CDK AWS CDK 앱은 주어진 환경에 배포될 때마다 기본적으로 동일한 결과를 보여야 합니다.

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

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

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

배포를 성공적으로 완료한 지 몇 개월 또는 몇 년이 지나면 AWS-side 변경이 발생할 수 있으므로 이러한 상황은 치명적일 수 있습니다. 갑자기 배포가 “이유 없이” 실패하고 오래 전에 수행한 작업과 이유를 잊어버린 것입니다.

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

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

역할 및 보안 그룹을 AWS CDK 관리하도록 하세요.

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

myBucket.grantRead(myLambda)

이 한 줄은 Lambda 함수의 역할 (사용자를 위해 생성되기도 함) 에 정책을 추가합니다. 이 역할과 해당 정책에는 직접 작성하지 않아도 CloudFormation 되는 십여 줄이 넘습니다. 는 함수가 버킷에서 읽는 데 필요한 최소한의 권한만 AWS CDK 부여합니다.

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

모든 제작 단계를 코드로 모델링합니다.

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

애플리케이션을 합성할 때 cdk.out 폴더에 생성된 클라우드 어셈블리에는 각 환경에 대한 별도의 템플릿이 포함됩니다. 전체 빌드는 결정적입니다. 애플리케이션에는 out-of-band 변경 사항이 없으며, 커밋을 수행해도 항상 똑같은 AWS CloudFormation 템플릿과 함께 제공되는 에셋이 생성됩니다. 따라서 유닛 테스트의 신뢰성이 훨씬 높아집니다.

모든 것을 측정하세요

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