はじめに とあるお客様先の環境で、数十システムをAWSアカウント１つで運用してまして、複数アカウントに分ける事になりました。 「マルチアカウントするならControl Towerでしょ」って気がしませんか？ でも検証・調査した結果、不採用としました。 ざっくりまとめ Control Towerがカバーする範囲が不明確 たぶん一番とっつきにくいであろうAWS SSO設定をやってくれない 分かり辛い部分が増えるのを上回るメリットを感じない 筆者（私）について マルチアカウント環境を自分で作るのは初めてで、「Control Tower使ってなかった時はこうだったのにー」という話はできないのでご了承ください。 役割 普段は特定システムのAWS環境の設計構築がメインですが、今の案件ではシステムをまたいだ全体的な改善対応をしてまして、技術的な方針決め・共通部分の実装が主な役割です。 アカウント分離もそ

はじめに 基本的にAWSエンジニアとして仕事していて、Azureは未経験でしたが案件で採用されて触れる事になりました。 Azure Functionsで処理する所があって私に一任という感じだったのですが、まぁAWS Lambdaみたいなもんでしょと（恐らく他の人も）思ってました。 それがこんな事になろうとは… 必要なリソースが多い まず戸惑ったのがこれです。 関数を書くまでに以下のリソースが必要です。 Azure Functionsのインスタンス（という表現が正確か不明ですが。） Lambdaと違って１つのインスタンスに複数の関数を乗せる形になります（１つ１つ作ってもいいですが…） プラン 料金プランの事だと思えば良いかと。なんですが、プランも１つのリソースなんです。。 Azure Storage アカウント コードや一部の設定情報などが保存されています。 Application Insi