本記事はわた推し～AWSアワードエンジニア編～ 6日目の記事です。
💻 5日目 ▶▶ 本記事 ▶▶ 7日目 💻

こんにちは、TikTokで足元にお手元芸人の動画をつい見ちゃう志水です。

2021年に続き2022年もAPN ALL AWS Certifications Engineersに選出されました。2021年に選ばれていたAPN AWS Top Engineerは今年落選しちゃったので来年こそは選ばれるよう精進します。
NRIネットコム、2022 Japan APN Ambassadors / Top Engineers / ALL Certificate Engineersによるわた推しシリーズの6日目です。

私が紹介するのはAWS Cloud Development Kit (CDK) です。1週目の人たちは推しサービスの癖が強かったので、この記事でなんとかバランスをとっていこうとおもいます。（AWS DataSyncにしなくて良かった）

CDKとは

まずはCDKについて説明していきます。CDKとは プログラミング言語でAWSリソースをコード化してプロビジョニングするツール です。この「コード化してプロビジョニングするツール」という部分はInfrastructure as Code(IaC)のことで、CDKはIaCツールの一種です。IaCは他にもCloudFormationやTerraform、Pulumiなどがあります。

IaCについての説明は、去年のTop Engineersウィークの時に書いたArchitecture as Codeってなぁに？〜Infrastructure as Codeを超えて〜という記事を見て頂ければ幸いです。

AWSリソースをプロビジョニングするツールとしてデファクトスタンダードなのはCloudFormationです。しかし、リソースの設定をyamlやjsonで記述することになり、コードが多くなると非常に見づらいです。 ~~あと、あんなの人が書くもんじゃないです。~~ このツラミを解消してくれるのが、CDKです。CloudFormationと比べてコード量が少なくてコードの流れも分かりやすいので、まじ天使です。

CDKの推しポイント

ということで、CDKの推しポイントを挙げていきます。

書いてて楽しい

まずはCDKはそもそも書くのが楽しいです。皆さんどうですか？　json書いてて楽しいですか？　僕は書くとなった途端目が死んだ魚のようになります。やっぱりコード書くのって楽しいんだなぁと思いました。また、テストもCDKで利用した言語のテストフレームワークを使って書くので、これもまた楽しいです。個人的にはテストコードを書くほうが好きです。

例えが良いかは分かりませんが、CDKを初めて知った時にCDKとCloudFormationの関係が、プログラミング言語のPythonとC++の関係に思えました。C++で苦しみながら書いていて、Pythonを知った時に「何これめっちゃシンプルに書けるやん！」とすごく嬉しくなってコードを書きなぐってた覚えがあります。それがCDKを知った時も同じように「こんなにシンプルに書けるんだ！おっしゃれー！」と思ってコードを書きなぐっていました。自然とコードを書くのが楽しくなっちゃってました。

結局仕事や育児など、何でも楽しむことが出来れば長く続くし何でも出来ます。楽しくないと苦行になるので続かないです。やっぱり楽しいことをしていきたいですね。

ベスプラで構築

VPCを作るのって大変ですよね。サブネット作ったり、ルーティング設定したり、ゲートウェイ作ったり。なので出来るだけVPCを使わないサーバレスな構成を取りたいんですが、もちろんそんな事はできずにコンテナやサーバの構成の場合も多くあります。そういう時はCDKを使いましょう。CDKではVPCのベストプラクティス（ベスプラ）に沿った構成を一発で作ってくれます。

例えばEC2を作成してセキュリティグループを設定するケースを考えます。CDKで行うと下記のようなコードになります。

vpc = ec2.Vpc(self, "OshiVpc")
my_security_group = ec2.SecurityGroup(self, "SecurityGroup",
    vpc=vpc,
    description="Enable SSH access via port 22",
    allow_all_outbound=True
)
my_security_group.add_ingress_rule(
  ec2.Peer.ipv4("1.2.3.4/32"), 
  ec2.Port.tcp(22), 
  "allow ssh"
)

my_instance = ec2.Instance(self, "Instance1",
    vpc=vpc,
    instance_type=ec2.InstanceType("t3.small"),
    machine_image=ec2.AmazonLinuxImage(),
    security_group=my_security_group
)

ec2.Vpc(self, "OshiVpc") の一行を入れるだけで2サブネットx2AZのVPC環境が作成できるので上記コードをデプロイすると下記構成が作られます。

もちろんベスプラに沿わないカスタマイズも可能で、AZを3つに増やしたい場合は ec2.Vpc(self, "OshiVpc", max_azs=3) と設定すれば可能です。他にもCIDRを 10.100.0.0/24 、NAT Gatewayを1つにしたい場合は、 ec2.Vpc(self, "OshiVpc", cidr="10.100.0.0/24", nat_gateways=1) で可能です。

IAMについて本気出して考えなくて良い

AWS Well-Architected フレームワークは、AWSでシステム構築をするときの設計や運用のベストプラクティス集になります。そのAWS Well-Architected フレームワークの6つある柱のうちの一つであるセキュリティの柱を見ると、権限管理において最小権限のアクセスを付与するべきと書かれています。つまり、ベストプラクティスに沿うと、IAMの権限は最小にする必要があります。

そこで、IAMの最小権限について本気出して考えてみたらどうでしょうか。対象のリソースの選定や必要なポリシーの洗い出しなど、色々と考えることが出てきてしんどいです。歌は良いですけどね。また、ポリシーはjsonで記述する必要があり、また目を死んだ魚にする必要があります。そのため、IAMを最小権限に出来てないケースも多くあるんじゃないかと思います。

これをCDKでは簡単に実装が可能です。例えば下記の図のようにLambdaからS3の読み込みを行う例を考えます。

この例だとLambdaからS3の読み込みを許可する必要があります。それをCDKコードでそれぞれのリソースを作成するところから表現すると下記のようになります。

oshi_bucket = s3.Bucket(self, "OshiBucket")
oshi_lambda = lambda_.Function(self, "OshiFunction",
    runtime=lambda_.Runtime.PYTHON_3_9,
    handler="index.handler",
    code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
)

oshi_bucket.grant_read(oshi_lambda)

oshi_bucket.grant_read(oshi_lambda) だけで対象リソースのみに制限できていて、最小権限の設定になっています。また、コードを見るだけで大体どのような権限が出来るかも推測しやすいです。

推せないIAMについて本気出さなくても良いCDK。良き。

見やすい（コード・差分）

先程のoshi_bucket.grant_read(oshi_lambda) を見るだけで、おおよそどのような権限が出来るかもコードから推測しやすいです。

実際には、PrincipalにLambdaが指定され、対象のリソースが oshi_bucket とその配下のディレクトリになり、Bucket*/Object*/List* のS3権限が付与されます。この権限をCloudFormationで表現すると79行になりますが、CDKだとそれが1行で表現されて非常に見やすいです。

また、CDKコードだけでなくテストコードも合わせて書く事になります。なので、CDKコードを見て分かりにくければテストコードを見ることで何をしているかもより分かりやすくなります。CDKのコードも見やすいし、テストコードでコードの解説もされてるので更に理解が進みます。もうCDKのビジュ最高ですね。

また、コードだけでなくスタックの差分も見やすいです。これ以上見やすくなって大丈夫ですか？　先程のS3とLambdaのコードをスタックの差分を取ると、下記のように出力されます。

一番下のAWSリソースの差分だけでも見やすいですが、更にIAMの細かい差分が上のように見ることができます。ここがCloudFormationやTerraformとの決定的な違いだと思っています。もうIAMのjsonやHCLを見なくても良いんです。

またIAMと同様に、Security Groupの差分もいい感じに出してくれます。ベスプラの説明時に利用したコードを利用した時の差分が下記になります。

こちらもリソースの追加だけでなく、個々のルールについての差分が表示されて見やすいです。運用でSecurity Groupの修正が頻繁に行われるケースがよくあるのではないでしょうか。そのような運用では、CDKを利用することで、差分も理解しやすくなり、更にコードとしてトレース可能になるため、非常にマッチするのでオススメです。