処理が軽くなる
そうですね！Webサーバ側の処理が軽くなりますね。
690 Matching Annotations
- Apr 2021
-
qiita.com qiita.com
-
-
片方のEC2が忙しそうなら
簡潔で判りやすい表現！ 気遣う感じが表現されていて好きです。素敵！
-
セキュリティに伴う処理の負荷の問題
Webサーバー側でSSL処理をすると、その分の管理など工数も増えてきますので人的負荷も増えちゃいますね。
-
インスタンスID,IPアドレス,Lambda関数を設定できます
こちらよいですね！インスタンス以外にも振り分けがELB可能ですので、ちゃんと明記されるの素敵だと思います
-
-
qiita.com qiita.com
-
はい。作成されましたね。今回はここまでです。
作成おつかれさまでした！今回はVPC名はtest-vpcでしたが実運用や本番環境などを考慮し命名規則なども考慮が必要になってくるかと思います。
その際にはこちらも参考になると思いますのでご確認ください。
https://dev.classmethod.jp/articles/aws-name-rule/ VPCだと・・・ {sysname}-{env}-vpc
-
×を押して
すごい丁寧！ 私いつも無視してますｗ
-
※リージョンの選択によって、通信速度,料金,サービスが違ってくるようですが、通信速度を考えて近いリージョンであること、学習用であることを考えて東京を選択します。
料金、速度、サービスを考慮しての選択ですが、企業の場合によってはコンプライアンスによって国外でデータ保持してはNGというのもあったりするので、法令や規定なども意識すると良いかもしれません。
-
今回は、学習用のため、デフォルトで構いません。
学習のためにさくっと選択！良いと思います！
-
割高です。
コスト意識しての記載すばらしいです。確かにコスト割高ですね。セキュリティ面以外にライセンス的にテナンシーを選択する場合もあります。
MSのサーバソフトウェアでライセンスをすでに保有していて持ち込みする場合などはホストに割り当てを行う必要があるのでテナンシー選ぶみたいな感じになります。
-
AWSアカウントに紐づいた専用の仮想ネットワーク環境。リージョンに作成される。
さすがです！VPCはリージョン毎に準備が必要ですね！
-
基本遠いほど通信に時間がかかる。
現在地より遠方ですとおっしゃるとおりネットワーク通信に時間がかかりますね。
その分グローバルにサービスを展開する際には、エンドユーザーに近い場所に選択などができるメリットもありますね
-
AWSにIAMユーザとしてサインイン出来ることとします。不明な場合は、情報は色々落ちていると思うので、ググってください。
一番最初のハンズオンとしてAWSでも”ハンズオンはじめの一歩”を公開しています。それも結構おすすめですので紹介するのも良いのかもしれません。
https://aws.amazon.com/jp/blogs/news/aws-hands-on-for-beginners-05/
-
アラフォーのAWS初心者が学んだことをつらつら書いていきます。
こつこつ積み重ね大事です！ 私もアラフィフになりますが、常に新しい事できるようコツコツ続けます。一緒に頑張っていきましょう！
-
-
-
ログが収集できています！お疲れ様でした！
IISのエラーログまで収集できていますね。さすがです！お疲れさまでした！
-
IISのアクセス、エラーログは、デフォルトではこちらのように構成されているので以下のように設定します。
IISのエラーログはアクセスログとは別場所に保存されるのですね！知らなかったです。これは情報ありがとうございますφ(..)メモメモ
-
割愛します。
設定ファイルを手動編集する場合でも、かなり項目が多いので割愛はよい判断かと思います。
必要時にドキュメントを確認するスタイルで私も進めます。
-
SSMを使用したCloudWatchエージェントのインストール
図説一気に判りやすくなりますね。ありがとうございます！さすが！
-
インターネット経由でmsiをダウンロードしてインストールする。
SSMで一括作業できるので作業効率が上がりますね。次回時間があれば、AmazonSSMManagedInstanceCoreのポリシーを解除し、手動でダウンロードインストールし比較するのも良さそうですね。きっとその利便性がよく判るかと感じました！
-
SSMでEC2を使用するために付与する
なるほど。SSMでRun Command実行するためにポリシー付与されたのですね。
-
統合CloudWatchエージェントがサポートしているWindowsサーバであること 参考：サポートOS一覧
本家AWSサイトのドキュメント掲載流石です。 （awsが入ったURLも見える状態ですと閲覧者も安心するかもしれません）
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html
-
基本的に新規インストールはこちらを使う。
注意喚起ありがとうございます。
-
CloudwatchエージェントでWindows 2019サーバのIISのログ取得
WindowsサーバのイベントログをCloudWatchで取り扱うのですね。IIS自体最近見かけてなかったので参考になります。（期待値高まります）
-
-
-
手順としてはEC２の削除→NAT gatewayの削除→Elastic IPの開放→VPCの削除です！！
削除順番ありがとうございます！
-
そのあとは全て進んでいただいて起動をクリックします！
セキュリティグループはデフォルトのものになりますかね？ Public Subnetに作った同じように新しくセキュリティグループを作って、SSHを許可するソースを test-sg-1 を指定するのが好ましいので、参考にしてください。
-
煮付けて
TYPOです！
-
ミグ上
右上、ですかね！
-
色んな種類
多すぎて混乱しますよね...
-
インターネッとゲートウェイをアタッチする
typoです...!
-
必ず日本にいるならば日本のリージョンを選択しましょう！
利用するAWSサービスによっては、リージョンごとでコストに差があるので、お試し構築なら日本以外も選択肢にいれるのもいいかもしれません
-
先ほどのキーペアはサーバーにアクセスするための鍵だと思っていてください！
私は自宅の鍵だと思うようにしていますね
-
静的なのでインスタンスが再起動や停止しても同じアドレスが保たれます！！
Elastic IP に対して課金が発生する条件も押さえておくと良いかもしれません！
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#eip-pricing
-
必ず手書きでもいいので初めは構成図を書きましょう！！！
大事です！
-
これは作成しただけでは意味がありません！
ここは私も罠だと感じていますｗ 作成するタイミングでアタッチをできるようにしてほしいですよね
-
インんターネットゲートウェイはVPCにアタッチするんでしたね！！
リソースがどこにアタッチされるのか理解しておくのは大事ですね。
-
こちらが東京になっていることを確認しましょう！！！
確認大事！ 何かのタイミングでリージョンが変わってることが多々あります！
-
基本的にはルートユーザーでは作業せずIAMユーザーで通常の作業をすることをAWSは推奨しています！
こちら大事なことですね！
-
パブリックサブネット ...インターネットに接続できる プライベートサブネット... インターネットに接続できない
更に正確な表現をする場合、
パブリックサブネット：インターネットゲートウェイにルーティング出来るサブネット
プライベートサブネット：インターネットゲートウェイにルーティングしないサブネット
と覚えておいた方が好ましいかもしれません。
-
AIMユーザーでログイン
typo です...!
-
リージョン
ここは「AZ」ですかね？
-
大阪リージョン
大阪も最近フルリージョンに昇格しましたね！ 脱線ですが、東京と大阪で使えるAWSサービスで差があるのは注意したいですね。
-
今回はこんな感じの構成で作成していこうと思います！
構成図があってイメージが付きやすいです！
-
対象読者
対象とするレベル感が分かると読み手側にも優しいですね！
-
-
-
最後までお読みいただきありがとうございます!
記事作成おつかれさまでした！
-
ロゴが表示されれば成功です！
ロゴがぐるぐる回りました！ありがとうございます。
-
# WEBリクエストをローカルホスト3000番ポートへリダイレクト
なぜこの設定を行うかの説明が記載してあり理解しやすかったです。さすがです！
-
クローンします。
今回はローカルでアプリを作成せずに、EC2上で下記コマンドを実行しアプリ作成し検証してみました。
npx create-react-app my-app cd my-app npm start
-
下記エラーが表示されてしまうので、
defaultのindex.htmlが表示されていますね！
-
curl -sL https://rpm.nodesource.com/setup_14.x | bash -
rootなど管理者権限を保有してないとエラーが生じますね。
-
権限ユーザーの切り替え
以降の作業ですが、sudoを使ったり、sudoを使わないで管理者権限である状態での作業などと混在してらっしゃいますので、このあたり統一されたほうが閲覧する方も混乱しないかと思います。
ご検討ください。
-
.12
細かいリビジョン指定までされていますね！φ(..)メモメモ
-
続いて、新しいセキュリティグループを作成します。
ご存知かと思いますが念の為にお知らせです。
今後、既存環境を拡張して運用する場合、SSHの接続元などソースは固定化できるなら固定化されたほうがより安全性が高まるかと思います。
（要件にもよると思うのですが、即時作成→即時削除のインスタンスならSSHの接続元ソースは「0.0.0.0/0」でも良いと思うのですが、今後もご利用されるのであれば心配になり記載いたしました）
-
今後の拡張のため作成
オンプレでも同様ですが、今後要件が変更されたり拡張されるというのはよくある事なので、事前に拡張性高い設計を行うのは素晴らしいと思います。
-
AWSのEC2でReactアプリを起動してみたい。
要件が異なると思うのですが、amplifyでもReactアプリの利用が出来そうですね。
https://aws.amazon.com/jp/getting-started/hands-on/build-react-app-amplify-graphql/
-
Reactアプリ作成したことがある。
Reactを触ったことがなかったので、今回良い機会になります。ありがとうございます！
-
今後も拡張していき学習の効率化を図る。
学習の継続ですね。頑張っていきましょう！
-
-
-
ソース カスタム 10.0.0.0/24
プライベートサブネットのEC2(proxyserver1)からの接続しか受け付けない設定「ソース：Proxy-SG-1」とした方がセキュリティ的に高まります。
このままだとプライベートサブネットに所属する全てのリソースから8080ポートを受け付けるので注意です。
また、画面キャプチャはポート22が0.0.0.0/0で解放されておりますが、ここも同様に「ソース：Proxy-SG-1」の方が良いかと思いますのでご参考に。
-
行ったことは次の通りです。 nginx環境を構築、インストールしてブラウザ表示させる Apache環境を構築・インストールして、nginxと連携してWebページを配信させる phpMyAdminをインストールして、Mysqlと連携・ブラウザ表示させる （失敗談）WordPressのインストール
全体の流れが記載されていて、Goodです！
-
今回の構成図はこちらです。
NATゲートウェイが本課題のPrivate SubnetのEC2にApacheをインストールする際に必要なAWSリソースと理解したので、NATゲートウェイのアイコンはPublic Subnet1枠の端っこに置いておくのが好ましいかもしれません。
-
今回の構成図はこちらです。
最初に本記事で実施する内容の構成図が描かれていて、とても分かりやすいです！
-
（失敗談）WordPressのインストール
記載ありがとうございます！
-
RDSをプライベートサブネット1のEC2からのみアクセスできるようにする
ここはしっかりと押さえておきたい部分ですね
-
なし
今回の要件では「なし」が必須パラメーターですね
-
nginxの画面から、Apacheから配信されているindex.htmlの画面に切り替わる。
想定した挙動を確認できると、楽しいですよね！
-
プライベートサブネット1のEC2にApacheをインストールする。
前工程で作成したNATゲートウェイを介して、Apachをインストールされる流れですね！ コマンドもありがとうございます！
-
有効
Private Subnet の場合、自動割り当てパブリックIPが無効になるのかな？と思いました。
-
※これ以降、特記しない限りデフォルトの設定のままにしています。
注意書きがあり、進みやすくなります。ありがとうございます！
-
AWSで再現
他環境での構成をAWSで再現するだけでも勉強になりますよね。
-
-
zenn.dev zenn.dev
-
カオスでした
やはりカオスだった
-
-
zenn.dev zenn.dev
-
カオスでした
テスト投稿
-
-
fledglingengineer.xyz fledglingengineer.xyz
-
今回の内容がみなさんのお役に立てれば幸いです。
簡潔な内容でわかりやすかったです。 まとめ記事作成お疲れさまでした！
-
以下のコマンドで実行すれば、あなたもEC2を自動構築可能です!
クロススタック参照の場合、削除作業の際に削除順番も考慮が必要になるので、ここはちょいと注意が必要ですね。
時々「スタック削除されない！どうして？」と焦るケースを見かけます。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/walkthrough-crossstackref.html
-
使用するVPCファイルは以下の通りです。
VPCのテンプレート。。 意外と設定箇所が多いので長めになりますが、丁寧にまとめられてすごく見やすいです！
Outputsについても「ec2.ymlで仕様するための出力変数」と説明コメントもありましたので一発理解できました。
-
一つのファイルにまとめて使用することも可能ですが、 どうしてもコードが長くなりがちなので、全体を把握しづらくなります。
機能単位で分割していると把握しやすい事と、他の環境へ流用もしやすくなると感じています。
ただちょっとした簡単な環境だと１つのファイルで纏めて作成しちゃいがち。。このあたりバランスも要考慮だと個人的には感じています。
-
コメントが記述できる、人間にとって読みやすいといったことから、 YAML形式がおすすめです。
そうですね！可読性が高いのでYAML形式でのテンプレート作成が作業しやすくなりますね。
-
要約すると、コードを記述したテンプレートファイルで AWSリソースを管理できるということです。
簡潔で非常に判りやすい説明！ ありがとうございます。
-
画面からポチポチしていくのはなかなか時間がかかりますよね。。。
毎回検証用の構成環境を構築する際に、１からポチポチ構築するのは確かに時間がかかって大変です。
自動化にもつながるCloudFormationの説明記事ありがとうございます。
-
-
zenn.dev zenn.dev
-
このように、OutputsセクションとImportValue関数を使うことで、CloudFormationのスタック分割を実現することができる。
非常に分かりやすいです！ ありがとうございます！
-
AWSで推奨しているスタック分割の仕方は以下の通り。
誰かと共同で作る時のためにも、推奨される分割方針は理解しておきたいですね。
-
本番環境だけ、追加でEC2インスタンスを構築するといった動きを記述してみる
「特定の環境だけ何かを追加で作る」というのは私も経験しているので、Conditionsは覚えておくといいかもしれませんね
-
同じテンプレートも場合によって設定を変えることができるようになる。
検証環境/本番環境でテンプレートを個別に作る必要がなくなる、ということですね！
-
Metadataキーは他にもあるがここでは割愛する
良い活用例があれば、余力がある時に次回作お願いします！
-
パラメータの入力も見やすくなる！
これは便利ですよね！
-
Parametersセクションを利用する
汎用性が高まるので、積極的に利用していきたい機能ですね！
-
作成されていることが確認できたら、今度はスタックを削除すれば、MyVPCやMySubnetが勝手に削除されることがわかる。
「スタックを削除して、リソースは残す方法」について、公式ドキュメントのリンクを貼っておくとより親切力が向上するかもしれません！
https://aws.amazon.com/jp/premiumsupport/knowledge-center/delete-cf-stack-retain-resources/
-
各項目は以下のような役割を果たしている
表として整理解説されていて、とても分かりやすいです！
-
背景・目的
IaC導入のメリットが整理されていて、わかりやすいです！
-
-
zenn.dev zenn.dev
-
仮想サーバーとは
いいですね！
-
Webサービスに関するインフラの知識不足の解消＆クラウドサービスの世界シェア１位であるAWSの学習のため、YouTubeでAWSの学習動画やエンジニアに関する情報を提供している「くろかわこうへい」さんが開催する AWS CloudTech に参加しました。
ありがとうございます！
-
-
zenn.dev zenn.dev
-
ACMを使ってhttps通信にも対応していきます。
HTTPS通信も使うんですね！
-
CloudFrontはAWSのCDN（Contents Delivery Network）サービスです。 CDNはキャッシュサーバーを使って、コンテンツを高速で配信するシステムのことです。
簡潔でいい感じですね！
-