エラー対応お疲れ様でした！

構成図、とてもキレイで良い感じです！ よくを言えば ・SSH(22) ・http（80） ・MySQL(3306) など、通信のポート番号を書いてあげるとよりよいと感じました！

何はともあれ、無事に動作確認が完了したようで良かったです！後続のレッスンも頑張ってくださいね！ お疲れ様でした！

Slackで質問いただいていた件ですかね？

もしかしたら「ホームディレクトリの違い」によるものだったかと記憶しています。

【コマンド】 wget http://ja.wordpress.org/latest-ja.tar.gz ~/

このコマンドの最後の ~/ は何を表しているか整理しましょう。

「ec2-user」ユーザーで以下を実行してみてください cd ~/ pwd ⇨/home/ec2-user/ が表示

「root」ユーザーで以下を実行してみてください sudo su - cd ~/ pwd ⇨/root が表示

チルダ記号「~」は「今ログインしているユーザーのホームディレクトリ」を表します。

引き続き疑問点があればSlackで質問してみてくださいね！

構成図、シンプルで良いと思います！ もし余力があれば公式アイコンなどを使ってあげると他エンジニアからの視認性も高まるかと思いますので、ぜひチャレンジしてみてください！

あるあるですね！ 私も現役エンジニア時代（そして今でもたまに…）セキュリティグループ設定ミスで時間を溶かしてしまった経験があります。

接続できない場合、 ルーティング 権限 など、自分なりにチェックするクセをつけておくと良いと思います！

こちらはWindows特有の対応のようですね。 教材内で補足できずに失礼しました。

他の方もヒアリングしてみて、改めて教材に反映するか検討してみますね！情報提供ありがとうございます！

⇨失礼しました、コマンドラインから接続する場合ですね！ナイストライです！教材にも補足いたします！

こちら、既存ルールを一旦削除すれば解決されるとのこと、解決できて良かったです。 エラー調査お疲れ様でした！

RDSは停止していても、1週間経過すると自動起動（！）するのでご注意ください。 https://www.t3a.jp/blog/infrastructure/rds-auto-startup/

大切です。 補足として、利用する時間（例：9:00〜18:00）のみ起動終了を制御するCloudWatch Eventsで作る仕組みもあります。仕組みで強制するのもひとつの手です。 https://qiita.com/t-toyota/items/5d7455568f1856fd2f4e

また、EC2を停止していても、EC2にアタッチされているEBSボリュームを保持しているだけでわずかな料金がかかります。ご注意ください。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/ebs-charge-stopped-instance/

こう見ると、一般的なWebシステム系の構成はほとんどがEC2とRDSで占められますよね。

ご自身で費用を調べるこのような視点、素晴らしいです！

IT業界も半年でしょうか？ それでプラクティショナー取得は素晴らしい！センスあると思います！

AutoScaling設定で監視を入れており、バッチリですね！

ポートフォリオとしてのアピールには別途、メモリ使用率やストレージ容量など基本的な監視設定が入っていると運用も考えられているなと高評価になりますので、ぜひチャレンジしてみてください！

通知もメールに飛ばす、Slackに飛ばすなど色々とエラーレベルに合わせて設定するとなおよしです！

くろかわ

EC2をプライベートサブネットに配置する場合、GitHubからのダウンロードを実現するためには一時的にインターネットの接続経路が必要なのでNATゲートウェイを利用する等の対応が必要です。 プライベートサブネットに配置する場合はご注意ください。

くろかわ

久保玉井さんのおっしゃる通り、EC2はプライベートサブネットに配置しても良さそうですね！

プライベートサブネットでyum updateはどうするか？ですが、S3のエンドポイントを設定することで実現できます。以下の記事を参照ください。

https://soypocket.com/it/ec2-yum-privatesubnet-s3endpoint/

他、インターネット向けの通信が必要な場合は、コスト的な面を考慮すると一時的にNATゲートウェイを配置するなどで対応するのが良いと思います。

くろかわ

まとめ記事作成ありがとうございました。 お疲れさまでした。

エラー原因についても事前説明記載されていてわかりやすいです。ナイス説明です。

すごい盛りだくさんですね！まとめ記載お疲れさまでした。

ただ作業が多いのでゴールデンAMI作成して、それをAutoScaling用に利用するのも良さそうですね。

このエラーの説明まで記載されているのが素晴らしいです。なぜエラーになるのかの原因も補足で記載されていてさすがです。

なるほど。検証用とかの利用であればご自身環境からのみのアクセス限定ですね。

可用性を高める為にマルチAZ構成ですね。 さすがです！

わかりやすい構成図素晴らしいです。

ちょっとご提案です。ELBのみパブリックサブネットに設置。WebサーバやAPサーバはプライベートサブネットに設置という構成は如何でしょうか？

WebやAPサーバも安全性も高まるかと思います。

素晴らしい。学習効果が促進されると思います！

再起動だとIPアドレスは変わりませんよね！ AWSのビジネスから見ると、「EC2を起動しておらずお金が入ってこないのに貴重なIPアドレスを確保されている」ということで、停止すると自動解放されるのだと想定します。

「既存のIPv4CIDRルールの参照グループIDを指定することはできません」 というエラーメッセージですね。。 私も英語で検索してみましたが、これといった情報がなく、おそらくAWS側のバグとみてよさそうです。

Administrator権限を持ったIAMユーザーですね！ ルートユーザーを使わないところが明記されており、良いと思います！

構成図、バッチリです。 IGWからEC2へ、アクセスの矢印があるとなお良いと思います！

ここにあったー！！www ありがとうございます。

おっしゃるように途中違和感がありました。ただCLBでも構成はできるのでそのまま記事を読んでいたのですが、最後で大納得です。あえて改良するのを意識してCLB→ALBへの切り替えさせるのですね。なるほど。

デプロイ作業もスクリプト化することによって冪等性も保たれますね。コマンド叩くだけで作成されていくので凄い便利だと思います。素晴らしい！

参照するために名前をつけて!ImportValueで呼び出すって感じですね。わかりやすい説明ありがとうございます。

サブネットマスク計算の説明もあって基本情報技術者試験のようにわかりかったです。すばらしい。

ここから各要素の説明が始まっていくのが丁寧ですごくわかりやすかったです。

この形式バージョンですが、現時点で2010-09-09が唯一の形式となってます。またAWSTemplateFormatVersion セクションは任意記載となりますので、「Shebang的」のような必須項目とはちょっと異なってくるかと思われます。

Shebangは記載ないとスクリプト動きませんよね？

ご確認いただければ幸いです。 https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/format-version-structure.html

基本だと思うのですが、トラブル時に切り分けが一気にしやすくなるメリットも出てきますね。

これめちゃくちゃ目立ってすぐ判りました！ よければアスキーアート生成方法などの記述もあると読者ももっと喜ぶと思うかもしれませんｗ

まずはSAA合格おめでとうございます。

合格も凄いですが、知識の掘り下げを実践されているのがもっと凄いと思います。今後上位資格にトライする際にも有用な取り組みだと思います！さすがっ！

退避させて記事にまとめるのは非常に面白いアプローチですね！

NAT poolなどIPアドレスの確保はAWSが管理してくれるのでユーザー側では不要となります。クラウドの利点ですね。

論理的には多少影響はあると思われますが、システムのパフォーマンスに影響を及ぼすほどのものではなさそうですね。

Auto Scalingもそうですが、ELBが最低限確保が必要なIPアドレス数に満たないためでもあります。

IGWがオンプレのデフォルトゲートウェイという表現はなかなか面白い表現ですね！ 厳密に言うとデフォルトゲートウェイは「ルーティングでデフォルトとなるルータ」を指す意味合いが強いと思いますので、誤解を防ぐ意味で「インターネットとの境界に設置されたルータ」などはいかがでしょうか？

ハンズオン１の記事でElasticIPアドレスについて明記していましたが、こちらでELBを使う予定だったのですね。納得いたしました。

意外とこちらの作業をする際はドキドキします。

素晴らしい！安全性がより高まりますね。

ヘルスチェックトラブルに関して、確認項目も明記されていて流石です。

Wordpressの場合ですとindex.phpファイルも存在するかと思います。

この注意表示ですが、初見の方は驚きますよね。明記されていて流石だと思います。ありがとうございます。

これでEC2インスタンスの区別がつくようになりましたね。

引き続き、課題記事作成お疲れさまです。ありがとうございます。

課題記事の作成および提出お疲れさまです。

今回のネットワーク構成ですと、EC2を停止し改めて起動するとパブリックIPも変更になります。ElasticIPを付与し固定化する方法だとパブリックIPアドレスの変動は起こりませんので、ぜひ一度お試しになってください！（若干金額発生しますが）

エラーについても記事内に記載されているのは非常に有用だと思います。成功ばかりではなくエラーも経験すると更に理解度が増すからです。素晴らしい。

/var/www/html配下にあるディレクトリを一旦削除し、ダウンロードしたWordpressを再度展開および/var/www/html 配下に設置してみるのも解決手法の１つです。ぜひ一度お試しください。

確認なのですが、プライベースサブネット分のルートテーブル作成＆サブネット関連付けは行わないのでしょうか？

参考記事まで掲載し、簡潔な説明で非常にわかりやすかったです！流石！

最近ではセキュリティ対策として、データベース名も推測されない名称を指定するケースも出てきてます。wordpress以外のランダムなデータベース名を設定するのも対策としてありだと思います。

実際に手を動かして注意点を記事としてまとめる事により、より理解度が深まりますよね。取り組み素敵です！

このエラーはまだ続いている状況でしょうか？ なんでしょうね。。。Apacheは正常に起動できている状態ですかね？

お疲れ様です！

EC2にアタッチしているセキュリティグループのみ許可する設定は良いですね！よりセキュアにもなりますし、EC2が増えた場合にも楽になるかと思います。

すべて消して保存して、ルールを追加する対応のやつですね！私もハマったことあります！

課題作成ありがとうございます！

ちなみに停止して7日後に自動起動してくるので、この仕様は覚えておくといいですね。

重要
DB インスタンスは最大 7 日間停止できます。7 日後に DB インスタンスを手動で起動しなかった場合、DB インスタンスは自動的に起動されるため、必要なメンテナンス更新が遅れることはありません。

【一時的に Amazon RDS DB インスタンスを停止する】 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_StopInstance.html

「VPC内のルートのみが設定されている」の方がより正しいですね

SSHのソースIPについては、SSHの接続元のIPが固定化されている場合、「0.0.0.0/0」ではなく、IPを指定する形の方がよりセキュアになりますね。

HTTPのソースIPに関しては、インターネットに公開されることが前提かと思うので、「0.0.0.0/0」で良いかと思います。

参考にしていただければ幸いです！

サブネット名とIPv4 CIDRは構成図に表記されているものに読み替える感じですね

本記事でのゴールが構成図として記載されていて、とても分かりやすいです！

課題記事の作成と提出ありがとうございました。 丁寧な記事内容で理解しやすかったです。

APサーバへのSpringBootアプリケーション設置ですが、素朴な疑問としてElastic Beanstalkで出来るかな？と感じました。Fat JarとしてまとめてElastic Beanstalkへ配置すれば、APサーバの構築作業も軽減できるかな？と考えています。

参考記事 https://qiita.com/riversun/items/9d53238fef611ce7d466

アプリケーション側の知識に疎くて申し訳ないです

APサーバインスタンスの停止、起動があるとIPアドレスの変動が起きてしまいソースコード修正が発生しちゃうので、Elastic IP指定でAPサーバを作成すると修正作業しなくて済みそうですね。

まったく同じ構成で準備を始めるのであれば、作成するインスタンス数を「2」で指定して作成するのも楽になりますね。

このあたりコストが気になる方が多いので予め記載されてて素晴らしいです。

そうですね。事前準備が必要になりますね！素晴らしい！

APサーバへのアクセスポートが8080となっておりますが、外部からもアクセス可能な状態になっているのが少し心配です。

アクセス元がWebサーバーのみであれば、APサーバー用のセキュリティグループを別途ご準備してみるのはいかがでしょうか？

プライベートサブネット用のルートテーブル作成は処理漏れしやすい箇所ですので、丁寧に記載されていて素晴らしいです。さすが！

展開して内容確認しました。丁寧な手順説明が素晴らしいです！

サービス利用時にAPサーバにエンドユーザーはアクセスしないのであれば、APサーバはPrivateSubnetに設置するのも良さそうですね。

それにしてもエンドユーザーがラーメン食べているのが可愛らしいｗ

「泥臭いけど」と書かれていらっしゃいますが、個人的には”すごくかっこいい”と思います。行動されているのが素敵です。

想定した動きが実現できるととても面白いですよね！

VPC以外のリソースのパターンも見てみたいですね。

自身の中でCloudFromationのテンプレートを作成する場所をルール化しておくのも良いですね

設定内容の記載ありがとうございます。 これは参考になる人が多いきたいと思います！

この機能はとても便利ですよね！

課題作成ありがとうございます！

ちなみにここはフルアクセスではなく、一部のグローバルIPにしぼって公開するようなルールにすると、証明書の自動更新処理に失敗します。 参考としてコメントしておきます！

https://blog.serverworks.co.jp/tech/2018/12/13/acm-certification-auto-renewal/

AMCで発行されたSSL証明書に関しては（DNS検証の場合）、自動的に更新がされます。 自動更新にはいくつかの条件が満たされている場合に限るので、詳細はドキュメントを参照いただければ幸いです。

【ACM 証明書の管理された書き換え】※タイトルは翻訳がおかしいです。。。 https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/managed-renewal.html

WordPress側の対応記載いただきありがとうございます！

DNSレコード（CNAME）が追加されていることと合わせて、検証状態を確認する手順を入れた方がより良くなりますので、参考にしてみください！

【ACMの証明書をDNS検証にする】 https://blog.kozakana.net/2019/03/aws-dns-validate/

ACMで発行できる証明書の種類は「ドメイン認証（DV: Domain Validation）型SSLサーバ証明書」のみとなります。 利用すべき証明書の種類によっては、ACMが利用できない場合もあるので、今後の参考にしてみてください！

【ACM 証明書の特性】 https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/acm-certificate.html

【SSLサーバ証明書の種類と比較】 https://www.websecurity.digicert.com/ja/jp/theme/ssl-compare

ブログだとしてはHTTPS化は必ずやっておきたいですね

課題作成ありがとうございます！

ここは動作確認は必ずやっておきたいポイントですね！

クリックしただけでは、閲覧ができませんでしたー ここは必ず修正しましょう！

この設定をする時、いつもドキドキします

動作確認大事です！

ウィザードで作成する方法ですね。 ウィザード作成とクイック作成の２つ方法があるので、今回はどちらの方法かを記載すると、より分かりやすくなると思います！

最後にnslookupコマンドなどでNSレコードが設定した内容に反映されているか確認するようにすると、より良くなるかと思います。

以下はWindowsでのnslookupに関する記事ですが、参考にしてみてください。

【nslookupコマンド】 https://www.n-study.com/tcp-ip/nslookup/

ここはFreenom側での作業になると思うので、以下のような章立て？にすると、とても分かりやすくなるかと思います。

１．Freenomでのドメイン取得 <br> 　１－１． <br> 　１－２． <br> <br> ２．Route 53でのホストゾーン作成 <br> 　２－１． <br> 　２－２． <br> <br> ３．Freenomで NSレコードの修正 <br> 　３－１． <br> 　３－２． <br>

止めていたものを起動したりすると、なぜかうまく動作しないことありますよね。考慮不足だったりしますが、ドキドキするところです

S3にアップしたSorryサイトが表示されるということですね

課題作成ありがとうございます！

是非冒頭に記載した資料を参考にしてみてください！

冒頭にも記載しましたが、ELBを利用する構成の場合、EC2はプライベートサブネットに配置することがよりセキュアな構成になります。 プライべートサブネットの場合、ここの設定は 無効化 になるので参考にしてみてください。

実施手順の記載ありがとうございます！

すべては厳しいと思いますが、ポイントを絞った形でマネジメントコンソールの画像を貼るとより分かりやすくなるかと思います。 例えば、各手順の最後に表示される画面など、想定している結果の画面ですね。

ELBを配置する構成の場合、振り先となるEC2に関してはプライベートサブネットに配置するとよりセキュアな環境になります。

以下のイベント資料のP20にベストプラクティスの構成になるので、参考にしてみてください！

https://d1.awsstatic.com/events/jp/2020/innovate/pdf/S-9_AWSInnovate_Online_Conference_2020_Spring_AWS_Web_System_Architecture.pdf

コスト管理の強化にも繋がるので、要件に応じて使っていきたい機能ですね

ここは大事なポイントですね！

課題作成ありがとうございます！

「人生変える！」って凄い意気込みだと思います。頑張ってください！

Route53で簡単にドメイン名の購入や設定が出来ますが、実はEC2にドメイン名割り当てて使用する場合には、AWS以外のドメインレジストラの利用も可能だったりします。

Amazon Relational Database Serviceで「RDS」ですね。

判りやすい！ ちなみに「うちのエリアは１つだけでなく、複数あるんだよ」的に、VPCも複数作成可能です（最大値制限はありますが）

まとめ記事作成ありがとうございました。

ELBなどを使うと、EC2に固定IPを割り当てずにELB側でIPが固定化されますので、EC2側は柔軟に交換切り替えなどが可能になりますよ。お試しください。

AWSではいくつかのサービスがありますが、EC2はご認識のとおり重要なサービスの１つです。

このあたりは試験でも取り上げられますので要チェックですね。

東京のAZは通常利用可能なのは３つとなります。１つは現在新規利用できませんのでお気をつけください。

簡潔な説明で理解しやすいです。素晴らしい。

一年間無料は学習を行う際に非常に助かりますね。 私も以前AWSで独自ドメインでブログ運営していましたが、一年間は黒字継続できて助かりました。 （２年目からは収支逆転したのでAWSから他の固定額サービスへ乗り換えしましたが・・）

こちらでちゃんと記載されていますね。安心致しました！流石です！

とても判りやすい説明なのですが、少しだけニュアンスが違う感じがしました。

サブスクだと定額課金になりますが、AWSの場合ですと「使った分だけ課金」になります。場合によっては無料の機能もありますので、そのあたりご認識はご注意ください。

複数のサービスの集まりになりますので、最後に複数形の「s」が付きます。ご確認ください。

正：Amazon Web Services 誤：Amazon Web Service

用語の説明をまとめると言う記事は、たしかに初学者向けには必要だと思います。何気なく３文字の省略用語を使うのが多いですので、初心にもどって改めて確認致します！

「賢く、超簡単に」というのが良いですね。興味惹かれます！頑張っていきましょう。

プライベートサブネットに配置するので、ここは「なし」ですね

WordPressの初期設定手順の記載ありがとうございます！

次回作に向けた下準備でもう一つ作成といったところでしょうか？

認識済みかもしれませんが、ルートテーブルで

0.0.0.0/0 (デフォルトゲートウェイへの通信) がインターネットゲートウェイに設定されているのが「パブリックサブネット」 設定されていないのが「プライベートサブネット」

と認識しているとより理解が深まるかと思います！

RDSを配置するプライベートサブネットですね。 とても良いと思います！

EC2を配置するようのパブリックサブネットですね

次回の記事も楽しみにしております！ 絶賛確認中です！

各コマンドの挙動についても記載していて、理解が深まりやすいと思いました。

セキュリティグループでの選択はとても良いと思います！

構成図が記載されており、とても良いと感じました！

課題作成ありがとうございます！

私も実務ではそのような考えで設計していますね

この違いは把握しておきたいポイントですね！

ネットワークACLとの理解を把握した上で、利用したい機能ですね。

うっかり解放忘れはあるあるですね...

私は実務ではデフォルトVPCは削除しちゃいますね。

「デフォルトVPC」を作成することも出来たりしますね。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc.html#create-default-vpc

１AZあたり、１つ以上のデータセンターの集まりですね。 認識合ってるかもしれないですが、念のためのコメントです！

古い動画ですが、こちらも参考になると思いますので是非見てください！ https://youtu.be/JIQETrFC_SQ?t=1428

利用料を出来る限り抑えたい、という場合、海外リージョンを利用する手もありますね。 EC2ではインスタンスタイプにもよりますが、バージニア北部の場合、東京リージョンと比べて20%くらい安く使えたりします。

以下のページでリージョンごとの料金が分かるので参考にしてみてください！ https://aws.amazon.com/jp/ec2/pricing/on-demand/

課題作成ありがとうございます！

課題作成ありがとうございました！

わかりやすい構成図ありがとうございます。 補足ながら通信経路となる接続線もあると更に理解が深まるかもしれません。ご検討ください。

なるほど！ こちらで最終的にプライベートサブネット用のルートテーブル作成されていたのですね。納得しました。

課金条件も明示素晴らしいです。

おっしゃるとおりVPC作成時点で作成されるデフォルトのルート情報でVPC内の経路は定められていますね！流石です。

こちらですが、パブリックサブネットと同じルート情報になっていませんでしょうか？

パブリックサブネットで編集したルート情報はデフォルトの経路情報になるため、プライベートサブネットは別のルート情報を設定する必要があります。

このままですとプライベートサブネットではなくパブリックサブネットになりますので一度ご確認ください。

金額概算も掲示されて丁寧ですね。凄いいいです。

補足ですがWindowsの場合だとこのパーミッション設定がなかったりします。

UnixライクなOSの場合に必要な操作になりますね

課金スタートのタイミングまで記載されて凄い！ コスト意識高いですね。素晴らしい！

この構成ですと実はちょっと危険でして、すべての場所からSSH接続が可能となります。

よってソースの部分はマイIPなどにし、SSH接続を行う箇所を限定的にしたほうがより安全度が高まります。

一度お試しください

今回の構成ではインスタンスが複数台設置されますので区分しやすくするためにもタグで分類は良い方法ですね。

経路情報を元にNATゲートウェイが必要と明記されていてわかりやすいです。

作業内容を元にして現時点での構成図を提示されているので非常に丁寧で理解しやすいです。素晴らしい！

見落としがちな設定箇所ですね。ちゃんと明記されていて素晴らしいです

こちらですがサブネットを選択するのではなく、VPCを選択となります。

一度試して欲しいのですが、サブネット作成せずにVPCへインターネットゲートウェイをアタッチされてみてください。サブネットなしでもアタッチ可能です。

こちらもしかすると全角で「ｖ」と混在入力されているかもしれません。

AWSのグローバルインフラストラクチャ構成についての補足説明流石です！

用語の細かい作成?素晴らしいです！

検索するのが手っ取り早いケースもありますので別の方法をしっかり説明されているのが好印象です。

こちら意外と大事な所ですね。 VPCやサブネットなどの作成では利用料金発生しませんげ、NATGatewayやEIP利用の場合には利用料金が発生しますので要注意ですね。

最初に構成図があるので理解しやすいですね。流石です！

今回添削するにあたり事前に内容確認しましたが、超大作ですね。まとめ作業おつかれさまでした！

構成図分かりやすいかと思います。 RDSを配置するサブネット(10.0.2.0/24)がPublicSubnetになっていますが、PrivateSubnetになるか思うので確認お願い致します。

ここは

「セキュリティグループが設定されているリソースから」

が正しいかと思います。

コマンドの列挙ありがとうございます！

ここは記載通りのセキュリティグループでの設定にしたいですね！Webサーバを増やす要件が発生した際に対応しやすくなります。

冒頭でも触れましたが、RDSを配置するサブネットは手順の記載通りプライベートサブネットが好ましいです！ 構成図の修正を検討ください！

各用語解説とても良いと感じました！ これらの用語はおさえておきたいポイントですね。

EC2のパブリックIPにブラウザでアクセスする旨を記載するとより分かりやすくなるかと思うので、参考にしてみてください。

課題作成ありがとうございます！

自己研鑽にもつながるので、とても良いと思います。 まとめ記事作成おつかれさまでした。

こちらもtypoかもしれません

誤：できるのできる 正：できる

こちらですが課金対象となりますので、DBインスタンス削除後にずっと残しずつけて課金され続けるケースを見たことあります。要注意ポイントですね

実運用を考慮したアドバイス内容が記載されてあって流石です。

本記事を読まれた方にとって有用だと思います。

こちらはtypoでしょうか？

誤：通常業 正：通常業務

長いトランザクションが常時走っている場合ですと、もう少し時間がかかる恐れがあります。

Amazon RDS のフェイルオーバープロセス https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

このあたりは悩ましい問題ですね。費用面を抑えて構築する際に、サービス停止の許容レベルを前もって決めておかないと実際停止した際に「なんで停止してるんだ！ﾌﾟﾝｽｺ」ってなる依頼主を何度か見たことあります。

実装前の段階で折り合いがちゃんとつけば、世の中もっと穏やかになるのですが・・

とても素晴らしいと思います。あとあと自分自身で活用されるはずなので未来の自分へのプレゼントになりますね。素晴らしい！

テンプレート公開ありがとうございます！ 私も参考にさせていただきます！

次回作お待ちしております！

どの情報をどこに入れるべきはとてもイメージしやすかったです！

踏み台ホストは実業務でもよく出てきますね。 よりセキュアに、よりコスト管理を強化したい場合、SSM セッションマネージャーの利用を検討すると良いですね。参考にしてみてください。

【セッションマネージャー越しにSSHアクセスすると何が嬉しいのか】 https://dev.classmethod.jp/articles/ssh-through-session-manager/

取得の流れが分かりやすかったです！

構成の特徴が細かく記載されていて、とても良いと感じました！

構成図がとても分かりやすいです！

整理ありがとうございます！

課題作成ありがとうございます！

マネジメントコンソールの流れを画像で記載いただくとより良くなると感じました。参考にしてみてください！

これは大事！

これは利用できる場面は多そうですね！

GUIだけではなく、 AWS CLIの操作方法も押さえておきたいですね。記載とても良いと感じました！

クロススタックを行ない場合には必ず覚えておきたいポイントですね！

画像と合わせて記載していて、とても分かりやすいです！

テンプレートの内容を記載いただきありがとうございます！

ドキュメントのリンク記載ありがとうございます！

どこまでCloudFormationでインフラを管理するかにもよりますが、押さえておきたい機能ですね！