AWS CDK ハマるかもしれないポイントメモ
リソースとオブジェクトが紐付いてるので，new Hoge() するとリソースが新しく作られてしまう
既存リソースを使うときは Hoge.fromHogeAttributes() を使う
実は Hoge.fromHogeArn() とか Hoge.fromHogeName() は非推奨らしい
それっぽさはある
デプロイ失敗時は cdk destroy で消す
そのままやるとStack Nameがかぶって失敗する
Stackのコンストラクタに渡すidがstack nameになるため
ここを変えて毎回deployするのも手間なのでおとなしく消そう
cdk destroyしても消えないものもある
Log Groupとか
消えても困るので当然の挙動だが試行錯誤のじゃまになることも
Log Groupとかバックアップとかはライフサイクルがサービスとかと異なるので，別Stackにまとめておくべき
こうすれば試行錯誤のじゃまにならない
Stack同士のデータのやりとりは，クラスにプロパティはやしたり，コンストラクタのprops の型をStackProps をextendsしたinterfaceで置き換えてやればいい
あくまでOutputとImportValueを使った形のCFnに翻訳されることに注意
Fn.selectを使おうとすると Template format error: The Value field of every Outputs member must evaluate to a String.で落ちる
stringの配列のoutputへの変換がうまくいかないっぽい？
バグ報告されてるが放置されてる
CfnOutput内ではselectもjoinもうまく動くので，Outputを作ってImportValueで読み込む作業を手で実装すれば回避できる
joinしてexportしてimportしたやつをsplitするいつものやつ
stack間に引数に現れない暗黙の依存関係ができるので，addDependencyをするのを忘れずに
これをやると後述のExportの名前を変えると死ぬ現象が起きがちに
デフォルトだとPublicのSubnetもNAT Gatewayが作成されるので，natGateway で数を指定することで数を抑える必要がある
タグ付は node: ConstructNode が大体プロパティにあるのでそこから hoge.node.applyAspect("new Tag("Name", "fuga"))みたいな感じでやる
ecs-patternsは実はALBのSecurityGroupを作ってる
ALBのSecurityGroupは上記のFn.select のバグのせいで参照できない
ALBのSecurity Groupを参照したい場合は自前でALBをつくてそれに自前で作ったSecurity Groupをアタッチするのが良さげ
Export hoge cannot be deleted as it is in use by Fugaで死ぬ
Stack間のリソース共有はExport/ImportValueで行われているので，後続のstackが使うExportNameが変わるのを検出してエラーを吐く
しかし，後続のstackが使うか否かは前のstackのテンプレートから判断するので名前変更とかだと問題なにのdeployできない
解決策として，名前がないと言われてるhoge のExportNameを持つOutputをCfnOutputで作って問題なくなったら消す
valueが前と違うとまた怒られるのでそっくりそのままのものを作ろう
SecurityGroupとか場合によってはどうしようもなくなって全部消す必要が出てくることもある
CfnのgetAttrを使った結果がListの場合，string[]とはならない場合がある
Token.asList を使って string[]に変換できる
Hoge already exists in stack と言われて死ぬ
リソースを別Stackに移したりすると名前が重複してこれが起きる
Cloudformationがterraformみたいに賢くリソースをアップデートしてくれないため
移動元のStackを消して移動元のStackを更新，移動させて移動先のStackを更新と二段階に分ける必要がある
場合によっては失敗する(参照元のリソースがないとかいわれる)のでその場合潔く関連してるものを全部消してやり直すしか無い
Security Groupの定義はaplication stackで行う
ライフサイクル的に
アプリケーション固有の値(e.g. port番号)とかも利用する必要がある
アプリケーションやデータストアなどの依存関係がある場合はIConnectable なサービスをconstructorのpropsとして渡してやる
IConnectable のインスタンス同士はhoge.connections.allowFrom などであとからRuleを設定できる
Security Groupに addIgressRule とかするよりも，hoge.connections.allowTo などを使ってサービスとポートを指定するのがよさげ
各サービスごとに絞ったSecurity Groupを設定して，通信の関係をServiceのstackで定義できる
だいたいのServiceは IConnectionのインスタンスになってるので上記ができる
いざとなったらCFnのstackをコンソールから直接消す
設定ミスなどで度々deployやdestroyが取り返しのつかない失敗をするので
コンソールから消してcdk destroy する
CodeCommitとCodeBuild(CodePipeline)のstackを分けると死ぬ
sourceの検出にEVENT を使ってるとCloudWatchの設定必要で暗黙のCodeBuild -> CodeCommitの依存関係ができている
この状態でCodeCommitからrepositoryとか持ってくると循環依存になって死ぬ
sourceのtriggerをPOLEにするか，依存関係を手動で構築してやる
循環依存してないのに循環依存だと言われて死ぬ
上記のCodeCommitとCodeBuildの例のように暗黙に循環依存していることがある
Stackのコンストラクタに渡した値が使われていないと循環依存していると言われることがある
は？？？
create-service-specific-credentialはCDKで使えない
必要がないからかもしれないが，CodeCommit用のユーザー作成とかを手でやらないといけないのは辛いところ
aws sdkを使えばできるので局所的に使ってCustom Resoucesを作るのも手
CodeBuildのsubnetの設定はPipelineProjectにある
CFnではサポートしてるがCDKではConstructがないリソースがある
CognitoのIdentity Poolとか
L1のCFn直接生成するやつらが使えるので，用途に合わせたConstructを自前で作る必要がある
ECSのServiceにアタッチするSecurityGroupはEgressの443を許可する
CDKというかFargateのハマリポイント
ECRからコンテナとってこれない
一応IPの範囲は決められる
aws-ecs-patternsで生成されるdefaultのSecurity Groupはegressがガバガバなので注意する
443と使うポートだけ開けとけばなんとかなる
ALBとDatabaseとの通信
aws-ecs-patternsの ApplicationLoadBalancedService の