３年目社員がAWSトレーニングを受けた話
こんにちは！システム開発部の河井です。
エンジニアとして働き始めて早2年。尊敬する先輩や良い後輩に恵まれ、日々充実した社会人生活を送っています。
さて、約1年ぶりのnote投稿。
何を書こうかなぁ…とネタに困っていたところ、親切な先輩が「この前受けていたAWSの研修のこと書けば？」と一言。
と言うのも、私はつい1か月ほど前に、AWSトレーニングというAWS公式の研修を受けたばかりだったのです。
確かにちょうど良いネタかも！とその一言に感謝しつつ、今回は「AWSトレーニング」をテーマに書き進めることとしました。
この記事が、AWSトレーニングの受講を検討されている方や、AWSの勉強を始めようと思っている方の一助となれば嬉しいです。
AWSトレーニングとは？
AWSとはAmazon社が提供するクラウドコンピューティングサービスの総称で、AWSを利用すれば、物理サーバーを自社に設置することなく、短時間でのインフラ構築が可能になります。
それだけではなく、AWSで提供されているサービスを組み合わせて利用することで、様々なケースに対してより容易に構築・管理することができます。
そしてAWSトレーニングとは、AWS公式から認定を受けたインストラクターがAWSの利用方法等を教えてくれるというもので、レベルや目的別に複数のコースが用意されています。
その中で、私が受講したのは「Architecting on AWS」という設計者向けの中級コースです。
受講の目的
受講に至ったきっかけは社内で数名受講できることになり、上長から運良く声をかけてもらい、受講します！と回答したのがきっかけです。
ただ、受ける以上は目的が必要です。
「AWS公式のベストプラクティスを学び、実務に活かす」
というのが、上長から提示された目標でした。
しかし、実務に活かす、と一口に言っても具体性を持たせないといけないなぁと思い、私なりに「AWSの構成図が書けるようになる」ということを受講の目的としました。
受講前の知識レベル
受講にあたって、私には1つだけ問題がありました。
それは、こちら↓
前提条件
このコースを受講するにあたっては、次のことを⾝につけておくことをお勧めします。
AWS Cloud Practitioner Essentials または AWS Technical Essentials の修了
分散システムの実務的知識
⼀般的なネットワークの概念に関する知識
IP アドレス指定に関する知識
多層アーキテクチャの実務的な知識
クラウドコンピューティングの概念に関する知識
出典：
https://d1.awsstatic.com/ja_JP/training-and-certification/classroom-training/architecting-on-aws.pdf（最終閲覧日：2024年4月4日）
前提条件を満たしていない…。
ネットワークやIPアドレスに関する最低限度の知識があったとしても、入門～初級レベルのコースである「AWS Cloud Practitioner Essentials」または「AWS Technical Essentials」受講済みレベルの知識が十分にあるとは到底思えませんでした。
受講前に私が知っていたことと言えば、
RDS for Microsoft SQL ServerのSSL証明書更新等のメンテナンス方法
CLIでS3にファイルをアップロードする方法
IAMユーザの作成方法
など、断片的な情報ばかり。
AWSの体系的な知識が足りていないのです。
これではまずい。せっかくの講義が馬の耳に念仏になってしまう…。
そんな焦りを感じた私は、受講1か月前にして、応急処置的に1冊の入門書を読みました。
私の性格上、途中で疑問が浮かぶと検索し始めて、納得するまで調べ続けてしまうせいで、ざっと読み終えるのに1日どころか3週間はかかってしまいましたが、これでAWSの各種サービスの概要を俯瞰できました。
受講内容
そうして迎えた受講当日ですが、結果的には、危惧していたような「？？？」状態にはならずに済みました。
その理由は、直前の詰め込み勉強の賜物…というよりは、講師の初心者にも優しい説明のおかげでした。
ただ、毎日7時間みっちりの講義が3日間続いたので、疲労感はすごかったです。
トレーニングの形式はオンラインで、基本的には講師の説明を聞き、時折ハンズオンで環境構築を実践するという感じでした。
内容は以下の通りです。
アカウントのセキュリティ（IAM）
ネットワーク/コンピューティング（VPC・EC2）
ストレージ（S3）
データベースサービス（RDS・Dynamo DB）
モニタリングとスケーリング（CloudWatch・ELB）
オートメーション（CloudFormation）
コンテナ（ECS）
サーバーレス（Lambda）
エッジサービス（CloudFront）
バックアップと復旧
学んだこと
AWSサービスの具体的な中身については、ネットにいくらでも情報が転がっていると思うので、ここではトレーニングを通して得た「考え方」を紹介したいと思います。
ベストプラクティスは枷ではない
トレーニングの序盤には、AWS Well-Architected フレームワークと呼ばれるベストプラクティス集の説明がありました。
Well-Architected フレームワークには6つの柱があって…などと説明が進む中で、講師が唐突にこう言いました。
「別に最初から膨大な数のベストプラクティスを考慮する必要なんてありません」
それを聞いて、虚をつかれました。
私はてっきり「設計時にきちんとベストプラクティスを取り入れるべきだ」といった類の話をされるものと思っていたからです。
考えてみれば確かに、設計時にすべてのベストプラクティスを把握して取り入れるのは現実的ではないし、工数がかかりすぎます。
そのせいで、AWSの強みである「すぐに」環境を構築できるという点を損なっては、本末転倒なのです。
だから、運用しながらより良い形に変えていく。
ベストプラクティスに縛られすぎずに、後からでも柔軟に対応できる点がAWSの特長なのだと感じました。
誰がやっても同じ結果を
これは、CloudFormationというサービスの紹介時に感じたことです。
CloudFormationは、AWS環境をテンプレート化して自動で構築できるというもので、テンプレートを使い回すことで、何度でも同じ環境を作り出せる点が利点です。
つまり、それを使うことで、特定の技術者しか扱えない、といった属人化の状況を防ぐことができるのです。
私は入社して2年間、作業を「こなす」ことに注力していて、「仕組化」するという点にはあまり目が向いていませんでした。
CloudFormationの説明を通して、「自分以外の人がやっても同じ結果を生み出せる」状態を作っていく意識が大切なのだと気づかされました。
おわりに
書き始めたら、あれも書いてこれも書いて…と大変な長文になってしまいました。
ここまで根気よく読んでいただいてありがとうございます。
今回、以前から興味があったAWSを学ぶ機会をいただき、とても感謝しています。
今後もAWSを勉強し続けて、業務でもしっかり扱えるようになりたいなと思っています。
ユニゾンシステムズでは、一緒に働く仲間を募集しています。
ぜひ一度オフィスに遊びに来てみませんか？お気軽にDMもお待ちしています！
求人の詳細はこちら: https://www.unixon.co.jp/recruit/
Youtube: https://www.youtube.com/channel/UCGacmgfpJ0fkHC0aKrSppVw
Twitter: https://twitter.com/unixon_recruit
この記事が気に入ったらサポートをしてみませんか？