テンプレートの構文途中にエラーがあっても中途半端に生成されることはなく、自動でロールバックされる。
細かくエラー時の挙動を記載してとても良いと感じました！
690 Matching Annotations
- Jun 2021
-
qiita.com qiita.com
-
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
課題作成ありがとうございます！
-
-
qiita.com qiita.com
-
参考にしたサービスではこのあとRDSも冗長構成にするハンズオンがありましたが、わたしは今回、事情があって実施しませんでした。もちろん後日実施予定です。
引き続きのアウトプット作業頑張ってください。 今回は記事作成お疲れさまでした。
-
※このままですと、EC2はロードバランサー以外の通信も許可してしまうので、 ALBからの通信のみ許可するように変更します。SGで。
EC2インスタンスのセキュリティ対策として既存セキュリティグループの修正作業。きっちり対応されていて素晴らしいです。
-
EC2作成時、マイAMIから作成し、アベイラビリティゾーン1cのPublicサブネットに置く
マルチAZ構成にするためにマイAMIを作成されたのですね。あらたに再度作成作業を行うよりも作成済のイメージを用いることで作業も短縮になりますね。ナイスです。
-
この状態で放置するとワードプレスの表示が崩れたままなので、以降の作業もぶっ続けで行うことをお勧めします。
DBに保存されたサイト情報の修正作業ということですね。理解です。
-
※前回作成したはずのWPが、504 Gateway Timeout と表示され焦りましたが、RDSをスナップショットを取って削除していたことを思い出し、スナップショットからRDSを復元しました。
課金を防ぐためにRDSを削除されたのですね。なるほど。 トラブルシューティングされてますね。流石です。
-
readmi.html
こちらはtypoかもしれません。
誤：readmi.html 正：readme.html
ご確認ください。
-
AWSブログサービスを構築する(1)の続きです。
引き続きのアウトプットお疲れさまです。 継続していくことが大事ですので頑張っていきましょう
-
- May 2021
-
qiita.com qiita.com
-
送信先がFW同様に0.0.0.0/16になっているので、0.0.0.0/0に修正。
2つ目発見おめでとうございます！
-
→SSH接続してみるが繋がらない...「え!?違うの?」と思いながら答え合わせ動画を見ると、もう一つ原因があるとのこと。(どこまでも実務に近くて良い課題!!)
一つ目の原因発見おめでとうございます！
-
戻りのルーティング(EC2→ローカルPC)があるか
ルートテーブルも抜けやすい部分ではありますね。
-
変なACLが設定されていないか
NACLを使ってどこまで制限をかけるかにもよりますが、挙動はある程度把握しておきたい部分ですね。
ここは以下のドキュメントが参考になります。
[一時ポート] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports
-
引き続きコンテンツを消化していく。
頑張ってください！
-
最後にSSH接続して、成功した。
おめでとうございます！
-
Security GroupでSSHが許可されているか
こちらもルール適用漏れがある部分ですね
-
インターネットゲートウェイはアタッチしているか
この確認は大事ですね。うっかり作成忘れもあります。
-
①物理的で基本的なとこから確認していく。 ②ローカルPC → 接続先に向かって実施する。
このセオリーは大事にしていただきたいですね！
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com
課題作成ありがとうごうざいます！
-
-
qiita.com qiita.com
-
送信先 ターゲット 0.0.0.0/0 igw
この経路情報がないとVPC外への接続が不可になりますね。意外と漏れやすい作業なのでちゃんと明記されていてナイスです。
-
（勉強させていただきました学習サービス 「AWS CloudTech」 https://aws-cloud-tech.com の図とAZの向きが違います）
向きが異なるとの事ですが、理解ちゃんとできます！
AZを複数利用、サブネットもAZ毎に設置、ルーティングテーブルもサブネット毎に準備。
Wordpressのアイコンもあるので一発理解できました。流石です！
-
スナップショットを取って削除する
データのバックアップとしてスナップショットを取得されていると思うのですが、スナップショットも保管に関して課金されます。
不要なバックアップであれば削除も良いかと思います。
-
⑤作成して忘れずにローカルPCにダウンロード （あちこちで使います）名前と場所を覚えておくこと。 WindowsでWinSCPを使うので鍵を変換してしまう人は、「.pem」の鍵も無くさないこと。
リモートのインスタンスに接続して操作するためにSSHが必要。その為に鍵の管理も必要となるわけですが、Session Managerを使うと鍵の管理は不要でリモートインスタンスの操作が可能になります。
ご参考までに。。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager.html
-
ssh22番がすべて（0.0.0.0/0)から許可になっている事を確認
SSH接続はリモートからサーバに接続して管理操作するために必要ですが、。0.0.0.0/0ですと色んな所から接続利用ができてしまいます。
httpの80番ポートですと多数の人に公開する必要があるので、0.0.0.0/0で良いのですが、ssh接続に関しては「マイIP」などを指定し、管理ネットワークからのみ許可したほうが安全性が高まります。
ご確認いただければ幸いです。
-
②作成したVPCに、PublicとPrivateをそれぞれ作成
後述されているルートテーブル作成にも関連するのですが、プライベートサブネット用のルートテーブルを作成が必要かと思われます。
現在の構成ですと、ルーティング情報は１つのみで、すべてがパブリックサブネット扱いになります。
-
※この図は「draw.io-14.6.13-windows-installer.exe」をダウンロード、インストールして作成しました。
ブラウザにて、https://draw.io/ にアクセスして利用も可能です。一度お試し下さい。
-
「シングル構成のAWSブログサービスを構築する」を実施しました。
手を動かしながらの実践的な学習は理解度も深まりますね。アウトプットとして記事作成も良い取り組みだと思います。作成お疲れさまです。
-
-
-
EC2インスタンスの画面に戻るとすでにST-WebServer-Autoが2台立ち上がっていることを確認できました.
ELBのターゲットグループにも確認する部分もあると、より良くなるかと思います！参考にしてみてください。
-
不要となったインスタンスはシャットダウンされていることを確認できました。
ELBのところ同じように想定した挙動を作れると楽しいですよね
-
ST-WebSever2でWebサイトを継続して閲覧できることが確認できました。
想定した動きになると嬉しいですよね。
-
目的
目的、どんな構成を文章だけではなく図でも記載されていて、とても理解がしやすいかと思います！
-
topコマンド
top コマンドは出力が分かりやすいので、覚えておきたいコマンドの一つですね。
-
接続したEC2インスタンスで以下のコマンドを４回実行してCPU負荷をかけていきます。
このコマンドでなら簡単に負荷をかけられますね
-
PIDが連番であれば波括弧を使って一括で終了できます。
こんな小技があるのですね！
-
欠落データの処理については、EC2のCPU高負荷が原因でデータが取得できないことを想定して [閾値を超えているとして処理]
なるほど、参考になります！
-
この２台で処理し切れないほどの通信が発生した場合
この要件に対応するためにも、AutoScaling は押さえておきたいポイントですね。
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com
課題作成ありがとうございます！
-
-
zenn.dev zenn.dev
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
記事作成お疲れさまでした！
-
データベースのログとイベントにMulti-AZ instance failover completedと出ていれば成功
最後のRDSの設定変更作業ですが、再起動も結構時間がかかりますよね。待つのがRDS多いと思います。
-
ELBのSGに変更
不特定多数のアクセスからELBへ限定されて安全性を高めてらっしゃいますね。素晴らしい！
-
ssl
前後の説明でSQL文の実行されるのを確認しましたので、こちらはtypoだと思われます。
誤：ssl通信 正：ssh通信
ご確認ください。
-
RDSに設定されているサイトのアドレスをELBのDNSに書き換える
Wordpressのデータベース上で登録されているURL情報の更新ということですね！
-
この時点で2つ目のインスタンスにはコンソールでssh通信できるようになっている
最初に作成したインスタンスからマイAMIを作成されることによりOS上でのインストール作業などコマンド投入作業も減りますね。効率的な作業の進め方でナイスです！
-
インバウンドルールのソースをIPアドレスからEC2のセキュリティグループに変更 👉こうすることで、EC2のセキュリティグループを持ってるインスタンスからしかアクセスできないようになる
大事なポイントですね！セキュリティーグループでの指定はオンプレミスではできないセキュリティ設定ですのでAWSならではだと感じます。ちゃんとポイント抑えて素晴らしいです
-
耐障害性を高めるため、下記のようにAZを分ける
マルチAZ構成ですね。シングルAZ構成に比べておっしゃるとおり耐障害性が高まりますね！
-
ートテーブル
こちらtypoだと思われます。ご確認のほどお願いします。
-
-
qiita.com qiita.com
-
今回は VPC を作成しました。 次回は EC2 の作成をしていきます。
課題作成お疲れさまでした。 引続き次回のEC2も楽しみに待っております！
-
こちらはターゲットにインターネットゲートウェイへのルートが設定されています。 この場合のサブネットは「パブリックサブネット」になります。
「なぜパブリックサブネットになるのか？」という質問に対しての判りやすい解答になりますね。
-
自分の環境に合わせて見やすいように変更しても良いかもしれません。
障害対策などを考慮して表示項目にはAZやIPv4 CIDRのどちらともあると俯瞰しやすいので便利ですね。
-
6.サブネット作成をクリックします
サブネットを作成の上にある「新しいサブネットを追加」ボタンを押すと同時に複数のサブネット作成が可能です。一度お試しされてください
-
この画面でのこの「サブネット作成」ボタンは、「サブネットの追加」もしくは「新しいサブネットの追加」などの方が良いような気がします・・・。 サブネットの設定画面にある「サブネットの作成」ボタンと被っているので混乱する人がいるかもです。
マネジメントコンソールですが、和訳についてはところどころ？？な分もあるので気にしていませんでした。しかしおっしゃるとおり混乱する元ですね。
-
今回は VPC ウィザードを利用し、必要なコンポーネント を自動的に作成後、 足りないコンポーネントを手動で作成・設定していきます。
なるほど。ウィザードでシンプルな１つのパブリックサブネットを持つVPCを作成するとゲートウェイなども自動生成されますね。
パブリック・プライベートと別れている構成なのでウィザードの上から２番目の「パブリックとプライベートサブネットを持つBPC」の選択でも行けるかと考えたのですが、あえて手動で一つずつ作成・設定されているのはやはり学習を意識してでしょうか？流石です！
-
自分の構成図
こちら細かくなってしまうのですが、以後の説明ではリージョン選択の説明があります。
それを踏まえると構成図にもリージョンの枠を入れておいた方が良いかと思います。ご参考までに・・
-
作成したリソースは必ず削除しましょう。削除し忘れた場合、想定以上の料金が発生する場合があります。
意外とリソース削除忘れは多いので、この案内は大事だと思っています。ありがとうございます。
-
RDSリソースのみ無料利用対象外ですが、構築後にすぐ削除すれば発生する料金は数十円程度です。 無料利用枠についてはこちらで確認できます。
利用枠の紹介や、有料であっても数十円と目安の料金掲載されているので、課金が怖い人であっても安心ですね。
-
実際にやったことを残しておこうと思いました。
学習した内容（インプット）を記録として残す（アウトプット）のは理解も深まるので良い取り組みだと思います。継続して一緒に頑張っていきましょう！
-
※ 構成図はdraw.ioにて作成
序盤で構成図を掲載されていて非常に判りやすいです。 また利用ツールのURLもあった丁寧だと感じました。 流石です！
-
-
qiita.com qiita.com
-
上記を実行する前には、下記の準備を行っておく必要があります。
EC2以外のAWSの構築ということですね。
-
cloud-init-output.log
ユーザデータを利用する際のためにこのログの存在を知っておきたいですね。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html#user-data-cloud-init
-
(サブネット把握しやすいように第3オクテットをNameの末尾の数字とした）
この設計はGoodだと思います！
-
既存IPアドレス削除し、Web-SGを指定する。
Wbs-SGを指定することでよりセキュアになりますね！
-
はまったこと
はまった点の共有ありがとうございます！
-
HTTPS＋AWS HTTPS 証明書 ACM＋(ELB or Route53
本番はこれらのサービスは必須ですね
-
インスタンス起動後数分すると・・・
sshで接続してコマンド実行がいらないのは便利ですよね
-
【ハンズオン1】基本的なブログサービスを構築する（シングル構成） AWSCloudTech
課題作成ありがとうございます！
-
ユーザーデータを利用して、wordpress AWS EC2でコピペだけでを立ち上げられる
ユーザデータを活用した記事ですね！
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
-
-
www.cloudgeeks.me www.cloudgeeks.me
-
AWSリソースのデプロイが非常に手軽で柔軟になる。
テスト
-
-
qiita.com qiita.com
-
テンプレート: 開発/テスト用（使用料金が気になる方は無料利用枠を選択）
コストに関して気になるところなので、有難いです！
-
EC2環境にターミナルでログインする。
WebServer1 のパブリックIPを指定してSSHするような補足をするとより良くなるので、参考にしてみてください。
-
3.作成手順
全体的に細かく手順書記載してとても良いですね。
マネジメントコンソールのスクリーンショットがあるとより良くなるので、参考にしてみください。
また、パラメーターのところは Markdownのテーブルを使って表で表現するとより分かりやすくなるので、参考にしてみてください。
【Qiita マークダウン記法 一覧表・チートシート】 https://qiita.com/zakuroishikuro/items/f33929eab9d55c5bd073
-
※何も指定がなかった場合はデフォルトのままで大丈夫です。
注釈ありがとうございます！
-
awsを使ってみたい人など是非参考にしてください。
AWSをやりたいのはじめの一歩としてとても参考になると思います！
-
烏合
Typoですかね。「動くのに」？
-
この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。
課題作成ありがとうございます！
-
RDSにはサブネットグループが必要であり、サブネットグループには2つ以上のサブネットが必要である。
こちらに記載されていることですね。 この補足は大事なことかと思います！
-
このような構成でwordpressのブログサイトを作っていきます。
構成図があり、イメージは沸きやすい内容になってますね！
-
-
qiita.com qiita.com
-
解決方法、原因不明、EC2インスタンス再作成。
EC2が原因不明で起動しないパターン、SSH接続できないパターンは実はたまにあります。 ログを確認できるように準備するのは大切ですね。
-
端末個別のIPではなくエンドポイントを接続設定に使う。
ご認識の通り、IPアドレスを固定にすると色々な不都合がありますよね。 解決策として「DNS」があります。
-
単純にHDDを増設する際にシステムに認識させるのにはこのような手順が必要になる
参考ですが、EC2にEBSを追加するにも手順が必要となります。 EC2にEBSボリュームを追加する手順はこちらも参考になります。チェックしてみて下さい。 https://qiita.com/kooohei/items/d692931cbebf97006f96
-
作成時のオプションに項目が存在しなさげ。
EC2インスタンスにEBSボリュームを追加でアタッチする場合、メニューに削除オプションはありませんので、EC2終了後にEBSだけ残り続けて課金されないように注意ですね！無駄な課金が発生していないか定期的にチェックしましょう！
-
設計するシステム要件によってサービスを選択、まずサブネット構成とセキュリティグループを考えるのが良さげ？
VPCは基盤となりますので、最初の設計は重要になりますね。ある程度TCP/IPのレンジも余裕をもってサブネット構成すると良いかと思います。
ご認識の通り「どのようなシステムを作成するか」を最初に決めるのが重要です。 3層アーキテクチャであればIPレンジを多くとりたいですし、単純にEC2インスタンス1台で動かすシンプルなサービスであればIPレンジは少なくて良いですよね。
-
インスタンスが指すものは、ユーザーがAMI（Amazon Machin Image)から作成した仮想サーバーのことではない。 選択可能なAMIひとつひとつをインスタンスという。イメージファイル＝インスタンス。
インスタンス＝仮想サーバ となります。 参考として以下の公式ドキュメントを確認いただければと思います
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html
-
多分一番重要。
おっしゃるとおり大事な要素ですね。 IAMは関連する他のサービスが多いので私も重要なサービスだと認識しています。
-
そんなのは困るはずなので基本的にEIPを作って割り当てるものと思っていればいいはず。
アクセスするたびにIPが変わると確かにサービス提供時に工夫が必要になるので手間がかかりますね。
-
ファイルシステムとして使えないよ、ってだけ。
そうですね。OSで利用できるファイルシステムで準備してあげる必要がありますね。
-
格
こちらはtypoだと思いますのでご確認お願いします。
誤：格 正：各
-
実践の中で気になったポイントだけをまとめています。
ご自身の学習メモ用の記事ですね。あとで振り返りで使えるのはよいですね。
-
-
qiita.com qiita.com
-
自分でカスタマイズしてマイAMIとして登録しておけば、いわゆる仮想マシンテンプレートのような使い方が出来る。
私も実業務でこのような使い方をする時ありますね。
-
その他参考
ドキュメントのリンク、参考になります！
-
（間違っていたら教えてください！）
新情報があればまた発信お願いします！
-
オーバーコミッド
細かいですがtypoです...!
-
ただし"T"インスタンスファミリーはオーバーコミッドされる
この例外は注意したいところですね。
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
課題作成ありがとうございます！
-
詳細設定とは全然違う
言葉の意味合いが違うってことが他の部分でもありそうですね。 また何か異なる部分があれば教えてください！
-
VMware ESXi にNSX組み合わせて構築したことがある人なら悩まずに進めると思う。
なるほど、参考になります！
-
仮想環境ばかり触っている私が気になった点
これは貴重な情報だと思います！
-
いくつか普段のオンプレミスでの仮想環境(VMwareなど)と考え方が異なる点がありましたので、備忘録
ありがとうございます！私も参考になります！
-
参考：CPUオプションを最適化する
参考文献の記載ありがとうございます！
-
OSインストールすることもなくなるのかと思うと少し寂しい・・・
私もそう思うことがありますｗ
-
-
qiita.com qiita.com
-
負荷の軽減になるといったメリットがある。
積極的に利用していきたいメリットですね！
-
・CloudFrontを利用する上で、配信先が多数ある場合の利用料金の削減に有効な方法
利用状況によって変わってきますが、コスト削減のためにも覚えておきたい機能ですね。
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
課題作成ありがとうございます！
-
用語
用語解説ありがとうございます！
Markdownのテーブルを使って表で用語解説すると、より分かりやすくなるので、参考にしてみてください。
【Qiita マークダウン記法 一覧表・チートシート】 https://qiita.com/zakuroishikuro/items/f33929eab9d55c5bd073
-
-
qiita.com qiita.com
-
CloudFront作成
ここもスクリーンショットがあるとより一層分かりやすくなるので参考にしてみてください！
-
StatusがDeployedとなれば完了(5分ほどかかる)
なかなか完了にならないとドキドキするところですね。
-
Route53でドメイン名とELBが紐づくレコードを修正して、alb.aws-demo.gaに変更
複雑なオペレーションになるので、ここはマネジメントコンソールのスクリーンショットがあるとより一層分かりやすくなるので参考にしてみてください。
-
手順
ここに構成図があると、この記事でどんなことをやろうとしているのかが分かりやすくなるので、参考にしてみてください！
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
課題作成ありがとうございます！
-
テスト
冒頭にも書いていますが、ここに挙動が分かるようにスクリーンショットがあると面白い記事になると思います！
-
このハンズオンでは料金が約10〜11円/時間かかります
情報ありがとうございます！
-
-
qiita.com qiita.com
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com
課題作成お疲れ様でした！
-
このハンズオンでは料金が約10〜11円/時間かかります。
大事な情報ありがとうございます！
-
補足2: セキュリティ面向上
こちらもマネジメントコンソールのスクリーンショットがあるとより分かりやすくなります。
-
wordpressの表示の仕様により表示が崩れます。
どのように崩れて、対処後の正常に表示される結果をスクリーンショットを貼るとより読み手がイメージしやすくなるので、参考にしてみてください。
-
補足1: httpsでwordpressを閲覧する
コマンドの詳細な記載ありがとうございます！
-
セキュリティグループの設定
リスナーのところと同様に、マネジメントコンソールのスクリーンショットも併せて載せるとより分かりやすくなるので、参考にしてみてください。
-
ロードバランサーでリスナーを追加
手順が細かく記載されておりますが、マネジメントコンソールのスクリーンショットも併せて載せるとより分かりやすくなるので、参考にしてみてください。
-
1, DNSの検証 （←今回はこちらを選択) 2, Eメールの検証
検証方法については以下のドキュメントに詳細な説明が記載されているので、目を通しておくと良いかもしれません。参考にしてみてください。
https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/domain-ownership-validation.html
-
通信を受け付ける設定でhttpsを追加
ここはリスナー追加の部分でしょうか？ 明記しておくとより分かりやすくなるかと思います。参考にしてみてください。
-
リスナー・・・通信を受け付けるポートの許可設定のこと
用語の解説ありがとうございます＾＾
-
HTTPS通信
常時SSL化のためにも押さえておきたいポイントですね
-
-
qiita.com qiita.com
-
以上より、CloudFrontとACMを使用したHTTPS配信環境を構築することができました。 今回の構築では、CloudFront設定はおおよそデフォルトのまま進めたので、細かいキャッシュの設定などはまた別の記事としてまとめていけたらなと思います。 以上、最後まで読んで頂きありがとうございました！
記事作成お疲れさまでした。 手順で図説もあり丁寧に記載されていてとてもわかり易かったです。
またセキュリティを意識した説明箇所もあって素晴らしいとほんと感じました。お疲れさまでした！
-
S3のバケットポリシーにOAIの設定が反映されたことを確認する。
S3のバケットポリシーもちゃんと確認されているのが、ほんと素晴らしいと思います。「なぜ接続できるのか？」が理解されているからこそバケットポリシーまで確認されているはずですので素晴らしいです！
-
そこで今回、CloudFront経由でのみS3バケットにアクセスができるように、OAIの設定をしていく。
セキュリティを意識した設定構成で良いと思います！
公式ドキュメントでも手順記載ありますのでご参考までに・・
-
トラフィックのルーティング先を選択
エイリアスの有効化スライドをONにしないとルーティング先の選択ができませんので、その旨注意が必要ですね。
-
「Origin Domain Name」
はじめて操作をされる方がOrigin Domain Nameに入力するバケット名を調べようとS3で確認するケースがあるのですが、記載されているとおり「選択する」なんですよね。
フォームクリックすると選択できるようになるので毎回便利だと思ってます。。がUI的には少し見直しをお願いしたいと毎回思ってます（汗）
-
CloudFrontディストリビューションが作成され、「Status」が「Deployed」、Stateが「Enabled」となることを確認する。
デプロイ処理に若干時間を要しますので少し待つ必要がありますね。
-
証明書の状況も「発行済み」となる。
証明書の状況ですが即時にならない場合もあります。若干時間的に余裕を持って作業する旨、明記されたほうが良いかと思われます。
-
※ CloudFront ディストリビューションに関連付ける SSL 証明書は「米国東部 (バージニア北部) (us-east-1)」 リージョンで実施する必要がある。
意外と見落としがちで作業時も漏れが多いので、ちゃんと明記されているのが素晴らしいです！
-
「パブリックアクセスをすべてブロック」にチェックが入っていることを確認
ここは今回ポイント箇所だと感じています。
S3で直接コンテンツ公開するのではなく、CloudFront経由となるのでパブリックアクセスをブロックにされているのがとても良いと感じました。さすがです！
-
Freenom
Freenomですが無料な分だと思うのですが、若干ドメイン取得時の挙動が止まるケースが最近見かけられます。
そのあたり作業時には気をつける必要がありますね。
-
今回、よりセキュアなHTTPS通信での配信が可能
昨今の検索エンジンのSEO対策としてもhttps通信は必須のようですので、S3で静的Webページ公開されている方にはとても参考になる記事だと思います。
-
- Apr 2021
-
-
このハンズオンでは料金が約10〜11円/時間かかります。
コストを意識しての金額明記！ナイスです
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
記事作成お疲れさまでした！
-
→ (ここで出てこない場合、ドメインとバケット名が不一致になっている可能性があるのでS3バケット名を見直す)
ドメイン名とバケット名の不一致による設定不具合ですが結構多いです。事前に注意記載されていて丁寧ですね。素晴らしいです。
-
フェイルオーバールーティングの設定
ELB側で障害が発生した際に、可用性が高いS3の静的サイトへルーティングするためですね？
以下でS3の設定を細かく記載されていて良いと思います。
ただバケットポリシーに関してはコードを掲載してみるのも良いかと思うのですが如何でしょうか？
-
→ 理由は、NSがまだ書き変わっていないからでしばらく時間を置いて、再度上のコマンドを入力して確認
DNSキャッシュの削除やdigコマンドでパブリックなDNSサーバを指定し情報が書き換わっているか確認するのも良さそうです。
-
[ Freenom ] というサービスを使用
Freenoomですが稀に管理画面の利用できないほど遅延が起きるので、そこがネックだと感じてます。
まぁ無料ですので仕方ないですが。。
-
ロードバランサーのIPアドレスでEC2サイトが問題なく閲覧できる状態
Freenomでドメイン割当する前にIPアドレスベースで接続テストをされているということですね？
問題切り分けになると思うので事前の検証作業素晴らしいと思います。
-
フェイルオーバーを設定して障害に備える
ドメイン取得してからのフェイルオーバー設定はより実践的になると感じています。記事作成お疲れさまです！
-
-
-
この記事はAWS初学者を導く体系的な動画学習サービスAWS Cloud Techの課題として作成しております。
課題記事の作成お疲れさまでした！
-
ただ、これを機にスナップショットと終了保護機能の重要性に気づけたので、次に活かしていきたいと思います！
前向きな取り組み！素敵です。
-
インスタンス作成後にで終了保護の設定
気軽にできる安全対策ですね！
-
スナップショットからEBSとAMIを作成
以下詳細な手順が一つずつ書いてあり、更に図説もあるので非常にわかりやすいです。
おそらく同様にインスタンス削除して焦っている人には神記事になってると思います！
-
スナップショットは、「ある時点（瞬間）における対象の全体像を丸ごと写し取ったもの」という意味で、ここではEBSのボリュームのイメージをS3に保存したものを指します。
これは簡潔な説明で非常にわかりやすいです。さすがです！
-
でも、まだ諦めちゃいけない。
諦めない心大事ですねｗ
-
スナップショットを取得しておいてよかった！！！
スナップショット取得たしかに大事ですね。よかったです。
ちなみにAWS BackupでもEC2のまるまるバックアップに対応しているので試されてみるのはどうでしょうか？ https://aws.amazon.com/jp/blogs/aws/aws-backup-ec2-instances-efs-single-file-restore-and-cross-region-backup/
-
SAA（ソリューションアーキテクトアソシエイト）試験に受かることを目論むエンジニア1年目の者です！
試験合格目指して頑張ってください！
-
今回はその時どうやって復元に成功したかについて、備忘録として記しておきたいなと思います。
トラブル時の復旧手順をまとめるのは他の方々もすごく助かると思います！
トラブルの時ほど成長できる機会だと思うのでナイス取り組みです！
-
-
qiita.com qiita.com
-
ENIで設定する、
ここで疑問が生じたのですが、なぜセキュリティグループをENIで設定したのでしょうか？
他のインスタンスへの付替作業が今後行われるならENIで設定するのも理解できるのですが、ELBなどの説明の流れでScalingと来ているのでENIじゃなくてもよいのでは？と素朴な疑問を感じました。
意図などあればご教授いただけると幸いです。
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
まとめ記事作成お疲れさまでした！
-
<起動テンプレートを作成>
作成した起動テンプレートですが、AutoScalingだけでなく普通にインスタンス起動でも使えるので、よく利用するハンズオン内容があるなら作成して準備しておくのもよいですね。
-
起動テンプレートを変更した際、テンプレートのバージョンを指定して更新することができる。
設定内容のバージョン化が出来るので実運用での管理もしやすくなりますね。
-
実際のEC2インスタンスの設定を反映した状態の起動テンプレート作成画面になり、自動的にソーステンプレートにソースインスタンスが表示される
既に完成形のインスタンスから雛形を作成するイメージですね。
-
作成方法
前回記事からの具体的なハンズオン手順ですね！
https://qiita.com/tr76aquarius/items/6b76baaab54e152ce6ed
概論的に最初に説明があったので、今回の手を動かす内容も一気に理解進むと思います。説明の流れがとても良いと感じました。流石です！
-
-
qiita.com qiita.com
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
今回も判りやすい課題記事作成お疲れさまでした！
-
定期的に処理が集中するシステムの運用はスケジュールを利用したスケーリングを設定すべきです。
業務パターンが定型化されているならば、予測もしやすいので記載されているとおりスケジュール設定がしやすいですね。
慌ててスケーリングしないので余裕を持った運用になるので素敵だと思います。
-
(例)アクセス数の増減により↓ ・負荷が70%を越えた状態ならEC2を１つ追加(限度は最大まで) ・負荷が30%を切っていたらEC2を1つ削除(限度は最小まで)
簡潔で判りやすい説明事例！素晴らしい！
-
起動設定を指定する必要があります。
こちらは起動テンプレートで設定するのではないでしょうか？説明で最初に起動テンプレートから進みましたが、途中から起動設定になっていましたので混在している可能性があります。
-
AWSは起動テンプレートの使用を推奨しています
起動テンプレートはAutoScaling以外でも普段使いでも使えるので便利ですよね。
今後、起動設定（旧版）は廃止されていくと予想してます。
-
期間限定のキャンペーンなどで負荷が増加した際、EC2インスタンスを増設して一時的な処理の増加に対応したり、逆に負荷が低下した状態ならEC2インスタンスを減らしたりできる
費用対効果の高い運用が出来るようになりますね。まさにクラウド的な使い方で理解もしやすい内容だと思います。
-
-
qiita.com qiita.com
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
こつこつとまとめて記事アップされて素晴らしいと思います。作成お疲れさまでした！
-
更に開くとシステムログが確認できます。
おめでとうございますヽ(^o^)丿
-
※awslogsdがスタートするタイミングでIAMロールがついていないとログが送られない可能性があるので、awslogsdがスタートした後にIAMロールを設定した順番なら一旦再起動すると正常に送られる。
細かい注意点記載ありがとうございます。 最初でIAMロール設定を行った後にインスタンス設定などしたほうがトラブルも減りそうですね。
-
以下をEC2のユーザーデータに設定することでEC2作成時に自動でCloudWatch Logsにログ送信が可能となります。
インスタンスメタデータからリージョン情報を取得したり、catコマンドでEOFが投入されるまで設定項目を追記したりとテクニック満載で素晴らしいです。しゅごい！
-
ドキュメントのリンク、Agentコマンドの説明
各項目の細かい説明記載があって理解しやすいです。流石です！
-
ログ監視の方はユーザーが設定する必要があります。
デフォルトでログ監視はされてない事の注意記載ありがとうございます。
-
ap-northeast-1に変更
利用するリージョンを選定しての変更ですね。
-
実装
オフィシャルなドキュメントに沿った手順内容ですね。基本に忠実で良いと感じました。ナイスです！
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html
-
ログの監視をCloudWatchで設定
以下実際の構築手順を細かく記載されていて理解しやすかったです！素晴らしいぃ！
-
-
qiita.com qiita.com
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
作成お疲れさまでした。
-
(例1) CPU使用率ならBadを設定するのが良い → なんらかの不具合によってメトリクス自体を送信できていない可能性があるのでそこを検知するため (例2) エラーが発生した場合のみにメトリクスが作成される場合 → 欠落データをGood(適正)するのが良い
実際の例を元に説明があるのでとても理解しやすくなりました。流石です！
-
感覚
なんども指摘で心苦しいのですが、こちらもTypoだと・・
正：間隔 誤：感覚
-
CloudWatchで収集した情報のこと
メトリクスの説明項目にて、「名前空間」の概念も説明あると今後良いかと思います。
メトリクスが沢山あって混入すると可読性も下がるので、グループ分けする目的でも名前空間指定は必須だと個人的には感じています。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html
-
1分間隔(Period)でCPU使用率を計測し、評価期間中(Evaluation Period)に何回越えたか(Datapoints to Alarm)という設定となる
例を用いての説明が判りやすいです！ありがとうございます。
-
感覚
こちらtypoになるかと思われます。
正：間隔 誤：感覚
-
ユーザーが独自に設定したメトリクス
カスタムメトリクスもよく認定試験で見かけます。
「どの項目がカスタムメトリクス内容か？」ということで多岐選択肢から選ぶというのがあるので、このあたり抑えておくと試験対策になるかと思います。
-
使用すべき理由
仕様すべき理由として各種メリットを上げているのが素晴らしいと思います。
閲覧する方も判断できるので納得度が変わってくると思います。
-
感覚
こちらtypoになるかと思われます。
正：間隔 誤：感覚
-
Alarmが起動したら様々なアクションを設定できる
AWS CloudWatch Eventsでイベントアクション設定ができますね！多種多様なイベント先がありますが以下で詳細確認が可能です。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html
-
→ 監視条件を設定するのがAlarmの役目
安定稼働を意識しての閾値設定ですね。
-
メトリクス
太字で記載されてますが、ここ大事なポイントですね。
-
オンプレのサーバーも同じ仕組みで監視できる
オフィシャルなドキュメントもありますので助かりますね！
-
ログファイルなども収集できる
各種サーバーサービスのログなども集約出来るので一元管理が可能になりますね！
-
→ (例)EC2のCPU使用率が90％など高負荷まで上がったら通知を出すなど
具体的事例で判りやすくなりました。さすがです！
-
-
qiita.com qiita.com
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました
課題作成お疲れさまでした！
-
続行→ 変更スケジューリング(デモなので今すぐ変更を選択)
このあと少し時間がかかると思います。次の障害テストに進む前に「変更スケジューリングの反映には少し時間を要しますので、待ちましょう」的なメッセージもあると良いかもしれません。
-
セキュリティグループを選択
IPアドレスではなく、ちゃんとセキュリティグループを選択しているのがポイント高いです。
-
ロードバランサーからのセキュリティグループからのアクセスのみに許可するよう設定を変更する
セキュリティを意識した取り組み！ ナイスです！
-
(※)wordpressのテーブルを使用する宣言)
SQL文まで解説あって、初学者の方も助かりますね。
-
どちらかのウェブサーバーにログインして下のコマンドでRDSに接続します
コマンド詳細解説が丁寧にあり素晴らしいです！
-
ヘルスチェック
ヘルスチェック先の対象ファイルなどが無い場合にはヘルスチェックエラーになりますので、ヘルスチェック先の指定も重要ポイントですね。
-
パブリックサブネットを選択
この設置するサブネットの指定ミスが結構多いので注意ポイントですね！
-
RDSのDBインスタンスを削除しないと 実装デモ終了時は9~10円/時間かかります。
コストを意識しても書き込みありがとうございます、 細かいとは思いますが素晴らしいです。
-
障害を想定した試験として ①メインのEC2を手動で停止してブログが見れるか確認 ②メインのRDSを停止してもブログが見れるか確認
これは良い取り組みですね。 予め障害対策をして試験に望むのはとても良いと思います。
今後はAWS側でもFault Injection Simulatorとして障害試験のサービスを提供するようですので、期待ですね。
-
-
qiita.com qiita.com
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
課題作成お疲れさまでした！
-
※メンテナンス時はメンテナンス用のEC2を用意してそこからメンテナンスをする踏み台サーバーを準備するケースがある
セッションマネージャーを用いて管理する手法もありますね。この場合ですと踏み台サーバーは不要になります。
-
ネットワーク
ALBでは裁けない大規模トラフィックの場合にはNLBを使う事もあります。
-
セキュリティグループによるアクセス制限が可能。
ALBの特徴の一つですね。 SAA試験などでも出てくる内容ですので要チェックポイントだと思います。
-
セキュリティが高いが、暗号化された通信の処理が重い
ELBの素晴らしいと思う点は、「マネージド」な所だと私は考えてます。
ロードバランサー自体の管理が不要でAWS側に任せる事ができるのがすごく良いと考えてます。
もしオンプレミスでロードバランサー準備する場合、処理負荷が高まった際にそのロードバランサー自体もスケールさせなきゃいけませんが、ELBだとAWS側でそれもやってくれるのでホント助かります。
-