今回は、Mappingセクションで設定したNameキーは一つだけでしたが、複数設定することができます。
ここにも、リファレンスを含めると良いと思います！ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/mappings-section-structure.html
690 Matching Annotations
- Apr 2022
-
-
-
エラーを起こしてしまいます。
実際のエラー画面とかもあると良いと思います！ 合わせて今回のケースの場合はマネジメントコンソールの出力やパラメータの画面もあるとより読者がイメージしやすいと思います。
-
[CloudFormation]複数環境を用意して共有リソースをエクスポートする
全体的に丁寧な説明に加え、Qiitaの記法を活用し視覚的に読みやすくしており素晴らしいです！ 企業でもドキュメンテーションは重視しているので引き続きアウトプット頑張ってください！
-
vpcのリファレンスは、こちらです。
リファレンスの記載、地味に大事です！ ハマっているときにいろんな記事見てても実はリファレンスをよく見ると答えがあることは多く、検索してヒットした記事からでもリファレンスを見て解決するケースもあります。
-
・クロススタック参照を使用して共有リソースをエクスポート
VPCを作成した後にSubnetやEC2を作成する。その他いくつか例があると、「こういうときに困るので、クロススタック参照を活用したい」という動機付けを読者にできるのでおすすめです！
-
ざっくりとしたイメージです。
イメージ図が合って分かりやすいです！ 最近Qiitaがダイアグラムに対応したようなので、こちらで書いてみるのもありかもしれません。（と言いつつも、この図には向かないかもしれません） https://qiita.com/Qiita/items/c07f3262d8f3b25f06c9
-
- Jan 2022
-
qiita.com qiita.com
-
$ kill {topコマンドの1番左のPIDを入力}
topで確認した際に、COMMANDがyesであることを確認することも付け加えてあると、あやまってCPUが一時的に100%になった全く別のプロセスを削除しないで済むかなと思いました。
また、「killall」というコマンドがあります。 以下の場合、「プロセス名がyesのプロセスを全てkillする」というコマンドです。 killall yes
本番環境などミスが許されない場合はひとつひとつpidをコピペするのが良いですが、開発環境などの場合はこちらで効率を上げてもOKかと思います！
-
$ yes >>> /dev/null &
リダイレクトが1字多い気がしますがいかがでしょうか。
` $ yes >> /dev/null & -
ヘルスチェックを行わないと何か障害が起きた場合に、ユーザーが接続できない状態になるので、つけておきます。
ここのヘルスチェックについては、ELBで設定できるヘルスチェックを対象とするかという意味になりますので、ELBのヘルスチェックも対象とするかどうかを記載すると、より分かりやすくなるかなと感じました。
-
起動設定は毎回設定を１から作らないといけないので、起動テンプレートを使用します。
1から設定を作成するのは大変ですよね。そういった意味でこのコメントがあることで、なぜ起動テンプレートなのだろうというのがわかりやすいです。
ちなみにですが2022年現在、AWSの公式より、起動設定は推奨されていませんので、そのコメンともあるとより親切かと思われました。 https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/LaunchConfiguration.html
-
- EC2 - RDS - ELB - Cloud Watch - AutoScaling
リスト表示になっていないかもしれません。
-
できなくなってしまいます。
例えば、大量アクセスがあっても処理できる場合もありますので、
できなくなる場合があります。
くらいに留めておくと、より適切かなと思いました。 前半部分の説明は非常に分かりやすい文章になっていると思いました。
-
https://qiita.com/pd1/items/cf17af9641503e7c1916
過去記事をリンクするのは親切で良いですね。 URLのみだけでも良いですが、プラスを考えるとタイトル名にハイパーリンクするとより過去記事を参照していただけるかもしれません。
-
-
qiita.com qiita.com
-
冗長性とは、耐障害性を高めるためシステム全体を二重化して予備システムを準備すること。
冗長性について簡潔にまとめられており、良いですね！
冗長化には、サブのシステムの電源を落としておく「コールドスタンバイ」（後述のホットスタンバイと比べて費用が低くなる・重要度の低い冗長化の方法）や、 サブのシステムの電源を入れっぱなしにして待機させておく「ホットスタンバイ」があります。
今回の冗長化はホットスタンバイですね。 実際には予算などに応じて、コールドスタンバイの場合もあります。 ・EC2のAMIを定期的にバックアップする ・RDSのスナップショットを定期的にバックアップする 上記の方法だと費用を抑えられます。 ただし、システム復旧に時間がかかるので、重要度の高くないシステムに向いていますね。 メリットデメリットがありますので、ご参考に！
-
前回のハンズオンでは、VPCにパブリックサブネットにEC2、プライベートサブネットにRDSを配置したシングル構成を構築しました。モック図は下記のようになります。
前回の状況を書くの大事です！最初にこの記事を見た方が「この構成から変更する」というのが伝わらないと、勘違いを生んでしまうこともあります。せっかくなので前回の記事のリンクを載せておくと合わせて読んでくださる方が増えてオススメです！
-
今の作業の目的や何をしようとしてるのかを意識しつつ行っていくことで
ここの意識素晴らしいです！ 目的によって作る構成も変わって来ますし、どうなっていればOKというのも変わってきます。この積み重ねが自分でAWSの構成を考えたりする力に繋がっていきます。どんどん手を動かしていきましょう！
-
DNS名の書き換え RDSに設定されているサイトアドレスをロードバランサーのDNS名に書き換えます。 ターミナルから
ここの設定はWordPress側の設定なので、AWSの設定だけで油断していると忘れてしまいます。 WordPress側の設定忘れるとどうなるか？とかがあると同じ状況でハマった人も見ることができるので余裕があれば試してみるのもオススメです。（と言いつつ全方面でやろうとするときりがないので、ハマったら書く位が丁度良かったり悩みどころではあります）
-
具体的には、VPC、EC2、RDSを使用して作成しました。 今回はそれに冗長化とスケーラビリティを構築していく手順を追っていきます。
EC2,RDSのオーソドックスな冗長構成の設定方法が丁寧にまとめられていています！
-
・CloudWatch ・AutoScaling
構成図も丁寧に描かれていて素晴らしい！のですが、今回、CloudWatchとAutoScalingは使用されてません。これらを使うことで、「EC2が規定の数起動していなかったら自動で新しいEC2を起動する」などができます。 こちらもご参考下さい。 https://qiita.com/Unimaru/items/9c4bbc03d8fe795540f6
-
障害テストをする
EC2,RDS共に障害テストまで行っていて素晴らしいです。 実務でも冗長構成などは障害テストまで含めて確認していく必要があり、実際に確認してみるとセキュリティグループなど地味なところで設定ミスがあり、冗長構成のはずが上手く機能しなかったと言うのはよくあります。
-
-
qiita.com qiita.com
-
無事1時間後にスタックのコンプライアンスが非準拠であることがSlackに通知されました。
標準機能の組み合わせて、CloudFormationの1時間ごとのドリフト有無をチェックし、あればSlackへ通知を行う連携の手順を丁寧に説明いただき、大変興味深く読ませていただきました。
運用管理やコンプライアンスの強化としてとても良い取り組みですね。
「変更対象は全てCloudFormationで行う」前提であり、厳格な運用ルールを重視するシステムでは非常に導入メリットがありますね！
技術トピックの選定センス、手順や説明が完結でわかりやすい、有益な補足など大変レベルの高い記事でした。
この度は課題提出ありがとうございます！
-
今回は頻度を「1時間」に設定します。
このアカウント全てのcFnドリフトがチェックされるのか？と思いきや、、
どうやら、ここでリソース識別子を設定することで、特定のCloudFormationテンプレートのみを検知対象としてできそうですね！
-
作成したプライベートチャンネル内で/invite @AWSと入力し、実行します。 また、Chatbotチャネル作成時にプライベートチャンネルのIDが必要になりますので控えておきます。
Slackへの連携、このような方法があるのですね！ すごく便利ですね。
-
S3バケットについてはCloudFormationで付与されたタグが付いていない状態ではありますが、ドラフトがない状態として認識されています。
これは不思議ですね。 ドリフト検知ではCloudFormationのタグまではみていないということですね。 確かに、タグはAWSが自動作成する作成日時等の情報のマネージドタグもあるのでここは無視されているのかもしれません。興味深い補足ありがとうございます。
-
ドリフト検出
テスト前に状態チェックをするところまで記事に記載しており、大変親切ですね！素晴らしいです！
-
Parameters:
全てDefaultが設定されておりテストしやすいですね。 良いと思います。
-
また、定期的なドリフト検出とSlackへの通知も併せて構成していきます。
検出だけでなく通知の仕組みも実装されていて大変素晴らしいです。AWSのベストプラクティスにも通じる考え方ですね。
-
【AWS】CloudFormationのドリフト検出を通知
ドリフトに絞った技術記事の選定センスがほどよくニッチでいいですね！
-
- Dec 2021
-
qiita.com qiita.com
-
RDSに設定されているsiteurlの確認
最後に補足をありがとうございます！ ここはWordPressの仕様によるもので、業務ではそうそう変更することはないかと思いますが、構築中は引っかかってしまう箇所ですよね。大切な設定です。
-
インスタンスレベルで稼働するファイアウォール
正確には「ENI」単位となります。 ・VPCエンドポイント ・ALB これらにもセキュリティグループを設定できますので、IPアドレス単位と言うことができますね。
-
ルートテーブル
パブリックサブネット / プライベートサブネットの違いをルートテーブルから優しく解説されていて、書籍を読んでいるようでスッと頭に入ってくると思いました。素晴らしいです！
-
プライベートサブネット同士をグルーピングしてあげる必要
正確には「異なるAZのサブネット」なので、 パブリック / プライベートは問いません。
データベースをパブリックに設置するのはかなりのレアケースですが、、
-
構成図
RDSがEC2アイコンになっているのに違和感を感じました。ここはRDSのアイコンの方が混乱がなく良いかと思います。
と言いつつ、RDSの実態はEC2です。（ストレージもEBSを使用） 「EC2をデータベースにセットアップし、マネージドしますよ」というのがAWSのビジネスモデルですね。 余談ですが、ELBもNginxをインストールしたEC2、もしくはDockerコンテナでは？と噂されていたりもします。
-
私自身がネットワーク関連の設定をしていて、躓いてしまったところ、躓きやすいところをシェアしていきたいと思います。
記事の目的を提示しているのが素晴らしいです。 それだけでなく、経験談から知識をシェアするのは必ず誰かを助けます。アウトプットする社会意義というか、価値がありGoodです！
-
-
qiita.com qiita.com
-
※ フェイルオーバールーティングは、デモをおこないました。（Sorry Pageを表示） → 自分で手を動かしてみることで理解度が増します。
おっしゃる通り、文章でまとめるのと実際に手で動かすのとは理解度が全然違いますよね！
昔はDNSの動きを手を動かして学習するのはオンプレや個人環境では困難なものでしたが、クラウドでは可能です。どんどん手を動かしていきましょう！
-
DNS, Route53の理解は障害対策、トラブルシューティング時に必要不可欠。
おっしゃる通りです！ 基本的なhostsファイルの動作も含めて「名前解決」は奥が深いトピックですので、じっくり学習していきましょう！
-
トラフィックルーティングの種類
大抵はシンプルと加重とフェイルオーバーで十分ですので、ほかのルーティングが必要となるケースで実務を担当する際は貴重な経験だと思います。 位置情報などはかなり大規模な構成ですよね！
-
Amazon Route53 Resolver
こちらの具体的な使用用途について補足します。
オンプレ（ネット接続無しの閉じた環境）とAWSとを専用線接続する際、オンプレはAWS側のリソースを名前解決できません。ネットに繋がってませんからね。
オンプレからAWSリソースのIPアドレスに対して通信できますが、名前解決できないのでAutoScalingなどでIPアドレスが変わると通信できなくなります。
そこで、Route53 Resolverを使用すると、内部に閉じたDNS Zoneを解決できる（ネットが繋がっていないオンプレでもAWS側の名前解決ができる）という使い方があります。
なお、この仕組みで月に3万円くらいかかります。 参考になれば幸いです。
-
コンテナ
AWSマニュアルではRoute53で「コンテナ」と表現されていますが、Dockerコンテナと紛らわしい直訳となっておりますので、こちらは「単位」とか「集約単位」とか「骨組み」「入れ物」のようなイメージを持たれた方が理解できるかと思います。
-
-
qiita.com qiita.com
-
ビルトインのセキュリティ機能（WAF連携、DDoS対策）
このセキュリティ対策がCloudFrontの大きな導入メリットだと思います。 パフォーマンスと並んで導入のメリットになりますね！
-
S3バケットへのアクセスをCloudFrontからのみに制限
OAI関連では以前、別の方が課題記事を書かれていました。とてもわかりやすい記事でしたので、共有しておきますね！ https://qiita.com/zeems/items/e41593dff8a1878a05dc#annotations:group:__world__
-
無料で利用できる。
AWS Shieldには無料版と、追加料金が必要なAdvancedがありますね。 https://aws.amazon.com/jp/shield/pricing/
ただし、 「AWS Shield Standard は、Elastic Load Balancing (ELB)、Application Load Balancer、Amazon CloudFront、Amazon Route 53 といった AWS のサービスを使用する場合、自動的に有効になります。発生するのは、AWS の該当するサービスの料金ページに記載されている標準料金のみです。」とありますので、余程のことが無い限り個人開発では無料版で十分そうです。
-
CloudFrontをCFnテンプレートで作成予定
これは楽しみです！期待しています！
-
HTTPS通信のみ可能に変更する。
余談ですが、実際にはHTTPで受信した通信はHTTPSへリダイレクトする設定をWebサーバーに入れるケースも良くありますね。
-
- Nov 2021
-
qiita.com qiita.com
-
ALB（ELB）のセキュリティ
後述WAFと合わせてしっかりセキュリティについてもまとめられていて素晴らしいです！
-
ECS, Fargate, CodePipelineをCloudFormationで構築時
この記述部分は何かのインフラ構成を指しているのでしょうか？
-
ALBとAWS WAFの連携
WAFと組み合わせる構成まで調査されたようで、大変素晴らしいと思います。 余談ですがオンプレでWAFを導入するとコストがかかりますが、クラウドだとスモールスタートできてコストメリットがありますね！
-
パブリックサブネットに指定する。
余談ですが、NLBをプライベートサブネットに配置するパターンは割と多くみます。ご参考に。
-
ALBがスケールする時は、IPアドレスが変化する。
ALBは負荷があ高まってスケールするとIPアドレスが増えることがあります。自動でスケールする機能が確認できます。
-
-
qiita.com qiita.com
-
dev環境、stg環境とprod環境など、目的別にVPCを分割するのがベストプラクティス
1つのアカウントでVPCを分割するパターンももちろん多くの企業で採用されていますが、前述の通り複数アカウントを使うパターン（クロスアカウント）も多いので参考にしてみてください。
-
無料で利用できるがどこにもアタッチしていない場合1時間あたり1円程度で料金が発生する。
初学者が意図せぬ課金となる最初の関門（洗礼？）ですので、消し忘れに注意しましょう。
-
サブネット間の通信経路を設定
正確にはサブネット間に限らず、サブネットとAWSサービスや、サブネットとインターネットなど様々なルーティングを設定することがありますね。
-
対価用
高い、の誤字でしょうか？
-
と
細かいですが、「に」の誤字と推測します。
-
オンプレミスや他のVPCのレンジと重複しないようにしておく。
ここは大変重要です。 将来的にハイブリッドクラウドの構成をとるときにレンジが被ると予期せぬ不具合となる可能性があるので、設計段階で注意したいところです。
-
CIDRブロックは、/16 が推奨されている。
ここは要件によりますね、、オンプレだと/16は比較的大規模なシステムです。
-
dev環境、stg環境とprod環境でVPCを分けることがスタンダード。
組織によってはdevアカウント、stgアカウント、prodアカウント、とアカウントをAWS organizationで分けてしまうパターンもあります。
-
1アカウントで複数のVPCを作成することも可能。
1つのAWSアカウントで1リージョンあたりに作成できるVPC数の上限は5個です。作りすぎに注意ですね。
-
プログラマブルな作成、管理、展開
特にCloudFormationでテンプレート化（コード化）しておくとクラウドのメリットが享受できますよね！
-
-
-
【AWS Black Belt Online Seminar】AWS CloudFormation
あ、やはり参考資料にありましたね！ Black Beltは中級者向けの知識整理に最適ですね！
-
新たに追記予定。 実務の中で学んだことを書き足していけたらなと。
技術書のひとつのトピックになるくらい有益なまとめだと感じました。 今後、運用（スタック実行時の再鑑者のチェック、cFn実行のIAM権限整備やルール）にも踏み込んでまとめられるのを（勝手ながら）期待します！
ありがとうございます！
-
【上：依存する側、短命かつ高頻度 下：依存される側、長寿かつ低頻度】
良いまとめです。素晴らしい！ （もしかしてBlackBeltのセミナーなどの講義メモでしょうか？ご自身でまとめられたのなら相当要約が上手だとお見受けしました！）
付け加えるならば、VPNやDirectConnect周りの設定はcFn化【しない】べきだと考えます。 理由は使い回しが少なく、クリティカルな（設定誤りが許されない）リソースで、かつ一発もののためcFn化をする恩恵があまりないからです。
-
っ
細かいですが、誤字の連携です。
-
VPC→SG+IAM→アプリケーションが基本となる
まさしく、こちらが基本となる「定石」です。 他システムへの使い回しも効きますからね！ 加えて監視（CloudFormation）が更に上に乗る感じでしょうか。
-
画面から入力、デフォルト値を設定しておくことが可能。
特にテストだと同じ値を何度も入れることになるので、地味ですが大切なポイントだと思います！
-
AWSリソースの依存関係は自動判別してくれる
正確には、DependsOnを利用して手動で依存関係を調整してあげないといけないものもありますね。
例えば、NATGatewayとEIPなど。 （EIPを作り、それをNATGatewayにアタッチする順番。ここは自動判定はされない）
エラーを読み解きながら経験を積むと、次第に勘所がつかめるかと思いますので、どんどんエラーを対処するのもcFnのスキルアップになるかと思います。
-
アプ
細かいですが、誤字を見つけましたので連携します。
-
-
-
RDSの死活監視も盛り込もうと思ったが、どうやらRDSの起動状態に関するメトリクスは存在しないようで実現には一手間必要そうだったのでパスしたがいずれ盛り込んでみたい。
RDSの死活監視が何故ないのか？ 良い視点だと思います。
そもそもRDSはAWSのマネージドサービスであるため、「AWSが管理するから基本ユーザー側の死活監視は必要ないですよ。」ということかと推測します。
（CloudWatch自体の死活監視メトリクスが用意されていないのと同様ですね）
「RDSが予期せぬ停止になるか心配だったら、マルチAZのオプションを利用してね。」ということとも捉えられますね。
さて、じゃあシングルRDSの実際の死活監視はどのような落とし所が適切か？ですが、、
個人的には「CPUやメモリなど基本的な監視を入れておき、もしそれらメトリクスデータがINSUFFICIENT_DATAが3回連続したらRDSが落ちている可能性がある」 ということで、そのようなCloudWatchのアラームの判定を入れておくのが良いと思います。
もちろんシステムの要件など、どの程度コストとバランッスを取るかの判断は必要です。
ご参考になれば幸いです。
くろかわ
-
この記事はAWS初学者を導く体系的な動画学習サービス 「CloudTech」の課題カリキュラムで作成しました。
課題記事の作成ありがとうございます。 お疲れさまでした！
-
お試し動作テストの観点だとCPUなどのリソースを監視して、意図的に負荷をかけ続けてスケールアウト、負荷停止でスケールインさせた方が多分楽かなと思った。
おっしゃるとおりですね。アラーム状態の確認もですが、自動的にインスタンスが増える様子が目に見えてわかるので、スケールアウト・スケールインのハンズオンが理解もしやすいかと思います。
-
※Auto Scaling グループの一部として実行するインスタンスの数。このメトリクスには保留中もしくは終了処理中のインスタンスは含まれません。
「保留中、もしくは終了処理中のインスタンスは含まない」と明記されているのと、公式ドキュメントのURL掲載が丁寧だと感じました。流石です。
-
【補足 AutoScalingによる起動台数について】 個人的に誤解していた部分だが、 ここで設定するのは、あくまでAutoSclingグループ内での台数設定で、 すでに作成済みのEC2(AutoScalingではない方法で作成したもの)はその数に含まれない。 例えば、作成済みのEC2を2台(webserver1,2)起動してある状態で、AutoScalingグループ 希望する容量2、最小0、最大2で作成・起動すると、 以下のように作成済み2台 に加え AutoScalingにより EC2(WebServer-Auto)が2台起動するので合計4台が起動している状況になる。 「すでに2台作って起動しているからAutoScaling発動しない」ということにはならない。
この補足説明は、他の方々も非常に参考になる内容だと思います。
誤解されていたとの事ですが、経験されたことによって他の方にとっても有用な情報になると思います。ありがとうございます。
-
ここからプライマリレコードとは入力値が異なる
注意点ですね。 しっかり赤字で記載されて注意喚起されてわかりやすかったです。ありがとうございます。
-
フェイルオーバールーティングのセカンダリを設定していないが、セカンダリにはS3のURLを指定する項目があるので、先にS3の作成を行う
先にS3側の設定を行った後に、Route53側の作業をまとめてやると手戻り少なさそうですね。
-
【正常時の通信経路設定(LB向け)】
丁寧な手順で非常に理解しやすかったです。 図も多めでありがとうございます。
-
※AliasレコードとCNAMEレコードの違いは以下公式ドキュメントに記載あり
よくあるFAQとして出てきますので、公式ドキュメントのURL掲載は丁寧で素晴らしいと思います。
-
CloudWatchでAutoScalingグループ内のインスタンス稼働台数を監視し、EC2が落ちてアラーム状態の場合はメール通知する
実務に即した内容でとても良いですね。 アラート発砲処理をメールされていますが、今後余裕があればSlackなどChatと連携するのを試すのも面白そうです。
ぜひトライされてみて下さい。
-
EC2(wordpress)・RDSの冗長化構成(※)に以下機能を追加して構築してみたので、その際の手順をまとめました。
引き続きの課題および手順資料の作成ありがとうございます
-
-
qiita.com qiita.com
-
ここに、バケットポリシーを適用する（ポリシージェネレータで作った結果をはってます）
もし余裕があれば、ご自身でJSONをいじってみるとより深く細かい制御の練習になるかと思います。
例えばConditionで「この時間からこの時間まで許可」ということもできます。
参考 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws-dates.html
本番運用では、大きめの企業の場合に「本番にアクセスできるIAMロールを用意する。このロールにスイッチできる権限をユーザーAに対して、リリース開始時間からリリース終了予定時間まで付与する」といった時限の許可操作も可能です。（GMOでもそのような制御で運用しようという案がありました。）
くろかわ
-
この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。
楽しい課題記事の作成ありがとうございました。 フランクな内容でしたが、終盤は結構重要な検証作業をされていたので、他の方々も参考になると思います。
-
- 1.1 ユーザAで作成したバケットに、ユーザC(S3のFull権限を持っている)の全ての操作をDenyするバケットポリシーを作成 - 1.2 ユーザCで1.1で作成したバケットにアクセスする。
この動作確認方法はとても良いですね。 複数の権限ポリシーがどう動くのか疑問が生じると思うのですが、実際に検証作業して理解が深まると思います。
-
おおおお！！！
AWS CLIで権限関係の操作体験できると、ShellScriptなどで自動化とかも試したくなるかもしれません。
ぜひお時間があればトライされてください！
-
ロールをアタッチ
ロールで動作確認をするのも良いですね。ロールは重要なIAMの構成要素ですので、しっかり抑えるのが素晴らしいです。
-
ちょっと飽きてきた。
対象ユーザーが多いと確かに飽きてくるかもしれません^^;
-
2. IAMグループの巻
実務で運用する場合、個人ごとの設定ではなくグループ単位で権限設定するのが多いので、とても実践的だと思います。素晴らしい！
-
Access Denied ！で失敗！ いい感じ！
これとても良いと感じています。 「自ら意図して設定した内容がちゃんと適用されている」のが判りますよね。いい感じです！
-
S3の読み込み権限付与
あえて権限を絞って付与するのが良いですね。判別しやすくなるのでとても理解しやすいと思います。
-
ファイルアップロードするべ。昨日の晩飯。もっかいたべたい。
じっくり課題の内容を確認させていただいてましたが、突然の飯テロで「羨ましい」となりました。
-
実験しよう。
本を読んだだけで「完全に理解した！」って方も多いのですが、知識の確認ということで実際に体験するその行動が素晴らしいです。
-
イメージはできてるぞよ。
ちょっとかわいくて「ふふふ」となりました(^^)
-
-
-
補足 時刻表示の変更
こちらも駒かな配慮、素晴らしいです！
-
補足 意図的にログに出力する方法
こちらはテストに便利ですね！
-
これはロググループのログの保持期間。デフォルトでは期限なしで明示的に削除しないと保持される。 アクション - 保持設定を編集で変更可能
ログの保管容量に応じて課金がされてしまうので、こちらは適切な期間で削除することをお勧めいたします。
-
2-9. ロール付与反映のため、EC2で以下コマンドを実行して再起動
こちらはAWS認定資格でも出題されますが、IAMロールをEC2にアタッチした後の再起動は不要です。 権限は即時反映されます。
-
EC2にCloudWatchエージェントのインストール
今後動画講座に追加する方針ですが、CloudWatch統合エージェントという方法があります。 興味があれば試してみてください。
設定ファイルをJSONで持ちます。
以下、参考サイトです。 https://open-groove.net/amazon-cloudwatch/cloudwatach-agent-log-setup/
-
"ERROR"文字列を検知した場合、アラーム発報する。
messagesの場合、他にもWARNやCRITという文字列を監視することが多いです。 クリティカルなものに応じて通知レベルを上げる（例：CRITが出力したらSlackにも通知する）などSNSトピックを分けることもできますね！
-
CloudWatch、SNSトピックを利用してログに特定文字列が出力されたらアラーム発報し、メールを送信するところまで試しに構築してみたので手順をまとめました。
基本となるCloudWatchの機能をまとめたものですね！実務でもよく使います。 しっかりまとめられており素敵です！
-
-
qiita.com qiita.com
-
ここからLighting Networkの操作を進めるまで環境構築できました。
正直、Lighting Networkなどで実現できることが私の勉強不足ではありますが、無事にサーバー構築できたようで良かったです！ 後続もあればぜひお知らせください。楽しみにしています！
-
ブロックチェーンの同期が完了しました。2か月程かかってしまいました。
そんなにかかるんですね！もしかしたらt系インスタンスでマシンパワーを使い果してしまったとか…？
-
ビットコインのブロックチェーンを格納するため、本来は400GB弱の容量を必要とするのですが、さすがに大きすぎます。 ブロックチェーンのデータを丸々持っているに越したことはないのですが、BTCPayを動かすのに必要な分のブロックチェーンに留め、25GBくらいに抑えることにします。 他諸々データが必要になることを考慮し、64GBの容量を確保することにしました。
要件と、推奨設定と、実現したいことのバランスをうまくとられていて素晴らしいです。
-
クレジット仕様: "無制限"のチェックを外しました。
t系のバーストを無制限としない設定で、外されるのは課金を抑える意味でも大変良い選択だと思います！
-
今回はt3a.smallを利用します。
多くの方はAmazon Linux2でt2.microと（ある意味思考停止で）選択されるのに対して、youjiさんはAMDプロセッサのt3aタイプを選び、OSもDebian10としています。
t2よりもt3の方が最新ですし、t3よりもt3aの方がプロセッサの違いにより安価で、自分流に選ばれてるなと感心しました！
-
今回はSubnetは1つだけなので、必要かどうかわからないのですが、Subnetも作ります。
EC2はサブネットに配置を必要とするものなので、必要となります。 VPCだけでできることはほぼ無いものだと思っていただいた方が良いかと思います。
-
-
qiita.com qiita.com
-
AWSの仕様でキーペアの権限を読み取り専用にしてあげないと、ログインできないので、
正確にはsshクライアント、sshサーバーの仕様となります。（opensshと呼ばれるオープンソースのソフトウェアの仕様）
鍵の権限変更が必要なのはAWSに限らず一般的なsshの仕組みと捉えていただければと思います。
-
ElasticIPは、EC2インスタンスにアタッチされていて、かつそのインスタンスが実行中であれば、無料となりますが、追加した場合やアタッチされていない場合は、単位時間で使用料金が請求されるので注意しましょう。
簡潔なEIPの課金説明、親切でGoodです！
-
パブリックサブネットにするためには、vpcにインターネットゲートウェイをアタッチする必要があります。
細かい表現のツッコミで恐縮ですが、パブリックサブネットの条件は「外部インターネットと疎通がとれるルーティング（0.0.0.0/0 ⇨ InternetGateway）が設定されたサブネット」となります。
-
②AWS System Manager Session Manegerを使用する
ご認識の通り、Systems Managerを使う方法も多く選択されますね。
他、少しトリッキーですがAmazon Linux2のDockerコンテナをFargateで起動させる踏み台パターンもあります。
-
このサーバーのことを踏み台サーバーと言います。中継サーバーのことですね。
余談ですが、Bastionサーバー（バスチョン or ベイスチョン）とも呼ばれますね。
-
ローカル環境やインターネット環境から、直接プライベートサブネット内にあるEC2サーバーにアクセスするのではなく、パブリックサブネット内にあるEC2サーバー経由でプライベートサブネット内EC2サーバーにアクセスすることです。
簡潔な説明、Goodです！
なお、踏み台の目的はEC2の他にもRDSへの接続（DBクライアント）もよく使われますね！
-
この記事の対象者
テーマを踏み台に絞っており、とても興味深く拝見いたしました。 最初にこのような案内があるので、読み手を迷わせない配慮ができており素晴らしいと思います！
-
-
qiita.com qiita.com
-
こうすることで、10.0.0.0/24の通信はVPC内
正しくは、10.0.0.0/21 (VPCレンジ内)の通信はVPC内ですね。 RDSへの通信もVPC内にルーティングされます。
-
※「終了時の削除」にチェックを入れない場合、EC2インスタンスを終了・削除してもEBSのみ残る。(料金に影響する可能性がある)
細かい補足、ありがとうございます！ 課金に繋がるので重要ですね！
-
■作業手順詳細
トグルで展開できるようになっており、読み手に配慮ができており素敵です！
-
■構成図
シンプルでわかりやすい図で、素晴らしいです！
ルートテーブルに矢印が伸びて許可が記載されていますが、これはセキュリティグループへの注釈が適切かと思います。
あと、現在はサブネットを 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 ... と連番ですが、 これにAZ 1cのサブネットを追加した場合 10.0.0.0/24（パブリック） 10.0.1.0/24（プライベート） 10.0.2.0/24（プライベート） 10.0.3.0/24（パブリック） となってわかりにくくなってしまいます。
なので、AZ 1cにパブリックサブネットを追加した場合も分かりやすくなるよう 10.0.0.0/24 (パブリック) 10.0.1.0/24（プライベート） 10.0.3.0/24（プライベート） と敢えて2をスキップすると完璧です！
ご参考に！
-
無料利用枠
無料利用枠縛りですかね？ 常に課金を意識してサービス選定を行う訓練にもなり、これはこれで良い勉強になると思います。
-
-
qiita.com qiita.com
-
【AWS】HTTPSでS3上のWebページにアクセス
こちらの記事、ハンズオン構成となっており、かつそれに付随する周辺知識も学べて大変有用だと思いました。 ありがとうございます！
くろかわ
-
この記事は AWS CloudTech の課題として作成しました。 動画やハンズオン等で学習を進めることができるので、AWS初学者にはおすすめです。
まとめ記事の提出ありがとうございました。
-
ポリシーが自動的に追加されていることが確認できます。
すでに対策済ならば良いのですが気になったので明記致します。
ポリシー内でOAIの情報も記載されていますが、これは架空の情報でしょうか？
Qiitaで公開されていて本番利用の情報ですと、「HTTPヘッダーいじってS3にアクセスされちゃう！」と老婆心ながら気になりました。
すでにOAIの情報を書き換え済なら問題ありません
-
ただし、このままでは index.html のオブジェクトURLを直接指定してWebページにアクセスできる状態です。
最初でOAIの設定をせずに、ここまでで導通確認しているのが堅実な設定手順だと感じました。
ステップを踏みながらの確認なので、設定不具合の切り分けもしやすくなりますね。
仕事の進め方もきっと丁寧なんだろうなと想像いたしました。
-
レコード名に入力する値とディストリビューションで指定した代替ドメイン名が一致しないと、ディストリビューションの選択ができません。
丁寧なFAQ！ありがとうございます。
-
ACM管理画面の左メニューで[証明書をリクエスト]を選択後、証明書タイプで[パブリック証明書をリクエスト]を選択し、[次へ]をクリックします。
CloudFrontですが操作画面がローカライズ（日本語化）されて一気に判りやすくなりましたね。説明文も簡潔で内容理解しやすくて素敵です。
-
以下のような構成を目指します。
構成内容が非常に判りやすいです。図説で一気に理解度増しますね。
-
また、S3のURLに直接アクセスしてもWebページが表示されないようにするためにオリジンアクセスアイデンティティ(OAI)を使用してアクセス制御をしていきます。
セキュリティ対策的にも好ましい設定内容ですね。流石です！
-
-
qiita.com qiita.com
-
例えるなら、飲食店の１日のような感じですね。 朝からお昼前はお客さんが少ないのでスタッフも少なく、ランチタイムのピークに向けてスタッフを増員、そして夜のピークタイムまではまた人員を減らし、ピークタイムに人員を増やす。 そんなイメージを頭の中で描きながらやってみるととても面白いですよね。 しかも自動で調整してくれるなんて、本当に便利ですね！
良い例えだと思います。
なお、オートスケーリングは便利ですが、EC2にデータを持たないなどアプリケーションに工夫をする必要も出てきます。
余談 私が過去、AWS Summit2019という幕張メッセで行われた数万人が訪れるイベントに出向いた時、受付が大混雑していました。 TwitterでAWS Summitを検索すると「おーい、受付、オートスケールしろよ。」といった書き込みが多く見られました笑
引き続き頑張っていきましょう！
-
TOP で PIDの番号を取得し、kill {3091..3096} ←例 のように、連番になっている番号で一括でKillする。
一括でもKillできますが、 もちろん kill プロセス番号 で単独のプロセスもKillできます。 間違えて他のプロセスをKillしないように気をつけましょう。
-
この設定を７０％以上と３０％以下で作成する。
実務では「なぜ70%にするのか？」「なぜ30%か？」まで考えて設計書に理由を記載するケースもあります。
すぐに必要なスキルではありませんが、実際のシステムのアクセス数や過去の数値を見て検討していくことになると想定されますので、頭の片隅に置いていただければ幸いです。
-
必要に応じてEC2インスタンスを増減してくれる便利な機能。
手書きでノートっぽい図、いいですね！
-
- Oct 2021
-
-
削除しただけで、DBRのポート番号が欠落した状態だったため、エラーになっていた。
もし余裕があれば、主語を明確にされることをお勧めいたします。
自分用のメモでしたら構いませんが、実務で他エンジニアへ伝えたい場合は、例えば 「RDSにアタッチするセキュリティーグループの許可ポート番号が誤っていた為、接続エラーとなっていた」などでしょうか。
知識習得を進めていくうちに具体的にドキュメントを書けるようになるかと思いますので、この調子で頑張りましょう！
-
初学者で、複雑な設定に戸惑い基本的なことが抜けてしまった。
一見複雑そうに見えるエラーでも、凡ミスだったことは私も多々あります。。
初学者の頃はとくにネットワーク系のエラーに振り回されると思いますので、頑張ってください！
基本的な見直しで解決するケースがほとんどです。
・セキュリティグループは適切か？ ・ルートテーブルは適切か？
ひとつひとつ見直すことで、次回はエラー対処の勘所となりますし、知見がたまっていき、徐々に対応速度が上がっていくことかと思います。
-
”You may not specify a referenced group id for an existing IPv4 CIDR rule”
こちらはRDSのセキュリティグループの作成時に出てくるエラーですね。他のかたも引っかかっておりました。 対応としてはご認識の通り、一旦セキュリティグループのルールを削除して、新規ルールを追加して設定することで対応できます。
https://dev.classmethod.jp/articles/aws-you-may-not-specify-a-referenced-group-id-for/
エラー対応お疲れ様でした。
-
-
qiita.com qiita.com
-
実際にちゃんと動作するかを確認する。 Webブラウザを立ち上げてEC2インスタンスのパブリックIPを指定して接続。 Wordpressの初期設定画面が開くため、必要情報を入力すると完成。
ひとつ上の文言と一緒ですが、、、TYPOでしょうか？？
ご自身が構築したサーバーで動くWebサイトがブラウザを通して表示されるの、最初は感動しますよね（私は感動しました）
これからも基礎を積み上げてどんどん応用技術を身につけていきましょう！ 課題提出ありがとうございました！
-
インスタンスを最新に
細かいですが、「EC2インスタンスにインストールされているソフトウェア（パッケージ）を最新にするコマンド」となります。
-
そこでSGを新規作成(設定は上記のもの)し、SGをこちらに適用し直す。
こちらはみなさん引っかかるエラーですね。 落ち着いてエラーメッセージをググれば解決記事がいくつもあります。対応お疲れ様でした！
-
※PrivateSubnetの方にもさっき設定したRouteTableが適用されてしまうため、新たにRouteTableを作成しこちらをPrivateに適用し直すことが必要。(これをしないとPrivateSubnetが直接インターネットゲートウェイを通って通信できてしまう。)
デフォルトではルートテーブルが共有されてしまうので、注意が必要ですね。
Publicサブネットは「インターネットへの通信経路がある」 Privateサブネットは「インターネットへの通信経路がない」 設定を指し示す呼称でしたね！
-
AWS操作時には、RootアカウントではなくAdministratorアカウント(Root以外のアカウント)で作成のこと。
AWSのベストプラクティスに則った大切な手順ですね。 両方のアカウントに仮想MFAの設定をしていくと、万が一パスワードが漏洩した場合でも安心です。
最初に設定するのは少し手間ががかかりますが、初学者の頃から癖づけておくと良いと思います。
-
-
-
本記事のレコード作成手順では「ウィザード」による作成で進めていきます。 以下の画像のような「クイック作成」となっている場合は右上の[ウィザードに切り替える]をクリックして進めてください。
丁寧な案内で素晴らしいです！
-
上記バケットポリシーは以下のAWS公式ドキュメントに記載の値を使用しています。
公式ドキュメントへのリンクありがとうございます！ S3のアクセス制御は奥が深いので、機会があればACLにも踏み込んでみてくださいね！
-
Sorryページ用HTMLファイルをアップロード
講座ではHTMLと画像のサンプルでしたが、CSSやJavaScriptもホスティングできるので、少しリッチなSorryページの作成にチャレンジされても遊び心として面白いかと思います！
-
Webサイトにアクセスする際に使用するサブドメインを後の手順で設定しますが、SorryページをホストするS3バケットの名前はそのサブドメインと同じにする必要があります。
ここの制約は大切ですね。 何度も問い合わせがある部分でハマりポイントです。
-
今回ドメイン取得は「お名前.com」で行いました。
実務でもテストでもよく使われるサービスですね！ 設定方法に慣れておくと実務でもスムーズに仕事ができるかと思います！
-
構成図
構成図、分かりやすくて素晴らしいです！
-
-
qiita.com qiita.com
-
CidrIp: !Ref DBinboundCidrIPs
今回はIPに対して許可設定しました。
別の方法で、セキュリティグループに対する許可設定も「SourceSecurityGroupId」でできるので、試してみてください。 EC2インスタンスのセキュリティグループの論理IDを!Refで指定します。結構よく使います。
-
この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。
おぉ！バナー付きだ！嬉しい！ありがとうございます！
-
下記のコマンドで作成したファイルをデプロイします。
初回作成時にロールバックしない CLIオプション -–disable-rollback が最近追加されましたのでご参考までに！
失敗した時のリトライ時間が短縮できます。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stack-failure-options.html
-
}
おっと、この } はTYPOですかね？ （あっても動くはず）
-
・CloudFormation スタックの作成
コメントが丁寧に書かれていてわかりやすいですね！ 他の方がみてもすぐに意味が理解できて良いと思います！
-
その後、CLIからSSH接続しCloud Formationを使ってプロビジョニングします。
おっしゃる通り、講座では「ローカルPC⇨EC2インスタンス」に接続し、AWS CLIのconfigファイルを設定してデモを行いました。
しかしながら、「ローカルPC」でAWS CLIのconfigファイルを設定することでも同様にCloudFormationの操作など可能となりますので、お時間があれば試してみてください。
ローカルPCにAWS CLIをインストールし、ローカルPCのユーザーに対してconfigファイルを設定します。
-
-
qiita.com qiita.com
-
VPCを自分で作るときはリソースの設定やアタッチをする事も出てくるので、何故タイムアウトが起きたのかを記録に残したく書いてみました。
お疲れ様でした！ 小さなトラブルシュートを重ねることで着実に実力が付いてくるかと思います！
原因に自分で気づけたのは素晴らしく、さらにイチからVPCのリソースを構築しようという学びの姿勢がさらに素晴らしかったです！
課題提出、お疲れ様でした！
-
②VPCにインタネットゲートウェイをアタッチします。
バッチリです！
-
ルートテーブルにインターネットゲートウェイをアタッチします。
細かい指摘ですが、「アタッチ」とは取り付けるようなニュアンスなので、 「VPCにインターネットゲートウェイをアタッチする」は正解ですが、 「ルートテーブルにインターネットゲートウェイをアタッチする」は少々違和感があります。
「ルートテーブルにインターネットゲートウェイ向けのルートを設定する」くらいが他のエンジニアから見ても表現の混乱がなく良いかと思います。
-
構成図を書くのも慣れが必要ですね((((；ﾟДﾟ)))))))
申し分ない構成図だと思います。
敢えて1点（超細かいですが）指摘するならば、Internet Gatewayのアイコンが2018年度版のひとつ古いアイコンになっていますね。
最新のものだと紫色のはずです。
（とは言っても、十分に伝わるので聞き流してください。。）
-
※今回、IPアドレスを固定しないのでEIPは不使用
EIPはEC2などに紐付けをしていないと（未使用状態だと）月に2〜3,000円ほど課金がされますので、意図しない課金を避けるために利用しないのは正解ですね！
-
全て自分の手で作り直してみるのも良いと思います。 自分は後者にしました。
良い機会になりますよね。ナイス判断です。
-
インターネットゲートウェイを.....。
課金は確かに怖いですが、インターネットゲートウェイは課金対象ではありませんのでご安心を！
-
-
qiita.com qiita.com
-
閲覧ありがとうございました。
記事作成ありがとうございました！ 今後も楽しみに課題提出お待ちしております！
-
今回の動作確認で下記の事が分かりました。
実際に手を動かして理解度もかなり向上されたのではないでしょうか？お疲れさまでした！
-
albの方は直ぐ反映されることが分かります。
blog.aws-demo-xxx.gaの分はCloudFront（各エッジロケーション）へ反映されるのに時間を要しますね。
-
[ここで注意があります]
事前の注意喚起さすがです
-
ドメイン名と一致した
大事なポイントですね。よく間違えがちな箇所だと思います
-
以下の流れで構築を進めます。
前もって概要手順を提示されているので判りやすいですね
-
これによって、ユーザーにとってはWebページの表示が速くなり、サーバーにとっては、データを渡す処理が減るため、負荷が軽減されるメリットがあります。
説明文の最後に判りやすいメリットが記載されていますので、これから利用を検討する人も興味を引きますね！さすがです
-
構築→記事作成→指摘反映の中で間違いがあったら業務でも発生するので、これからも気を引き締めて行きたいと思います。
引き続きの記事作成お疲れさまです。 継続する人が一番強いと思います。頑張ってください！
-
-
kotsutsumi.hatenablog.com kotsutsumi.hatenablog.com
-
自動テストは大体行える環境を作ってはいるが、自動デプロイに関しては無知だったので、とても良い経験になった
手を動かして知識も向上させるの素晴らしいです！
-
今回Yamlファイルで書いていますが、Jsonでも書くことができます。 しかし、Json形式ですとコメントが書けないといったデメリットがあります。
もう激しく同意してます。わかります。 コメント書きたいので私もyaml派ですｗ
-
ここでコードを書かなくてもS3に配置するなどでも大丈夫
すでにご存知かもしれませんがメモ的に。。
S3へコードを配置した場合、S3でバージョニングを有効にしS3バージョンIDで更新したzipファイルの指定や、そもそも保存場所であるバケットの変更などをすると、更新後のソースファイルを正しく参照できるかと思います。
「あれ？！ソース更新したのに反映されてない」ってなる場合がありますので、もしもS3に保存するならお気をつけください。
-
Parameters
AccessTokenをパラメーターとしてどのように安全に引き渡すのか気になっていたのですが、AWS CLIで環境変数から指定するのを見て安心しました。さすがです！
-
CloudFormationがスタックを作成するために、特定の機能が含まれていることを明示的に示す必要があ理ます。
公式ドキュメントでも掲載されている内容ですね！ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/APIReference/API_CreateStack.html
今回はLambda実行用のロールを作成したので該当されますね。
-
-
qiita.com qiita.com
-
今後の学習予定↓↓↓
ECSの講座を開始していますので、ぜひコンテナのスキルまで伸ばしていきましょう！
くろかわ
-
独自ドメインの設定と障害時にSORRYページへ通信を流す方法を学びました。 手を動かしながら学ぶと頭に入ってきますね。この調子で学習を進めたいと思います。
良いペースで進んでますね！ この調子で頑張ってください！
くろかわ
-
今の状態ではEC2からCloudWatchにログを送信する権限がありません。 その為権限を付与するためIAMロールを作成します。
S3バケット作成の見出しでCloudWatchの設定は少し違和感がありました。
前回、標準メトリクスでCPU使用率は設定されていたので、ここではカスタムメトリクス（例：メモリ使用率）の設定を入れてよりシステムの監視を充実させるとか、別の切り出しかたが良いかと思います。
くろかわ
-
■EC2(オンデマンド)→時間単位または秒単位で計算されるため停止中にすること。
これは2台目のEC2インスタンスのことですかね？ 念の為、EBSボリュームも削除されていることを確認すると予期せぬ課金が発生し続けることを防げるため、良いと思います。
くろかわ
-
この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。
課題記事作成ありがとうございました。 そしておつかれさまでした！
次回記事も楽しみにしております。
-
1時間に13円ほど費用が発生します。 構築してすぐ停止すればもっと安く構築できますよ！
目安の料金を提示されていてありがたいです。他の方もトライする際に料金面は心配になると思いますのでありがたい情報ですね。
-
上記が確認出来たら講座は完了です。
機能テストでは若干時間を要するかもしれません。講座対応おつかれさまでした。
-
っ
不要文字かもしれません
-
性的
こちらはtypoだと思われます。
誤：性的 正：静的
ご確認いただければ。。
-
IAMロールを作成後、EC2にアタッチします。
IAMロールでの権限付与はベストプラクティスとなりますね。ちゃんと勘所を押さえていて素晴らしいです。
-
今回はFreenomからドメインを取得します。
Freenom無料で非常にありがたいのですが、稀にFreenomのコントロールパネルの挙動がおかしかったりしませんか？特に言語を日本語選択して設定を行うと止まったりします。
言語はEnglishで設定すすめるとトラブルも減るような気がします。
-
※構成図の作成にcloudcraftを利用しています。
構成図があると一気に理解しやすくなりますね。作図ありがとうございます
-
構築→記事作成→指摘反映の中で間違いがあったら業務でも発生するので、これからも気を引き締めて行きたいと思います。
作業後に記事としてまとめることにより見直す部分も把握しやすくなりますよね？気を引き締めて行くという事ですが素敵です。私も見習います
-
-
kotsutsumi.hatenablog.com kotsutsumi.hatenablog.com
-
CloudFormationでインフラをコード化する ※別記事にて解説予定 GitHub Actions でmasterにpushしたら自動でデプロイする ※別記事にて解説予定
楽しみにしてます！
-
なぜLambdaを使ったかと言うと、EC2などに上げるより簡単かつ時間のイベント発火も簡単にできるためです。しかも無料で使える！
今回のケースだとLambdaが向いてますね！ EC2は費用面を見てもベストとは言えません。さすがです！
-
UTC(協定世界時) になっており、日本の時刻から-9時間する必要があります。
Lambdaのタイムゾーン自体を日本時刻に合わせることもできるようです。
環境変数でキーに TZ 、値に Asia/Tokyo と入力
未検証ではありますが、参考にしていただけますと幸いです。
-
- Sep 2021
-
qiita.com qiita.com
-
お約束ですが、下記サービスを使わないときは切っておきましょう。
テスト環境で課金が発生しないようにする配慮ですね！ 一言加えておくと読者が「なぜ削除？」と疑問をもつのを防げると思います。
くろかわ
-
今回の構成図
相変わらずCloudcraftの構成図は目を引いてカッコいいですね！矢印もプロトコルによって色分けされており、ナイスです。
くろかわ
-
2台のEC2が処理しきれないほどの通信が大量発生することも想定し、 Auto Scalingを設定してEC2を条件に合わせて増減してくれるように構成したいと思います。
最初に「問題提起」⇨「解決方法」と構成を組んでくれているのが良いと思いました。私も講座や記事でよく使う構成です。 実務でも提案などで役立ちますね！
くろかわ
-
この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。
記事作成ありがとうございました！そしてお疲れさまでした！
-
1時間に22円ほどです。
実際の金額を提示されているので、これから作業をされる方も安心ですね。お財布にも人にも優しい！
-
プロセスを終了させCPUが30%より低くなると、スケーリングポリシーにより 不要となったインスタンスはシャットダウンされていることが確認できます。
スケールアウトの時より、スケールインが待ち時間長く感じますよね。詳細モニタリングを設定すると監視間隔が１分と短くなりますので待ち時間も短くなると思われます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-cloudwatch-new.html
一度お試し下さいませ。
-
以下の流れで構築を進めます。
前もって手順を明示していて判りやすいです。さすが！
-
具体的には、ELBの配下にAuto Scalingグループを紐づけて、EC2インスタンスを最小２、最大４の範囲でスケーリングをさせます。
トラフィックが少ない時にはインスタンスの数がすくなくなり、多いときには増えるという様に、動的にインスタンス数を変動することによって、コスト効率も高まりますね。素晴らしい！
-
AWSを使った運用から開発まで極めるため日々精進
「極めるために日々精進」・・・最近流行りの「心を燃やせ！」を想像しました！一緒に頑張っていきましょう！
-
-
qiita.com qiita.com
-
You may not specify a referenced group id for an existing IPv4 CIDR rule. (既存のIPv4CIDRルールの参照グループIDを指定することはできません。) 一度、デフォルト設定を削除、新規作成することで事なきを得ました。
エラー対応お疲れ様でした！ こちら、他の方も引っかかってましたので教材に補足いたします。
-
Visual Stadio Code + Draw.io
ナイスです！VSCodeは実務でも（インフラエンジニア界隈でも）よく使われているので、ぜひ操作に慣れてくださいね！
ひとつリクエストをするならば、 構成図の背景の黒色と矢印、3306のポート番号の記載箇所が重複しておりますので、こちらは修正した方がよろしいかと思います。
-
DBへのアクセスはセキュリティグループで絞っている。
すでに認識済みかと思いますが、正確にはEC2もセキュリティグループでアクセスを絞っています。
-
また1から構築するのも学びのためには必要ですね。
そうなんです。基本動作を繰り返すと実務での対応スピードも上がります。 難しいことを何とか時間をかけてすることも大切ですが、基本動作を素早く対応できるのも同じくらい大切です。
-
初めての経験でしたが何とかゴールすることができました。 多分ですが、今まで通り例題が載っている専門書を買っていたら、途中で投げ出していたと思います💦
嬉しいご評価ありがとうございます！ CloudTechをある程度進めたらより高度な専門書籍も難なく読めるはずです。そのレベルまで到達すればスキルのレベルアップが爆速になります。頑張ってください！
-
セキュリティグループのRDS-SG-1のインバウンドルールは肝ですね、ここをWebServerのみアクセスとすること。
おっしゃる通り、データベースは通常大切なデータが保管されている企業の命とも言えるものなので、セキュリティの意識があって良いと思います。 間違ってもパブリックアクセスにしないよう練習段階から意識づけしておきましょう。
-
※カッコ内の文字列は設定値です（後で振り返るときに無いと困りそうで💦）
名前タグを設計書に書いたということですね！ 後から見返しても分かりやすいと思います！Goodです！
-
-
qiita.com qiita.com
-
AWSについてほとんど知識がない所からはじめましたが、だんだんイメージが掴めるようになってきました。 基礎を振り返りつつ、少しずつ知識定着をしていきたい。
課題記事の提出、ありがとうございます！ これからQiitaでアウトプットを積み上げて外部に向けてアピールできるものを積み上げていきましょう！
今回は文章量も少ないのでコメントも少なめでお返しします。引き続きよろしくお願いいたします。
-