AWS CCP 자격증 - 9 (인프라 배포, 관리)

 

CloudFormation

CloudFormation는 AWS에서 중요한 기술입니다.

AWS 인프라의 모든 리소스에 대해 윤곽을 잡아주는 선언적인 방식이기 때문입니다.

구체적인 예시를 드리자면 CloudFormation에서 보안 그룹을 원하고 2개의 EC2 인스턴스가 해당 보안 그룹을 사용합니다.

또한 S3 버킷을 원하고 로드 밸런서를 모든 머신 앞에 두고 싶습니다

그러면 CloudFormation이 자동으로 여러분을 위해 순서에 맞게, 여러분이 지정한 구성에 맞춰 이것들을 만들어줍니다.

CloudFormation을 사용해서 얻는 혜택은 다양합니다

 

먼저 모든 인프라가 코드로 되어 있습니다 즉, 사용자는 절대로  리소스를 수동으로 만들지 않습니다. (제어하기에 훌륭)

이 말은 AWS 클라우드가 어떻게 동작할지 변경을 할 때마다 코드 리뷰를 통해 검토해야 한다는 뜻입니다.

 

클라우드에서 작동하기 좋은 방식입니다

거기에 비용 절감 효과가 있습니다 이 스택 내 각 리소스는 스택 내 만들어진 모든 다른 리소스와 비슷한 태그를 갖게 됩니다 따라서 CloudFormation 템플릿을 사용하여 쉽게 리소스의 비용을 추정할 수 있습니다,

 

또한, CloudFormation 덕분에 절약 전략을 가질 수 있습니다

예를 들어, 어떤 환경에서는

 

오후 5시에 모든 템플릿을 자동으로 삭제할 수 있습니다. 이는 템플릿과 연결된 모든 리소스를 삭제하고 오전 9시나 8시에 안전하게 다시 만듭니다. 따라서 비용을 절약할 수 있습니다 오후 5시와 오전 8시 사이에 리소스가 없기 때문입니다

CloudFormation에서는 리소스를 만들고 지우기가 쉽습니다.

 

 

그리고 생산성도 있습니다 즉시 인프라를 삭제하고 다시 만들 수 있기 때문입니다.

템플릿에 관한 도식도 만들어 줍니다

선언적 프로그래밍도 있습니다 EC2 인스턴스에 먼저 DynamoDB 테이블을 만들어야 하는지 모든 것을 같이 만들어야 하는지 파악할 필요가 없습니다.

CloudFormation 템플릿은 어떻게 이것들을 처리할지 충분히 알고 있습니다

CloudFormation에서 이미 있는 것을 다시 만들 필요가 없죠

즉, 웹에 있는 기존 템플릿을 이용할 수 있습니다

공식 문서를 사용할 수 있고 CloudFormation은 대다수의 AWS 리소스를 지원합니다.

지원되지 않는 리소스는 사용자 정의 리소스를 사용할 수 있습니다

CloudFormation은 AWS 인프라의 기반으로, 코드화됩니다

온라인 WordPress CloudFormation 스택을 가져왔는데,

 

디자이너로 가서 무엇을 보여주는지 확인해 보았습니다 이 도식인데,

보이는 것처럼 다양한 구성 요소가 만들어졌습니다

 

예를 들어, 보안 그룹이 있고 ALBListener, 실행 구성, 로드 밸런서, RDS용 데이터베이스 인스턴스, 오토 스케일링 그룹이 있습니다

CloudFormation은 도식을 만들 만큼 똑똑하고 모든 구성 요소 간 모든 관계를 만들 수 있습니다,

모든 리소스와 관계가 보입니다

 

시험 측면에서는 CloudFormation은 코드로 인프라를 가질 때 아키텍처를 다른 환경, 리전, 심지어 다른 AWS 계정에서

반복해야 할 때 사용됩니다

 

이런식으로 코드를 통해 EC2 인스턴스를 생성합니다

 

AWS Clood Develoment Kit (CDK)

이는 익숙한 프로그래밍 언어로 클라우드 인프라를 정의하는 방식입니다.

 

예를 들어, YAML 형식이라서 CloudFormation을 직접 사용하지 않고

JavaScript, TypeScript 또는 Python이나 Java나 .NET을 사용하고 이러한 언어로 클라우드 인프라를 작성하고자 한다면

CDK를 통해 가능합니다

이런 프로그래밍 언어로 인프라를 작성하면 CDK를 통해 코드가 JSON 또는 YAML 형식으로

CloudFormation 템플릿에 컴파일 됩니다

그래서 인프라와 애플리케이션의 런타임 코드를 함께 배포할 수 있죠

동일한 언어를 공유하기 때문입니다

람다 함수에 유용하고

ECS와 EKS의 도커 컨테이너에 유용합니다

Python을 프로그래밍 언어로 선택해 예시를 살펴보겠습니다

 

CDK 애플리케이션을 Python으로 작성하고 다른 AWS 서비스를 위한 DynamoDB 테이블의 람다 함수를 정의합니다.

이제 CDK CLI를 사용하는 이 CDK 애플리케이션은 CloudFormation 템플릿으로 변환되고

 

생성된 CloudFormation 템플릿은 CloudFormation에서 인프라 배포에 적용됩니다

프로그래밍 언어를 사용해서 클라우드 인프라를 사용하는 것입니다

예시로 형식 안정(type-safe)을 갖도록 하거나 익숙한 구조 등을 갖도록 하고 빠르게 수행하거나 코드를 재사용하도록 하고For 루프와 같은 것을 갖도록 하기 때문입니다

 

 

CDK 코드의 예시를 살펴보겠습니다

JavaScript 또는 TypeScript을 사용한 예시입니다 정의된 VPC와 ECS 클러스터가 있고

Fargate 서비스용 ALB도 있습니다

 

이 3가지가 CDK CLI로 사용 가능한 CloudFormation 템플릿에 컴파일 되어 업로드와 배포를 할 수 있습니다

 

Beanstalk

AWS에서 웹 애플리케이션을 배포했을 때 일반적으로 3-티어 아키텍처라는 아키텍처를 따릅니다.

 

따라서 사용자는 여러 AZ에 있을 수 있는 로드 밸런서와 통신하고 로드 밸런서는 트래픽을

오토 스케일링 그룹에서 관리하는 여러 EC2 인스턴스에 보냅니다

그러면 EC 인스턴스는 데이터를 저장해야 하므로 관계형 데이터베이스인 Amazon RDS와 같은 데이터 베이스를 사용해 데이터를 읽고 씁니다

 

인 메모리 데이터베이스나 인 메모리 캐시가 필요하면 일래스티 캐시를 사용해 세션 데이터나 캐시 데이터를 저장하고 검색합니다 이런 아키텍처는 손쉽게 수동으로 복제할 수 있습니다

 

Elasic Beanstalk

 

일래스틱 Beanstalk은 AWS에 애플리케이션을 배포하는 개발자 중심 관점으로

Beanstalk 이면에는 이전과 동일한 구성 요소가 있습니다

 

EC2 인스턴스와 오토 스케일링 그룹 리고 ELB와 RDS 데이터베이스 등

하지만 Beanstalk는 개발자 중심적으로 모든 것을 이해하기 쉽도록 한 번에 볼 수 있습니다.

전체 구성 요소를 여전히 제어할 수 있지만 모두 Beanstalk 내에 있는 것입니다

클라우드의 관점에서 Beanstalk은 서비스형 플랫폼 혹은 PaaS입니다

우리는 코드가 중요하니 크게 신경 쓸 필요 없습니다

요약하자면, Iaas인 서비스형 인프라를 살펴봤고 PaaS이자 서비스형 플랫폼인 Beanstalk을 살펴봤습니다

그리고 AWS의 다른 서비스에 관한

서비스형 소프트웨어도 살펴볼 예정입니다 Beanstalk는 무료이지만 기본 인스턴스 비용이 있습니다

마지막으로 시험에는 상태 모니터링에 관해 출제됩니다

 

Beanstalk에는 서비스 자체에서 사용할 수 있는 전체 모니터링 suit이 있습니다

그리고 CloudWatch에 지표를 푸시할 Beanstalk의 각 EC2 인스턴스에 상태 에이전트가 있고

 

Beanstalk 내부에서 지표를 확인하고 모니터링 등을 할 수 있죠

또한, 애플리케이션 상태를 확인해 상태 이벤트를 게시합니다

 

여기 보이는 사진 Beanstalk에서

애플리케이션 상태의 모니터링 방식입니다

 

CodeDeploy

CloudFormation과 Beanstalk을 살펴봤으니 CodeDeploy를 살펴보겠습니다.

CodeDeploy도 애플리케이션을 자동으로 배포하는 방식입니다

 

차이점이라면 CodeDeploy가 조금 더 관대하다는 것인데

Beanstalk이나 CloudFormation을 사용하지 않아도 됩니다 완전히 독립적입니다.

 

CodeDeploy로 버전 1의 애플리케이션을 버전 2로 업그레이드 할 수 있고

CodeDeploy에서 그 방법을 파악합니다

 

CodeDeploy는 2가지로 실행됩니다

 

먼저, EC2 인스턴스로 실행되며 많은 EC2 인스턴스를 v1에서 v2로 업그레이드 할 수 있습니다

 

또한, 온프레미스 서버에서 실행됩니다

온프레미스에 서버가 있고 애플리케이션을 버전 1에서 버전 2로 업그레이드 하려면 CodeDeploy로 가능합니다

그래서 CodeDeploy를 하이브리드 서비스라고 합니다 온프레미스와 EC2 인스턴스에서 모두 실행되기 때문입니다

 

CodeDeploy는 모든 서버에서 실행되지만 서버를 미리 프로비저닝 해야 하고 업그레이드를 지원하는 CodeDeploy 에이전트를 설치하도록 구성해야 합니다 CodeDeploy는 AWS에서 꽤 유용한 서비스입니다

 

온프레미스 서버 또는 EC2 인스턴스로 애플리케이션을 배포하는 방식과 동일한 방식으로 온프레미스에서 AWS로

전환할 수 있기 때문입니다

 

기억할 것은 EC2 인스턴스 애플리케이션과 온프레미스 서버 애플리케이션을 단일 인터페이스에서 자동으로

버전 1에서 버전 2로 업그레이드 가능하다는 것입니다

 

AWS CodeCommit

AWS에서 코드와 연관된 도구를 살펴보겠습니다

 

애플리케이션 코드를 서버로 푸시하기 전에 어딘가에 저장해야 하는데 개발자들은 주로 코드 리포지토리를 선택하고

Git 기술을 사용해 백업됩니다

가장 유명한 공용 서비스는 GitHub이지만

 

AWS에도 경쟁 서비스가 있는데 바로 CodeCommit입니다

CodeCommit은 AWS의 버전 관리 리포지토리에 코드를 저장하는 방식입니다

따라서 Git을 기반으로 한 리포지토리입니다

 

CodeCommit을 기반으로 하는 이유가 뭘까요?

Git 기반의 리포지토리가 있으면 개발자들이 코드로 협업하는 것이 정말 쉽습니다.

코드 변경 사항은 자동으로 버전 관리되고 롤백이 가능합니다

 

CodeCommit의 장점은 완전 관리형 코드 리포지토리이며 확장성이 있고 고가용성이면서 AWS 계정 내에 있어서

프라이빗하고 안전하며 모든 AWS 서비스와 통합된다는 것입니다

 

AWS CodeBuild

CodeBuild 서비스를 살펴보겠습니다

이름에서 알 수 있듯이 클라우드에서 코드를 설계하도록 합니다

 

소스 코드가 컴파일 되고 테스트가 실행되며 출력값으로 패키지가 생성되는데

패키지는 예를 들어 CodeDeploy로 서버에 배포된 준비가 되어 애플리케이션을 실행하도록 합니다

 

도표로 확인해 보겠습니다

코드가 CodeCommit에 있고 CodeBuild는 CodeCommit에서 코드를 검색하고

정의해야 하는 스크립트를 실행하고 코드를 설계해서 배포 준비된 Artifact를 얻습니다.

 

왜 CodeBuild를 사용할까요?

완전 관리형이며 서버리스이기 때문이며 지속적으로 확장 가능하고 고가용성이며 안전하면서 종량 과금제가 있기 때문인데 종량 과금제는 코드 설계 시간에 대한 비용을 지불하는 것입니다 관리할 서버는 없습니다

 

즉, 사용자는 코딩만 신경 쓰면 되고 CodeCommit 리포지토리에 코드 업데이트를 푸시 할 때마다 AWS 내 서비스에서 코드 설계에 걸리는 시간만 확인하면 됩니다

 

AWS CodePipeline

 

다음은 CodePipeline입니다 CodeCommit과 CodeBuild을 어떻게 연결할까요?

CodePipeline으로 연결할 수 있습니다

CodePipeline은 코드가 자동으로 프로덕션에 푸시 되도록 다른 단계를 조정하는 방식입니다

 

즉, 코드를 가져오는 파이프라인을 정의하고 설계와 테스트를 하고 일부 서버를 프로비저닝 해서 해당 서버에 애플리케이션을 배포하는 것입니다

더 복잡할 수도 있죠 이러한 단계를 조정하려면 파이프라인 도구가 필요한데 이것이 바로 CodePipeline입니다

 

CICD라는 용어를 들어 보셨는지 모르겠지만 지속적 통합과 지속적 전달이라는 뜻입니다

전체 개념은 개발자가 리포지토리로 코드를 푸시할 때마다 구축되어 테스트 되며 일부 서버에 배포되는 것입니다

CodePipeline를 살펴보죠  오케스트레이션(orchestration) 계층인 코드가 있고 CodeCommit에서 코드를 가져와서CodeBuild로 구축하고 CodeDeploy로 배포를 결정한 뒤 일례로 일래스틱 Beanstalk 환경으로 배포됩니다

 

이는 파이프라인 설계의 한 방법으로 다양한 방법이 있습니다

CodePipeline 사용 이유는 완전 관리형이기 때문입니다 많은 서비스와 호환되는데 CodeCommit, CodeBuild CodeDeploy, 일래스틱 Beanstalk, CloudFormation, GitHub 등이며 다른 타사 서비스와 사용자 플러그인과도 호환됩니다

 

그리고 빠르게 전달되며 업데이트도 빠릅니다

AWS 내의 CICD 서비스의 핵심으로 파이프라인의 오케스트레이션에 관한 것이 시험에 출제되면 AWS CodePipeline을 생각하면 됩니다

 

AWS CodeArtifat

AWS CodeArtifact를 살펴보겠습니다 개발자가 생성한 소프트웨어 패키지 대게 서로 의존적으로 설계되는데

소프트웨어 패키지의 아키텍처와 같은 것이며 코드 종속성이라고도 합니다

 

그리고 이 종속성을 저장하고 검색하는 것을 Artifact 관리라고 합니다

기존에는 Amazon S3나 EC2 인스턴스의 사용자 지정 소프트웨어에서 자체 Artifact 관리 시스템을 설정해야 했으며 복잡할 수 있습니다

 

그래서 안전하고 확장 가능하며 비용 효율적인 소프트웨어 배포에 관한 Artifact 관리 소프트웨어인

AWS CodeArtifact가 출시됐습니다

 

지금은 자체 인프라를 설정하는 대신 CodeArtifact를 사용할 수 있고 개발자들이 사용하는 일반적인 종속성 관리 도구인Maven, Gradle, npm, yarn, twine, pip 그리고 NuGet이 CodeArtifact와 통신해 이러한 코드 종속성을 저장하고 검색합니다

 

따라서 개발자는 기본적으로 이러한 종속성을 저장하고 검색하는 안전한 장소를 갖게 됩니다

이는 코드를 CodeCommit으로 푸시하면 CodeBuild에서 설계하고 CodeArtifact에서 바로 종속성을 검색할 수 있습니다

 

시험에 관련해서도 팀이 Artifact 관리 시스템이나 코드 종속성을 저장할 장소가 필요할 경우에 CodeArtifact을 떠올리면 됩니다

 

AWS CodeStar

AWS CodeStar를 살펴보겠습니다 CodeStar는 통합 UI로 소프트웨어 개발 작업을 한곳에서 쉽게 관리할 수 있습니다

 

그러면 CodeCommit과 CodeBuild 그리고 CodeDeploy를 어떻게 설정할까요?

CodePipeline과 모두 통합해야 할까요?

 

복잡해 보이지만 CodeStar로 이 문제를 해결할 수 있습니다

원스톱 숍을 제공하여 개발 프로젝트를 시작하도록 하고 자동으로 이 깔끔한 대시보드를 제공합니다

 

그리고 대시보드와 백그라운드에서는 CodeCommit 리포지토리와 CodeBuild 설계 프로세스 CodeDeploy, CodePipeline이 생성되고 모니터링 등도 실행됩니다

 

Beanstalk 환경이나 EC2 인스턴스 등에서도 빠르게 시작할 수 있습니다

장점은 AWS Cloud9로 클라우드에서 바로 코드를 수정할 수 있다는 것입니다

 

따라서 이 모든 것이 CodeStar를 핵심 서비스로 만들고 개발자가 CICD의 모범 사례를 사용해서 빠르게 개발을 시작하도록 합니다 시험에 대비해서는 여기까지 알면 됩니다

 

AWS Cloud9 

AWS Cloud9을 살펴보겠습니다 Cloud9은 클라우드 IDE로 통합개발환경의 줄인말이며

클라우드에서 바로 코드를 읽고, 실행하고, 디버깅할 수 있습니다.

 

코드 편집기처럼 보이지만 클라우드에서 실행되며 웹 브라우저에서 실행됩니다.

IntelliJ, Visual Studio Code와 같은 유명한 기존 IDE는 컴퓨터에 다운로드 되고 사용 전에 설치되지만

클라우드 IDE는 Chrome, Firefox Internet Explorer 등의 웹 브라우저에서 사용 가능합니다.

 

이는 어떤 설정도 없이 사무실이나 집 또는 인터넷에 액세스 가능한 모든 곳에서 프로젝트 작업을 할 수 있고

빠르게 작업으로 돌아올 수 있다는 의미입니다

 

또한, 실시간으로 코드 협업을 하고 페어(pair) 프로그래밍을 할 수 있도록 합니다.

오른쪽에서 보시는 것처럼 3명이 Cloud9에서 같은 시간에 같은 코드로 협업할 수 있죠

이제 IDE를 보면 Cloud9을 생각하세요

 

AWS SSM (Systems Manager)

AWS System Manager인 SSM을 살펴보겠습니다

SSM은 EC2 인스턴스와 온프레미스 시스템을 규모에 맞게 관리하도록 합니다.

온프레미스와 AWS 모두를 관리하는 방법인 것입니다

 

그래서 하이브리드 AWS 서비스라고 합니다 SSM으로 복잡한 많은 작업을 실행할 수 있습니다

Systems Manager이기 때문에 인프라 상태에 관한 운영 인사이트도 얻을 수 있고

10개 이상의 상품에 액세스할 수 있습니다

시험에 대비해 모든 상품을 살펴볼 필요는 없지만

하지만 가장 중요한 상품과 기능은 규정 준수를 강화하기 위해서 서버와 인스턴스에 패치를 자동으로 적용할 수 있습니다

 

또한, SSM에서 바로 전체 서버에 명령을 실행할 수 있고 SSM 파라미터 스토어로 기본 구성을 저장할 수 있습니다. 

그리고 SSM은 Windows 서버와 Linux 서버에서 실행됩니다

 

따라서 시험에 EC2 인스턴스 플릿이나 온프레미스 서버의 패치가 나오면 SSM을 생각하면 되고 모든 서버에 전반적으로명령을 실행하는 경우에도 SSM을 생각하면 됩니다

 

 

 

 

 

 

SSM 원리를 통해 더 확실히 이해할 수 있습니다

SSM 서비스는 자체적으로 실행되지만 먼저, 제어하는 시스템에 SSM 에이전트를 설치해야 합니다.

 

백그라운드에서 실행될 작은 프로그램입니다

AWS에서 Amazon Linux AMI나 Ubuntu AMI를 사용하면 기본적으로 설치됩니다.

 

EC2 인스턴스와 온프레미스 가상 머신에서는 전체에 SSM 에이전트를 설치해야 하며

SSM 에이전트는 AWS의 SSM 서비스에 다시 리포트를 전달합니다

 

보시는 것처럼 EC2 인스턴스와 온프레미스 VM에 연결됐고 이렇게 하이브리드 서비스가 됩니다

SSM으로 인스턴스를 제어할 수 없는 경우는 에이전트 문제일 가능성이 높습니다.

 

이제 서버와 EC2 인스턴스에 에이전트가 설치됐고 SSM 서비스를 사용해 전체 서버에 명령을 실행하거나

전체를 한 번에 패치하거나 일관되게 구성할 수 있습니다 이것만 기억하면 시험에 대비할 수 있습니다

System Manager Parameter Store

System Manager Parameter Store에 대해 알아보겠습니다.

구성 데이터나 암호를 안전하게 AWS에 저장해주는 방식인데요

API 키나 비밀번호, 구성 데이터 등 원하는 것을 모두 저장할 수 있습니다

 

서버가 필요없습니다 즉, 제공할 게 없다는 뜻이죠 확장도 가능합니다

한번에 여러 API 호출에 응답할 수 있고요 지속적이고 사용도 간편합니다

무엇보다 안전합니다, IAM을 사용해 Parameter Store에 있는 각 파라미터의 액세스를 관리할 수 있기 때문이죠

게다가 구성 데이터가 진화할 수 있고 파라미터도 진화할 수 있습니다

그래서 버전 추적과 선택적 암호화가 가능합니다 

 

하지만 Parameter Store에서 우리 애플리케이션이나 사용자는 일반 텍스트 구성 또는 암호화된 구성 데이터를

입력할 수 있는데 이때는 KMS로 암호화됩니다 그래서 한 곳에서 수많은 애플리케이션 구성 데이터를 관리하고 중앙 집중식으로 저장할 수 있습니다

 

배포 정리

 

첫 번째로 AWS 전용 도구인 CloudFormation이 있습니다

이것은 Infrastructure as Code를 가능하게 하며 거의 모든 AWS 리소스와 호환된다는 특징이 있었습니다.

이를 이용하여 템플릿을 제작하고 그 템플릿은 AWS에 인프라를 배포하는 데 사용할 수 있습니다

 

마찬가지로 AWS 전용인 Beanstalk가 있습니다  다양한 지역과 사용자에서 모두 이 템플릿을 사용할 수 있도록 함으로써

진정한 반복 가능 인프라로 만들수 있습니다.

 

Elastic Beanstalk는 서비스형 플랫폼, 즉 PaaS(Platform as a Service)로

특정 프로그래밍 언어 또는 Docker로 제한됩니다 알려진 아키텍처를 이용하여 코드를 지속적으로 배포할 수 있습니다

예를 들어 Load Balancer와 EC2 인스턴스, 그리고 RDS 데이터베이스를 조합할 수 있습니다

 

CodeDeploy는 어떤 애플리케이션도 서버로 배포하고 업그레이드할 수 있습니다

이는 예를 들어 AWS에서 EC2 인스턴스에 적용할 수도 있지만 회사의 사내 인프라에도 적용 가능합니다

CodeDeploy가 하이브리드 유형의 서비스라 불리는 이유입니다

 

Systems Manager 역시 하이브리드 서비스입니다 이것을 이용하면 모든 서버에서 규모를 조정해 가며 패치, 환경설정, 그리고 명령 실행이 가능합니다

 

배포 서비스에 관한 내용은 여기까지입니다

이제 개발자 서비스에 대하여 이야기하여 봅시다

시험에도 나오는 CodeCommit에 대해서 전에 배웠습니다

이것은 비공개 Git 저장에 코드를 저장하는 서비스로 이를 통하여 version control(버전 관리)가 되는 코드 리포지토리를 가질 수 있습니다

 

CodeBuild는 AWS에서 코드를 서버 없이 구축하고 테스트하도록 해 줍니다

 

CodeDeploy는 서버에 코드를 배포할 수 있도록 합니다 CodeDeploy는 배포와 개발자 서비스에서 모두 소개하였습니다

 두 유형 모두로 볼 수 있기 때문입니다

CodePipeline은 AWS 내부에서 파이프라인을 조직하기 위하여 필요합니다 즉 코드를 짜는 것부터 구축, 테스트

배포, 그리고 공급까지 모든 곳에 쓰입니다

 

CodeArtifact는 AWS에서 소프트웨어 패키지와 종속성을 저장할 때 필요하며

 

CodeStar는 통합적 관점을 제공하고(UI)

 

OneStopShop은 개발자에게 CI/CD(지속적 통합/배포)와 직접 코딩이 가능케 해줍니다

 

그리고 마지막으로 클라우드 IDE인 Cloud9가 있습니다 이것은 즉 통합 개발 환경입니다

이것을 이용하면 웹 브라우저에서 직접 코드를 수정할 수 있으며

콜라보레이션 기능을 일부 가지고 있어 페어 프로그래밍 등을 할 수 있습니다

 

다음으로는 CDK가 있습니다 프로그래밍 언어를 이용하여 클라우드 인프라를 정의하는 데 사용됩니다

예를 들어 JavaScript, TypeScript, Java, Python 등등을 이용할 수 있습니다

정의한 내용은 CloudFormation 템플릿으로 번역됩니다