プロジェクトでAPI Gatewayを使っていて、手軽にエンドポイントやらバックエンドをつけたりをコンソールUIからポチポチできて便利なんだけど、ある一定数のエンドポイントやメソッドを超えてくると管理がとても煩雑になりがちで、特に各人がいきなり追加したエンドポイントやインテグレーションが管理しきれなくなるケースに遭遇し始めた。これによって、どの定義がイキなのか、使っていないのかが判別できず困るので、YAMLで定義したものを正として冪等にリソースやインテグレーションを管理するツールを書いた。
これは何
API Gatewayのリソース・インテグレーション管理ツール。YAMLの構造に従って定義を書くことで、同期先のAPI Gatewayのエンドポイント定義、インテグレーション、メソッドリクエスト、メソッドレスポンスを冪等に管理する。よって、このファイルに定義の無いものは同期する際に落としてしまうので、常にYAMLの定義を正とすることができる。
さらに、メソッドリクエストのHTTPヘッダマッピングなどは都度ポチポチ設定するのも本当に面倒な作業なので、これらも全て一元化してつけたり外したりできるようにした。現在使っているプロジェクトではHTTPヘッダマッピングは10個くらいあったり、レスポンスのパターンもそれぞれ6個くらいあるけど、定義を書くだけですべてのエンドポイントに等しく設定が入るので、CIからこのツールでデプロイすることでAPIGatewayの設定を一元化した（逆にコンソールUIからの追加は禁止としている）。
Lambda統合はもちろん、{proxy+} なリソースやカスタムオーソライザー、VPC Link、HTTPプロキシに対応しているので、バックエンドとの統合も定義ベースで管理される。
Lambdaは実行権限（addPermission）も自動で付与される。
使い方
全ての設定パターンを書ききれてないけど、README.md を見てください。 やや業務固有のオプションがあったりするけど誰にとっても便利だと思うのでそのままにしている。
CLIからもぱぱっと実行できるが、nodeのスクリプトからだとより詳細な実行設定が可能。
dry-run
APIGatewayはdeploymentに対しては履歴があるので問題があった場合には前のdeploymentに切り戻すことができるが、 リソース自体は巻き戻らない。 これは結構使いづらくて、設定を入れて問題があった場合、前の設定が見られない。なので、このツールでは dry-run の仕組みを入れて、実行前にどのリソースがどういう変更になるかを確認することができるようにした。内部ではAPI Gateway上のリソースとローカルのYAML定義を比較して、差分を検出していく方式（追加 or 更新）にしている。
新規作成の場合は createXXX で作成し、更新の場合は patchOperation のパラメータを自動生成して適用する。
実行時間
このツールのプロトタイプは半年前くらいに作ってそれを運用していたけど、その時はフルビルドだったので、リソースが増えてくると普通に30分くらい、かつAWS APIのRate limitに引っかかったりでだんだんとDXが下がってきてて辛かった。なので差分更新で実装しなおしたところ、だいたい5分くらいに短縮された（そもそも一度作ったリソースはそうそう変更にならないので）。
まとめ
API GatewayってLambdaのGateway程度にしか使われない印象だけど、どれくらい使われてるんだろう？そもそも API Gatewayなので使い方間違ってるんじゃないか、というのもある、、、。
現場からは以上です。