Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
北欧、暮らしの道具店を支えるAWSマルチアカウント運用 / hokuohkurashi aws...
Search
ryosukes
May 18, 2021
0
15k
北欧、暮らしの道具店を支えるAWSマルチアカウント運用 / hokuohkurashi aws multi account
ryosukes
May 18, 2021
Tweet
Share
More Decks by ryosukes
See All by ryosukes
ALBと外部IDプロバイダーで認証しつつ、LaravelではGate・Policyを使わずシンプルに アクセス制御する方法
ryosukes
0
22
フィットする暮らしを支えるSRE 2021
ryosukes
1
3.6k
EKSではなくECSを採用する理由
ryosukes
0
2.6k
RegExp Error caused by PHP upgrade 5.6 to 7.2
ryosukes
0
2.9k
Hello kubernetes
ryosukes
0
1.6k
コマンド履歴にタグを つけるCLIツールを作った
ryosukes
0
2k
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Into the Great Unknown - MozCon
thekraken
33
1.5k
Raft: Consensus for Rubyists
vanstee
137
6.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
GitHub's CSS Performance
jonrohan
1030
460k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
98
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
170
Adopting Sorbet at Scale
ufuk
73
9.1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Transcript
北欧、暮らしの道具店の AWSマルチアカウント運用 2021.05.14 株式会社クラシコム 佐々木亮祐
名前: 佐々木 亮祐(@ryosukes47) 出身: 宮城県 趣味: 音楽 好きな食べ物: 寿司 自己紹介
北欧、暮らしの道具店とは
• クラシコムが運営 • ECメディア • 月間訪問者数 約450万 • 月間注文件数 約3〜4万
北欧、暮らしの道具店とは hokuohkurashi.com
“当店は「フィットする暮らし、つくろう」 というコンセプトを掲げ、 2007年9月18日にインターネット上で ひっそりと産声をあげました。” (店長からお客様への挨拶より) 北欧、暮らしの道具店とは 佐藤
今日話すのは
北欧、暮らしの道具店の AWSマルチアカウント 運用について
まずは マルチアカウントにする前の 昔話からします
昔話 • 元々はASPのECでサービスを運用 • 2015年頃からフルスクラッチで作るプロジェクトが始動 • このときAWSを選択 • 当時のエンジニアはたった2人 •
2016年5月にリリース • リリース後すぐに1人減る • なかなかハード…
昔話 • シングルアカウント1VPCに詰め込まれた本番・ステージング ・テスト環境 • ローカル開発が上記アカウントのS3、SESを使用する前提 • 全エンジニアに付与された強めのIAM • 例えばLambdaFullAccess
LambdaFullAccessの中身抜粋 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action":
[ "cloudwatch:*", "dynamodb:*", "events:*", "lambda:*", "logs:*", "s3:*" ], "Resource": "*" } ] } ※ 実際は他にも Actionあります
この状態のときに どんなことが起こるか
いつでも誰でも本番環境に S3バケットやDynamoDBを 作成・削除ができる
気づかないうちに作られる なぞのS3バケットや DynamoDBテーブル達
ローカル作業中に意図せず 作られてしまったり…
なんとかしよう
2020年1月 マルチアカウント化 スタート
どんな状態を目指すか 1. 本番環境守りやすく 2. 見通し良く 3. 権限管理・移譲しやすく
本番環境守りやすく • 本番環境が存在するアカウントでの変更を減らしたい • 減らして、オペミスなどで事故る可能性を下げたい • 本番を変更できるユーザーを最小限にして事故を減らしたい • 開発に必要な環境は別途用意すればOK
見通し良く • 環境が混在するとリソースの依存関係が把握しづらい • 他の環境に影響しないか毎回確認するのはつらい • リソース名に環境のprefix/suffixが付くと冗長 • なので各アカウントに環境を混在させるのはできるだけ避けたい
権限管理・移譲しやすく • そもそもエンジニア全員が持ってる権限強すぎるのでついでに絞りたい • かといって権限がなく身動き取りづらいという状況は減らしたい • 環境ごとにいくつかIAMロールを用意・整備して、ロールの利用可否で権 限管理すれば柔軟に管理できるのでは
実際に分けてみた
分けた結果のアカウントリスト • マスター • 本番 • ステージング/テスト • サンドボックス •
分析 • 社内ツール • ユーザー
分けた結果のアカウントリスト • マスター • 本番 • ステージング/テスト • サンドボックス •
分析 • 社内ツール • ユーザー
マスター • AWS Organizationsの管理 • 監査・監視、ログ集約 ◦ CloudTrail ◦ GuardDuty
サンドボックス • AWSリソースで新しく使うものの検証など • 気楽に壊して良いし他の人に壊されても文句言えない環境 • 使えるエンジニアには強い権限を与えてるがIAMだけは壊されると困るの でIAMは最低限
ユーザー • 各アカウントにスイッチロールできるヒューマンユーザー管理 • IAMユーザー、使用できるロールの管理のみ
分けてみた感想
非常に良くなった • 本番環境に安心感 • 本番の近くに余計なリソースがなく探しやすくなった • 爆弾処理みたいなことも減った • 事故る心配が減り本番以外の環境も改善しやすくなった •
IAMユーザーの管理・権限付与が楽になった • コストが把握しやすくなった
課題になった点 • 本番アカウントから剥がすと動かない環境が発生 ◦ 頑張るしかない • AWSのコンソール、aws-cliで環境切り替えがやや面倒 ◦ コンソール: AWS
Extend Switch Role ◦ aws-cli: aws-vault • 各環境のセキュリティ管理 ◦ AWS Control Tower, AWS Config など
各環境のセキュリティ管理 • マスター・本番だけがセキュリティ厚くなりがち • テスト・サンドボックスのアカウントが薄くなりがち • 気づいたらマイニング用のEC2が立ってた、みたいな事例もあるので気を つけないといけない • AWS
Control Towerで複数アカウントをまとめてセキュアに • 2021/4/9に東京リージョンでも使えるようになった
改善余地はまだあるが だいぶ良い状態になった🙌
ありがとうございました