転職活動の記録〜クラウドと英語〜
2023年8月で新卒から約13年半勤めたSIerを退職します。関係者の方々、本当にお世話になりました。
9月から新しい職場で働くのですが、転職活動が初めてということもあり、色々と試行錯誤しながら進めたのでここにまとめたいと思います。 なお、具体的な企業名やそのプロセス、オファー条件はここには記載しません。企業名、特に前職は色々調べるとわかる情報なのですが、企業名で検索してこの記事が出てくるのもちょっと違う気がするのであえて書いておりません。
転職に向けてどう準備、活動したかにフォーカスして書こうと思うので何かしら参考になれば幸いです。
自己紹介、私の経験値
クラウドアーキテクトとして、お客様のクラウド導入支援を行っていました。AWSがほとんどで、Google Cloudもたまに触るくらいです。Webシステムのインフラ設計、構築をやることが多かったです。IaC書いて構築したり、設計書書いたり、AWSアカウトのセキュリティ・ガバナンス設定やったりとそんな感じです。社内のメンバー育成、採用、アライアンスリードなんかもやっており社内のクラウドに関わるところはひととおりやっていました。幅広くやっていましたが、逆に言うと、1つのプロダクトや技術に責任を持って徹底的に開発、改善するといった機会も無かったと思います。
クラウドを本格的に使用することになったのは2019年以降で、それまではオンプレミスのインフラ構築をメインにやりつつ、たまにバックエンドのコードを書いたりして活動していました。
業務外では、AWS Ambassadorsに選ばれてそこで活動していたり、AWSに関する本もいくつか執筆しています。なおAWS Ambassadorは退職に伴い卒業です。
なぜ転職するのか
好きなクラウドをたくさん使用してそこには満足していたのですが、クラウドを使用しつつ、英語を使ってグローバルに活動したくなり、転職活動を始めました。
業務内は関係者全て日本人でドメスティックなのですが、AWSのコミュニティの中で、海外の方々と交流する機会があり、その中で日本の話をする機会が何度かありました。そこで持った私の感想は、みんな思ったより日本に興味があるというものです。日本は（主にクラウド活用の点で）進んでるねと言われたり、たくさん資格持っててすごいねとか、興味津々に聞いてくれる感じは少し衝撃でした。そんな経験から、日本って素晴らしい技術やカルチャーがあるのに、言語が日本語（＝英語情報が無い）って理由であまり世界に知られてない？と思うようになりました。
自分自身の英語力についても、少しずつ自信も付くようになりました。そこまで英語力が高いわけではないのですが、ノンネイティブの方とであれば割と苦労せずにコミュニケーションが取れるくらいの会話力はあります。英語ネイティブな国に行ったら「英語あまり喋れない人」に分類されますが、日本にいるとこれが「英語できる人」に分類されるというのが正直な印象です。技術力が優秀な日本のエンジニアが英会話でタジタジな姿を見て、「あれ俺これなら割としゃべれる方かも・・？」と謎の自信を付けた経験もあります。正直これは自信ではなく過信の可能性もありますが、まぁそれぐらいの強い気持ちで良いのかなとも思ってます。
こんな経験から、クラウド活用は継続しつつ、日本の技術を世界へアピールできるような活動、組織内もグローバルで色々な考えから刺激をもらえる環境、自分の英語力も伸ばせる環境に興味を持ち、転職活動を始めました。
企業探し
クラウド×グローバルという観点で企業探しを始めました。 外の企業をあまり知らない、英語とクラウド知識を幅広く活用といったポジションが少ない、といった理由で候補となる企業は多く見つかりませんでした。
転職動機についても、具体的に行きたい会社や業界は決まっておらず、正直ふわっとしてるよな・・と自覚もしております。同年代でやりたいことはこれだ！と見つけてスタートアップに転職している方を見て羨ましく思ったものです。
また、前職でもそれなりの給料をいただいており、それをそのまま希望年収として出すことでハードルとなってしまうパターンもありました。私自身年収UPにそこまでモチベーションがあるわけではないですが、子供・家庭があることもあり簡単に収入は落とせないという背景もありました。
企業探しに使用したものは以下のとおりです。
結果的にはLinkedinを一番多く使用しました。理由は単純で英語の求人情報やメッセージが一番多かったからです。
Linkedinは、公開設定で転職興味があることを通知できます。私は「採用担当者のみ」に設定していましたが、それだけでもメッセージ量は増えました。
企業を探すという段階では、色々なサービスに登録すると良いかと思います。
色々と調べたり、エージェント面談、カジュアル面談をする中でいくつか応募したいという企業が見つかりました。そんな中でエージェントさんから聞いたのが、「この企業は最初に簡単なアルゴリズムかコーディングの試験がありますね〜」というものでした。
ほほぅ・・・。簡単という言葉が入っていましたが私にとって簡単ではないことはすぐにわかりました。この時点ではどんな感じの試験が想像も付かなかったので時間を取って色々調べてみることにしました。
選考準備
どうやらSoftware Engineerの選考ではライブコーディングをやるというが普通ということがわかってきました。私の希望ポジション的にはガッツリなコーディング試験も無さそうだったのですが、良い機会だと思い色々見てみることにしました。やったことを書いていきます。
読んだ本
いくつか読みました。本の知識をそのまま選考に活かすということは私の場合少なかったのですが、エンジニアとしてとても面白い本ばかりでした。
問題解決力を鍛える!アルゴリズムとデータ構造
アルゴリズムってなんだったっけ？状態だったのでこちらから。代表的なアルゴリズムがわかりやすく紹介されており入門として良かったです。計算量やオーダー記法の説明もあります。
データ指向アプリケーションデザイン
転職活動でこれを読んでいるという方の記事を複数見つけたので読みました。良本でした。複雑化するデータをどう扱うかという観点で色々な技術の仕組みが紹介されています。Twitter（現X）のホーム画面の仕組みや、AWSのAuroraやRedshiftの紹介など、読んでいて面白い内容が多かったです。
ただ、分厚いです。600ページ超。値段と物理的な大きさに少しひよった私は、図書館でこの本を見つけ借りました。2週間という期限があったので業務の空き時間で頑張って読み切りました。正直時間の関係で理解を深めずに読み飛ばしたところも多いので、またどこかでちゃんと読みたいです。こういった良本が図書館で無料で借りれるとは申し訳ないくらい素晴らしい仕組みですね。
時間が無いぜ！って方はまずこちらの動画を見てみるのが良いと思います。監訳された方がわかりやすく３０分でまとめて説明してくれています。
［試して理解］Linuxのしくみ
後述するTechnical Interview（技術面接）で出てきそうなトピックだったので購入しました。こちらも良本でした。普段からLinuxやコンテナを触っている（≒Dockerfile書くくらい）のですが、なんとなく雰囲気で触っている部分も多いというのを痛感しました。Resumeに書く技術については、中身も含め理解しブラックボックスにしないというのが重要かと思います。
システム設計の面接試験
元々英語版であった本ですが、日本語版が発売されたタイミングで買いました。発売日はすでに選考が始まっていたので、一気読みしました。
自分の業務でもよく使うデータベースやキャッシュ、CDNなどの仕組みの紹介、それらを使用して実際のシステムをどう設計するかの紹介があり、読んでて面白かったです。面接対策として読んでいる感じはあまり無かったです。
世界で闘うプログラミング力を鍛える本 コーディング面接189問とその解法
Kindle版がセールになっていたのでそのタイミングで買いました。こちらも買ったタイミングが選考の後半戦だったので、半分くらいしか読めませんでした。ライブコーディングをたくさん受けるのであれば、こちらの本と後述するLeetCodeを徹底的にやった方が良いかと思います。
LeetCode
コーディング試験対策の定番ですね。私も漏れなく実施しました。正直言うと私はガッツリライブコーディングをやるという面接は無かったのですが、それでも面接中に「このコードのアウトプットは？」とか、Home Assignment（宿題）でコードを書いたりしたので、やっといて良かったなと思ってます。
私はトータルで40問ほど解きました。Backend Engineerなどの方からすると少ないなーというレベルでしょうが、それでも以下のような感覚は得られたのでやって良かったなと思います。
- 知らない記法を色々と知れた
- コードを書く瞬発力が上がった（気がする・・）
- 計算量を意識するようになる
私はPython3で解いていました。
Technical Interview（技術面接）対策
コーディング以外の技術面接についてです。最初は何が聞かれるのかわからなかったのですが、調べるとシステム一般的な知識が問われることも多いということがわかりました。
以下のような想定質問を用意して、英語で答えられるよう準備しておきました。普段一般的に使っている技術領域であっても、それを説明しろとなるとうまく言えない場合も多いですからね。
- What is the difference between containers and VMs?
- What will happen when you open "https://example.com" in a browser?
- What is ACID?
- What is NoSQL?
- What is the difference between TCP and UDP?
Behavioral Interview（行動面接）対策
色々なシチュエーションで、どのような行動をしたか、対処をしたか、が問われるインタビューです。HR（人事）担当や、マネージャとインタビューをする場合はこのパターンが多いかと思います。 ここは何か新しい知識を身につけるというより、過去の自分の経験を振り返って想定質問に準備するということをやっていました。
質問はパッと思いつかなかったのでChatGPTに作ってもらいました。以下のような感じです。
- Can you tell me about a time when you had to handle a difficult team member? How did you approach the situation, and what was the outcome?
- Describe a situation where you had to learn a new technology or programming language quickly. How did you manage it, and how did it impact your work?
- Can you share an instance when you had to explain a complex technical concept to a non-technical audience? How did you ensure they understood?
自分が経験してプロジェクトにおいて、何が大変だったのか、大変だったことに対してどういう行動を取ったのかというのを振り返るのが大事だと思います。
あと、回答はSTARメソッドでお願いしますと企業側から言われることも多いです。簡単に言うと「Situation ：状況」「Task：課題」「Action：行動」「Result:結果」の順番で話す方法です。ここはYoutubeやChatGPTでもサンプルな回答方法が色々と出てくるので調べてみると良いと思います。一番大事なのは話し方ではなく、自分の経験をしっかり話すというところなのでそこは注意ですね。
企業研究
ここは割と当たり前の話ですが、なぜその企業なのか、なぜそのポジションなのか、今までの経験がそのポジションでどう活かせるのか、あたりはきちんと説明できるよう準備していました。
選考
準備をしながら応募したいと思える企業がいくつか見つかったので選考に進みました。よくある書類選考や面接とは違うパターンの選考もあったので紹介します。転職に慣れている方？には一般的かもしれません。
Home Assignment
呼び方は企業によって様々かと思いますが、１−２週間ほどで技術的な成果物を構築して提出する形式の選考です。私は２社ほどこの形式で受けました。クラウドを使用するポジションだったので、あるお題に対してIaCを使ってGit形式でソースコードを提出してくださいといったものでした。正直業務も忙しい時期だったので、時間を取るのに苦労しました。業務後の夜に頑張って作っていました。自分自身はコードだけでなくドキュメントもたくさん書いてきた人間なので、非機能要件（セキュリティ、拡張性、運用）の説明も含めてたくさん書くようにしました。正直ここはどう評価されたのかはわかりません。説明部分など、書く言語は基本的には英語になります。
時間を取るのに苦労した部分はありますが、採用方式としてはミスマッチも減りそうで良い方式と思っています。コードの書き方、ドキュメントの書き方、Gitコミットの残し方まで、その人の開発手法を幅広く見ることができるので。
プレゼン面接
1対1ではなく、複数名の担当に資料を用いてプレゼンを行うという形式です。この形式も私は２回ほど経験したのですがテーマは基本的に自由で良いという感じでした。幸い私は外部の勉強会などでお話する機会が多かったので過去の資料を流用させてもらいました。ただ一部資料の英語化は行いました。個人的にはエンジニアはプレゼン力も重要だと思っているのでこちらも良い形式の選考だと思っています。資料の書き方や話し方も見れますからね。
英語について
面接やカジュアル面談、採用担当との打ち合わせをたくさん行いましたが、英語を使ったのは全体の30%〜40％くらいだったと思います。グローバル環境を求めたとは言えど、日本企業または海外企業の日本拠点を受けている形だったので、必然的に日本語のコミュニケーションも多かったです。日本語or英語どちらでも良いよって場合は日本語を選ばせてもらいました。それでもまぁ、15〜20時間くらいは英語で会話していたと思います。英会話スクールにお金を使っていた自分としてはお得な気分ですw。
なお、注意していただきたいのは英語力についてです。私の英語力の場合、USやイギリスなど英語ネイティブしかいない環境の場合は普通に英語力で落ちていると思います。日本のポジションということもあり、日本語も使用しつつ、ノンネイティブの人含め海外の方とやり取りできるくらいのレベル感が求められていました。私に気を使ってはっきりしゃべってくださった方もおり、助かりました。英語力に関してはまだまだ伸ばしていきたいスキルです。
オファー受諾まで
最終的に２社からオファーをもらいました。１社は海外の方が多く入っている事業会社、もう１社は３大クラウドではない某クラウドプロバイダーです。
色々と悩んだのですが事業会社に行くことに決めました。転職活動で色々と話を聞く中で、世の中の課題に対して技術で直接解決する、そういった事業会社さんの姿勢が魅力に感じました。SIerやクラウドプロバイダーではお客様企業のために自分たちの技術または技術力を提供すると言う側面を感じ、そこはそこで技術をやる上で魅力だったのですが、初転職ということもありこれまでとは違った立場で技術に関わりたくなりました。もう１社のクラウドプロバイダーも、担当の方が超ナイスガイ、みんな良い人でチームメンバーはほぼ全員外国の方という、魅力も多かっただけに悩んだしお断りするのも申し訳なかったです。
ということで9月1日から新しい会社で働きます。ダイバーシティを武器に世の中に貢献するといったミッションの会社なのですごく楽しみです。
オファーに関して２点ほど気にしておくべき点があったので書いておきます。
オファー後はすぐに返事する必要がある
会社にもよると思いますが、大体遅くとも１週間以内にはオファーに返事を出す必要があります。つまり、複数社受ける場合は最終面接やオファーの日程を調整しましょうということです。私の場合はオファーをもらった２社共エージェント経由ではなく直接応募していましたが、それぞれに他社の進捗状況を伝えつつ各種日程を調整してもらいました。
入社までの期間は2~3ヶ月程度
こちらも会社によると思いますが、オファーをもらった場合、その後2ヶ月くらいで入社するつもりで活動した方が良いと思います。私も前職の引き継ぎ業務があり、オファーから入社まで3ヶ月ほどでした。プロジェクトにガッツリ入っている方だとここが難しい場合もあると思いますので、入社先の企業にも確認した方が良いかと思います。
転職活動を振り返って
改めて書いてみると色々やっていたなと思います。本やLeetCodeなどは、転職活動をしないと多分やっていないので新しい知識としてインプットできて良かったです。知らないことを学ぶのは楽しいですね。
ただ、メンタル的に大変なところもあったので気軽にやる活動でもないなというのが正直なところです。普通に選考で落ちることもあったので、落ちるとアレ俺って無力エンジニアなのかな・・となったり、受かったら受かったでお断りするのも申し訳ないです。結果が出るまではドキドキですしね。しばらくは次の企業で頑張りたいなというお気持ちです。自分の足りないスキルも色々と見えたので引き続き働きながら学習していきます。
こういった情報が少なかったのでまとめてみました。以上です！
AWS入門書の比較＆新しい本を書きました。
Amazon Web Services（AWS）の学習を始めるための入門書、たくさんありますね。
今回、めでたく（？）、私も新しい本を書かせていただきました。本日発売です！！
本書を書く参考として、他の入門書もいくつか読ませてもらいました。
せっかくなので、各入門書の紹介をしつつ、どのように選んだら良いのかポイントをまとめてみます。
紹介する本は以下の３つと今回書いた本です。
１．
２．
３．
1. AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー
AWS認定の基礎クラスである、クラウドプラクティショナーの対策テキストです。認定取得を最初の目標としている方はこれに決まりです。以下の特徴があります。
システム構築の経験が少しでもある場合は、とても分かりやすく理解がどんどん進むと思います。私の知り合いの若手メンバーもこの本を読んで試験合格したという人が多いです。
オンプレミスやデータセンター、IPアドレスといったシステムの基礎用語は理解している前提になっているかなと思います。
2. 図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書
表紙で「AWSの一番やさしい本」と言っていることもあり、難しい言葉を使わず、AWSをイメージでつかめるようやさしくわかりやすく記載されています。以下の特徴があります。
- システム構築経験が少ない方でもわかりやすく、難しい用語が出てこない
- 「オンプレミス」の紹介など、システムの基本的な紹介もある
- 紹介するサービスはEC2、RDS、S3、VPCがメインで、無理に多くのサービスを紹介していない
- カラーでわかりやすい
AWS、クラウドってなんだっけ？という方やシステム構築経験が無い方、使用予定のサービスがEC2やRDSだけなど限られる場合はこの本が合うと思います。
AWSには現在200以上のサービスがありますが、広く知ろうとすると混乱することもあるので、まずは基本サービスに絞って理解したいという方はこの本がおすすめです。先ほどのプラクティショナー対策本よりもやさしい内容になっていると思います。
3. AWSではじめる クラウド開発入門
この本は紹介した2冊とはまた系統が異なります。ハンズオン中心です。「認定とか概要理解は興味ない、オレはAWS上で何かを作りたいんだ！」って方は是非こちらの本をどうぞ。以下の特徴があります。
- ハンズオン中心なので、作ることが好きな人は楽しい。PCの横にこの本を置いて学習を進める形になりそう
- AWSアカウントやGit、AWS CLIなどの環境セットアップが必要。楽しい人は楽しいが、未経験の人は少し苦労するかもしれない
- サーバーレスSNSアプリや、深層学習アプリなど、ハンズオンで作成するものが本格的。最後までやればかなり力がつく
技術者向けの本になっています。本の難易度としては今回紹介する中で一番高いかなと思います。
（New!） 図解 Amazon Web Servicesの仕組みとサービスがたった1日でよくわかる
私含め4名で書いた本となります。レベル感やイメージとしては、2で紹介した図解即戦力の本に近いです。以下の特徴があります。
- システム構築経験が少ない方でもわかりやすく、難しい用語が出てこない
- 「オンプレミス」や「IPアドレス」、「データベース」の紹介など、システムの基本的な紹介も多い
- 紹介するサービスが多いので、AWSで出てくる単語を網羅的に理解できるようになる
- カラーで図も多くわかりやすい
わかりやすさと幅の広さを重視して書きました。
最近では、最初のシステム構築がAWSになる新人さんや、いきなりAWSの営業をしてこいと言われる営業社員も増えているのではないでしょうか。 そんな方が増えるなか、AWSをバリバリ使っている人は容赦なくAWS用語を繰り出してきます。
そういった新入社員や営業社員が、クラウド・AWSの理解を深め、AWSエンジニアの会話についていけるようになることを目指して書いた本になっています。
AWSってなんだっけ？その前にシステム構築やオンプレミスってなんだっけ？って方は是非本書を読んでもらえると嬉しいです。逆に、ある程度システム構築経験のある方や、認定合格知識や構築スキルを身に付けたい方はこの本は簡単すぎるところもあるのでご注意ください。
4冊の比較表
私の主観も多いですが、各本の比較をまとめてみました。紹介サービス数は多ければ良いというものでは無いので、好みや状況に合わせて比較材料としてみてください。
| 表紙 | ターゲット | やさしさ | ページ数 | 紹介サービス数 |
|---|---|---|---|---|
 |
認定合格を目指す方 | ★★★★☆ | 291 | ★★★★☆ |
 |
主要サービスを中心にAWSを理解したい方 | ★★★★★ | 240 | ★★☆☆☆ |
 |
AWS構築スキルを身に付けたい方 | ★★★☆☆ | 368 | ★★★☆☆ |
 |
AWSを幅広く理解したい方 | ★★★★★ | 260 | ★★★★★ |
その他紹介できなかった本
今回は私が中身を読む機会があった本を紹介しましたが、入門書はほかにも多く発売されています。 表紙とAmazonページの情報からですが、簡単に紹介しておきます。
「学習ロードマップ」という学習の進め方・順序に合わせて紹介してくれる本ですね。AWSを深く理解しようとすると自分で学習することが必須となるので、その進め方を教えてくれるのは良いですね。
フルカラー、AWSマネジメントコンソールの画像も多く使用し、AWSの利用イメージとともにわかりやすく解説されているようです。
AWSに詳しいエンジニアがたくさん在籍するクラスメソッドさんのメンバーが書かれている本です。私もいつもブログにはお世話になっています。526ページとボリュームが多く、深く理解できそうな本です。
AWS社員の方が書かれている本です。社員ならではのディープな情報もサンプルを見るとありそうでした。AWSさんの説明（セミナー）や資料はよく拝見するのですが、どれもわかりやすいのできっと本も読者にわかりやすい仕様になっていると思います。
AWS上のEC2とRDSでWordPressをセットアップしながら、システム構築の流れを理解するといった内容になっています。（目次より）AWSだけでなく、EC2上でのソフトウェアインストールなど、システム構築一般的な知識も身に付きそうです。
まとめ
いっぱい入門書があって選ぶのが大変ですね・・（汗）
今回私たちが書いた本は、入門書の中でもかなりやさしい部類に入ると思いますので、手に取っていただけたら嬉しいです。
試し読みもできますので、気になる方は是非チェックしてみてください。
DetectiveがOrganizationsに対応したのでマルチアカウント設定してみる
こんにちは、久しぶりに個人ブログを更新します。 最近は会社のブログによく書いております。
私も普段良く触るAWS Organizationsですが、すてきなアップデートが出ていました。
Amazon Detectiveはアップデート前はOrganizationsに対応しておらず、複数アカウントの情報を集約するには1アカウントずつ招待する必要がありました。このアップデートで組織内のアカウントの情報を一気に集められるようになりました。
他のセキュリティサービス（GuardDutyやSecurity Hubなど）は、基本的にOrganizationsに対応していたので、ついにキタ！という感じですね。
Amazon Detectiveとは？
改めて復習です。
Detectiveは、VPC Flow Logs、CloudTrail、GuardDuty などの他のAWSサービスの情報をインプットに、潜在的なセキュリティ問題や不信なアクティビティを分析、調査できるサービスです。
たとえばGuardDutyの検出結果にはDetectiveへのリンクが用意されており、検出したリソースやIPアドレスをベースに、発生した時刻やリソースでどういうことが発生していたか確認できるようになっています。
Organizationsを使用したマルチアカウント設定
やっていきます。手順の流れは以下のとおりです。
- メンバーアカウントへ委任
- メンバーアカウントのDetective有効化、組織内アカウントの自動有効化
- (Option) 組織ベースの状況確認
メンバーアカウントへ委任
マネジメントアカウントへログインし、Detectiveの画面へ遷移します。
左側のメニューから全般を選択し、委任するアカウントを指定します。
(今回はAuditというアカウントに設定します。）
委任されたアカウントへログインし、Detectiveのアカウント管理画面へ遷移すると、次のようにOrganizations配下のアカウント一覧が表示されています。
委任設定はこれで完了です。
メンバーアカウントのDetective有効化
まだメンバーアカウントのDetectiveが無効状態で、集約もされていません。1アカウントを指定してメンバーおよび有効にしてみます。
なお、メンバーアカウントのDetectiveを有効にするには、GuardDutyをONにしてから48時間以上経過している必要があります。
system01アカウントを対象に有効化してみます。
すでに有効化したようなメッセージが出ますが、忘れずに有効化を押しましょう。
しばらくすると有効になります。
有効にしたsystem01画面にログインしてDetectiveを見てみると、以下のようになります。
集約された場合、現時点ではメンバー側では自分のイベントがDetectiveで確認できないため注意が必要です。
つづいて、組織内のアカウントをすべて有効化してみます。
ふたたび委任したAuditアカウントにログインし、すべてのアカウントを有効にします。
有効にできました。
Organizations配下の新規アカウントについて自動有効することも可能です。
設定検証はここまでです。
組織ベースの状況確認
せっかくなので、何かメンバーアカウントでイベントを検知させ、集約されたAuditアカウントのDetectiveで状況調査をしてみます。
今回はコチラのS3イベントをメンバーアカウントで検知させてみます。
バケットのブロックパブリックアクセスを無効にすると検知されるイベントです。
任意のバケットで次のとおり無効にします。
しばらくすると次のように、GuardDutyでイベントを検知します。
集約しているAuditアカウントでもGuardDutyのイベントが見れるので、Detectiveで調査してみます。
検知したAWSアカウントID、操作したIAM（今回はAWS SSOのロール）、操作元のIPアドレスをベースに調査が可能です。 IAM（ロールセッション）をベースに調査してみます。
Detective上では色々な情報が表示され、次の画面ではイベント発生の時刻で、どのAPIが何回呼ばれたのか表示されています。 たとえばバケット作成（CreateBucket）を1回呼び出しているのがわかります。
イベントの発生した国の情報も地図で表示できます。
イベントを発生させたユーザー（ロール）が、イベント前後でどのような操作をしていたのか、よくわかりますね。まさにDetective（探偵）という感じです。
また、今回はイベントが発生したsystem01アカウントではなく、集約したAuditアカウントで調査したというのもポイントです。
まとめ
個人的には待望のアップデートでした。便利ですが、集約するとメンバー側で情報が見れなくなるのでそこは注意ですね。
コチラのOrganizationsまとめの記事も更新しましたので、是非セキュリティサービスについてOrganizationsを活用したい方は参考にしてみてください。日々アップデートされるので私も日々勉強中です。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～まとめ～
ひととおり、各サービスについてOrganizationsを使用した集約設定方法をまとめました。本記事でまとめていきます。
Organizationsの復習
Organizationsは元々、複数アカウントの利用料請求を一括にまとめる機能でしたが、現在では各サービスの情報を組織内で一括管理できる機能があります。
デフォルトではManagement（親）アカウントに情報が集約されます。（以下CloudTrailの例）
アカウントの委任という機能に対応しているサービスもあり、これを利用することで集約するアカウントをOrganizations配下のメンバーアカウントに変更できます。（以下Configの例）
また、いくつかのサービスは、組織へアカウントが追加されたときに、そのアカウントでサービスを自動有効化する機能もありました。（以下GuardDutyの例）
各サービスの対応状況
- Organizations集約に対応
- メンバーへの委任
- アカウント追加時の自動有効
の３点について、各サービスがどう対応しているか表にまとめました。各サービス名をクリックすると設定方法の記事へ遷移します。
| サービス名 | 1.Organizations対応 | 2.メンバー委任 | 3.メンバー自動有効 | 補足 |
|---|---|---|---|---|
| ルートユーザーの保護 | × | × | × | 各アカウントで個別に実施する必要あり |
| AWS SSO(IAM) | 〇 | × | - | 権限セットとしてグループごとにIAMポリシー管理 |
| Cost Explorer | 〇 | × | 〇 | |
| AWS Budgets | 〇 | × | - | メンバーアカウント単独で予算設定は可能 |
| CloudTrail | 〇 | △ | 〇 | 証跡S3バケットをメンバーアカウントに設定することは可能 メンバーアカウントから閲覧は追加設定が必要 |
| AWS Config | 〇 | 〇 | × | メンバーアカウントはあらかじめ有効が必要 |
| GuardDuty | 〇 | 〇 | 〇 | |
| IAM Access Analyzer | 〇 | 〇 | × | 組織とメンバーのアナライザーは別扱い |
| AWS Security Hub | 〇 | 〇 | 〇 | |
| Detective | 〇 | 〇 | 〇 | ※2021年12月アップデート 集約するとメンバー側は情報が見れない |
| Personal Health Dashboard | 〇 | × | - | PHD単体は自動有効 |
| Trusted Advisor | 〇 | × | - | TrustedAdvisor単体は自動有効 |
※アカウント単体で一律有効にするサービスではないAWS SSO、AWS Budgetsの③は「-（対象外）」としています。
※PHDとTrustedAdvisorはアカウント単体で自動有効なので同じく「-（対象外）」としました。
一括設定の方針
もし新規のOrganizationsでこれらの設定を一気にやるにはどうやったら良いのか考えてみます。
流れとしては以下のとおりです。私の1案となります。
-
これを行うことで、Organizationsの組織が作成され、各サービスでOrganizationsと連携ができるようになります。 AWS CLIでも実行できますが、特に初めての方はマネジメントコンソールがわかりやすいです。
CloudFormationテンプレートの作成、CloudFormation StackSetsのデプロイ
AWS Config、IAM Access Analyzerはメンバーアカウントでサービスを手動で有効にする必要があります。
アカウントの追加時に自動で有効になってほしいこの2つは、有効にするCloudFormationテンプレートを作成しておきます。
それをCloudFormation Stack Setsとして登録しておくことで、アカウント追加時に自動有効化することができます。
※佐々木さんのブログより拝借しました。StackSetsの詳細はこのブログで書かれています。
各サービスのOrganizations機能有効化
これまでの記事で紹介してきた手順のとおり、各AWSサービスでOrganizationsを使用した集約設定をやっていきます。記事のとおりマネジメントコンソールでやるのもわかりやすいし、面倒な方はCLIでも良いと思います。ルートユーザの保護（MFA設定）は手動で行う必要があります。
一度設定すると変更する機会も少ないので、CloudFormationまで作るのは微妙かもしれませんが、複数のOrganizationsでやるには良いかもしれません。CloudFormationが各Organizationsの機能に対応しているかは確認する必要があります。
初期の設定はここまでやっておけば大丈夫かと思います。そのほか環境に応じて必要なサービスがあれば合わせて有効にすると良いでしょう。
新規アカウント追加時の対応
自動有効でもなく、CloudFormation StackSetsでも有効にできない以下のサービスおよび設定はアカウント追加時に手動で作業を行う必要があります。
- ルートユーザーの保護
- AWS SSO(IAM) ⇒必要に応じて権限セットも追加
- AWS Budgets ⇒予算額を設定して設定。組織のみで管理であれば不要
- Detective ⇒1アカウントに集約する場合は招待、承認の作業が必要
SSO、Budgetsは本来アカウント単位で権限や予算を設定すべきものなので、手動なのは仕方ないかなと思います。
ルートユーザーの保護は、悩ましいです・・。作成時は利用者がわからない自動生成されたパスワードが設定されますが、 きちんと手動でMFA設定が良いと私は考えています。
Detectiveは、そのうちOrganizations対応すると思いますｗ
今後期待する新機能
一つ前に書いたルートユーザーの自動保護と、DetectiveのOrganizations対応に期待しています。
また、請求情報をまとめたり、ボリュームディスカウントを効かせるために、プロジェクトA、プロジェクトBといった複数プロジェクトを1つのOrganizations組織に入れることも多いのですが、この場合AWS SSOやセキュリティサービスはプロジェクト単位で実施したくなります。
※ボリュームディスカウントやSavingsPlansの割引は、組織全体で効かせることができます。
紹介したサービスはOrganizationsの1組織全体で行う前提なので、今後、たとえばOU単位でサービスの設定ができたり、複数のOrganizations組織の請求部分だけ1つにまとめるといった機能に期待しています。
さいごに
Organizationsを活用したサービスシリーズ、10サービスについて書きました。謎の達成感を感じております。
今回はセキュリティをトピックにサービスをピックアップしましたが、他のサービスでもOrganizationsは活用できます。
たとえばAWS Backupで使用すると組織単位でバックアップ管理ができたり、AWS RAM（Resource Access Manager）を使用してTransit Gateway等のリソースを組織内に承認なく共有できたりします。
アカウント間の連携で課題を感じる部分があれば、このOrganizationsを活用することで幸せになれることがあるかもしれません。
それでは良いマルチアカウントライフを！
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～10. Trusted Advisor～
Organizationsシリーズ第十弾、Trusted Advisor編です。
今回でサービス別の紹介は最後になります。
AWS Trusted Advisorとは
AWS Trusted Advisor（以下Trusted Advisor）を使用すると、AWSが推奨するベストプラクティスに従い、以下5点の観点でアドバイスを受けることができます。セキュリティのサービスというよりは、セキュリティのアドバイス機能を含むサービスという感じです。
- コスト
- パフォーマンス
- セキュリティ
- フォールトトレランス
- サービス制限
すべてのチェック結果を確認するためにはビジネスサポート以上のサポートプランが必要です。
Organizationsを使用したマルチアカウント設定
Trusted AdvisorはOrganizationsに対応しているため、複数アカウントの情報を1アカウントに集約できます。アカウントの委任には対応していないため、確認はManagement（親）アカウントで行う必要があります。
Organizationsを使用した組織ビューを有効にするには、Managementアカウントでビジネスサポート以上のサポートプランに加入する必要があります。
また、組織ビューは単体アカウントで確認するときのように画面上から情報を見るのではなく、レポートとしてJSONまたはCSV形式でダウンロードする機能のようです。今後は画面上で見れる機能も追加されるかもしれません。
設定手順
設定方法は簡単です。Trusted Advisorの画面から、組織ビューを有効化するだけです。
有効化すると、レポートを作成できるので作成してみます。
レポートの形式や含める情報を入力します。今回はCSV形式で、すべての情報を含めます。
レポート対象のアカウントを指定します。今回はすべてのアカウントを含めるためRootを選択します。
アカウントの一覧はOUごとに表示され、OU別で選択もできます
しばらくするとレポートの作成が完了し、ダウンロードできるようになります。
レポート名をクリックすると、要約を表示できます。
以下のように要約が表示されましたが、Managementアカウントのダッシュボードの数よりも少ないため、情報が一部反映されていないように見えます。
ダッシュボードは以下のとおりで、↑の要約よりも多くなっています。
どうやら、反映に時間がかかるようで、5日ほどたってまた見ると以下のようにGreen以外は一致していました。
Greenについては、AWS公式ドキュメントに以下の記載があり、組織ビュー側では表示されない項目があるようです。
一部のチェック項目では、リソースが Red または Yellow である場合にのみ表示されます。すべてのリソースが Green である場合は、レポートに表示されない場合があります。
次にレポートをダウンロードしてみます。
以下のように検知されたアカウントID、チェック内容がCSVファイルとして出力されます。
このままでは見にくいので、Excelでうまくまとめるか、JSONでS3に格納してAthenaやQuickSightで可視化するなどの工夫が必要そうです。
CSV以外にも以下の2ファイルがセットでダウンロードされます。
ダウンロードしたレポートには、Managemenetアカウントの情報しか含まれませんでした。 AWSサポートにも確認したところ、Managemenetアカウントだけではなくメンバーアカウントの情報も含まれるとのことでしたが、反映に時間がかかっているようです。
今後はこの更新が早くなると良いですね。
※5日後にダウンロードしたレポートも、メンバーアカウントの情報は含まれませんでした。
検証はここまでです。
さいごに
現時点では、組織全体の情報はCSV or JSONのレポートダウンロード形式となるため、きちんと分析するためにはもうひと工夫必要そうです。 まだOrganizationsに対応したばかりのため、今後、有効化するだけでいい感じに見えるようになるかもしれませんね。期待です。
次回はこれまでのサービスのOrganizations対応をまとめて振り返りたいと思います。
July Tech Festa 2021 winter で Infrastructure as Codeについて話をしてきました
AWS Organizationsシリーズは今回一旦休憩です。
1/24(日)に行われた、インフラエンジニア向けのカンファレンスJuly Tech Festa 2021 winterでお話しました。せっかくなのでブログにも内容をまとめます。
発表資料
なぜこのテーマでしゃべろうと思ったのか
Infrastructure as Code（以下IaC）は、構築や環境の複製を楽にするもの。
だけではない！
インフラ環境の品質UPにもつながるはずだ！と私は信じております。
私はオンプレミスのインフラ構築も多く行ってきており、手動のインフラ構築・運用も行ってきました。IaCでは多くの手動管理の課題が解決できるなと感じているのですが、まだまだIaCが浸透せずに手動管理となっている現場を多く見かけます。
この発表をきっかけにIaC始めてみよう、難しくないんだ！と思ってもらえると良いなと思い発表に至りました。（CFP通って良かった）
発表内容
資料を貼りながら補足部分を書いていきます。
対象は先ほど書いたとおりIaC初心者としております。ここでいう初心者とはインフラ・クラウド構築の初心者ではなく、AWSなどクラウド環境の構築経験はありつつも、手動管理を行っているIaC初心者ということになります。
IaCを使わない手動インフラ管理
まずはIaCを使わない場合（＝手動でインフラ構築、管理）どういった流れになるのかをお話しました。
最初はまずインフラってなんだっけというところです。
そしてインフラ構築の流れ。V字モデルですね。
手動管理では通常、パラメータ設計で設定するパラメータを決定しそれに従い構築、構築ができたら設計したパラメータ通りになっているかテストする。という流れで構築を行っていきます。
具体的なパラメータ内容は構築してみないとわからない部分もあり、設計と構築を行ったり来たりすることも多いですね。
手動管理の課題
1つ目の課題です。
この課題が1番わかりやすいかなと思います。すべて手作業になるため、環境数分の作業時間（手間）がかかります。
また、環境をコピーしている訳ではないため、すべての環境で想定通りのパラメータになっているかテストする必要があります。
実際の開発現場では、アプリ開発チームに、「開発環境もう一つ必要だから作って」と言われることもあります。予定してないから無理と断るか、同じ手間をかけて作るかの2択です。
2つ目の課題。
これも手動構築の現場ではよく見てきました。開発でうまくいっていた設定が、本番では入っていない！？というやつです。
こういった事象を無くすために、各環境できちんとテストをしていくのですが、テストするのも人間であるため、100%ミスを無くすのは難しいです。
3つめの課題。
設計どおり構築をしてもうまくいかない、本番運用中に障害があった場合、その場で急遽設定変更をします。その場でうまく動いたことがとても嬉しいので、たいていの場合設計書への反映が忘れられます。
「たいていの場合」は言い過ぎかもしれませんが、私もこういった経験はあり、「この設計書本当にあってるの？実環境見てくるわ」ということもありました。今でもオンプレ環境だとあったりしますね。
4つめの課題。
「設定の履歴が残らない」です。
これが無いとどういった場合に困るのか、というところですが、たとえば、ファイアウォール（SGでもOK）で見知らぬIPアドレスからアクセス許可の設定が入っていたとします。 IPアドレスの値が入っているのみで、どこのIPアドレスなのかわかりません。
そうなると、誰が、いつ設定したんだ？となりますが、改定履歴がないとそれを聞く相手もわかりません。
そして、その設定は消していいのか、変更していいのかわからないため、怖くていじれなくなります・・
ということでいつ、誰が、何のために設定したのか履歴情報を残すことはとても重要です。
が、資料管理をきちんとやるのはとても難しです。人により履歴の書き方も変わってきます。
ということで課題4つ紹介しました。
IaCが解決する課題
いくつかIaCのツールはありますが、今回はAWSのCloudFormaitonを前提としてお話しました。
1つ目の課題解決。
1番わかりやすいIaCのメリットかと思います。テンプレートベースになるので環境の複製が容易にできますね。
2つ目の課題解決。
1つ目と似ていますが、ここは品質観点です。同じテンプレートベースになるため、環境間で差があるといったミスが発生しにくくなります。
ポイントとして書いているリソースを同一にというのは、たとえばサブネットの数が本番と開発で異なると、テンプレートも環境ごとに書き換えたり工夫をする必要があります。サブネット数など料金に影響を与えない部分は基本的に全環境同じにしたほうがテンプレートとして書きやすいのでおススメです。
また、人のミスを減らすという目的においては、CloudFormaitonのデプロイ作業もパイプラインからコマンド経由で行ったほうが良いです。
3つ目の課題解決。
これは、リポジトリで管理しているテンプレートから正しくリリースしている前提になりますが、実環境を見に行かなくても、テンプレートを見れば設定内容がわかるという点です。
特に運用する方にとって嬉しいポイントかと思います。
4つ目の課題解決。
IaCをGitリポジトリ管理にすることで、強制的に履歴を残せます。
コミットメッセージについては組織でルールを決めて正しく運用でカバーする必要がありますが、少なくとも「誰が、いつ」という情報は残るようになります。その人に聞きにいくことができますね。
課題の解決まとめです。
元々あった課題が完全に無くなるわけではないですが、かなり減らせる部分はあると思います。
CloudFormationの使い方
実際の書き方に入っていきます。
まずパラメータシート。手動管理の場合Excelを使用して以下のような資料を作りますね。VPCを例としています。
これをCloudFormaiton（YAML）で書くとこうなります。（右側）
太字で書いている部分が一番のポイントです。パラメータシートの場合も、CloudFormaitonの場合も書いている内容はほぼ同じです。
おそらくここで難しいと感じる場合は、CloudFormaitonが難しいのではなく、AWSの設定がわからなくて難しいと感じているのだと思います。
CloudFormaitonはYAMLの場合コメントも残せるため、設計で大事となる根拠や補足なども書き込むことができます。
CloudFormtaionのポイント
書き方を覚えたら活用のポイントです。
まずParameters。ほぼ必須で使用する機能です。
環境ごとに変わる値（名前で使用する環境名Env、VPCのCidr）をParametersとして別出ししています。
コードも貼っておきます。
Parameters: Env: Description: "Environment" Type: String Default: "dev" VpcCidr: Description: "VPC CIDR" Type: String Default: "10.0.0.0/16" Resources: vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: !Ref VpcCidr InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${Env}-sys-vpc"
次にテンプレートの分割です。実際の運用では1システムすべてを1テンプレートで書くことはあまりなく、いくつかのテンプレートに分割します。
たとえばネットワークのまとまりであるVPCやサブネットを1テンプレートにしたりします。
一方で、VPCの情報は他のリソースでもIDをインプット情報として与える必要があるため、テンプレート間で参照できる必要があります。
そこで紹介したのがOutPutとImportValueの機能です。
コードは以下のとおりです。
- VPC（参照される側）
Outputs: vpc: Value: !Ref vpc Export: Name: vpc
- Security Group（参照側）
Resources: SecuritygroupEC2: Type: "AWS::EC2::SecurityGroup" Properties: GroupName: !Sub "${Env}-ec2-sg" GroupDescription: "for EC2" VpcId: !ImportValue vpc
その他には、SSM Parameter StoreやSecrets Managerを使用するやり方もあります。
次からは運用面。
テンプレートのデプロイやテストも人の手から離れて自動化したいため、以下のようなパイプラインを作ります。
パイプラインの要素ごとに見ていきます。まずはChange Sets。
aws cloudformation deployコマンドを実行すると、すぐさま変更が反映されるのですが、CloudFormaitonでは重要なリソースを管理している場合も多く、変更対象を間違えると意図しない変更や削除が発生する可能性もあります。
そのために本番環境へ反映される前に、事前に反映予定の内容を確認できる機能がChange Setsです。本番環境のパイプラインでは入れることをおススメします。
つづいてCloudFormaitonのテストツール。
cfn-nagやcfn-python-lintはコード解析のツールであるため、テンプレート開発中もローカルで実行することができます。各テストツールのリンクを貼っておきます。
TaskCatは、実環境にデプロイできるかという観点でテストができます。CloudFormaitonはテンプレート内容としてOKでも、実際の環境によってNGになることもあるため、デプロイを事前確認することで品質UPにつながります。
パラメータチェックのツールです。
たとえばCLIでVPCの情報を見たい場合はaws ec2 describe-vpcsというコマンドで確認できます。
awspecはテスト用のツールです。
以下のように書いてVPCのあるべき状態を書いてテストが可能です。
require 'spec_helper' describe vpc('my-vpc') do it { should exist } it { should be_available } its(:cidr_block) { should eq '10.0.0.0/16' } it { should have_tag('Name').value('my-vpc') } end
テスト手法について書きましたが、2つ目に書いたパラメータチェックは必要なのかというところについての考察です。
どちらが正解という結論はここでは出していませんが、私としては、IaCではテンプレートの内容がとても重要になるため、できればまず複数名でレビューを行って、テンプレートの品質UPを目指すのが良いと思っています。
テストツールを使ってパラメータチェックをするのも良いと思いますが、全パラメータをやみくもにチェックするのではなく、ポイントを絞って方針を決めることをおススメします。
たとえばセキュリティに関わるところとか、環境ごとに差が出そうなところです。
テストケース数や実施状況を報告しなきゃいけないという状況となり、関係者の品質共通認識としてテストツールを使うことが良い場合もあるかと思います。
まとめ
少しでもIaCで解決できそうな課題がありましたら是非ご使用を！
手動管理をやってきたインフラな方は、CloudFormaitonが取っ付きやすいと思います。
いただいた質問
「Go Formationのように、プログラム言語でCloudFormationを書く機能もあるがそれについてどう思うか。」
という質問をいただきました。ありがとうございます。
CloudFormation、全設定を見るという面では非常に優れていると思うのですが、これがツライ部分もあります。 たとえばマネジメントコンソールでは自動設定くれる場所も書かないといけないので、記述量が多くなりがちです。
また、ループのような処理もCloudFormation単体では難しいです。
そういった記述の柔軟さで言うと、Terraformのほうが優れているかなと思います。
AWS CDKも使ってみたいです。
ただ、組織全体で考えると、まだIaCに慣れていないメンバーがいる場合は、CloudFormationが入りやすいと思い選ぶことが多いです。
自分1人であれば、次はCDKで頑張ってみたいなという気持ちもあります。
登壇してみて
私にとってはとても大きなイベントでの登壇でした。
他の方の発表はとても専門性が高くて素晴らしく、私のはあまり見られないなと予測しておりましたが、それなりに見ていただけて良かったです。
運営されていた方、発表された方、視聴してくれた方、機会をいただき本当にありがとうございましたm(__)m
アーカイブされたらほかの方の発表もじっくり見たいと思います。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～9. Personal Health Dashboard～
Organizationsシリーズ第九弾、Personal Health Dashboard編です。
AWS Personal Health Dashboardとは
AWSアカウント内のAWSリソースの障害やイベントが発生した（する）場合に、このPersonal Health Dashboardを経由して通知されます。アカウント内のリソースではなく、AWSサービス全体としての稼働状況はService Health Dashboardとして公開されています。Service Health Dashboardの内容（パブリックイベント）は、Personal Health Dashboardにも表示されます。
たとえば使用しているEC2インスタンスが稼働するハードウェアの障害であったり、RDSのメンテナンス予定日や内容がこのPersonal Health Dashboardに表示されます。
セキュリティサービスなのか？と言われると微妙なところですが、大事なサービスなので書いておきます。
Organizationsを使用したマルチアカウント設定
Personal Health DashboardはOrganizationsに対応しているため、組織内の全アカウントの障害やメンテナンス情報を一括で表示できます。
ただし、アカウントの委任には対応していないため、イベントの確認はManagement（親）アカウントで行う必要があります。
設定手順
組織ビューを有効にするところだけやってみます。というのも、特に私の検証環境では通知されているイベントが無いので、アカウント間の通知確認は現状できませんでした。（サンプルイベントも思いつかず）
Personal Health Dashboardの画面へ遷移し、組織ビュー（organizational view）を有効にします。
Successとなり、組織ビューのメニューが追加されています。
DashBoardは以下のようになっています。特にissueは無いですが、きっとAWSリソースの障害やメンテナンスがあるとここに表示されるはずです。 見え方はシングルアカウントのときと同様ですね。
Event logは以下のように表示されています。ここに表示されているのはAWS全体のパブリックイベントですね。過去の障害情報が表示されていました。
短いですが設定検証はここまでです。
さいごに
組織ビューを有効にするだけだったため、すぐに終わってしまいました。障害イベント等見せれずですいません。
AWS側の障害は、CloudWatch等の監視では気づけない場合もありますので、通常の監視と合わせてPersonal Health Dashboardの監視も行いたいところです。
次回はTrusted Advisorの予定です。
