20220113のAWSに関する記事は15件です。

【AWS】AutoScalingの起動設定でAMIを変更しただけのはずがAWS利用料が倍になっていた話

はじめに あ…ありのまま 今 起こった事を話すぜ! 「おれは 起動設定でAMIを変更したと思ったら いつのまにかAWS利用料が倍になっていた」 な… 何を言っているのか わからねーと思うが  おれも 何をされたのか わからなかった… 頭がどうにかなりそうだった… 催眠術だとか超スピードだとか そんなチャチなもんじゃあ 断じてねえ もっと恐ろしいものの片鱗を 味わったぜ… おふざけはさておき、タイトルのとおり起動設定でAMIを変更しただけだったはずが、AWS利用料が倍になってしまったため、自分への戒め及びAWSを利用している方へ共有するためにも記事として残します。 やったこと 新しくAMIを作成したため、既存の起動設定をコピーして新しい起動設定を作成した。 ※この時、変更したのはタイトルとAMIのみ変更し、他の設定は変更していない。 起きた事象 毎日EBSボリュームを作成しており、1か月後にAWS利用料が倍になっていた。 ※起動設定を入れ替える前はEBSボリュームを作成することはなかった 原因 この環境ではAutoScalingでEC2の台数を毎日増減しており、EC2を削除した際にEBSボリュームが自動で削除されなくなっていた。 ここでピンときて、EBSを自動削除する「終了時に削除」を確認する。 既存の起動設定では「終了時に削除」の設定は有効だった。 新しい起動設定では「終了時に削除」の設定は無効となっていた。 ※「やったこと」にも記載しているとおり、筆者は既存の起動設定をコピーして新しい起動設定を作成していた。 「終了時に削除」は変更していなかったはずが、いつの間にか変更されている点に注意してほしい。 なぜ発生したか 新しい起動設定を作成する際にAMIを変更したが、このAMIに問題があった。 AMIを作成するときに「終了時に削除」が無効のまま作成していた。 その結果、新しい起動設定でAMIを変更したときにAMIの情報で起動設定が上書きされてしまい、元々有効だったはずの「終了時に削除」が無効になってしまっていた。 対策 起動設定を再作成し、「終了時に削除」を有効にすれば今後は発生しなくなる。 しかし、起動設定の「終了時に削除」はスクロールしないと見えない位置にあり、起動設定を頻繁に更新する場合は毎回目視でチェックするのは難しく、現実的ではない。 そのため、AMI作成元のEC2の「終了時に削除」設定を変更し、「終了時に削除」を有効にすることで今後作成するAMIの「終了時に削除」を有効にすることができる。 やり方は以下の記事を参照。 【AWS/EC2】EBS自動削除をオフ→オンに切り替える方法 また、EC2自体を新しく構築しなおした際に「終了時に削除」が無効になると同様の事象が発生してしまうため、lambdaとCloudWatchで定期的にチェックしても良い。 EC2(インスタンス)が削除されて残ってしまったボリュームの削除 後はCloudFormation等の構成管理ツールを使うのもありかと思いますので、状況に応じた対策をとっていただければと思います。 最後に AMIの設定に応じて起動設定の内容が変わるなんて盲点でした。。。 また1つ勉強になりました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Step Functions チュートリアル

背景 Step Functions の書き方を勉強するため、AWS 公式のチュートリアルをやってみる。 (公式の日本語は変なので、意味が分からない場合は英語を参照するといいかも) Lambda を使った Step Functions ステートマシンの作成 AWS Lambda 関数を使って、 Task ステートを実装する Step Functions ステートマシンを作成する。 ステップ 1: Lambda 用の IAM ロールを作成する ステップ 2: Lambda 関数を作成する ランタイムは Node.js 14.x を選択し、下記コードをコードソースにペースト。 exports.handler = (event, context, callback) => { callback(null, "Hello, " + event.who + "!"); }; ステップ 3: Lambda 関数をテストする テストイベントに下記データをペーストする。 { "who": "AWS Step Functions" } ステップ 4: ステートマシンの作成 ステートマシン定義ペインで、下記のステートマシン定義をペーストする。 { "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": arn:aws:lambda:ap-northeast-1:xxx:function:HelloFunction, "End": true } } } ステップ 5: 新しい実行の開始 Step Functions を使用したアクティビティステートマシンの作成 Java と AWS Step Functions を使用して、アクティビティベースのステートマシンを作成する。 アクティビティにより、ステートマシンの別の場所で実行されるワーカーコードを制御できる。 ステップ 1: アクティビティの作成 ステップ 2: ステートマシンの作成 ステップ 3: ワーカーの実装 ステップ 4: 実行の開始 Java の知識が必要だったので、アクティビティは実行できず。 (ビルドが必要だが、知識不足でビルドまで到達できず) 雰囲気としては、 ローカルで実行したスクリプトを、Step Functions の一部に取り込める ってことはなんとなく分かった。 Step Functions ステートマシンを使用してエラー条件を処理する Catch フィールドを使用する ステートマシンを作成する。 ステップ 1: Lambda 用の IAM ロールを作成する ステップ 2: 失敗する Lambda 関数を作成する ステップ 3: Lambda 関数をテストする ステップ 4: Catch フィールドを使用するステートマシンを作成する ステップ 5: 新しい実行の開始 CloudWatch イベントを使用して定期的にステートマシンの実行を開始する ステップ 1: ステートマシンの作成 ステップ 2: CloudWatch イベントルールの作成
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

知識0からAWS認定ソリューションアーキテクト プロフェッショナルになるまで

はじめに  こんにちは@sk_130と申します。  本記事は、NonIT人材がAWSソリューションアーキテクト プロフェッショナルになるまでの  過程をまとめたものになります  大きく分けて以下のパートに分けて整理しています Part 1 : AWS ソリューションアーキテクト-アソシエイト資格の合格 Part 2 : 応用情報試験の合格 Part 3 : AWS ソリューションアーキテクト-プロフェッショナル資格の合格 Part 4 : AWSを実務を通してスキル向上させる   AWSは昨今よく使われるので 漠然と勉強はしたい、でもどうすればプロになれるんだろう?って   人の役に立てばいいかなと思って整理しています  ブログの書き方は以下を参考にしています。  ソリューションアーキテクト-アソシエイト資格の合格の勉強でも参考にさせてもらいました  知識0から175時間で合格したAWS認定ソリューションアーキテクト-アソシエイト- 筆者のスペック(知識0のとき) ・理系大卒20台後半男性 ・HW開発職であったため、なんとなーくIT業界は知っているがプログラミングはできない  一応大学では少し触った ・転職を期にIT業界へ、基礎力を付けるため開発よりの部署にアサイン(2019年秋ごろ) ・開発といっても委託先に開発をお願いする感じのタスクが多め   (いわゆる仕様書書き。Officeを使いこなす人が多めな会社) ・オンプレって何?クラウドって何?AWSって何?と上司に質問して場を凍らせた ・LINUXの知識も皆無 ・もちろん実務未経験  開発よりの業務をすることになったので、勉強するモチベが欲しくてAWSの資格を取ることにしました  その過程で応用情報も持っていた方がいいかなと思って、途中脱線しています。  最終的にAWS SAPの資格は2021年春ごろに取得しました  ですので、1.5年で上記達成しています。 それでは、各Partの説明をします Part 1:AWS ソリューションアーキテクト-アソシエイト資格の合格  まず、上記のAWS ソリューションアーキテクト-アソシエイト(SAA)の資格を取ることにしました。  いきなりSAAをとることにしたのは、最終的にプロフェッショナルの資格が取りたかったので  簡単といわれているクラウドプラクティショナーはもういいかなと思ったからです。    今思うとちょっと無謀だったので、ちゃんと順序だてて取った方がいいのかなとも思います。  ちなみに、転職をして、半年での取得です  やはり最初は転職をして、目の前のタスクに時間を取られてなかなか勉強できず  ちょっと落ち着いてから資格取得しました。 勉強の流れ  1. 適当に本を買って、各サービスの概要をつかむ(サービスの名前と何をするものなのかを覚える)  2. 本の最後にある問題演習をやってみる(間違ったところを重点的に覚える)  聞いた感じだと以下がいいみたいです  私は以下を使っていました  買うべき本はいろいろありますが、各サービスの特徴が書かれており、最後に問題演習が載っているものがおススメです  ただし、その問題演習で足りるかというと正直もうちょっとむずい問題をやった方がいいかなとは思っています  3. Udemyの問題を買って、それをひたすら解く  アソシエイトはたくさんUdemyで出展されていると思うので、問題量が多いものを買っておけばいいかと思います  4. 1~3の繰り返しをして9割ぐらい解けるようにする  5. 余力があれば、Blackbeltとか読んでみる  9割ぐらい覚えたほうがいい理由  本やUdemyよりも個人的にはやや難しい問題が出題されると思っており  確実に1度見た問題はあてたほうがいい+なんで解答がダメなのか、誤答の理由も把握しておいた方がいいからです ・いろいろ書きましたが、正直本もサイトもソリューションアーキテクト-アソシエイト(SAA)は充実しているので、ググってQiitaとかの上位に載っている人の勉強法やお勧めの本を買うなど真似すればいいかなと思っています  こんな感じの勉強法でSAA取得しました(2020年春ごろに取得) Part 2:応用情報試験の合格  ここでAWSの資格から脱線しました。  理由は業務でAWSの知識だけでは困った+AWSの学習においてもある程度のIT知識がないと資格取得は厳しいからです ほかのサイトには書かれていませんが、AWSのプロフェッショナルの資格を取りたいなら基本情報か応用情報を持っていた方が、理解が早いですし、つぶしが効きます  今思うと、ITのことがまったくわかっていないものの、AWSの資格は良くも悪くも  クラウドやIT基礎知識がわからなくても取得できるので  そこまで上記の重要性がわかっていませんでしたが、後々ここで基礎固めできてよかったなと思っています  ここで応用情報を取得した理由ですがプログラミングがすごく苦手だったため応用情報にしました  応用情報の午後は、選択問題でプログラミングを選ばなくていいので、そこを狙っています  逆に言うとプログラミングが得意なら、基礎固めとして基本情報でもいいかもしれません  午前の問題の難易度も基本情報+αで、サイトもたくさんまとまっているので、ひたすら過去問を解いたり  スマホアプリで勉強をしました 過去問道場が最強だと思っています。これで万事解決!  で、、2020年の秋に取得しました。転職して1年ぐらい経ちました Part 3 : AWS ソリューションアーキテクト-プロフェッショナル資格の合格  プロフェッショナルも基本的には勉強法は同じです。  ただし、教材がそろっていないので、かなり限定的になります。  私は以下の3つを使って勉強をしました。どれも欠かせなかったと思います。  1.本を使って問題演習 以下の本を使いました  プロフェッショナルの本は、AWSサービスを知っている前提で書かれており、問題演習のみです  ですので、アソシの時に使った本を横に並べて勉強しました。  2. Udemyで問題演習  3. いわゆる黒本で問題演習  振り返ると、実際のテストで上記すべてやったからといって  同じ問題が出るかというとそうじゃないです  SAAの時は結構同じような問題が出ますが、SAPは問題文も長く  本質的な理解が問われます  とはいえ、いろんなサイトで言われている  Blackbeltをよみこむんや的な学習は  自分には合わなかったので量をたくさんこなして、なんとか合格しました。  (センター試験の対策を思い出しました・・・)  そして、、お分かりになるかと思いますが、まあまあ課金しています。  でも、自分のためになっているのでいいかなと思っています!  準備不足で落ちるよりはいいかなーと  2021年春ごろの合格です  転職して1.5年ほど経過しました Part 4 : AWSを実務を通してスキル向上させる  これ、今思うと意外と大事だな、と思っています  AWSの資格取得では全然AWSを触らなくても取れるのですが  やっぱり実際に触った方が知識は身に付きます。  歴史の偉人で例えるなら、実際にドラマとか見ている戦国武将のとかキングダム読んだ方が  記憶に残るよねーって話です。  前の記事でどんなことをすべきかを書いています。これを実務を行う上で私自身もやっています。  こそこそ実際にハンズオンとかをすれば、より合格率がUPするかとおもいます。  ハンズオン   おわりに  結構長くなってしまいましたが、同じような境遇の方の参考になればいいなと思っています
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

IT未経験からAWS認定ソリューションアーキテクト プロフェッショナルになるまで

はじめに  こんにちは@sk_130と申します。  本記事は、NonIT人材がAWSソリューションアーキテクト プロフェッショナルになるまでの  過程をまとめたものになります  大きく分けて以下のパートに分けて整理しています Part 1 : AWS ソリューションアーキテクト-アソシエイト資格の合格 Part 2 : 応用情報試験の合格 Part 3 : AWS ソリューションアーキテクト-プロフェッショナル資格の合格 Part 4 : AWSを実務を通してスキル向上させる   AWSは昨今よく使われるので 漠然と勉強はしたい、でもどうすればプロになれるんだろう?って   人の役に立てばいいかなと思って整理しています  ブログの書き方は以下を参考にしています。  ソリューションアーキテクト-アソシエイト資格の合格の勉強でも参考にさせてもらいました  知識0から175時間で合格したAWS認定ソリューションアーキテクト-アソシエイト- 筆者のスペック(知識0のとき) ・理系大卒20台後半男性 ・HW開発職であったため、なんとなーくIT業界は知っているがプログラミングはできない  一応大学では少し触った ・転職を期にIT業界へ、基礎力を付けるため開発よりの部署にアサイン(2019年秋ごろ) ・開発といっても委託先に開発をお願いする感じのタスクが多め   (いわゆる仕様書書き。Officeを使いこなす人が多めな会社) ・オンプレって何?クラウドって何?AWSって何?と上司に質問して場を凍らせた ・LINUXの知識も皆無 ・もちろん実務未経験  開発よりの業務をすることになったので、勉強するモチベが欲しくてAWSの資格を取ることにしました  その過程で応用情報も持っていた方がいいかなと思って、途中脱線しています。  最終的にAWS SAPの資格は2021年春ごろに取得しました  ですので、1.5年で上記達成しています。 それでは、各Partの説明をします Part 1:AWS ソリューションアーキテクト-アソシエイト資格の合格  まず、上記のAWS ソリューションアーキテクト-アソシエイト(SAA)の資格を取ることにしました。  いきなりSAAをとることにしたのは、最終的にプロフェッショナルの資格が取りたかったので  簡単といわれているクラウドプラクティショナーはもういいかなと思ったからです。    今思うとちょっと無謀だったので、ちゃんと順序だてて取った方がいいのかなとも思います。  ちなみに、転職をして、半年での取得です  やはり最初は転職をして、目の前のタスクに時間を取られてなかなか勉強できず  ちょっと落ち着いてから資格取得しました。 勉強の流れ  1. 適当に本を買って、各サービスの概要をつかむ(サービスの名前と何をするものなのかを覚える)  2. 本の最後にある問題演習をやってみる(間違ったところを重点的に覚える)  聞いた感じだと以下がいいみたいです  私は以下を使っていました  買うべき本はいろいろありますが、各サービスの特徴が書かれており、最後に問題演習が載っているものがおススメです  ただし、その問題演習で足りるかというと正直もうちょっとむずい問題をやった方がいいかなとは思っています  3. Udemyの問題を買って、それをひたすら解く  アソシエイトはたくさんUdemyで出展されていると思うので、問題量が多いものを買っておけばいいかと思います  4. 1~3の繰り返しをして9割ぐらい解けるようにする  5. 余力があれば、Blackbeltとか読んでみる  9割ぐらい覚えたほうがいい理由  本やUdemyよりも個人的にはやや難しい問題が出題されると思っており  確実に1度見た問題はあてたほうがいい+なんで解答がダメなのか、誤答の理由も把握しておいた方がいいからです ・いろいろ書きましたが、正直本もサイトもソリューションアーキテクト-アソシエイト(SAA)は充実しているので、ググってQiitaとかの上位に載っている人の勉強法やお勧めの本を買うなど真似すればいいかなと思っています  こんな感じの勉強法でSAA取得しました(2020年春ごろに取得) Part 2:応用情報試験の合格  ここでAWSの資格から脱線しました。  理由は業務でAWSの知識だけでは困った+AWSの学習においてもある程度のIT知識がないと資格取得は厳しいからです ほかのサイトには書かれていませんが、AWSのプロフェッショナルの資格を取りたいなら基本情報か応用情報を持っていた方が、理解が早いですし、つぶしが効きます  今思うと、ITのことがまったくわかっていないものの、AWSの資格は良くも悪くも  クラウドやIT基礎知識がわからなくても取得できるので  そこまで上記の重要性がわかっていませんでしたが、後々ここで基礎固めできてよかったなと思っています  ここで応用情報を取得した理由ですがプログラミングがすごく苦手だったため応用情報にしました  応用情報の午後は、選択問題でプログラミングを選ばなくていいので、そこを狙っています  逆に言うとプログラミングが得意なら、基礎固めとして基本情報でもいいかもしれません  午前の問題の難易度も基本情報+αで、サイトもたくさんまとまっているので、ひたすら過去問を解いたり  スマホアプリで勉強をしました 過去問道場が最強だと思っています。これで万事解決!  で、、2020年の秋に取得しました。転職して1年ぐらい経ちました Part 3 : AWS ソリューションアーキテクト-プロフェッショナル資格の合格  プロフェッショナルも基本的には勉強法は同じです。  ただし、教材がそろっていないので、かなり限定的になります。  私は以下の3つを使って勉強をしました。どれも欠かせなかったと思います。  1.本を使って問題演習 以下の本を使いました  プロフェッショナルの本は、AWSサービスを知っている前提で書かれており、問題演習のみです  ですので、アソシの時に使った本を横に並べて勉強しました。  2. Udemyで問題演習  3. いわゆる黒本で問題演習  振り返ると、実際のテストで上記すべてやったからといって  同じ問題が出るかというとそうじゃないです  SAAの時は結構同じような問題が出ますが、SAPは問題文も長く  本質的な理解が問われます  とはいえ、いろんなサイトで言われている  Blackbeltをよみこむんや的な学習は  自分には合わなかったので量をたくさんこなして、なんとか合格しました。  (センター試験の対策を思い出しました・・・)  そして、、お分かりになるかと思いますが、まあまあ課金しています。  でも、自分のためになっているのでいいかなと思っています!  準備不足で落ちるよりはいいかなーと  2021年春ごろの合格です  転職して1.5年ほど経過しました Part 4 : AWSを実務を通してスキル向上させる  これ、今思うと意外と大事だな、と思っています  AWSの資格取得では全然AWSを触らなくても取れるのですが  やっぱり実際に触った方が知識は身に付きます。  歴史の偉人で例えるなら、実際にドラマとか見ている戦国武将のとかキングダム読んだ方が  記憶に残るよねーって話です。  前の記事でどんなことをすべきかを書いています。これを実務を行う上で私自身もやっています。  こそこそ実際にハンズオンとかをすれば、より合格率がUPするかとおもいます。  ハンズオン   おわりに  結構長くなってしまいましたが、同じような境遇の方の参考になればいいなと思っています
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS WAFにてIP制限かけてみた。(EC2 + ALB + WAF)

はじめに こんばんは、山田です。 今回は、AWS WAFについて検証していきたいと思います。 全体構成図 全体構成図は以下の通りです。 クライアントVPNからの接続は許可し、パブリックサブネットに配置されているEC2からのアクセスは拒否するように設定していきます。 接続方法 接続可否 User → クライアントVPN → ALB 〇 User → IGW → EC2 → ALB × 構築手順 下記より、構築手順について記載していきます。 前提条件 今回は、クライアントVPN、WAFの構築に焦点を当てて記載していきます。 なので、EC2,ALB等は構築済みとします。 また,EC2はWindowsServerとしIISの機能は追加済みとします。 クライアントVPNの構築 AWS管理コンソール -> VPC -> クライアントVPNエンドポイント -> クライアントVPNエンドポイントの作成をクリックします。 設定項目 設定値 備考 名前 yamada-test-clientvpn - クライアントCIDR 10.2.0.0/22 ※/22以上でVPCのCIDR範囲と被らないように注意! サーバ証明書 ACMに登録してある証明書選択する - 認証オプション 相互認証 DNSサーバー 10.1.0.2 ※AWSのDNSサーバーはVPCのCIDR範囲に+2した値になる。今回のVPCのCIDR範囲は10.1.0.0/24を指定したので、DNSサーバーは10.1.0.2になる。 ターゲットネットワークの選定 AWS管理コンソール -> VPC -> クライアントVPNエンドポイント -> 関連付け ->関連付けをクリックします。 ターゲットネットワークの選択を行う。その際、注意点として、/27以上のサブネットを指定する必要があります。 今回は、ターゲットサブネットとして、10.1.0.0/26の範囲を指定します。 承認済みネットワークの選定 AWS管理コンソール -> VPC -> クライアントVPNエンドポイント -> 認証 -> 受信の認証をクリックします。 今回は、承認済みサブネットとして、10.1.0.64/26の範囲を指定します。 クライアント設定ファイルのダウンロード AWS管理コンソール -> VPC -> クライアントVPNエンドポイント -> クライアント設定のダウンロードをクリックします。 以下のようなファイルがダウンロードされます。 末尾に以下の記載を追加します。 cert部分:クライアント証明書本文 key部分:クライアント証明書のプライベートキー AWS VPN CLientのダウンロード 以下のURLより、AWS VPN Clientをダウンロードします。 以下のようなアイコンが表示されるのでダブルクリックします。 ファイル -> プロファイルの管理 -> プロファイルを追加をクリックします。 表示名は人で入力し、VPN設定ファイルは先ほどダウンロードしたファイルを選択します。 接続をクリックします。以下のように表示されれば接続完了です。 WAF構築手順 今回は、IPによるアクセス制限をかけてみたいと思います。 CIDR範囲 アクセス可否 備考 10.1.0.0/26 〇 ターゲットネットワークのCIDR範囲 10.1.0.128/26 X パブロックサブネットのCIDR範囲 IPホワイトリスト設定 AWS管理コンソール -> WAF -> IP sets -> Create Ip Setをクリックします。 ホワイトリストに登録したIP範囲を指定します。 今回は、10.1.0.0/26をホワイトリストとして登録しました。 Web ACLsの作成 AWS管理コンソール -> WAF -> Web ACLs -> Create web ACLをクリックします。 name等を入力し、AWS resourceの選択では今回はALBを選択します 。 Add rules -> Add my own rules and rule groupsをクリックします。 以下のような画面が表示されます。 設定項目 設定値 備考 Rule type IP set - Name yamada-test-rule - IP set yamada-test-ipset 先ほど作成したIPホワイトリストを選択する。 Action Allow - ルールにマッチしなかったリクエストはブロックするように設定します。 上記の設定値でWeb ACLsを作成します。 動作確認 クライアントVPNに接続し、<ALBのDNS名>に接続します。 例)internal-yamada-test-alb-1082603350.ap-northeast-1.elb.amazonaws.com 以下のように表示されればOKです。 次にパブリックサブネットに配置されているEC2に接続し、<ALBのDNS名>に接続する。 例)internal-yamada-test-alb-1082603350.ap-northeast-1.elb.amazonaws.com 以下のようにアクセスが拒否されればOKです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Python+サーバレス開発を勉強する中でzappaがデプロイするリソースについて気になったので調べてみた

はじめに 動かして学ぶ!Pythonサーバレスアプリ開発入門 著:本田崇智 を読み Python+サーバレスを学習する中で 作成したアプリケーションをAWS環境にデプロイしてくれるzappaというツールが どのようにApiGatewayとLambdaを構築したのか気になり、確認した際のメモ デプロイするアプリケーション構成 参考書のchapter9が完了した時点での構成をざっくり抜粋して書くと、以下のようになる application ├sever.py # アプリ起動プログラム ├zappa_settings.json # zappa設定ファイル  └ flask_blog ├__init__.py # 初期処理プログラム ├config.py # アプリケーション設定プログラム ├models/ # モデルプログラム群 ├static │ └style.css # CSS定義ファイル ├templates/ # HTMLファイル群 └ views # ビュープログラム群 zappaでデプロイしたリソース確認 以下コマンドでデプロイ $ zappa deploy dev ApiGatewayの確認 Lambdaの確認 でてきた疑問点 HTMLファイルの実体どこにあるんだ? よく目にするのは静的ファイルはs3に格納して表示するパターン lambdaのソースコードどうなっている? 以下のようにコードのファイルサイズが大きすぎると表示されて、 コンソールからはファイルが確認できない the deployment package of your Lambda function "application-dev" is too large to enable inline code editing. However, you can still invoke your function. 調べた内容 AWS Webアプリのサーバレスアーキテクチャ例 そもそもサーバレスでどういったアーキテクチャが考えられるのか調べてみたところ やっぱり静的コンテンツをS3(またはs3を内包するamplify)に格納しておいて 動的コンテンツはApigatewayとlambdaを使うといったアーキテクチャは公開されていた s3 + ApiGateway + Lambda 参考 初めてのサーバーレスウェブアプリケーションを構築する CloudFrontを使って設計するパターンもあるよう 参考: AWS Well-Architected フレームワーク ウェブアプリケーション Powering HIPAA-compliant workloads using AWS Serverless technologies サーバーレス LAMP スタック – Part 3: Webサーバーの置き換え ここまで調べた段階で、zappaが作成するs3を確認してみたが何も入ってなかった、、、 どうやら作成されたs3は一時的に使用しているだけのようで 調べてきたアーキテクチャとは違う模様 上記から結論づけるにHTMLもlambdaから返却している ->Flaskで作成して動的にHTMLを返すアプリケーションなので当たり前か 後述するがlambdaのソースコードを確認しても 作成したアプリケーションのコードが全部含まれていた Lambdaのソースコード取得方法 Lambdaのソースコードは調べたところ以下コマンド取得できた (コンソールから アクション->関数のエクスポートでも取得できるみたい) $ aws lambda get-function --function-name [function名] --query 'Code.Location' | xargs curl -o [出力ファイル名指定(例 xxx.zip)] 取得した結果を確認したところ デプロイするアプリケーション構成に記載したファイルもまるっと含まれていた 終わりに いつかサーバレスアプリケーションを作ってみたいなと思っていたので Pythonの学習に加えてサーバレスのアーキテクチャパターンを調査できたのはよかった SPAとMPAの違いもろくに分かっていなかったので Webアプリ開発の理解が乏しすぎることを再認識しました、、、
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS認定クラウドプラクティショナー資格】勉強備忘録③ AWSのテクノロジー

項目 1.AWSのサービス 2.AWSグローバルインフラストラクチャ ※ 『AWS認定資格試験テキスト AWS認定クラウドプラクティショナー』 の第4章に相当 1.AWSのサービス ● AWSサービスをどこで使うのか AWSでは、リージョンと呼ばれる世界のどこでサービスを使うかを選択するための地域と、アベイラビリティゾーン(AZ)というデータセンターの集合体があります。 2.AWSグローバルインフラストラクチャ ● リージョン AWSには、2021年4月現在、世界に25個のリージョンがあります。日本には、「東京リージョン」と「大阪リージョン」があります。 リージョン内には、2つ以上のアベイラビリティゾーンがあります。 アベイラビリティゾーンは、複数のデータセンターから構成されています。 システムの要件に応じて、リージョンを選択することができます。 世界のどこにいてもシステムを構築できるので、ものの数分で世界中にデプロイすることができます。 複数リージョンに、完全に稼働する同じシステムを構築して、災害の際のダウンタイムを最小にするマルチサイトアクティブという構成もあります。 リージョンは、 ・保存するシステムやデータがそのリージョンの地域の法律やシステムを所有している企業のガバナンス要件を満たしているか ・ユーザーや連携するデータに近いか ・必要なサービスが揃っているか ・コスト効率が良いか などの条件に基づいて選択します。 ● アベイラビリティゾーン 各リージョンには、アベイラビリティゾーンが2つ以上あります。 なぜ2つ以上あるのかというと、停電や災害によるデータセンターの障害が発生したときに対応するためです。 「全てのものはいつ壊れてもおかしくない」という前提に立ち、「Design for Failure (故障に備えた設計)」という考え方から、このような対応を行っています。 2つ以上のデータセンターは、地理的に離れた場所に位置しており、各データセンターが停電や災害の影響を同時多発的に受けることがないようになっています。 AWSでは、この構成を提供される機能として利用できます。 アベイラビリティゾーンを複数使うことで、対障害性の高いシステムを構築することができます。 サーバーなどのコンポーネント単位で、負荷分散、レプリケーション、冗長化を実現し、障害が発生した際にはフェイルオーバーできるようなアーキテクチャを簡単に実装できるサービスや機能が提供されています。 「フェイルオーバー」とは、稼働中のシステムで問題が生じてシステムやサーバーが停止してしまった際に、自動的に待機システムに切り替える仕組みのこと。 同一リージョン内のアベイラビリティゾーンは、高速なプライベート光ファイバーネットワーキングで相互に接続されています。 この高速なプライベートネットワークにより、数ミリ秒の低レイテンシー(遅延度)接続を実現しています。 AWSのデータセンターは、どこにあるのか公開されていません。 また、一目見ただけではデータセンターとはわからない施設となっています。 監視カメラ、侵入検知テクノロジー、多要素認証など、物理的に厳重に保護されています。 セキュリティ、コンプライアンス上の様々な統制も行っています。 運用においてはオートメーションシステムを構築し、第三者監査によるセキュリティ、コンプライアンスの検証を行っています。 ● エッジロケーション AWSには、リージョンとは違う場所に、全世界で200以上のエッジロケーション(コンテンツ配信を行う仕組み)があります。 エッジロケーションは、「低レイテンシーなDNSクエリの実現」「コンテンツの低レイテンシー配信」の二つの用途で利用されます。 低レイテンシーなDNSクエリの実現 DNSサービスであるAmazon Route 53がエッジロケーションで利用されます。 ※ DNSとは、インターネットなどのIPネットワーク上で、ドメイン名(ホスト名)とIPアドレスの対応関係を管理するシステム。 ユーザーに対して、最も低いレイテンシーのエッジロケーションからDNSクエリを返すことができます。 「Amazon Route 53」は、www.example.com のような名前を、コンピュータが互いに接続するための数字の IP アドレス (192.0.2.1 など) に変換するサービスで、デベロッパーや企業がエンドユーザーをインターネットアプリケーションにルーティングする、きわめて信頼性が高く、コスト効率の良い方法となるよう設計されています。 参考: Amazon Route 53 コンテンツの低レイテンシー配信 CDNサービスであるAmazon CloudFrontがエッジロケーションで利用されます。 ※ CDNとは、インターネット上で、デジタルコンテンツ配信のための最適化されたネットワークのこと。 ユーザーに対して最も低いレイテンシーのエッジロケーションから、コンテンツキャッシュを配信することができます。 「Amazon CloudFront」は、高いパフォーマンス、セキュリティ、デベロッパーの利便性のために構築されたコンテンツ配信ネットワーク (CDN) サービスです。グローバルな規模で展開されているので、負荷分散を行うことができます。 参考:Amazon CloudFront エッジロケーションの分散サービス妨害攻撃からの保護 「Route 53」と「CloudFront」は、分散サービス妨害(DDoS)攻撃に対する保護サービス(AWS Shield Standard)の対象です。 追加料金なしで通信レイヤーへの攻撃の保護に適用されます。 高度なレベルの保護を適用するためには、AWS Shield Advancedを利用します。 多様な選択肢 ●AWS Local Zones(AWSローカルゾーン) 主に、メディアエンターテイメントのコンテンツ作成・リアルタイムゲーム・ライブビデオストリーミング等のアプリケーションを想定しています。 AWSローカルゾーンはAWSのリージョンを拡張し、レイテンシーの影響を受けやすいアプリケーションをエンドユーザー近接の地域で実行させます。 ●AWS Wavelength(ウェイブレングス) ミリ秒単位のレイテンシーが求められるアプリケーション向けに提供されています。 AWS コンピューティングおよびストレージサービスを 5G ネットワーク内に組み込んで、超低レイテンシーアプリケーションの開発、デプロイおよびスケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供しています。 ●AWS Outposts(アウトポスト) オンプレミス施設でAWSサービスを利用できます。 AWSコンピューティング、ネットワーキング、セキュリティ、およびその他のサービスをオンプレミスで拡張して、低レイテンシー、ローカルデータ処理、およびデータ常駐のニーズに対応します。 参考書籍 ※ 『AWS認定資格試験テキスト AWS認定クラウドプラクティショナー』 ● Amazonはこちら ● 楽天はこちら
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Certified DevOps Engineer - Professional 合格しました

先日、AWS認定DevOpsエンジニアプロフェッショナルの試験を受験し、合格しました! その記録を残しておきます。 AWS認定資格としては12個目になります。先月からの約1ヶ月での連続受験としては7個目です。今回でAWS認定資格をコンプリートしました。 前回の受験はSolution Architect Professionalでしたが、その数日後に今回の受験です。 前回受験の記事 AWS Certified Solutions Architect - Professional 合格しました - Qiita 勉強方法 Solution Architect Professionalの試験の時は、AWSのすべての領域を勉強したつもりになっていました。しかし、Solution Architect Professional受験後の夜にDevOps Engineerのサンプル問題を見たら、ぜんぜんわからなくて、DevOps Engineerの領域は改めて勉強しないといけないと気が付きました。当たり前なんですが。。。その後なにもしないまま、よし明日受験しよう!と思い立って試験を申し込み、それから勉強し始めたので、勉強は約24時間前からです。 前日午後にBlack Beltの資料を読みました。一部はYouTube動画を見ました。見たのは以下のあたりです。これを見ながらこれまでの試験勉強で書いた自分のノートを更新します。 CodeCommit CodeArtifact CodeBuild CodeDeploy CodePipeline X-Ray ECS Black Beltを読んだ後、もう一度サンプル問題を解いたら正答率8割でした。BenchPrepの模擬試験も解き、正答率75%でした。 試験当日 75問180分。一巡するのに160分ぐらいかかりました。途中から疲れてきて、だんだん考えるのも適当になってました。難しくてちゃんと問題文も選択肢もちゃんと読まないと解けないのですが、選択肢を全部読み込まずに適当に答えた問題もあります。落ちたらまた受ければいいし、という感じ。前回のSolution Architect Professionalと違って、完全に一夜漬けでしたので、寝不足で集中力欠けました。それでも前回のSolution Architect Professionalより少し早く解けたので、Solution Architect Professionalよりは簡単だったのでしょう。 日本語は前回のSolution Architect Professionalに比べて今回ひどかったです。日本語だけでは絶対に解けない問題がいくつかありました。 ここ1ヶ月の7連続受験はすべて同じテストセンターで受験しました。週に1〜2回ペースでテストセンターに来てたことになります。勤務先オフィス出社よりも高頻度です。受付でやりとりする内容も毎回まったく同じなので、スムーズです。スタッフの顔ももちろん覚えてます。きょうは混んでるから受付が増設されてるとか、きょうはエレベータが故障中とか、いろいろありましたが、しばらくお別れです。 なんの試験ですか?→ AWS 予約時間と名前(かぶりやすい名字なのでフルネーム)を言う 書類記入 身分証明書2つ提示(片方はすぐにしまう) 体温測定 顔写真撮影 ロッカーに荷物入れる 注意書き書面を渡される(毎回同じなので読まない) ポケットチェック 手のひらチェック マスクの裏面チェック 注意事項を説明される(受けたことあると言えば省略される) 席案内 画面上で名前と試験名の確認 Startボタンをクリック 結果 スコア 885 (合格ライン 750)。試験中の難易度の印象と比べて意外とスコアがいい。もっとギリギリかと思ってました。 所感 これまでにアソシエイトやスペシャリティやソリューションアーキテクトを受験してきたので、DevOpsエンジニア独自領域と思われるCodeなんちゃら系のサービスを中心に勉強しただけで済みました。これまでの試験で勉強した範囲と絡むような試験問題もたくさんありましたが、連続受験のおかげで記憶がある程度残っており解きやすかったです。AWSの各試験は出題範囲が重なっているので、数を集めたい場合は連続して取得してしまうのがおすすめです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【個人開発】全くのRails初心者が一人でwebサービスを作ってみた

初投稿です。昨日で、一通り制作が完了したので、11月~1月前半までの二か月半を時期ごとに振り返ってみようと思います。 開発環境 ruby on rails(6.1.4.4) heroku S3 cloudflare 開発開始(11月前半) 掲示板的なそれぞれの人がそれぞれの目的でゆるーく使えるwebサービスを作ろうと思い、開発を開始しました。 開発言語はRailsが一番情報が多そうだと思い、Railsに決定。 どこから制作を初めていいかもわからない状況だったので、「rails webサービス 作り方」でググっていたところこのような記事を発見。 こちらの記事には大変お世話になりました。。。こちらを参考にしながら一通り作ってみようと思いました。 bootstrapとHTMLとCSSに触れる(11月後半) 先程の記事を参考にしながら、順調に開発は進んでいました。 ですが、bootstrapの導入が上手くいかず、ここで1週間ほど苦戦。。。。 それもそのはず、自分はrails6を使っていたのでgemでの導入ではなく、yarnからのインストールが必要でした。その時参考にさせていただいたのが、以下の記事です。 これを参考にして、無事bootstrapが導入できました。 今までPythonしかプログラミング言語に触れてこなかったので、railsどころかHTMLやCSSに関しても全くの無知でした。 この開発を通して、少しは理解できたと思います。。。 開発中盤①(12月前半) 参考にさせていただいた記事を一通り読み終わり、ある程度bootstrapもいじれるようになったので、レイアウトを整えていき、それっぽい見た目になってきました。 ですが、ここで問題が発生。投稿画面にRails6から導入されたAction_Textの導入が上手くいかない。 これで5日間ほど苦戦。。。12月中にはリリースしてみたかったのに。。。。 結局、Railsのファイルを最初から作り直して解決しました。 開発中盤②(12月後半) 結構形になってきました。googleログイン認証とか、当初は予定していなかった機能も結局付けることになりました。 タグ機能もあったら便利だろうな~と思い、以下の記事を参考にしながらタグ機能を付けることができました。 こうして、必要な機能がだんだんと揃ってきたので、正月休みが終わったら公開してみようと決めました。 開発後半(1月前半) 正月休みが終わり、まずは、サーバー選び。今回はherokuとs3を用いて実装を行うことにしました。 理由は、何としてでも無料で運用したかったからです。そして、herokuでは独自ドメインも使えるらしいので、お名前ドットコムにて取得。 クレジットカードも持っていなかったので、即日発行のカードを後先何も考えずに発行してしまいました。。。 準備は完了したので、いざ実装。。。って言っても何をどうすれば良いか分からない。。。 なので、「rails heroku」でググり散らかしていると以下の記事を発見。 さらに独自ドメインをfreeplanで適用するために以下の記事を参考にさせていただきました。 無事に独自ドメインでの公開が完了いたしました。 本当に色々な方の記事を参考にさせていただきました。本当に感謝しています。 完成!! 無事に完成させることができました。これから実装しなくてはならない機能がありますが、キリがないのでこれから修正していきます。もしよろしければ覗いてみてください。。。 日記やブログ、質問や、雑談など、それぞれの人がそれぞれの使い方をゆる~く出来るサービスです。 終わりに 一人での開発で、初めての言語でしたので公開すらできないかもという不安もありました。 この記事がこれからRailsに触るという方やプログラミング初心者の方のお役に立てればそれほど嬉しいことは無いです。 以上、長文、駄文失礼致しました。 以下参考にした記事です。本当に感謝しています。ありがとうございました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CloudFormation のお客様による AWS Systems Manager でのアプリケーションの管理が可能に

はじめに DX技術本部の yu-yama です。 AWS CloudFormation のお客様は、AWS Systems Manager の機能である Application Manager を通じて、運用データを表示し、CloudFormation スタックリソースに関連する問題を解決するためのアクションを迅速に実行できるようになりました。この機能を使用すると、お客様は CloudFormation スタックを介してプロビジョンされたリソースのアプリケーションビューを取得できます。デベロッパーは、Application Manager Dashboard から取得した運用メトリクス、ログ、アラート、およびコスト情報を使用して、ライフサイクル全体でスタックリソースを効率的に管理できます。 AWS CloudFormation コンソールで使用を開始するには、特定のスタックのスタックアクションから View in Application Manager を選択すると、選択したスタックの Application Manager ダッシュボードに移動します。スタックのコンテキスト運用データを使用すると、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの再起動や、Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットの取得などの修復アクションを開始することで、問題を診断および解決できます。 この CloudFormation コンソールの新機能は、追加料金なしで、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、AWS GovCloud (米国西部、米国東部)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、アジアパシフィック (香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、中東 (バーレーン)、アフリカ (ケープタウン)、南米 (サンパウロ) といった 23 の AWS リージョンでご利用いただけるようになりました。詳細については、CloudFormation ユーザーガイドを参照してください。 の記事の更新内容を確認してみました。 一言で ApplicationManager から CloudFormationで作成したリソースの管理(メトリクス、ログ、コスト)が容易になった ちょっとやってみる 適当に作成したスタック(VPC、ルーティングテーブル、igw、セキュリティグループ、EC2)を用意して スタックを選択し、Application Manager で表示を押下する SSMのApplication Managerに遷移し、概要が表示されます 概要では、アプリケーション情報、OpsItems、アラーム、ランブック、CostExplorer、アプリケーションインサイトが確認できます リソースタブを表示してみる 作成したリソースの一覧(リソースID、ステータス、タイプ)とCostExplorerが確認できます プロビジョニングタグを表示 CFnのイベントヒストリーが見れますね コンプライアンスタブ AWS Configルールの準拠非準拠が確認できます モニタリングタブ アプリケーションインサイトを有効化するとメトリクス、ログ、アラームが確認できます OpsItemsタブ OpsItems一覧が確認できます ログタブ 現在のアカウントの Amazon CloudWatch Logs ロググループが確認できます ランブックタブ ランブックログが確認できます まとめ Application Manager から CloudFormationで作成したリソースの管理(メトリクス、ログ、コスト)が容易になりました。 これまでは各サービス(CloudWatch、Config、CloudFormation etc)からスタックのリソースを確認していたものが、スタックから各サービスのステータスの確認、操作が出来るようになったのはうれしいアップデートだと思います。 さいごに ログタブを見たときにスタックが作成したAWSリソースのログのみが一覧となって表示されている?超絶便利じゃないか!と思ったのですが、よく見るとただロググループが見えているだけでした...... あとランブックを実行したのにランブックログに表示されないのがなんでだろう
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSクラウドプラクティショナーの存在を知ってから5日間で合格したので勉強法をメモ。

はじめに この記事の対象 これからAWSの勉強をしようかなって方 基本的なITの知識のある方(基本情報技術者レベル) 受験時の筆者の状態 AWS?なにそれ美味しいの? 転職活動中のニートです。 基本情報技術者には合格しています。 応用情報技術者には2点足りなくて一回落ちています。(まだ未取得) ITエンジニア歴2年半の駆け出し。 前職は組み込み系の開発会社に勤務していて、次はWEB系の会社に転職したい。 受験のきっかけ 転職活動中にさまざまな企業様とのカジュアル面談を通して、自身にWEB系の知識が少ないため、その足がかり兼転職への意欲アピールとして取得を勧められたのがきっかけです。 カジュアル面談前まではAWSの存在については知っていましたが、詳しい資格試験の内容については知りませんでした。 ちなみにプラクティショナーを選んだのは現在離職中であり、早く就職しないと生活できないので受験までに時間をかけられないためです。あと、私自身AWSの知識が皆無でしたが、ネット上で合格体験記を調べるとお仕事をされながら1週間程度で合格している方が多く、無職の私なら勝てると思いました。 試験の概要 試験費用...11000円(税抜)(高い) 試験日...試験を受けたい日の大体4日前くらいだと予約できる。(ありがたい) 難易度...かなり低い。AWS関連資格の入門編に位置する。(詳しくは https://aws.amazon.com/jp/certification/) 試験場所...全国のテストセンター、ピアソンVUE会場、もしくはリモート受験。(私はピアソンVUE会場で受験しました。) 教材 AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー Kindle版(以下テキストと記載します。) https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-AWS%E8%AA%8D%E5%AE%9A-%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%BC-%E5%B1%B1%E4%B8%8B-%E5%85%89%E6%B4%8B-ebook/dp/B07QX45RXM/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr= 【2022年版】この問題だけで合格可能!AWS 認定クラウドプラクティショナー 模擬試験問題集(7回分455問)(以下Udemyと記載します。) https://www.udemy.com/course/aws-4260/ 勉強方法について 1~2日目 テキストを一周読む。章末問題も軽く読んで即答できるようにする 3~4日目 Udemyの基礎、応用を全部テスト→復習→再テストして90点目安にする 5日目 Udemyの基礎、応用を再度全てテストし、忘れている部分を再確認。96点くらいまで仕上げた(全コース) 勉強時間は1日2時間程度+移動時間に教材見る程度 所感 試験範囲自体はそこそこ広いが、各サービスの内容さえ覚えておけばなんとかなる。 情報処理試験とは違い、全く同じ過去問はほぼ出ないため、ちゃんと本質を理解した方がいい(問題文覚えるのは良くない) 難易度はそこそこ低い。(65問出題で70%取れれば合格。大体46問正解すればいいはず。点数の内訳が不明のため配点に偏りはあるかも。) 学習はデジタルで完結させたいため、iPadとPCで行った。PCでテキスト(Kindle)やUdemyを表示して、iPadで手書きノートを作成。出先や試験会場までの移動中はiPadで確認するなどした。 今後について 次はAWSソリューションアーキテクトアソシエイトに挑戦します。 お仕事が決まればですが。 2022年は応用情報技術者試験のリベンジと、DBスペシャリストも受験予定です。 趣味でやってる競プロ(Atcoder)にハマりそうなのでそちらもまずは緑になりたい。 またそれぞれ達成できれば記事にできればと思います。 ここまで読んでくださってありがとうございました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Cloud Practitioner について勉強してわからないことをまとめた ~モジュール4~

はじめに 「AWS Cloud Practitioner について勉強してわからないことをまとめた ~モジュール3~」の続きです。 過去投稿分 「AWS Cloud Practitioner について勉強してわからないことをまとめた ~モジュール1~」 「AWS Cloud Practitioner について勉強してわからないことをまとめた ~モジュール2~」 「AWS Cloud Practitioner について勉強してわからないことをまとめた ~モジュール3~」 参考:AWS Cloud Practitioner Essentials(Japanese) Amazon Virtual Private Cloud(Amazon VPC) AWSリソースに対する境界を確立するために使用できるネットワークサービス。 AWSクラウドに独立したセクションをプロビジョニングできる。 インターネットゲートウェイ インタネットからパブリックトラフィックをVPCに渡すためには インターネットゲートウェイをVPCにアタッチする。 VPCにプライペートリソースのみが含まれている場合はどうするか。 仮想プライベートゲートウェイ 仮想プライベートゲートウェイの例 インターネットは、自宅とコーヒーショップの間の道路のようなイメージ。 ボディーガードに警護されながらこの道路を移動しているとします。 他のお客様と同じ道路を利用してはいますが、保護は強化されています。 ボディーガードは、周辺の他のリクエストすべてに対し、あなたのインターネットトラフィックを暗号化(または保護)する仮想プライベートネットワーク(VPN)接続のようなものです。 AWS Direct Connect データセンターとVPCの間に専用のプライベート接続を確立できるサービス コーヒーショップ直結の道路があるアパートがあって、この道路が利用できるのはアパートの住人のみ サブネットとネットワークアクセスコントロールリスト サブネット セキュリティまたは運用のニーズに基づいてリソースをグループ化できるVPC内のセクション。 サブネットはパブリックに設定することも、プライベートに設定することもできる。 パブリックサブネット オンラインストアのウェブサイトなど、一般公開されているリソースが含まれる。 プライベートサブネット 個人情報や注文履歴を含むデータベースなど、プライベートネットワークを介してのみアクセス可能なリソースが含まれている。 VPC内のネットワークトラフィック パケットからサブネットへのアクセス許可をチェックするVPCコンポーネントは ネットワークアクセスコントロールリスト(ACL)という。 ネットワークアクセスコントロールリスト(ACL) サブネットレベルでインバウンドトラフィックとアウトバウンドトラフィックを制御する 仮想ファイアウォール。 ステートレスパケットフィルタリング 処理情報が保存されないため、パケットはサブネットの境界(インバウンドとアウトバウンドの双方向)を出入りするたびにチェックをする。 パケットの Amazon EC2インスタンへのアクセス許可をチェックするVPCコンポーネントはセキュリティグループである。 セキュリティグループ Amazon EC2インスタンスのインバウンドトラフィックとアウトバウンドトラフィックを制御する仮想ファイアウォール。 デフォルトでは、セキュリティグループはすべてのインバウンドトラフィックを拒否し、全てのアウトバウンドトラフィック許可する。 ユーザーはカスタムルールを追加して、許可または拒否するトラフィックを設定できる。 ステートフルパケットフィルタリング 受信パケットに対して行われた以前の処理情報は保存される。 そのリクエストに対するレスポンスがインスタンスに返されるとき、以前のリクエストの情報がセキュリティグループに保存されています。この場合、セキュリティグループは、セキュリティグループのインバウンドルールに関係なく、レスポンスの通信を通過させます グルーバルネットワーク ドメインネームシステム(DNS) インターネットで電話帳と同じ役割を果たす。DNS解決は、ドメイン名をIPアドレスに変換するプロセスです。 Amazon Route 53 Amazon Route 53はDNSウェブサービスです。 AWSでホストされているインターネットアプリケーションにエンドユーザーをルーティングするための信頼性の高い方法を開発者とビジネスに提供する。 ユーザーからのリクエストを、AWSで実行されているインフラストラクチャに接続、また、ユーザーをAWS外のインフラストラクチャにルーティングすることもできる。 もう1つの機能は、ドメイン名のDNSレコードを管理すること。 ユーザーは新しいドメイン名をRoute 53に直接登録できる。 注意 自己学習のために割愛している部分があるので 公式も合わせてご確認ください。 AWS Cloud Practitioner Essentials(Japanese) 参考書籍: 図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon S3の公開設定を色々とためしてみた

Amazon S3の公開設定を色々とためしてみました 事前準備 Amazon S3のバケット作成とファイル登録 Amazon S3 #001 - バケット作成 Amazon S3 #002 - ファイル登録・ダウンロード ファイル公開 Amazon S3のファイルを公開する方法です。 アクセス許可 → ブロックパブリックアクセス(バケット設定)の「編集」をクリック。 パブリックアクセスをすべてブロックのチェックをOFF。 これだけでは公開されないので、バケットポリシーの「編集」をクリック。 バケットポリシーを設定 → 「変更の保存」をクリック。今回は、Amazon S3からオブジェクトを取得するためのアクセス許可を付与。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::バケット名/*" } ] } アクセス権限が公開になっているのを確認。 URLに直接アクセスするとファイルが表示されます。 指定IPのみファイル公開 Amazon S3の指定IPのみファイルを公開する方法です。 アクセス許可 → ブロックパブリックアクセス(バケット設定)の「編集」をクリック。 パブリックアクセスをすべてブロックのチェックをOFF。 これだけでは公開されないので、バケットポリシーの「編集」をクリック。 バケットポリシーを設定 → 「変更の保存」をクリック。今回は、Amazon S3からオブジェクトを取得するためのアクセス許可と指定IPのアクセス許可を付与。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::バケット名/*" }, { "Sid": "IP", "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::バケット名/*", "Condition": { "NotIpAddress": { "aws:SourceIp": "許可したいIP" } } } ] } アクセス権限が公開になっているのを確認。IP制限をした場合は公開表示にはならない。 設定したIPからURLに直接アクセスするとファイルが表示されます。指定IP以外はファイルが表示されません。 指定期間のみファイル公開 Amazon S3の指定期間のみファイルを公開する方法です。 対象のファイルを選択。 オブジェクトアクション → 「署名付きURLで共有」をクリック。 対象の期間を設定 → 「署名付きURLを作成」をクリック。クリップボードにコピーされたURLにアクセスすると期間中ファイルが表示されます。 静的ウェブサイトホスティング Amazon S3の静的ウェブサイトホスティングで公開するメモ。 公開したいHTML等のファイル一式をアップロード。 アクセス許可 → ブロックパブリックアクセス(バケット設定)の「編集」をクリック。 パブリックアクセスをすべてブロックのチェックをOFF。 これだけでは公開されないので、バケットポリシーの「編集」をクリック。 バケットポリシーを設定 → 「変更の保存」をクリック。今回は、Amazon S3からオブジェクトを取得するためのアクセス許可を付与。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::バケット名/*" } ] } アクセス権限が公開になっているのを確認。 プロパティ → 静的ウェブサイトホスティングの「編集」をクリック。 有効にする・静的ウェブサイトをホストする・ルートのHTMLを設定 → 「変更の保存」をクリック。 静的ウェブサイトホスティングが有効になったのを確認します。URLが発行されるのでアクセスします。 アップロードしたWebSiteが表示されます。 Amazon S3単体で色々と設定可能なことが改めて把握できました。AWS Amplify・ServerlessFramework・CloudFormation等でも構築可能ですが、AWSマネジメントコンソールからS3を操作し、基礎からふりかえるのもすごく大事だなと思いました 次回は、Amazon CloudFrontと組み合わせた別の方法も紹介できたらと思います。 Amazon S3について、他にも記事を書いています。よろしければぜひ tags - Amazon S3 やってみたシリーズ tags - Try
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お名前ドットコムで取得したJPドメインをAmazon EC2で利用する手順

「お名前ドットコム」で取得した JPドメイン を「Amazon EC2」で利用するための手順です。 もし誤っている箇所などがありましたら、連絡してもらえると助かります。 概要 「Route 53」と「お名前ドットコム」のそれぞれの画面でネームサーバーの設定を行います。 設定手順は以下です。 Step1: ネームサーバーを設定 [ Route 53 > ホストゾーン ]画面より、[ ホストゾーンの作成 ]ボタンを押してください。 Step2: ホストゾーンの作成 項目[ ドメイン名 ]に任意のドメイン名を、 項目[ タイプ ]に「パブリックホストゾーン」を選択して、ホストゾーンの作成をしてください。 Step3: ネームサーバーの取得 以下画面のタイプ[ NS ]レコードの「値/トラフィックのルーティング先」の値を コピー しておいてください。 Step4: お名前ドットコムでネームサーバーを設定 お名前ドットコムでネームサーバーを設定手順は以下です。 まず、[ ネームサーバーの設定 > 2.ネームサーバーの設定 > その他のサービス ]画面へ遷移してください。 Step3 でコピーしたネームサーバーの情報を入力してください。 末尾の「.」は不要なため、削除してください。 以上で、72時間以内には完了します。私は数時間で完了してました。 確認方法 確認は「dig」コマンドを実施して、DNSサーバー(「AUTHORITY SECTION」部分)の値を確認してください。 Step4 で設定した値が表示されていれば OK です。 または、「JPRS Whois」のサイトより、対象ドメインを検索して[ Name Server ]が意図した値になっていることを確認してください。 注意点 「Route 53」に JPドメイン を移管して、失敗した話。 2021年に勉強も兼ね、「お名前ドットコム」で獲得した JPドメイン を「Amazon EC2」で利用したかったため、「AWS Route 53」へドメイン移管しました。 移管自体はできたのですが、その際に以下の不満点が発生。 「Whois情報の公開代行設定」ができない 「Route 53」への移管費用がまぁまぁ高価 「Route 53」から別レジストラへ移管するのが困難 上記の不満点を簡単に解説。 1. 「Whois情報の公開代行設定」ができない JPドメインを取得する際に、個人情報(住所氏名、電話番号、生年月日など)を入力し、それを全世界の人が閲覧可能な状態にする必要があります。 個人情報なので、基本はレジストラの情報で代行してもらうのが一般的なのですが、それができませんでした。 どうやら 海外のドメインレジストラ では、GCPも含めてダメっぽいです。 2. 「Route 53」への移管費用がまぁまぁ高価 2021年1月頃に実施し、「.jp」は「.me」などに比べると割高のようで 約9000円 取られました。 結局利用しなかったので、無駄に。。 3. 「Route 53」から別レジストラへ移管するのが困難 「Route 53」の管理画面から別のレジストラに移管しようとしましたが、 JPドメインでは、本来できるはずの「有効」となっている移管のロックを「無効」にすることが、できませんでした。。 どうやら サポートしていない ようです。 サポートセンターにお問い合わせしましたが有効な回答は得られず、結局できなかったです。。(;_;) (もしかしたら、私の知らない方法はあるかもしれないないですが。。) 結論 基本、JPドメインは「Route 53」へ移管しないほうが良い。 参考 お名前.comで取得したドメインをAmazon EC2に紐付ける お名前.comからAmazon Route 53 へドメインを移管する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon EventBridge Events ルール → Amazon SNS トピックが上手く連携されなかった件

構成 Amazon EventBridge Events ルール → Amazon SNS → Eメール 発生した問題 Eventsルールが発火した後も, Eメールが送信されない 原因 SNSトピックがEvents ルールからのアクションを許可していなかった (プリンシパルの設定がなかった) 対処方法 SNSトピックに関連付けられているIAMリソースポリシーに, Events ルールからのアクションを許可するステートメントを追加する 例: AWS CDKの場合 (Python) target_topic.add_to_resource_policy( iam.PolicyStatement( actions=["sns:Publish"], effect=iam.Effect.ALLOW, resources=[target_topic.topic_arn], principals=[iam.ServicePrincipal("events.amazonaws.com")] ) ) 参考文献 https://aws.amazon.com/jp/premiumsupport/knowledge-center/sns-not-getting-eventbridge-notification/ https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_sns/Topic.html https://stackoverflow.com/questions/59172919/aws-cdk-how-to-include-principals-in-iam-policy [appendix] Events ルールが発火したかどうかを確認する方法 [Amazon EventBridge] → [ルール] → [ルールのメトリクス] メトリクスを選択し, 統計を[合計], 期間は見やすい期間に変更する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む