お知らせ
2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。
関係者各位のご協力に深く感謝いたします。
タイトル：AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ
本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました
チームで技術書を出版して学べた共同執筆メソッド
はじめに
インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。
背景
パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。
しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。
このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なスキルセット、および前提となるオンプレ知識や各種ツールの学習順序を提示します。
今自分がどこにいるのか？次は何を学習すべきか？
インフラ・クラウド領域の大海原を渡り歩くための海図としてお役立てください。
■初学者の方へ
- AWS学習の全体像が把握できます
- 学習順序に迷わず、安心して独学を進められます
■育成者の方へ
- エンジニアの育成指導に役立ちます
制作メンバーについて
当ロードマップ制作にあたり、協力いただいた皆様には深く感謝いたします。
■ルビコン (MENTAで上位1%のゴールドメダル認定メンター / AWSクラウドエンジニア / フリーランス＆起業 / CloudTech公認メンター / AWSの個別相談・個別指導が強み / Twitter＝駆け出しエンジニアの頼れるお兄さん)
■小澤 聡(富士山が育んだおじさんエンジニア / 立命館大学ラグビー愛好会出身/ 田舎が好き・釣りが好き / 一瞬でもいいから同級生の渡部陽一くんよりバズりたい)
■Kento.Yamada (自分をフルスタックエンジニアと信じて止まない一般男性 / 株式会社KDDIエボルバ ITスペシャリスト / 雑食系オンラインサロンAWS部部長 / AWS CloudTech 道場チャンネル主催 / Twitter / 発言は個人の見解)
■久保玉井純（AWS認定講師 / 沖縄県最大の専門学校の先生 / ラーメン戦士 / 学生は無料のAWS教材を提供中 / Twitter）
■yusuke.aoki（株式会社Olive）
■井上嵩章(某SIerのフロントエンジニア/Twitter)
■たかくにしんのすけ (クラスメソッド株式会社)
■tokku(某SIerのインフラエンジニア/プロフィール/Flutter Guild Japan/Twitter)
■mikawaya (夢に向かい日々奮闘する40代おっさんエンジニア/マインドマップの使い手)
■くろかわ こうへい (エンジニア系YouTuber / 株式会社KWS代表取締役 / 日本最大級のAWS有料学習サービス「CloudTech」運営 / Twitter)
Special Thanks!
瀬山政樹さん(AWS Top Engineer100)、フランさん、和田担当部長(コムチュア株式会社)
ロードマップ
YouTube動画でも解説しました！YouTubeはコチラ
【2021/7/5 追記】
JAWS-UGから登壇オファーをいただき記事を紹介しました！
登壇したYouTubeのリンクはコチラ
##補足
- 上から下に学習を進めるのを推奨しますが、途中の興味があるサービスから始めたり下から上に進んでもOKです。
- 進め方に正解はありません。あなたの目的や実務環境に合わせてアレンジして下さい。そもそも学習に正解を求め過ぎるのは良くないです。
- 目的を「いち早くロードマップ通りに学習を完了すること」としないでください。
学習は他人とスピードを競うものではありません。
皆同じような行動を求める学校教育の弊害により、早く正確にできる人が賞賛され、ゆっくりと自分の考えを深める研究的な学習は「マイペース」と揶揄されがちですが、あなたなりの学習方法が必ずあります。ぜひとも挑戦する心を失わずに自分の学習スタイルを研究し続けてください。
AWS Basic 基礎知識
What's AWS and Cloud?
Amazon Web Services (AWS) は世界シェア第1位の クラウドコンピューティングサービスおよび、サービスを展開している企業です。
AWS(クラウド)はインターネットを介してコンピューティングリソース（サーバー、ストレージ、ネットワーク機能など）をユーザー(我々)に提供してくれます。その対価としてサービスの利用した量に応じての金額を支払います。これにより従来型のITでは「所有」の概念であったコンピューティングリソースが、クラウドの登場により「利用」の概念にシフトされつつあります。
-
従来型のITの考え方
- 所有: 自分自身でサーバーを購入し、運用・保守点検を自身で行う。運用の柔軟性が高いものの、予め想定したピーク量の推定が必要であり、また購入までの時間的なコストが高い。
- たとえるなら：自分で選択したグレードの車を購入し、自分で運転し目的地へ向かう。
-
クラウド型のIT の考え方
- 利用：クラウドサービス上に展開されたリソース、およびサービスを利用し、利用した量に応じて金額を支払う。柔軟なスケール変更が即座に可能である一方で、クラウドベンダーの計画に合わせたメンテナンス・アップグレードに追従する必要がある。
- たとえるなら：状況に合わせた公共交通機関を選択した後料金を払って利用し、目的地へ向かう。
リージョン(Region)、アベイラビリティゾーン (Availability Zones、AZ )
AWSは超巨大な分散型システムです。そのため世界中で稼働しています。世界地域での地理的な拠点単位は「リージョン(Region)」と呼びます。全てのリージョン間は地理的に離れていますが、常に高速なネットワークで繋がっています。
リージョンを構成するデータセンター群を「アベイラビリティゾーン（Availability Zones、AZ）」と呼びます。リージョンを構成するAZは最低2つ以上となっており、地理的に分散され、常に高速なネットワークで相互に繋がっています。
各リージョン、各AZに自由にリソースを配置させることができます。これによりリージョンやAZ規模の障害、地理的な要件・制約に対応をすることが可能です。「障害が発生しても動き続ける仕組み」、「直ちに復旧できる仕組み」を構築するうえで非常に重要な要素となります。
https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/
責任共有モデル
ユーザー(我々)とクラウドベンダー (AWS)でセキュリティおよび運用・保守における責任を持つ分界点の定義となります。
例えばEC2 (Infrastructure as a Service 、IaaS)における責任分界点は以下の通りとなります。 これは一例でありサービス内容で変化するため使用するサービス毎の定義を確認しておきましょう。
- ユーザー：ミドルウェア、アプリケーション、データ
- AWS： OS 、ハードウェア、ネットワーク
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
AWS Well-Architected フレームワーク (W-A)
AWSが長年の運用によって導き出したクラウドでのITアーキテクチャを考える際のベストプラクティス集となります。以前は「運⽤上の優秀性 」、「セキュリティ」 、「信頼性」、「パフォーマンス効率」、「コスト最適化」、の5つの原則でしたが、近年「持続可能性」が追加され6つの原則になりました。これらはクラウドをより活用するための設計原則と、システム構築に関するベストプラクティスに沿っているかを確認するための質問と回答で構成されています。
なお6つの原則を全て盛り込む必要はありません。一番重要なことはベストプラクティスとリスクを理解した上でビジネス判断でW-Aの6つの原則を取捨選択すること、そしてW-Aによって顕在化したリスクや改善方法を企業・チームで認識することです。
英語版
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf
旧版(5つの柱のみ記載バージョン)
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf
EC2
EC2とはElastic Compute Cloudの略でAWSの仮想サーバーサービスです。
EC2を理解するためにはサーバーの構成要素を分解すると学びやすいでしょう。
各構成要素とAWSサービスを対応付けると以下の通り
- CPU,メモリなどのスペック = インスタンスタイプ
- HDD,SSD = EBS
- OS,その他設定情報 = AMI
EC2は自由度が高いですが、その反面コストが高くなりがちです。
時間単位の利用料金に加えてウィルスソフトなどのセキュリティコストや運用管理コストも必要となるケースがあるので注意しましょう。
デフォルトのオンデマンド以外の購入方法の特徴（リザーブド・スポット）や使いどころを理解すればコスト削減に繋がります。
基本的なLinuxコマンド、および後続のネットワークの知識も必須です。
一説によるとAWSで稼働しているEC2インスタンスのOSタイプはLinuxとWindowsが半々のシェアと言われており、Windows Serverの構築・運用スキルがあると強みになるでしょう。
Windows Server独自のトピックを次にまとめました。
Windows Server
EC2上でもWindows Serverを動作させることが出来ます。.NET Frameworkを利用して作られたアプリケーションを動作させる場合や、エンタープライズ向けのOA基盤(企業内のアカウント、メール、ファイルサーバー、Microsoft Office製品などを配布・管理する基盤)はまだまだWindowsが主流であることから、ある程度規模の大きいプロジェクトに参画する際にはWindowsの基礎的な知識習得は必須と言えます。
GUIでの操作が主になるので、初学者にとってLinuxよりもとっつきやすいと思いますが、WEB/APサーバーであるIIS(Internet Information Service)、タスクスケジューラによる定期実行、WSFC(Windows Server Failover Cluster)によるクラスタリングなど、出来ることは多岐に渡るので必要な機能を一つずつ覚えていけば良いかと思います。
また、LinuxやMacのターミナルとコマンド体系が根本的に異なるので、コマンドプロンプト(cmd)での基本コマンドの習得や、PowerShellの習得をやっておくと尚良いです。
OA基盤(企業のPC、Officeソフト、メール、プリンターなど、一般的な業務で扱う機器を使えるようにするITインフラ)の構築や運用に携わったら必ずActive Directoryというサーバーを扱うことになります。企業内のコンピューターやユーザーの管理を一挙に担うことから重要度が高いサーバーですが、習得するにはLDAP(ユーザーやコンピューターの集中管理を行うためのプロトコル)とDNSの基礎を身に着け、その上でActive Directory特有の考え方を身に着ける必要がある、難易度の高い技術要素となっています。Microsoft365(旧Office365)やMicrosoft Azureとの連携でもフェデレーションサービスとして扱うことになる技術ですので、Windowsを極めたい方は勉強してみるのもいいかと思います。
VPC
VPCはAWSの仮想ネットワークサービスであり、地域（リージョン）毎にアカウントと紐づいた仮想的なネットワーク空間です。
1つのアカウントで複数のVPCを作成することができます。
たとえば勉強用、本番稼働用、検証用とネットワークの環境を分けて運用することが可能です。
VPCの主な機能
- 外部インターネットとの接続を行う「InternetGateway」
- VPC内のネットワークを細分化する「Subnet」
- ネットワークの通信経路を設定する「Route Table」
- セキュリティ機能である「Security Group」や「NetworkACL」
他にもVPC同士を接続する「VPC Peering」や「Endpoint」「ENI」や「EIP」などの機能もあります。
AWS上で作成したサービスをインターネット上で公開したり、AWSとオンプレミスをVPNや専用線で接続するなどVPCの知識はAWSを利用する上で必須となりますので、AWS学習の各種サービスの中でも特に優先度を高く設定した方が良いでしょう。
TCP/IPを始めとしたネットワークの基礎知識があれば容易に設定できると思います。
AWSに限りませんが、Webサーバやデータベースサーバーなどのシステム運用においてもネットワークの知識は重要な要素となるため、VPCと並行してネットワークの基礎知識も学習することをお勧めします。
参考：Amazon VPCとは？
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html
IAM
IAMとはIdentity and Access Managementの略で、AWSの認証管理サービスです。
従来のパスワード認証の制御と違ったロールベースアクセス制御 (RBAC)の概念がポイントとなります。
ユーザー（またはAWSリソース）に対して直接操作権限を与えずロールを通して操作権限を与える方法です。
ロールは操作許可ポリシーを複数アタッチして権限をひとまとめにした単位であり、「何ができるか？」という側面と「誰がこのロールを使用できるか？」を決める「信頼関係」の側面があります。
これにより、各人のアクセス権の管理は「このロールは誰が使用可能か」を適切に割り当てることが中心となるため単純化できます。
権限関連のエラーが発生した際にIAMの知識がなければ原因究明は非常に難しいものとなります。
そのため、最低限IAM独自のポシリーの要素（Effect, Principal, Action, Resource, Condition）は読み解けるようにしましょう。
権限エラーを回避するために「とりあえずルート権限を付与する」考えは改めるべきです。
IAMのベストプラクティスに「最小権限の原則」があります。
ユーザーやロール作成時はデフォルトで何の権限も持っておらず、必要に応じてアクセス権限を追加する原則です。最初に強力な権限を与えておいて徐々に絞るのはセキュリティ的に推奨されるものではありません。
AWSのベストプラクティスを定期的に見直し、システム運用がそれに沿っているかどうか振り返るのが重要です。
AWS CLI
AWS CLIはAWSリソースをCLIベースで操作するためのオープンソースのツールです。
Linux, Windows, MacOSなど様々なOSに対応しており、ローカルPCにインストールしてAWSリソースを操作することが可能です。
Amazon Linux2を使用したEC2インスタンスではデフォルトでAWS CLIがインストールされているため環境構築不要で学習する事が可能です。
AWS CLIを使用してAWSリソースを操作する際は、IAMユーザから生成される認証情報の文字列（アクセスキーとシークレットアクセスキー）を用いて認証する方法があります。
万が一アクセスキーとシークレットアクセスキーが漏洩すると、第三者からリソース操作（設定した権限に応じた操作。例えばリソースの作成、情報取得、削除など）が可能となるため取り扱いには注意しましょう。
AWS CLIはバージョンが1系・2系の2種類存在しますが、基本的には最新のバージョン2系を学習しましょう。
学習方法としてはマネジメントコンソール(GUIベース)で学習したチュートリアルをAWS CLIで再現するなどの方法がお勧めです。
なお、コマンドの量が膨大なため、全コマンドを覚えようとするのは現実的ではありません。
実現したいコマンドやオプションを公式ドキュメントから素早く引けるようにしましょう。
また、マネジメントコンソールで設定出来ないことがAWS CLIで可能になるケースもたまにあります。例：AWS Config Delivery 配信チャネルを再作成するケース
参考：
公式リファレンス（英語表記ですが諦めずにファイトです！）
ローカルPCでのAWS CLI環境構築
RDS
RDSはAWSでデータベース(DB)をフルマネージドで使用するためのサービスです。
データを取り扱う手段として、ほぼ全てのシステムが何かしらのDBを使用しています。
このため、システム開発する上でDBの学習は必須といえます。
特にMySQLに関しては、以下の理由により今後も重要なRDBであり続ける可能性が高いと思います。
まずはMySQLを題材に学習を始めるのが良いと思われます。
- スケーラブルなWebアプリケーションに最適な選択肢
- LAMPスタックに標準で含まれている
- 一般的なコンテンツ管理システム(Drupal、Joomla、WordPress)は MySQL に依存している
直近で使用するDBがわかっているのであれば、それを選択して学習することも良いかと思います。
- Oracle Database：有償のDBであり、他のDBと比較するとコストがかかる為、主に日本では構築予算に余裕があるSIer系の企業で使われるケースが多い
- PostgreSQL：無償のDBであり、おおきな特徴としてはBSDライセンスという非常に緩やかなライセンスを採用している為、非常に扱いやすく商用環境で利用される場合もある。
また、Heroku標準で利用されるデータベースでもある。
PostgreSQL派生のDWH向けエンジンとしてAmazon Redshift、Netezza等がある。このため基礎として学習しておくのもあり。
フルマネージドであるRDSを使用することを考えますとDBの非常に詳細な部分まで理解しておく必要はないと思いますが、基本的な部分は理解し、最低でも独自で構築・運用できるレベルにはなりたいものです。
また、可能であればアプリ開発での利用に対応するための知識習得ができると尚良いかと思います。
CloudWatch
CloudWatchはリソース監視（モニタリング）サービスです。
AWSリソースによっては作成直後に自動で監視メトリクス（監視データ）がCloudWatchに送信され、CloudWatch管理画面から状態をグラフで確認できます。
CloudWatch監視エージェントをオンプレのサーバーにインストールすることでオンプレとクラウドの監視を一元化できます。
- CPU,メモリなど負荷状況の推移をグラフで可視化できる
- アラーム発砲の閾値を設定できる（CPU使用率が70%を超えたら発砲 など）
- 閾値超過に応じたアクションを設定できる（アラームメール送信、オートスケーリング発動など）
CloudWatch Logs
CloudWatchサービスの機能のひとつで、ログ監視に特化したサービスです。
EC2インスタンスのログやアプリケーションログを収集し、リアルタイムでモニタリングします。
特定の文字列の出現を監視して条件にヒットすればアクションを実行するといった基本的な監視機能を備えています。
データは蓄積するだけではなく、積極的に活用すべきです。CloudWatch Logsは収集したログをS3やKinesisなど他のAWSサービスへ連携できるので、ログ分析のための入り口の役割も担うことができます。
CloudWatch Events (Amazon EventBridge)
CloudWatchサービスの機能のひとつで、AWSリソースの状態変化（イベント）を監視するサービスです。
イベントとは、例えば「EC2が停止した」「EC2 Auto Scalingが発動した」などです。
発生したイベントがCloudWatch Eventsで予め設定したルールに一致した場合にアクション（Lambda発動、SNS発動など）を設定できます。
cron式を用いて定期的にアクションを発生することも可能です。この場合、タイムゾーンはUTCで判定されるため日本時間と9時間ズレがあるので注意しましょう。
CloudWatch Eventsは拡張サービスであるAmazon EventsBridgeに統合されています。将来的な機能追加はすべてAmazon EventsBridgeの方で行われます。CloudWatch Eventsは廃止されるわけではなく、名称がAmazon EventsBridgeに置き換えられる予定です。
https://aws.amazon.com/jp/eventbridge/faqs/
ELB (Elastic Load Balancing)
ELBはクライアントからのリクエストをLoad Balancing（負荷分散）してくれるサービスです。
オンプレの時代は高価な装置で、年間100万円以上するので勉強することも貴重でした。AWSでは安価に1ヶ月1,900円程度で使えます（それでも他サービスよりは高いかもしれませんが...）EC2やRDSと違い、停止して課金を避けることができないのでご注意ください。
ELBは4種類ありますが、良く使うのはHTTP/HTTPSに特化したALB (Application Load Balancer)、それ以外のTCP/UDPにも対応できるNLB (Network Load Balancer)です。ちなみにELBの"B"は「Balancing（分散サービス）」、ALBやNLBの"B"は「Balancer（分散装置）」で違うので、知っているとドヤ顔できるかもしれません。4種類の違いについては公式の https://aws.amazon.com/jp/elasticloadbalancing/features/ をご覧ください。
その他の特徴や機能についてまとめておきます。
- インターネットに向けて公開するELBと、VPC内部でしか使えない内部ELBの2通りある
- 後述するACMの証明書を使えば独自ドメインを使ったHTTPS通信が簡単に実装できる。セキュリティポリシーはデフォルトから変更してTLS1.0と1.1を無効にするのがオススメ
- 負荷分散先（＝ターゲット）は当初EC2インスタンスだけだったが、ALBではLambdaやECSコンテナなどにも分散できるようになった
- ALBではターゲットが正常でない場合に振り分けないよう、ヘルスチェックの設定が必要
- ALBではHTTPリクエストの中身（HTTPヘッダーやURLのパス）によって振り分け先を変えたり、HTTPからHTTPSへリダイレクトしたり、固定で403 Forbiddenや404 Not Foundの応答を返すこともできる
S3
S3とはAWSのサービスに含まれる機能のひとつで、「Amazon Simple Storage Service」の略称です。オブジェクトストレージサービスの一種であり、拡張性・安さ・耐久性を兼ね備えたクラウドストレージです。
- データ容量を気にすることなく保存することができる
- 1GBあたり0.025ドル（東京リージョン、スタンダードストレージ記事執筆時点の価格）
- 99.999999999% (9 x 11) の耐久性を実現するように設計されている
オブジェクトのファイル単位での出し入れが可能なので、その場に応じて自由な使い道が想定され、より柔軟なデータ保存が実行できるのも特徴です。
データ加工や分析系の他AWSサービスとの連携も容易なため、データを一元的に集約保管するデータレイク（Data Lake）としてS3を利用することがあります。
また静的ウェブサイトホスティングの機能も備えており、様々なケースで利用可能です。
まずは、ストレージとしての利用(ストレージクラス/ライフサイクル管理/バージョニング機能/バケットポリシー etc.)、静的ウェブサイトホスティングとしての利用をメインに学習を開始すると良いでしょう。
データ転送料金について、S3へのアップロード（受信）、同一リージョン内の(AZ非依存な)AWSサービスとの転送料金は無料です。つまり同一リージョン内のS3間のデータ同期にともなうトラフィック料金はかかりません。
Route53
Route 53とは、AWSが提供するフルマネージド型のDNSサービスです。DNSとはドメイン名からIPアドレスを特定するためのプロトコルで、DNSがなければ現代のWEBアプリケーションは正しく動作できません。
単にEC2にパブリックIPアドレスを割り当てただけでも自動でドメイン名が割り当てられますが、AWSから自動で割り当てられるドメイン名ではなく、独自ドメイン名で運用を行いたい場合にRoute 53が必要となります。
Route 53ではドメイン自体を購入することも、別サービスで取得したドメインを指定することも出来、さらにルーティングポリシーを活用してLBの障害時にsorryページを表示させるような機能を実装することもできます。
一般的なDNSの知識(ドメイン、名前解決の仕組み)を理解し、その上でRoute53で提供されているルーティングポリシーの知識を身に着けると効率よく学習できるかと思います。
ルーティングポリシーの選択 - Amazon Route 53
DNSとは - JPNIC
CloudFront
Amazon CloudFront は、高い安全性と高性能な実現するプログラム可能なコンテンツデリバリーネットワーク（CDN）です。
- エッジサーバでコンテンツのキャッシングを⾏い、オリジンの負荷をオフロード
- Distributionで証明書を設定することにより、独自ドメインでのHTTPS通信を実現
- HTTPからHTTPSへのリダイレクト、IPv6、HTTPレスポンス圧縮もチェック一つで対応
さらに踏み込んで学習する際は、エッジロケーション、トランジットセンター、AWS Global Acceleratorなど他ネットワーク要素と組みあわせて理解するとより良いでしょう。
参考となるドキュメント：AWS のネットワークで知っておくべき10のこと
ACM (AWS Certificate Manager)
ACMはSSL/TLSサーバー証明書を無料で発行できるサービスです。他で有料で購入したSSL/TLSサーバー証明書をインポートして使うことも可能です。発行時に[ドメイン名]だけでなく、*.[ドメイン名]の別名も一緒に付けると1つの証明書でサブドメインにも使い回せます。
前述のELBやCloudFrontでHTTPS通信を提供するために使えます。ただしEC2を直接公開する場合には使えないのでご注意ください。
証明書発行時にDNS検証を使うと有効期限が近づいた際に自動で更新してくれるので、期限切れを心配する必要がなくなります。無料なので使わない手はないですね。
東京リージョンのELBで使うならACMも東京リージョンで発行しますが、CloudFrontは全リージョン共通なのでACMはバージニア北部リージョンで発行してください。
CloudFormation
AWSリソースをコードで管理できるサービスです。
CloudFormation独自の記述ルールに沿ってAWSリソースをテキストファイル（JSON or YAML形式）で表します。（このテキストファイルをテンプレートと呼びます。）
AWSリソースの作成・更新・削除を効率化できます。
インフラをコード化する概念はIaC(Infrastructure as Code)と呼ばれます。
IaC化を行うことで以下のメリットがあります。
- 構築の効率化（GUIで手動構築する手間が省ける）
- 拡張がしやすい（環境の複製が容易。環境に合わせて一部パラメーターを変数化することも可能）
- 属人性の排除（誰でも同じ構成をデプロイする事ができる。環境が可視化できる）
- バージョン管理（Githubのフローを利用できる。バックアップ手段としても有効）
他、代表的なIaCツールはTerraformがあります。
CloudFormation学習の1歩目はテンプレートのステートメント（宣言）を理解する事です。
各ステートメントで何のAWSリソースをどのようなオプションで設定しているか読み解けるようになりましょう。
JSONとYAML形式どちらでもリソース定義が可能ですが、初学者にはコメントアウトが可能なYAMLをお勧めします。
AWS CLIと同様、全てのリソースのパラメーターを網羅して覚えようとするのは現実的ではありません。
上達への近道は「対象リソースの記述方法や詳細パラメーターを公式リファレンスから素早く読み解く力」がポイントとなります。
注意点は、「全てCloudFormationでコード化するのが正解ではない」ということです。
例えば、ほとんど変更が入らず使い回しが発生しにくい箇所（専用線接続部分など）のテンプレート作成に時間を使うのは効率的ではありません。
環境構築を自動化するサービスは他にもElastic Beanstalk、OpsWorksがあります。
目的に合わせてサービスを使い分けましょう。
参考：
公式リファレンス
Zenn：CloudFormationまとめ
AWS初心者によるAWS初心者のためのAWS環境自動化入門
Lambda
通常、Webサービスをインターネットに公開するためにはプログラムだけでなくサーバなども構築する必要があります。
サーバーの構築や保守や負荷対策など管理をすることなくプログラムコードを実行できるサービスがAWS Lambda（ラムダ）です。
サーバーの管理が一切不要になるので「サーバーレスコンピューティング」とも呼ばれます。
Lambdaは、AWSに関するなにかしらのイベントによって処理を実行できます。
たとえば
- S3にファイルをアップしたときにプログラムを実行
- APIサーバとして、クライアントから通信を受けたらプログラムを実行
といったような特定イベント時に自作プログラムを実行させることができます。
主にアプリケーション開発で使用されるケースが多いのですが、インフラ構築でも簡単な処理（S3に関する処理など）を書くのに便利です。
また、利用するアプリ側で何ができるか把握しておくこともインフラエンジニアとしては望ましいことです。
まずは、Lambdaが どのようなもので/何ができるのか の概略をつかめればよいかと思います。
Git基本操作
CloudFormationのテンプレートを社内共有・管理する為にもGitの基本操作は必須です。
リポジトリホスティングサービスはセキュリティの関係で会社指定があるかと思いますが、基本的にはGitHubを学習しておけば他サービスでも十分対応できます。
エディタはユーザー数が多く拡張プラグインも豊富なVSCodeを選択するのが無難です。
構成図作成ツールはdraw.io、もしくはVSCodeと連携するdraw.ioのプラグインを推奨します。
業務に役立つテンプレートも豊富で、AWSアイコンもインポートできます。
3Dで立体的に構成図を作成できるCloudcraftもユニークでお勧めです。
参考
VSCodeでDraw.ioが使えるようになったらしい！
おわりに
このロードマップ作成はAWS学習サービス CloudTechのコミュニティの有志によるプロジェクトメンバーで制作しました。
ロードマップ作成にあたりご協力いただいた皆様には改めて感謝いたします。
インフラエンジニアの教育、新人指導などで役立てていただけますと幸いです。
この記事に対するご意見などはQiitaのコメントで何なりとお寄せください。
建設的なご意見お待ちしております。
更新履歴
2021/5/10 初回投稿
2021/5/15 宗教論争回避のため、エディタにEmacs宗派を追加
2021/7/5 JAWS-UG登壇オファーのリンクを追加。登壇したYouTubeのリンクはコチラ
2021/9/13 ルビコンさんがMENTAの上位1%に与えられるゴールドメダルに認定されたのでプロフィールを更新
2021/9/22 直通ご意見フォームのリンクを削除しました
2021/11/20 全国出版書籍の情報を冒頭に掲載しました
2021/12/27 共同執筆の記事を冒頭に追加