クラウド移行のパターン

• relocate: オンプレで稼働しているシステムをそのままクラウドへ=VMWare Cloud on AWSとか
• rehost: オンプレミスVMをクラウドVMへ
• replatform
• refactoring: コンテナ・PaaSの最大限活用
• repurchase: SaaS活用
• retain: オンプレにシステム残す > L2使いたいとか
• retire: システムそのものをなくす > L2使いたいとか

Well-Architected Toolで自分たちの環境を評価する。その結果が大事なのではなくて、定期的に環境を評価していく営みを作ることが大事。対応できるできないの判断もあるし。

Auto Scalingを利用すると、載っているアプリケーションのライセンス体系によってはライセンス違反になってアプリケーションが立ち上がらない可能性もあるのか。

EDoS攻撃：Auto Scalingとか、呼び出し回数で従量課金の仕組みを利用して負荷をかけることによって経済的に負担を強いること

VPC間のつなぎ方

• VPCピアリング = VNET Peering。ほぼ一緒。非推移的。接続するVPCが少数の場合にはよいが、フルメッシュで繋ごうとするとVPC数によってはだいぶ煩雑になる。
• AWS Transit Gateway
  • VPC同士を接続するネットワークハブ機能を提供している
  • これってAzureにあったっけ？なさそう
  • 多数のVPCが接続する場合にはVPC同士を相互に接続しまくるんじゃなくて、Transit Gatewayに各VPCをつないでルーティング設定を行うことでVPC間の通信ができる
  • Hub-Spokeの場合にはあんまり出てこないんかな？
  • VPCが増えてもTransit Gateway上のルートテーブルが自動でVPCを追加する
  • AWS Direct ConnectやVPNとも接続できる。ので、オンプレ含めて疎通させることが可能
  • ってことは、、Azure Virtual WAN的な存在か、、、！

VPCピアリング<Transit Gatewayに見えるけど、、？Transit Gatewayは帯域上限が50Gbpsに対してピアリングは帯域制限がない。など良し悪しもあり。

• AWS Direct Connectには占有型と共有型がある、占有型はER Directに近いのかな？
• 帯域としても占有型の方が大きい。
• 共有型の場合にはTransit Gatewayとの接続ができないという制約あり

Direct Connectなら暗号化は不要なのか？

• 利用者DCとパートナーDC間の接続がWANである場合は、その間の通信は暗号化が必要
• またDirect Connectが共有型の場合は、物理回線を共有している形になるので、対策要否はコンプライアンス要件と照らし合わせる

AWS S2S VPN

• VPNアプライアンスは自前でもちろん用意しましょう
• キャリアのネットワークが死んだら終わりなので、複数業者、回線用意しましょう
• これはDirect Connectでも同じか

Direct Connectの場合でもパートナー企業複数と契約して、片側が落ちてももう一方の業者で接続できるように冗長化しておく

• 東西で持っている場合にはそれぞれパートナーを分けるのがいいのか？
• このパートナーは安定してて、このパートナーは不安定みたいな話も聞いたことあるし

Direct ConnectとVPNで冗長化する場合、AWS->オンプレは必ずDirect Connectが優先される(Azureと同じ)

• 待機系のVPNに切り替わったときに帯域上問題ないかは確認する必要がある

システムのアップデート方式

• Blue/GreenもCanaryも新旧環境用意して切り替えるという点では同じだけど、Blue/Greenは全ユーザ切り替え・切り戻しするのに対して、Canaryは一部のユーザのみが新環境に入る

ルートユーザはAWSアカウントを作成するとついてくる最高権威のアカウントなので、普段は使わない。ルートユーザでしかできない作業はJust In Timeで実施する。ルートユーザのログインはCloudTrailに記録されるので、それをSlackに通知して確認できるようにしよう。

IAMユーザー＝Azureのユーザー
IAMロール＝ユーザ割り当てマネージドID
に近しい。

これらに対してIAMポリシーによって実行可能なアクションを決めていく。アクションの定義には許可リスト方式と拒否リスト方式がある。許可リスト方式の方が、明示的に与えた操作しかできないため、新しいサービスが追加されても勝手に操作されることなく安全。

ただ実際のところJust Enough Accessの実現は難しいので、ログをとりながら不正が実質的にできない環境を作るのが大事。

予防的統制・発見的統制。AzureではAzure Policyの効果で使い分ける感じもあるが、AWSは昨日から違ってくるポイ。

バックアップ戦略

ディスクのスナップショット or EC2としてのバックアップ。スナップショットはそこから直接何かできるわけじゃないので一度EBSボリュームを作ってそれをもとにEC2インスタンスを復元する感じになるが、EC2のバックアップでは、EC2としてバックアップするので復旧の手続きが楽。

利用者の大半が関東にいる場合に、東京リージョン全壊の災害が起きたとしてビジネス継続しようとしてもユーザも被災しているので意味がなかったりする。そんな観点でもどこまで強化するのかは検討する必要がある。

DRは一大プロジェクトなので、自動でシステムごとフェールオーバーするのはほとんどない。DR発動の条件やフロー・体制をあらかじめ決めておく必要がある。また、DR発動訓練もめっちゃ大事。
Backup ＆Restore/Pilot Light（データだけコピー）/Warm Stanby（縮退環境を用意）/Active Active（並列稼働）など取りうるオプションがいくつかある。

オブザーバビリティ：可観測性
いつ・どこで・何が起こっているかをどれだけ把握できる環境か
ログ管理の考え方はAzureとも似ている
直近1か月間のログはCloudWatch Logsに保存し分析やアラートに利用。以降はS3にアーカイブ。

オンプレで使っていた監視パッケージをIaaSでクラウドに構築するっていうのもよくあるよね。ただPaaSとかSaaSで実装した方が、可用性やメンテナンスの負荷は軽減できる。一方、特にSaaSにおいては費用が高かったり、裏側のＤＣが海外にあったりするので、それって要件としていいんだっけ？を確認しよう。

重要度によってアラートのチャネルも使い分けよう。軽微なものはメールでいいし、重要なものはＳＭＳ＋メールで詳細ってパターンもある。チャットに送ればそのまま議論もできる。

運用自動化にはAzure Automation的なAWS Systems Manager Automationというものがある。AWS LambdaからAWS Step Funtions(おそらくDurable Functions的なもの)を呼び出すことで複雑な処理をすることもできる。

• RTO/RPOが十分長い場合にはバックアップデータをきちんとリージョン冗長にしておけば主導バックアップリストアでよい。手動とはいっても一部自動化することによって人為的ミスを減らすよう努める。

• AWSの場合EC2インスタンスの起動停止はそんな簡単にできない？Auto Scalingの予約されたアクションはAMIを指定して起動停止するのでAMIが変わる環境だと使えなかったり？ いや、AWS EventBridge SchedulerというものがAWSサービスの各種タスク実行をスケジューリングできるサービスな模様
• ほんで、インスタンスのみが対象の場合にはAWS Instance Schedulerってやつがあるやん
• 複雑なスケジュールがない場合にはEventBridge Schedulerが推奨らしい

• ん？AWSのRIって、キャパシティ予約の保証も含まれている？Azureもそう？そうならオンデマンド容量予約って意味あるんか？
  • いや、オンデマンド容量予約の場合はRIの1年とか3年とかだと長すぎる場合に使えるのか
  • 基本はRI+オンデマンド容量予約でやれば、RI価格にて起動保証ができる
• 請求管理用の "管理アカウント"で購入したRIやSPを配下の子アカウントに適用することもできる
  • Azureであれば当たり前ではあるが

そして、AWS的にはSPの方が柔軟性があって推奨ってあったけど、割引率はどうなんでしょうね？

• ロギングの話においてはAzure共通でやっぱり監査用のみに保管するログはS3にアーカイブして費用削減するのが鉄則。S3にもアクセス層の概念がある。S3 intelligent-Tiering というアクセス頻度に基づいて自動的に適切なストレージクラスに配置してくれる機能がある。Azureにもほしくないかい？

システム構築の順序イメージ

• まずは管理アカウントを作る。特に管理アカウントのルートユーザは扱いに注意。
• マルチアカウントアーキテクチャのための統制をかける。この辺でAWS Control Towerが使われる。これを使うと勝手にログアーカイブ用のAWＳアカウントと、監査用のＡＷＳアカウントが生成される（まじ？）
• AWS IAM Identity Centerも有効になるためAWSアカウントにログインするユーザの一元管理も可能
• Control Center なのか Organizationsなのか
• IAM Identity Centerなのか、Switch Roleなのか
• 踏み台サーバを用意するのはアクセス経路の集約とログの一元管理のため、必ずユーザが踏み台サーバを通るので、不正を行えば必ず記録に残る。

Control Towerではガードレール設定ができる。例えば、ホームリージョンを設定してそれ以外のリージョンは拒否するみたいな。OUを作成するのもここ。ログアーカイブ用・アカウントの監査用のアカウントもUIに従っていくと作成することになる。

IAMユーザの追加も、IAMグループを作ってそこに所属させる形にするので、AzureのSecurity Group＋Userの考え方と似てる

IAM Identity CenterからIAMユーザ・グループに対してAWS内のロールを付与していく。たとえばAWS側で事前定義している"AWSAdministratorAccess"とか、自分で作ったロールとかね。そういう意味ではIdentity CenterってAzure ADのユーザ管理画面に似てるのかも。ユーザを登録すると、そのユーザのメールアドレスに招待メールが届く。MFAを強制していれば、初回ログイン時にMFAデバイスの登録が求められる。

Control Towerで初回にOUの構造は作ったので、そのOU配下に置く実際のアカウントを別途作成する必要がある。

Identity Centerはそのサービス内の設定としてそのIdentity Centerの管理を委任する先のアカウントを登録できるため、そこにログイン用アカウントを登録する。

課金情報へのルートユーザ以外のアクセスはデフォルトで拒否なので、そこの設定をいじる。IAMユーザで管理できるようになれば、IAMユーザ側で予算を作成したりアラートを設定したりができる。使用料が一定の閾値を超えた場合に通知するということが可能。

Security Hubもサービスの設定として、管理を委任するAWSアカウントを設定できるので、そこで監査用アカウントIDを入力すれば委任可能。監査用アカウントのIAMユーザで、すべてのアカウントのセキュリティ情報が確認可能。なのでそもそもとして、　管理用アカウントのSecurity Hubの設定で、監査用アカウントに委任するように登録するっていうイメージかな？ GuardDutyも同じね。

↑のイメージがあってるかは一旦おいておいて、Security Hub/GuardDutyが委任された監査用アカウントでIAMログインして、それぞれのサービスを開くと「組織のSecurity Hubを有効にする」という項目が選択可能。

これによってAWS Organizationsに所属するメンバーアカウントのSecurity Hubの有効化が完了。

管理用アカウントの権限を引き継いでないとおそらくほかのアカウントのサービス有効化できないはずだからイメージあってそうだな

• 保守の費用も実は削減されている！ハードウェアの保守にかかっていた人件費は削減できる。その人員で新しいビジネスを創出していくのが理想的な流れ。削減される側もリスキリングでクラウドに順応していかないと。新陳代謝に飲まれないようにね。

• 時間的コストも見落とさないように。物理であればハードウェアの調達や調整に時間がかかるのに対してクラウドではターンキーですぐに機能を利用できる。ビジネスチャンスを逃さない。AOAIブームに乗れる乗れないもここに気付いたかどうかで決まっていた。
• 物理的なリソースを持たないってことは一方でビジネス撤退のリスクも低くできる。ハードウェアを購入してしまってからでは取り返しがつかないし、廃棄コストもかかる。

• セキュリティ対策もそう。物理DCを運営するには物理の世界でのセキュリティ対策に多額のコストをかけることになるが、クラウドならそこはベンダーの責任範囲になるね。しかも業界の認定を取得している。よってそのプラットフォーム上でIaaSレイヤ以上の管理をうまくやっていけばそれなりに安全。追加で要件に合わせて機能を追加すればいい。
• 脆弱性が発見された際のMitigationについても、ガイダンスが出ることが多いので安心感がある。