今日は、CDK(Python)APIの「Cfn」の違いについての日。

目次

とある日

CDK(Python)で開発を行っていて気になったBucketとCfnBucketの違いについてまとめました。

はじめに

想定読者

CDK(Python)で開発を初めた方。

注意事項

この記事では、CDKのPythonについてのみ言及します。

他の言語も同様の仕様なのかについては言及しません。

高レベルのコンストラクトについては、言及しません。

結論

AWSコンストラクトライブラリ

Cfnがついているものとついていないものの違いは、抽象レベルが違う。

CDKで開発を行うなら、Cfnがついていないものを使うのが楽だと思います。

理由はそれぞれの違いとしてデフォルト値があるかないかです。

Cfnリソースを使用する場合は、すべてのリソースプロパティを明示的に設定する必要があります。

CFNリソース構造を使用して自分で作成するデフォルト、ボイラープレート、およびグルーロジックを提供します。

aws_cdk.aws_s3.CfnBucket

このライブラリには、CFNリソース（または「レベル1」の略）またはCfn（CloudFormationの略）リソースと呼ばれる低レベルの構成から始まる、3つの異なるレベルの構成があります。これらのコンストラクトは、AWSCloudFormationで利用可能なすべてのリソースを直接表します。CFNリソースは、AWSCloudFormationリソース仕様から定期的に生成されます。彼らの名前はCFNエクシーズ、XYZはリソースの名前です。たとえば、CfnBucketはAWS :: S3 :: Bucket AWSCloudFormationリソース。Cfnリソースを使用する場合は、すべてのリソースプロパティを明示的に設定する必要があります。これには、基盤となるAWSCloudFormationリソースモデルの詳細を完全に理解する必要があります。

aws_cdk.aws_s3.Bucket

次のレベルのコンストラクトであるL2もAWSリソースを表しますが、より高いレベルのインテントベースのAPIを備えています。これらは同様の機能を提供しますが、CFNリソース構造を使用して自分で作成するデフォルト、ボイラープレート、およびグルーロジックを提供します。AWSコンストラクトは便利なデフォルトを提供し、それらが表すAWSリソースに関するすべての詳細を知る必要性を減らし、リソースの操作を簡単にする便利なメソッドを提供します。たとえば、s3.Bucketクラスは、バケットにライフサイクルルールを追加するbucket.addLifeCycleRule（）などの追加のプロパティとメソッドを持つAmazonS3バケットを表します。

詳細

上記で述べた結論をもっと詳しく解説します。

CFNリソース（または「L1コンストラクト」）

APIのリファレンスを見ると、AWS::S3::Bucket.AnalyticsConfigurations.

CloudFormationの記述があります。

それぞれのアトリビュートが、CloudFormationの記述と対を成しています。

Parameters - scope (Construct) scope in which this resource is defined. - id (str) scoped id of the resource. - accelerate_configuration (Union[AccelerateConfigurationProperty, IResolvable, None]) – AWS::S3::Bucket.AccelerateConfiguration. - access_control (Optional[str]) – AWS::S3::Bucket.AccessControl. - analytics_configurations (Union[IResolvable, Sequence[Union[IResolvable, AnalyticsConfigurationProperty]], None]) – AWS::S3::Bucket.AnalyticsConfigurations.

使用用途

dev.classmethod.jp

一応上記の記事みたいな、CloudFormationとCDKとの変換も行える様になっているので既存のCloudFormationを統合したい場合とかにも使えるようです。

bucket = s3.CfnBucket(self, "MyBucket", bucket_name="MyBucket")

CloudFormationで記述したい場合に使うことになると思われる。

L1コンストラクトは、AWS CloudFormationによって定義されたリソースとまったく同じであり、それ以上でもそれ以下でもありません。リソースに必要な構成を自分で提供する必要があります。

おそらく、CloudFormationからCDKへのAPIのコンストラクトレベルを一気に上げるのが大変なので、Cfnの低レベルのコンストラクトを作成して提供しているのだと思われます。

APIによっては、Cfnは安定版としてリリースされているが、それ以上のコンストラクトレベルのものは安定版ではなかったりするので、新しいサービスをCDKで使う場合は、Cfnを使うことが多くなると思います。

L2コンストラクト

L1コンストラクトと違って、メソッドやプロパティを使用してリソースの構成を変更します。

S3のバケットポリシーを変更したい場合とかは該当するメソッドを呼び出すかインスタンス化する際にアトリビュートに指定する。

コンストラクトとの相互作用

コンストラクトは、基本のコンストラクトクラスを拡張するクラスです。コンストラクトをインスタンス化した後、コンストラクトオブジェクトは、コンストラクトと対話し、システムの他の部分への参照として渡すことを可能にする一連のメソッドとプロパティを公開します。AWS CDKフレームワークは、コンストラクトのAPIに制限を設けていません。作成者は、必要なAPIを定義できます。ただし、AWSコンストラクトライブラリに含まれているAWSコンストラクト（次のような）s3.Bucket、すべてのAWSリソースで一貫したエクスペリエンスを提供するために、ガイドラインと一般的なパターンに従ってください。

使用用途

基本的に、CDKの開発はこのL2コンストラクト（Cfnがつかないクラス）を使用して行うと思います。

少なくとも自分は、そうしています。

ただ、色々とパラメータを指定するとなると、階層が多くなったりするでちょっと大変です。

from aws_cdk import aws_s3 as s3

# "self" is HelloCdkStack
s3.Bucket(self, "MyFirstBucket", versioned=True)
raw_data = s3.Bucket(self, 'raw-data')
data_science = iam.Group(self, 'data-science')
raw_data.grant_read(data_science)

〆

なにかの記事で、レベルが違うのは見たけど具体的にどう変わるかがきになって調べてみました。

調べてもなかなか記事がなくて、一次ソース探すのも一苦労した。