前置き

社内 LT で AWS CDK の概要を紹介したので Qiita に焼き増しします。
なお筆者は CDK 歴が浅いです。何かあれば指摘いただけますと勉強になります。

テーマ

AWS CDK はどこから来たのか
AWS CDK は何者か
AWS CDK はどこへ行くのか

AWS CDK はどこから来たのか

インフラの歴史

インフラ管理の歴史を振り返ってみるとざっくり二分できます。

秘伝のタレ時代
IaC 時代

秘伝のタレ時代

秘伝のタレ(エクセル等で管理された手順書) に誰しも一度は遭遇したことがあるでしょう。
コマンドを1つずつ手で流していき、ダブルチェックなんかもやっていきます。
今や歴史上の存在だと思いたいところですが今もどこかで継ぎ足されています。

IaC 時代

秘伝のタレでは管理が大変だということで IaC が登場します。
スローガンは「インフラをコードで宣言的に定義しよう」です。

代表的な IaC のツール
- 構成管理：Ansible、Chef
- クラウド：CloudFormation、Terraform

IaC の登場で世界はより良くなりました

バージョン管理できる
冪等性を担保できる

CDK 現る...

IaC は YAML や HCL 等の独自フォーマットで書かれます。
この多くは設定項目を列挙して記述しますがこれに満足できない人達がいました。

”インフラをもっとオブジェクト指向っぽくできないか”

AWS の Elad Ben-Israel 氏率いるチームはこう感じました。彼らはサービスのリアーキテクトを進めていましたが、YAML や JSON は「システムを説明する」のに適したアプローチではないと感じ CDK の開発に至ります。

↑ に詳しい経緯が書かれています。

AWS CDK は何者か

すごく雑ですが「SDK のクラウド版」と言えばイメージが湧きやすいかもしれません。

特徴はインフラを使い慣れた言語で書ける点です。
JavaScript、TypeScript、Python、Java、C#、Go に対応しています¹。

裏側では CloudFormation のテンプレートが生成されます。

サンプルコードで比較

Terraform と AWS CDK で同じ内容のコードを比較してみます。
やっているのは Role と Policy を作成してアタッチするだけです。

Terrafrom では Role, Policy, Attachment を個別のリソースとして定義しています。

sample.tf

resource "aws_iam_role" "sample_role" {
  name               = "Sample"
}

resource "aws_iam_policy" "sample_permissions" {
  name        = "Sample"
  policy      = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeVpcs",
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
EOF
}

resource "aws_iam_role_policy_attachment" "sample_policy_attach" {
  role       = aws_iam_role.sample_role.name
  policy_arn = aws_iam_policy.sample_permissions.arn
}

対して AWS CDK では Role のメソッドを呼び出して Policy を引数で受け付けています。

sample.ts

const SampleRole = new iam.Role(this, 'Sample', {});

const SamplePermissions = new iam.Policy(this, 'Sample', {
  document: iam.PolicyDocument.fromJson({
    Version: '2012-10-17',
    Statement: [
      {
        Action: [
          'ec2:DescribeVpcs',
        ],
        Effect: 'Allow',
        Resource: '*',
      },
    ],
  }),
});

SampleRole.attachInlinePolicy(SamplePermissions);

両者を見比べると AWS CDK の方がなんとなく動きのあるコードに見えます。
Role が Policy を受けるメソッドを持つのが直感的で理解しやすいです。

このコードでは表現できていませんが CDK は「抽象化されたリソース」を定義できるのが大きな特徴です。

CDKはどこへ行くのか

個人的結論

強い動機がない限りは CDK じゃなくてもよいかと思います。

既に CloudFormation や Terraform を活用している
- そのままでいい
新規でサービス構築する
- 選択肢に入る
  - アプリ&インフラを同じ言語で作りたい
  - CDK の柔軟性、抽象化をうまく活用したい

"CD系"

Terraform と K8s には AWS CDK にインスパイアされたツールがあります。

CDKTF
CDK8s (CDK8s+)

AWS CDK のコンセプトを受け継いでおり抽象化されたリソースを利用できます。
まだ導入事例は少ないですが注目していきたいです。

ちなみに、CDKTF や CDK8s を "CD系" と呼ぶことを流行らせたいと思っています。
ぜひご協力お願いします。

2023/3/12 時点の対応言語です。最新状況は https://aws.amazon.com/jp/cdk/faqs/ よりご確認ください。 ↩

CDKはどこから来たのか CDKは何者か CDKはどこへ行くのか

前置き

テーマ