ここまできて反省です。そもそもどういう動きをするのか、ちゃんとドキュメントを読めよという話ですよね。CLIとかSDKを扱うときに設定が必要なはずなので、こういうのをちゃんと読んで調べておけよという当たり前の反省がまず1つ。こちらが今回の本題なのですが、妥協せずテスト用の環境を作って試すべきだった。これは本当に反省していて、「テスト環境ができるまでどれぐらいかかるかな」「この設定変更だけで1週間か......うーん、うーん」となって諦めてしまいました。テスト環境ですが、実際に作るのはWebサーバ、DBサーバ、キャッシュ、S3、全部ゼロから作れと言われると、やっぱりめげちゃうわけですね。いう時のためにちゃんとコード化しなさいと言われると「そうだな」しか言えなくて、本当すみませんでしたって感じです。このネットワークの何がダメだったのか最後にまとめです。このネットワークの何がダメだったか。デフォルトのVPCとデフォルトtのSubnetを使用する場合、開発環境・staging環境・本番環境が同じネットワークに乗ってしまうわけですね。その時点でセキュリティ的にも設定変更に対する影響度的にも良くないわけです。別の視点から見てみると、ロードバランサーとWebサーバとデータベースが同じレイヤーにいるんですよ。これもアクセス保護やデータ保護の観点から良くないです。今回私がやらかしてしまったように、この各環境が同一のネットワークでは、例えば開発環境で設定変更をしましたと言ってて、実は本番環境にも影響していたという事が起こり得ます。開発環境だけ、staging環境だけといったテストがしづらい。ネットワーク部分の設定変更が難しいですね。開発環境がハッキング、乗っ取られてしまったら、他の環境にも入られてしまう可能性があります。