코드로 인프라 관리: AWS CDK

목차

• 서론
  • 코드로 인프라를 관리한다: Infrastructure as Code(IaC)
  • 대상 독자
  • 인프라 관리 불편 사례
  • aws-cdk를 사용했을 때 좋은점은?
  • 기존 기술과의 비교
    • AWS CLI (명령줄 인터페이스)
    • AWS CloudFormation
    • Serverless Framework
    • Terraform
• 본론
  • [실습] cdk 환경 구성하기
  • [실습] VPC와 EC2 인스턴스를 포함한 인프라 스택 생성
• 결론
  • 개선할 점
  • 실천 사항

코드로 인프라를 관리한다: Infrastructure as Code(IaC)

AWS CDK(클라우드 개발 키트)는 익숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 모델링 및 프로비저닝할 수 있는 오픈 소스 소프트웨어 개발 프레임워크입니다.

AWS를 사용하면서, Management Console 화면에서 이것저것 만들고 건드리고 하는 것이 뭔가 좀 어수선하다는 느낌을 받은 적이 있을 겁니다. 누가 언제 뭘 만들고 고쳤는지를 체계적으로 관리하는데 한계가 있었습니다.

화면에서 여기저기 타이핑하고, 클릭 클릭해서 만드는 대신에, 뭔가 진짜 설계도를 작성하듯이 인프라를 정의할 수는 없을까?하는 고민이 많았습니다.

이를 위해 코드로 인프라를 설계하는 개념, 즉 Infrastructure as Code(IaC)가 나왔습니다.

IaC를 지원하는 도구에는 AWS CloudFormation, Terraform 등이 있었습니다.

최근에는 AWS 사용자를 위해 aws-cdk가 출시되었는데, 그럼 오늘은 aws-cdk에 대해 알아보겠습니다.

aws-cdk, 2020년에는 너로 정했다!

대상 독자

• 코드로서의 인프라(Infrastructure as Code)에 관심있는 분
• AWS Management Console(GUI)을 사용하다가 좀 더 견고하고 가시적인 인프라 관리를 고민하신 분
• AWS CloudFormation이나 Terraform을 사용해봤고, 더 편리한 방법을 원하는 분

인프라 관리 불편 사례

코드로 인프라를 관리하지 않던 시절에는 어땠을까요? 지난 경험을 되살려봅시다.

사례1: 업데이트 되어 UI 스타일이 바뀐 관리 콘솔 화면

1. 인프라 관리 업무 영속성을 위해 매뉴얼을 만든다.
2. 열심히 캡처하고 코멘트 달고…
3. 어느날 AWS Management Console이 업데이트 되면서 UI 스타일이 싹 바뀜
4. 문서랑 안 맞음 (…)

UI는 언제든지 바뀔 수 있습니다.

GUI가 일반인들에게 친숙하긴 하지만, 전문가에게는 CLI가 오히려 더 편리합니다. 예를 들면, Windows 인스톨러를 받아서 프로그램을 설치하는 것과, 터미널에서 brew (맥OS)나 apt-get (우분투)로 설치하는 것 중에 어느 쪽이 더 쉬울까요? 문서화하기도 좋고 재현성(복사해서 붙여넣고 엔터치면 되는)이 좋은 CLI가 당연히 더 쉽습니다.

그런데 그 CLI 스크립트보다 더 좋은 게 있었으니… (그건 이따가 살펴보겠습니다.)

사례2: 정리되지 않은 리소스로 인해 예상치 않은 비용 청구

1. AWS 계정을 새로 만들었다.
2. “1년 동안 프리티어 기간이니까 이것저것 만들어보고 실습해봐야지.”
3. 이것저것 여기저기 만들어 본 후,
4. “음, 이제 과금이 되지 않도록 리소스를 해제해야지.”
5. (한 달 후)
6. “엥? 이건 왜 과금이 된거지? 아, 이걸 해제하는 걸 빠뜨렸구나…”
7. 용돈 날아감 (…)

설계도에 따라 한 번에 생성하고 한 번에 다 지웠다면 이런 일이 일어나지 않았을 것입니다.

인프라 리소스에는 계층이 있고 의존 관계가 있습니다. 예를 들면, VPC를 만들고, 보안 그룹을 만들고, 서브넷을 만들고, EC2 인스턴스를 만들고 서로 연결했다고 합시다. 나중에 VPC 단위로 리소스를 삭제하려면 어떻게 해야할까요? 의존 관계에 따라 생성의 역순으로 삭제해야 합니다. (분해는 조립의 역순) 만약 이것저것 여기저기 따로 만들었으면 삭제가 쉽지 않습니다. 이런 맥락이 어딘가에 일목요연하게 설계도처럼 정리되어 있으면 관리하기도 쉽고 생성/삭제도 어렵지 않았을 겁니다.

리소스의 계층과 의존 관계가 정리된 설계도를 AWS에서는 스택(Stack)이라고 합니다. (이것도 이따가 알아봅시다.)

사례3: 중구난방 어수선한 인프라 관리

1. AWS 인프라 관리 업무 인수 받음
2. “이건 뭐지? 지워도 되나? 의존 관계는 어떻게 되지?”
3. 어디에 뭐가 숨어있는지 몰라서 못 건드림
4. 리소스가 전부 따로 놀아서 개별 관리
5. 보안 설정? 권한? 컴플라이언스? (어떻게 되었는지 모르겠음)
6. 관리되지 않고 짱박힌 리소스 존재 (…)

여러분은 이미 클라우드 환경에 진입했습니다. 컴퓨터 몇 대를 세밀하게 관리하는 수준 대신, 거시적으로 인프라 관리를 해야합니다. 기껏해야 몇 명을 관리하는 분대장이 아니라 제법 큰 병력을 통솔하는 대대장/연대장의 시각에서 인프라를 바라보아야 합니다. 이것을 비유한 것이 바로 DevOps Concepts: Pets vs Cattle 인데요. 이 수준에서 일사불란한 인프라 관리를 하려면 수작업으로는 택도 없습니다.

수작업을 벗어나야 합니다.

사례4: 인프라의 재구성

개인 호스팅 블로그를 운용하는데 돈은 없고, 그래서 헝그리 정신으로 프리티어(1년)만 이용하고, 끝나면 계정을 새로 파서 서비스를 옮기려는 생각을 하신 분이 있을 것입니다. 그런데 VPC와 네트워크, 기타 리소스를 새로, 그것도 이전과 같이 그대로 다시 만드는 것이 쉽지가 않습니다. 서비스를 중단 없이 유지하려면 이런 절차를 손쉽고 빠르게 진행할 수 있어야 합니다. 어떻게 하면 그대로 인프라를 복제할 수 있을까요?

aws-cdk를 쓰면 됩니다. (본론으로)

aws-cdk를 사용했을 때 좋은점은?

aws-cdk는 내부적으로 CLI와 AWS CloudFormation을 사용합니다. 이 두가지 서비스를 코드로 작성해서 편리하게 이용할 수 있도록 해주는 것입니다.

CloudFormation의 요소인 스택의 특성은 다음과 같습니다.

• 스택(Stack) 단위로 인프라를 생성/업데이트/삭제합니다. (스택 수준의 원자성)
• 스택은 다른 스택을 포함할 수 있습니다. (계층 구조)

스택을 이용하여 인프라를 생성/업데이트/삭제하는 일련의 과정을 하나의 논리 집합으로 표현할 수 있습니다.

위의 인프라 관리 불편 사례에서 언급한 문제점을 다음과 같이 해결할 수 있습니다.

사례1: 업데이트 되어 UI 스타일이 바뀐 관리 콘솔 화면에 대해서

당연하지만, cdk를 이용하면 Management Console의 UI가 달라져도 아무 영향이 없습니다.

UI는 달라질 가능성이 있지만, aws-cdk의 인터페이스는 거의 변경되지 않습니다.

설령 변경되더라도 하위 호환이 유지될 것이고, 안 되면 코드를 조금 수정하면 됩니다.

사실 Management Console은 AWS의 인프라가 실제로 조직되는 방법과 AWS 사용자의 의도 사이에 화면이라는 해석 계층이 하나 더 들어가 있습니다. 실제로 CloudFormation 스택의 YAML 파일 내용을 보셨거나 cdk로 스택을 코딩하다보면, 리소스 간 연결 구조가 Management Console에서 화면으로 보는 것과는 다르다는 것을 알 수 있습니다.

사례2: 정리되지 않은 리소스로 인해 예상치 않은 비용 청구에 대해서

스택 단위로 인프라를 생성하고, 이용이 끝나면 다시 스택 단위로 말끔히 제거하기 때문에 실수로 남은 리소스 때문에 요금이 발생하는 불상사를 막을 수 있습니다.

AWS에서 사용자 교육을 위해 제공하는 Hands-on-Lab 실습 교재에서도 CloudFormation 스택을 제공합니다. 그리고 실습을 마친 후에 꼭 스택을 삭제하라고 하지요. (무료 제공 크레딧을 날려 먹고 추가 요금 청구를 받아서 항의가 빗발치는 것을 막기 위해)

사례3: 중구난방 어수선한 인프라 관리에 대해서

이미 존재하는 리소스에 그때그때 임의로 변경을 가하면 어떤 변경이 있었는지, 현재 상태가 어떠한지 추적하기가 힘듭니다. 대신 인프라 스택을 표현한 소스코드를 만들어두고, 인프라를 변경할 때 해당 소스코드를 바탕으로 애플리케이션을 배포하듯이 변경을 적용하면, 인프라의 변경 이력과 현재 상태를 쉽게 추적할 수 있습니다. 즉 소스코드 버전 관리 시스템과 같은 방식으로 인프라를 관리할 수 있게 됩니다.

사례4: 인프라의 재구성에 대해서

aws-cdk를 이용해 인프라 프로비저닝을 할 수 있습니다. (사실 사례2와 같은 내용이니, 철거도 쉽습니다.)

프리티어 만료 시에 새 프리티어 계정을 만들어서 프리티어를 유지하고 싶다면, cdk 스택에서 AWS Account 환경변수만 바꿔주면 됩니다. (단, DB 데이터 같은 건 마이그레이션 해야겠지요.)

기존 기술과의 비교

AWS CLI (명령줄 인터페이스)

CLI는 AWS의 모든 서비스의 기능을 API로 만들어 놓은 것이라서 Management Console 화면에서 무엇을 조작하거나 하는 등의 동작을 CLI로 대신할 수 있습니다. 다만 너무 Low Level이라서 직접 이용하기 보다는 다른 High Level의 인프라 관리 도구가 대신 사용하도록 합니다.

# EC2 인스턴스 생성 및 실행
$ aws ec2 run-instances --image-id ... --instance-type ... ... (주저리 주저리)

이걸로 인프라 관리하려면 빡셉니다.

AWS CloudFormation

리소스를 정해진 템플릿 문법에 따라 JSON 혹은 YAML로 작성합니다. 이것도 코드라면 코드인데, 역시 매우 Low Level이라서 직접 코딩하기 힘듭니다. 대신 Designer라는 WYSIWYG 편집기가 있어서, 리소스를 배치하고 연결하면 템플릿 언어로 변환해줍니다.

그런데 제가 WYSIWYG를 별로 안 좋아합니다. 그냥 코드로 바로 작성하면 좋겠네요.

Serverless Framework

AWS에서 API Gateway + Lambda 같은 서버리스 아키텍처를 구성할 때 serverless 프레임워크를 사용하면 편리하게 개발하고 배포할 수 있습니다. 다양한 서비스 프로바이더 구현을 제공하는 범용 프레임워크입니다. 그런데 서버리스 아키텍처를 벗어난 부분은 커버하지 못합니다.

서버리스 개발에는 여전히 좋긴 하지만, 풀스택 인프라 구성에는 적절하지 않습니다.

Terraform

테라폼은 이 분야의 강자입니다. HCL(*.tf)이라는 고유 문법을 사용해서 인프라 리소스를 선언합니다. AWS CloudFormation 보다 나은 점은, 조금 더 코딩에 가까워서 비로소 손코딩이 가능한 수준이라는 것입니다. 그리고 테라폼은 AWS 뿐만아니라 GCP, Azure 그리고 기타 클라우드 서비스 제공자의 인프라를 기술할 수 있습니다. 한마디로 범용이지요.

resource "aws_instance" "example" {
  ami = "abc123"

  network_interface {
    # ...
  }
}

아쉬운 점은 여러 서비스 프로바이더를 두루두루 다루다보니 AWS에 특화되지 않았다는 것이고, HCL 문법이 조금 생소하게 느껴집니다. 강력한 타입 검사 기능도 조금 아쉽습니다.

테라폼도 좋았지만, 우리한테 더 좋은게 나왔기 때문에 이제 갈아타려고 합니다.

AWS CDK

멀티 클라우드, 크로스 클라우드(다양한 클라우드 서비스 프로바이더 혼용) 혹은 하이브리드 클라우드(온프레미스 + 클라우드) 아키텍처를 사용하는 회사라면 테라폼을 사용해서 이득을 많이 볼 수 있지만, 보통은 한 회사에서 한 종류의 서비스 프로바이더(예를 들면, AWS)만 이용하는 경우가 많습니다.

AWS를 사용한다면 다가오는 2020년에는 인프라 관리 도구로서 AWS CDK가 유력합니다. CDK의 장점은 AWS에서 직접 개발해서 제공하는 도구이고, 기존 개발자들에게 익숙한 언어(TypeScript, JavaScript, Python, Java, C#)로 제공된다는 점입니다. 특히 TypeScript로 제공되는 CDK는 컴파일-타임 타입 검사를 제공하기 때문에 유지보수성이 좋습니다.

코드를 읽으면 인프라가 어떻게 짜여있는지를 볼 수 있습니다. 또한 코드를 작성할 때, Management Console(GUI)에서 봤던 것과는 다르게, AWS의 인프라 리소스의 부품들이 어떻게 연결되는지를 이해하면서 작성할 수 있습니다. 여기에다가 작성자가 적절한 주석으로 문서화를 하면 아주 훌륭한 인프라 구성 매뉴얼이 됩니다.

테라폼을 사용할 때와 같이 GitHub 저장소에 (혹은 애플리케이션 프로젝트와 같이) 올려놓고 버전 관리를 합니다. 그리고 인프라를 변경할 때는 cdk를 단일 창구로서 변경을 실시합니다. 그러면 인프라 관리가 지리멸렬해지는 것을 방지하고 체계적인 관리를 할 수 있게 됩니다.

그럼 얼른 사용해봅시다.

[실습] cdk 환경 구성하기

AWS에서 지원하는 프로그래밍 언어 플랫폼 중에서 업데이트가 가장 빠른 순서대로 Node.js, Python, Java, C#를 들 수 있습니다. 그중에서 Node.js는 거의 특별 대우를 받는 느낌이 듭니다. Node.js 안에서도, 최근에는 TypeScript의 강세로 SDK 소스코드는 TypeScript로 개발되고 있습니다.

그래서 여기서는 Node.js + TypeScript를 사용합니다.

GitHub의 프로젝트 저장소에 같이 올리든지, 별도의 이름으로 올리든지 하면 됩니다.

시작하기

기본적인 디렉터리 구조는 이렇습니다. (하지만 강제 규정은 없으니 알아서 만들면 됩니다.)

cdk init --language typescript 명령으로 생성할 수 있지만, 존재하지 않는 새 디렉터리에만 만들 수 있으므로 그냥 아래 구조대로 모양을 만들면 됩니다.

\
+- stacks
|  +- (인프라 스택 정의: *.ts 파일)
+- lambdas
|  +- (혹시 AWS Lambda를 사용하게 된다면, 람다 함수를 이렇게 두면 되겠죠?)
+- .env
+- .gitignore
+- cdk.json
+- index.ts
+- package.json
+- tsconfig.json

package.json

2019년 12월 현재 aws-cdk의 최신 버전은 1.18.x입니다. (TypeScript는 3.7.x)

{
  "name": "cdk",
  "version": "0.0.1",
  "dependencies": {
    "@aws-cdk/aws-ec2": "^1.18",
    "@aws-cdk/core": "^1.18",
    "dotenv": "^8.2"
  },
  "devDependencies": {
    "@aws-cdk/assert": "^1.18",
    "@types/node": "^12",
    "aws-cdk": "^1.18",
    "ts-node": "^8.5",
    "typescript": "^3.7"
  }
}

주요 모듈(npm 패키지)에는 aws-cdk, @aws-cdk/...가 있습니다. 여러분의 인프라 스택에 해당하는 AWS 서비스를 자유롭게 추가하시면 됩니다. (예를 들면, @aws-cdk/aws-s3, @aws-cdk/aws-dynamodb) 이때, 버전은 aws-cdk와 같게 유지하면 됩니다.

cdk.json

cdk를 실행할 때 동작을 설정하는 파일입니다. 진입점 파일과 실행 명령, 환경변수 등을 설정할 수 있습니다.

{
  "app": "ts-node ."
}

여기서 .은 package.json의 main 속성에 지정한 파일을 가리킵니다. 설정하지 않으면 디폴트로 package.json이 위치한 디렉터리의 index.ts 파일을 가리킵니다.

ts-node로 index.ts를 실행하도록 하면, ts 소스코드를 js 파일로 컴파일하는 대신, 바로 실행할 수 있습니다.

.env

dotenv 모듈이 읽을 수 있는, 커스텀 환경변수를 설정하는 파일입니다.

CDK_DEPLOY_ACCOUNT=123456789012
CDK_DEPLOY_REGION=ap-northeast-2

CDK 개발자 가이드 - 환경변수

index.ts

cdk의 진입점입니다.

import { App } from '@aws-cdk/core'
import { XXXStack } from './stacks/XXXStack'
import { config } from 'dotenv'

// 환경변수 (.env)
config()

// App 생성 (루트 스택)
const app = new App()

// 스택 추가 (여러 개 가능)
new XXXStack(app, 'stack-id', {
  env: {
    account: process.env.CDK_DEPLOY_ACCOUNT,
    region: process.env.CDK_DEPLOY_REGION,
  },
})

// 실제 인프라와 대조
app.synth()

아래 명령을 실행할 때, 사용됩니다.

# 예비 실행 (작성중인 코드와 실제 AWS에 전개된 리소스와의 차이점 대조)
$ yarn cdk synth

# 리소스 변경 적용
$ yarn cdk deploy

AWS CloudFormation이나 Terraform을 사용해보신 분이라면 이미 잘 아실텐데요,

인프라 관리 도구의 연산은 크게 두 가지입니다.

• 상태 확인(검사, 대조)
• 배포(생성, 업데이트 및 삭제)

그러면 코드로 실제로 인프라 스택을 작성하는 방법을 다음 절에서 알아보겠습니다.

[실습] VPC와 EC2 인스턴스를 포함한 인프라 스택 생성

AWS 서비스에서 가장 기본이 되는 VPC와 EC2 인스턴스를 생성해보겠습니다.

cdk 모듈은 AWS의 각 서비스 마다 @aws-cdk/aws-xxx로 세분화되어 있습니다. VPC와 EC2에 대한 스택을 구성하려면 아래 모듈을 추가하면 됩니다.

• @aws-cdk/aws-ec2

VPC는 따로 분리되어 있지 않고 @aws-cdk/aws-ec2에 포함되어 있습니다. (너무나 밀접해서?)

스택을 표현하는 코드의 뼈대는 아래와 같습니다.

MyStack.ts

import { App, Stack, StackProps } from '@aws-cdk/core'

export class MyStack extends Stack {
  constructor(app: App, id: string, props?: StackProps) {
    super(app, id, props)

    // (여기에 작성)
  }
}

여기서 Stack의 서브 클래스로 선언된 MyStack 클래스가 AWS CloudFormation의 스택 하나와 1:1 대응합니다.

여기에 내용을 추가하겠습니다.

import {
  SecurityGroup,
  Vpc,
  Port,
  AmazonLinuxGeneration,
  AmazonLinuxImage,
  InstanceClass,
  Instance,
  InstanceType,
  InstanceSize,
  SubnetType,
  Peer,
} from '@aws-cdk/aws-ec2'
import { App, Stack, StackProps } from '@aws-cdk/core'

const APP_PORT = 3000

export class MyStack extends Stack {
  constructor(app: App, id: string, props?: StackProps) {
    super(app, id, props)

    // 새 VPC 생성 (+ 해당 Region의 AZ 수만큼 Public/Private 서브넷 쌍 생성)
    const vpc = new Vpc(this, 'vpc')

    // 보안 그룹: Web 그룹
    const sgWeb = new SecurityGroup(this, 'sg-web', { vpc })

    // from: * => to: HTTP 허용
    sgWeb.addIngressRule(Peer.anyIpv4(), Port.tcp(80))
    sgWeb.addIngressRule(Peer.anyIpv6(), Port.tcp(80))

    // 보안 그룹: App 그룹으로 연결을 허용할 그룹
    const sgAppAllowed = new SecurityGroup(this, 'sg-app-allowed', { vpc })
    
    // 보안 그룹: App 그룹
    const sgApp = new SecurityGroup(this, 'sg-app', { vpc })

    // from: sgAppAllowed => to: 3000/tcp 허용
    sgApp.addIngressRule(sgAppAllowed, Port.tcp(APP_PORT))

    // EC2 Instance: web 서버 생성
    const webServer = new Instance(this, 'web-server', {
      instanceType: InstanceType.of(InstanceClass.T2, InstanceSize.MICRO),
      machineImage: new AmazonLinuxImage({
        generation: AmazonLinuxGeneration.AMAZON_LINUX_2,
      }),
      securityGroup: sgAppAllowed,
      vpc,
      vpcSubnets: {
        subnetType: SubnetType.PUBLIC,
      },
    })

    // EC2 Instance: app 서버 생성
    const appServer = new Instance(this, 'app-server', {
      instanceType: InstanceType.of(InstanceClass.M5, InstanceSize.LARGE),
      machineImage: new AmazonLinuxImage({
        generation: AmazonLinuxGeneration.AMAZON_LINUX_2,
      }),
      securityGroup: sgApp,
      vpc,
      vpcSubnets: {
        subnetType: SubnetType.PRIVATE,
      },
    })
  }
}

논리적으로는 AWS CloudFormation, Terraform과 내용이 같지만, 개발자에게 친숙한 프로그래밍 언어로 작성할 수 있다는 점이 장점입니다. 어떤 리소스가 어떻게 구성되었는지를 코드를 읽으면서 파악할 수 있습니다.

그러면 cdk의 synth 명령으로 예비 실행(dry-run) 결과를 살펴보겠습니다.

$ yarn cdk synth

혹시 논리적으로 맞지 않는 코드를 작성하면 오류를 출려합니다.

Error: There is already a Construct with name 'sg-app-allowed' in MyStack [musma-dev]

정상적으로 실행되면 AWS CloudFormation 템플릿을 출력합니다.

Resources:
  vpcA2121C38:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      EnableDnsSupport: true
      InstanceTenancy: default
      Tags:
...

이 템플릿을 Designer에 넣으면 아키텍처 다이어그램을 뽑을 수 있습니다.

실제 적용하려면,

$ yarn cdk deploy

스택을 통째로 제거하려면, (실습하시면서 혹시 만들었다면 필히 다시 제거하십시오. 돈 나갑니다.)

$ yarn cdk destroy

코드가 그리 길지 않았는데도 이렇게 많은 일을 했습니다.

Management Console이나 CLI, CloudFormation으로 똑같이 만드려면 한참 두드려야 하겠네요.

지금까지 보여드린 것은 Hello, World! 수준이었습니다.

나중에 여러분이 AWS 아키텍처에 관해서 공부한 다음에 적절한 @aws-cdk 패키지를 찾아서 생각한 구성을 코드로 옮기시면 됩니다.

2020년부터는 Management Console 그만 보시고, aws-cdk와 함께 Infrastructure as Code를 실천해보시면 어떨까요?

개선할 점

기존에 Terraform을 사용하시던 분들은 지금 당장 aws-cdk로 바꿀 필요는 없습니다. 왜냐하면 GA(Generally Available)된지 얼마 안 되어서 아직 커뮤니티에 널리 익숙해진 기술이 아니기 때문에, 혹시 잘 안 될 때 트러블슈팅을 하느라 애를 먹을 수 있습니다. (예를 들면, AWSKRUG 슬랙 채널에 물어봐도 아무도 답을 안 해준다든지…)

하지만 기존에 마땅한 Infrastructure as Code 프랙티스가 없었던 조직이라면 aws-cdk를 통해 시작해봐도 괜찮을 것 같습니다. 그리고 스스로 트러블슈팅 하실 수 있으면 문제 없을 것 같습니다.

당연하지만, AWS에서도 이제 제법 쓸만하다고 생각해서 GA로 발표한 것입니다.

실천 사항

AWS를 사용하는 회사라면, Infrastructure as Code와 함께 aws-cdk를 사용하는 것이 좋은 선택이 될 것으로 기대합니다. 우리 무스마부터 그렇게 해보겠습니다.

지금은 AWS 서울 리전(ap-northeast2)을 주로 사용하고 있는데요. AWS는 리전마다 VPC 5개, EIP 5개 등등 기본 제한이 있습니다. 그래서 VPC 하나는 Production 용으로 Multi-AZ 고가용성 설정을 하고 (서울 리전의 AZ가 3개이므로 NAT Gateway에 EIP 3개 소모), 또 하나는 Development 용으로 단일 AZ에 NAT Gateway 하나 (EIP 1개 소모)를 설정하면 VPC 2개, EIP 4개를 써서 스타트업 클라우드 환경 기본 세팅(?)을 하려고 합니다. 기존에 Management Console에서 만든 흩어진 리소스를 줏어담아 정리하고, cdk 기반으로 인프라를 다시 구성해야 겠네요.

그렇게 2019년을 마무리하고 2020년에는 aws-cdk와 함께 깔끔하게 시작해야겠습니다.

감사합니다.

References

• AWS Cloud Development Kit(AWS CDK), 이제 정식 버전 사용 가능
• AWS Cloud Development Kit (CDK) – TypeScript and Python are Now Generally Available
• AWS 클라우드 개발 키트 - 익숙한 프로그래밍 언어를 사용하여 클라우드 인프라 정의
• Will AWS CDK replace Terraform and the Serverless Framework?