過去の自分にAWS CDKを勧めてみる。

はじめに

以下の続きです。

最近転職してからCDKにデビューしました。

前職では、元々CloudFormationを採用していたこと、Javaが主言語でTypeScriptを導入していないことから採用をしていませんでした。

過去の自分のCDKの認識はyaml/jsonではなく、プログラム言語でIaCができる、くらいの薄すぎる認識でしたが、抽象度の高さ等々のメリットに感激しているので、今更ですがCDKの紹介記事です。

CDKを避けていた、半年前の自分に向けての記事です。

作ったもの

以下環境のAWS部分をCDKで構築してみました。

ソースは以下です。

以前は、Chrome拡張ツールのみでしたが、モノレポ化し、packages/cdkに格納しています。

AWS CDKとは？

AWS CDKについてはAWS Blackbeltを見るのが分かりやすいです。

触ったことがない方はまずはこの資料、動画を見てみることをお勧めします！

感じたメリット

CDKのメリットは、やはりプログラミング言語のメリットを最大に享受できることかな、と感じました。

実際に触ってみて、私が感じたメリットをいくつか紹介します。

アプリと同じ言語でリソースを定義できる

yaml/JSONの文法、CloudFormation固有の記載を使った処理分岐(!Equals、!If)などを覚える必要がありません。

cdk initコマンドでテンプレートは作ってくれるので、そこに書き慣れた言語で追記していく形です。

特にTypeScriptを採用している場合、IaCからフロント、バックエンドすべての領域でプログラミング言語をTypeScriptに統一することができるのはメリットが大きいですね。

オブジェクト指向等、プログラム言語のメリットを享受できる

CDKがTypeScript、Python、Java等、６つの言語を利用することがきますが、それぞれの言語の良い点をそのまま享受できます。

CloudFormationだと、リソース定義を細かく列挙していくことになりますが、CDKの場合、適切なモジュール化、カプセル化、抽象化など可読性の良いコードでリソース定義することができます。

高い抽象度

特に抽象化の部分に関しては、LambdaにS3読取り権限を付与する例がわかりやすいです。

CloudFormationだとこれくらいかかる記載が、

CloudFormation

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-bucket

  MyLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole

  MyLambdaPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: S3ReadPolicy
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - s3:GetObject
              - s3:GetObjectVersion
            Resource:
              - !Sub '${MyBucket.Arn}/*'
          - Effect: Allow
            Action:
              - s3:ListBucket
            Resource:
              - !GetAtt MyBucket.Arn
      Roles:
        - !Ref MyLambdaRole

  MyLambda:
    Type: AWS::Lambda::Function
    Properties:
      Role: !GetAtt MyLambdaRole.Arn
      # ...

CDKだと3行で済みます！

CDK

const bucket = new s3.Bucket(this, "MyBucket");
const myFunction = new lambda.Function(this, "MyLambda", { /* ... */ });

bucket.grantRead(myFunction);

アプローチが手続型ではなく、宣言型なんですね。

App/Stage/Constructの概念

プログラム言語のメリットに加え、CDKの構成も分かりやすいなと感じました。

CloudFormationにはStackという概念がありましたが、CDKはStackを束ねたApp、Dev/Stg/Prod等のStageなどの概念があり、インフラ環境が大きくなっても管理しやすい仕組みが導入されています。

（引用元：上記Blackbelt）

また、単一または複数のリソースである、Constructは抽象化レベルに応じて３段階存在し、一般的な構成であるほど抽象度高く、ローコードでリソースを定義することが可能です。

（引用元：上記Blackbelt）

変更が検知しやすい

採用するプログラム言語に沿った単体テストが実施できます。

メソッドのOutputに対する単体テストや、CloudFormationテンプレートレベルでの差分をチェックするスナップショットテストなどが用意されており、デプロイが既存リソースに与える影響を把握しやすいです。

例えばスナップショットテストで作成されるCloudFormationのテンプレートをプルリクに含めることにより、CDKソースだけではなく、そのCDKソースが既存リソースにどのような影響があるかまでをレビューすることができます。

まとめ

ということで、CDKの紹介とメリットをまとめてみました。

CDKにはまだまだ私が享受できていないOSS等のメリットがあると思います！

ただ、メリットの反面、コードを自由に書けてしまうのでコミュニティなどを活用し、ベストプラクティスを抑えておく必要はあるかなと感じました。

現職の有識者の方に教えていただきましたが、以下の資料や、過去のCDK Conferenceの登壇を見ておくと良さそうです。

・・・半年前の自分どうでしょう？導入したくなりません？