omuronの備忘録

個人的な備忘録

「第一回 AWSマルチアカウント事例祭り」 #ama_fes01 受講メモ

AWS 勉強会

zozotech-inc.connpass.com

ZOZOタウンで買い物したことなくて恐縮ですが、テクノロジーとしてはとても魅力ある企業ですね。

AWS Configを用いたマルチアカウント・マルチリージョンでのリソース把握とコンプライアンス維持への取り組みについて

講師：株式会社ZOZOテクノロジーズ 技術開発本部 SRE部 テックリード 光野 達朗(@kotatsu360)

speakerdeck.com

QA

通知を受け取った後の対応はどうしてるんですか？

実験的に見ているところなので自身で見てプロダクトチームへ連絡している。 プロダクトチームへ直接通知を検討中。

今後設定したいルールってなんですか

セキュリティに対して強く効果がある部分。ssh ポートをインターネットに公開してないかなど。
次にログに関して。「Aでは出てlB出だしてない」とかの状況にならないように、アカウントでログの状況を統一したい。

ルールはcontroltowerをベースに設定されたのでしょうか？

まだしてない。 Config のプリセットのマネージドルールを使ってる。 利用するだけでベストプラクティスになるので、これを中心にセキュリティを高めている。

Config Rulesの標準ルールだけでも汎用的なものからパラメータを個別に設定が必要なものまでいろいろあります。後者は各AWSアカウントの利用状況に依るので、全AWSアカウントに共通設定を適用は難しいなと感じています。ルールの採用方針があれば教えてください。

書いてあるとおりと思われる。 Config を採用したばかりということもあり、絶対に守りたい 22 port や S3 の公開権限などを中心にしている。 各アカウントの事情を細かく見なくていいレベルとしている。

Security Hubのセキュリティ標準チェックも活用できそうでしょうか？

活用できると思われるがまだ見れてない。 マルチアカウントマルチリージョンができることが重要。 リージョンに広く使えると思われるので検討していきたい。

どれくらいの期間で、現在の状態まで構築出来ましたか？

Try&Error も含めて、足掛け2週間。 Config の設定がアカウント単位やリージョン単位などをサポートに問い合わせるなどに時間がかかった。

マルチアカウント運用の開始までの取り組み

講師：株式会社ウェザーニューズ　Cloud Initiative 小野 晃路

アプリいつも使ってます。
86年創業。94年入社とのこと。
そんなにも歴史ある会社だったんですね。アプリのイメージしかなかった。

www.slideshare.net

  • 2012年から AWS 利用。グローバルの天気アプリの作成がきっかけ
  • 元々、オンプレがメイン。密結合
    • 現地に行くのも時間かかる
    • ケーブル片付けだけで半日など
    • ビルの法定停電
  • 最初は運用アカウントのみ、オンプレ接続
    • 開発アカウント追加、オンプレ接続
    • 利用促すために PoC アカウントを発行、オンプレ接続なし
      • 同じアカウントを使うとコスト配分できない
      • IAM 最低限にするのは大変、詳しくないときに作った最初のチームは権限ゆるい
      • サービス上限にひっかかる
      • オンプレと接続したい
      • 開発アカウントで試すときに権限がないので調整に時間がかかる --> オンプレでいいや
        • 問題も多いからマルチアカウントを検討へ
  • AWS Summit 2017 「AWSにおけるマルチアカウント管理の手法とベストプラクティス」を参考に
  • AWS Transit Gateway
  • AWS SSO
    • 複数アカウントのログインの一元管理が可能に
    • G suite 使ってるけど SAML 連携はせず
      • 各アカウントに対する細かい設定が難しそう
    • IAM ユーザーやスイッチ Role を使わなかった
      • アカウントごとに設定するのが大変だった
        • MFA がアカウントごとに増えたりとか
      • スイッチ Role も設定が大変
  • AWS 利用のガバナンスの決定
    • ガバナンスと権限移譲のバランスを取る
      • ガードレール方式
  • アクターの整理
    • AWS を利用する管理者と役割を定義
      • アプリ開発担当、アプリ管理者担当、事業部の管理者、監視担当、インフラ管理担当、セキュリティ管理担当、コスト管理者
  • アカウント名とメールアドレスの命名規則
    • {env}-{team}{-system}
    • ml-aws-{team}{-system}{+env}@wni.com
  • CDK を使って管理
    • cli も併用、コードベースにする
  • まとめ
    • SSO 使おう
    • 運用ルールを事前に決める
    • コード管理で運用しましょう
  • 課題
    • マスターアカウント＝運用アカウントのためシステムが乗ってる
      • 支払い専用へどう移行するか

QA

コード管理で運用するとのことですが、初期構築だけではなく運用含めて全てをコードで管理されるのでしょうか？

変更があれば、コードでするようにしている。

「進化し続けるインフラ」のためのマルチアカウント管理

講師：株式会社リクルート インフラソリューションユニット SRE部 須藤 悠

  • 13チーム、90アカウントを管理
    • 2016年数アカウントからスタート
  • Terraform 運用
    • Pull Request で 自動 plan
    • 最初は手動
    • 次の1年程度は CFn
    • 次の2年程度で次第に Terraform へ
    • 現在すべて Terraform + Terraform Enterprise で運用
      • 1000plan/月、200apply/月
  • 基盤の権限構成
    • 4つの権限
      • 管理者権限：プロダクト責任者向け
      • 開発者権限：開発者一般向け
      • 運用者権限：運用者向け
      • コンテンツ権限：S3 バケット更新用
  • root 権限はかなり厳重に制限
    • 基盤チーム専用の MFA デバイス
    • root 必須以外は利用不可
  • 利用リソース
    • CloudTrail
      • S3 の出力内容は変更削除不可、参照のみ
    • Config
    • CuardDuty
      • SNS Topic でメールと Slack 通知
    • VPC Peering
    • Transit Gateway
    • Organizations SCP
    • Compute SavingsPlans
      • Fagate で恩恵を受けたい場合は個別アカウントで設定
      • RI は個別アカウントのみ
    • Consolidated Billing & Cost Explorer
    • RDS
      • 意図せず再起動が出ないようにメンテンススケジュールを Slack 通知
    • Route53
      • 内部 HostedZone レコードを DynamoDB に集約
    • ACM + Route53
      • 開発でも HTTPS 使う
      • クロスアカウント化が必要なので Terraform 化してない
  • LDAP により ID 管理とフェデレーション
    • LDAP アカウントに登録で ssh とマネコン使える
    • 公開鍵と MFA トークン自動払い出しメール通知
    • Web アプリの管理ツールを作って提供
    • 今から作る人はマネージドサービスを使うべき
      • AWS SSO, Directory Service, Sysytems Manager ...
      • 独自 ID 管理は覚悟が必要
  • マルチアカウントで大切にしていること
    • 進化し続けるインフラ
    • 基盤チームでプロダクトを幸せに
      • インフラ運用だけじゃない価値を
      • プロダクトに寄り添い伴走し成長させる
    • AWS 新機能、新サービスのキャッチアップ
    • 障害を学びに
      • トラブルシュートは学びの宝庫

QA

アーキテクチャレビューできるには幅広いAWSスキルが必要になると思いますが、そのために基盤チームのメンバーの教育は何かやっているのでしょうか

メンバーごとに得分野と不得意があると思う。まず一つの機能の適用検証を一人でする。レビューアートしてハイスキルな人や知見のある人をつける。壁打ち相手を作って進めるようにする。

CFnからterraformへの移行を決めた際に、CFnでは辛いなと感じたポイントをいくつか教えていただきたいです。

当時は yaml が使えなかった。json を書くのが辛かった。 Terraform だとインポートして IaC に組み込めるのが良かった。

CCoEチームにいます。当初はCCoEチームがAWS全般に詳しかったのですが、複数案件を経るとプロダクトチームの方にノウハウが蓄積するようになり、相談されても答えられないものが増えつつあるのが悩みです。社内のAWSノウハウ共有のいい方法と、CCoEチームメンバーとしてのモチベ維持方法に関して何かあればお聞かせください。

前半に関しては、プロダクトチームが成長成熟することは素直に喜ぶ。CCoE チームが関与してたからこそ成長できたと誇っていいと思う。 社内のノウハウに関しては、モチベーションを持った特定の人が何人かいると思うので、その人に声をかけて勉強会とかカジュアルにオンライン飲み会で技術の話するなどもいいかなと。 モチベーションの維持は、プロダクトと CCoE で注目すべき AWS のサービスは違うと思う。そういったところでそれぞれ興味を持って突き進めばいいと思いました。

所感

10年ほど AWS 触ってるから徐々にアカウントが増えていき、綺麗にマルチアカウント管理はできてない状況です。
最初に作ったアカウントがマスターアカウントになって運用もしている状態だし、自分がメインでみてないアカウントはセキュリティ周りも後回しになったりするし...
計画的にまとめて管理を考えないとダメな状況になってきましたが、専門のインフラチームとかでないとなかなか難しいですね。