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

CloudFormationのスタック一覧を表示するワンライナー(AWS CLI & jq)

結論 ▼ステータスがDELETE_COMPLETE以外のCFn Stackを一覧表示する ※jqが必要 aws cloudformation list-stacks | jq -r '.StackSummaries[] | select( .StackStatus != "DELETE_COMPLETE" ) | .StackName' さらにソート… | sort さらに行数… | wc -l 補足 公式ドキュメントでは aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE となっているが、CREATE_COMPLETE以外も表示したいな〜と思った。 そして削除済みのスタックは表示したくないと思った。 CLI Referenceを見た感じ、--stack-status-filterは複数指定ができるが、not的な指定はできないのでjqでフィルターした。 なお、AWS CLIには--filtersと--queryがあるが、(個人的には)jqの方が書きやすいので使っていない。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

実務経験なしからのソリューションアーキテクトプロフェッショナル合格体験記

ついに・・・ ずっと取りたいと思いながら何となく先延ばしにしていたAWSソリューションアーキテクトプロフェッショナル(SAP)の勉強を1月頃からはじめ、2021/4/10に合格しました! いくつか教材を試して思ったことなどを書いてみます。もしどなたかが取り組まれる際の参考になれば幸いです。 勉強をはじめるまで 業務経歴 社会人になってから4年ほどサーバ(Linux)系の構築案件でプロマネをしていました。 その後はIT系の案件の企画やIT予算管理に携わり、今年で3年目です。 (残念ながら、AWSを実務で扱ったことは現在までありません) SAPの勉強を始めるまで 時系列で振り返ってみると、下記の5ステップくらいがあったかなと思いました。 長々と書いてしまいましたが、簡単にいうと周囲のAWS活用・認定取得の流れに乗った感じです。 【3年目くらいまで】 世の中でクラウド活用がはやってるし、クラウドのことをもっと理解しないとなあ(といいつつ、何もしない)。 【4年目】 会社でもクラウド活用に本腰を入れ始めたな…。そろそろ知識をつけないと。でも、なかなか実務で関わる機会が無いから、まずは個人的に触ってみよう。やるならネットで情報が充実しているAWSかな。お、結構面白い。 【5年目】 せっかくいろいろ触ってみたので、せっかくだしソリューションアーキテクトアソシエイト(SAA)を受けてみよう!(いまからちょうど2年前の2019年4月) 【6年目】 相変わらず実務でAWSに関わる機会が無いけど、会社でクラウド活用がどんどん進む…まずい、実務の機会が無いからこそもっと勉強しないと。(少しBlackbeltを受講し始める) 【6年目終盤(2021年になってから)】 周りでSAPに受かった人が増えてきた気がする…。よし、自分もチャレンジしよう。 ということで、勉強に着手しました。 勉強したもの ネットで調べながらいくつか教材に取り組みました。取り組んだ順番に書きます。 どの教材をやるにしても、分からないところや理解が浅いと感じたところはAWS公式のホワイトペーパーやブラックベルトの活用資料集、あとはYoutubeのチャンネルを見たりしてサービスの概要レベルから学びなおしました。 ① SAAの復習 徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 SAAを受けるためにAWSの各サービスについて体系的に学んだのも2年ほど前の話だったので、その時に使った本↓を使ってまずは総復習をしました(案の定、いろいろ忘れてました…)。 SAPの問題もSAAレベルの基礎知識で解けるものが一定数ありますし、もしSAAを受けてから時間が経っている方はしっかりやってみると良いかもしれません。急いでSAP取りたいときは、回り道に感じるかもしれませんが、意外と学びが多く、まさに急がば回れな感じだと思います。 ② 黒本 AWS WEB問題集で学習しよう あえてご紹介するまでも無いかもしれませんが、SAP以外にもSAAやSOA、他にもいろいろな資格試験向けの問題がたくさんあります。だいたい7問1セットで、SAPについては2021/4/11時点で55セット(385問)ありました。 全ての問題を解けるようにするには有料会員登録(2021/4/11時点で90日間税抜き5,480円)が必要ですが、コンテンツの豊富さなどを考えるとやってよかったです。 私はSAA(1,047問)とSAP(385問)の問題をそれぞれ2周しました。1セット7問というサイクルで取り組めるので、ちょっとした隙間時間に少しづつ進められるのが非常にやりやすく、効率よく知識向上ができました。 ただ、問題は都度最新化されているようですが、少し内容が古いように感じられるものがあるのと、他の教材とほぼ同じ問題で答えが違ったりするのでそれなりに注意が必要です。問題集を全問正答できることよりも、解説などを読みながら理解を深めることを目的とすればいいのかなと思います。 ③ AWS参考書 AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 現時点(2021/4/11)で唯一の日本語で書かれたSAPの参考書です。 問題数もそれなりにあり、なにより解説がしっかりしていて非常に良かったように感じます。解説は他のどの教材よりわかりやすかった気がします。 この本の模試部分を本番5日前くらいに解いたのですが、その後はひたすら分からなかった問題の深堀りを当日までやってました。模試の難易度は、だいたい本番と同じくらいだったと思います。 ただ、こちらも黒本と同様に一部問題の解答が間違っているように感じられました。「この問題の解説、少しおかしいかも?」と思って自分で調べることでさらに理解を深められる面もあったので、それはそれでよかったのかもしれません。 ④ 公式のサンプル問題 サンプル試験 本来は順序が逆な気がしますが、黒本や参考書を進める半ばくらいでサンプル試験を解きました。公式の問題で解説があるのはこれくらい(あとはAWS Summitとかにある試験対策講座の例題)だと思います。試験の雰囲気がつかめて良かったです。 これを解いたころに、試験ガイドも読みました。正直これはもっと早く取り組むべきだったと思います。 ⑤ 模試 AWS認定 AWS認定のリンクから、本番の試験と同時に模試も申し込んで実施しました。 本番の1週間前くらいに模試は受けました。結果は65%と合格ライン(75%)に届かず焦りました。そのおかげで終盤気合を入れて学習を進められたように感じる一方で、模試自体は解答も分からないですし、必須ではないと思います。 その他 他の方の合格体験記にもありますが、AWS Organizationsやオンプレとの統合(DXやSnowballなど)、Kinesis系は上記の教材を活用し、SAPに向けて特にしっかりやりました。 他にもUdemyに問題集があることはネットで調べて分かっていたのですが、そこまで取り組む時間が無く、私はやりませんでした(セールの時に買ってはいたのですが…)。 試験について いよいよ試験を申し込み、受験するまでです。 在宅での受験 ピアソンVUEで申し込み、受験をしましたが、コロナ禍もあったので在宅で受験を選択しました。 ただ、直前で受験前のガイドを見たのですが、模試と比べてしっかりとしたシステムテストなどがあるので、余裕をもって事前にテストを済ませておくことをお勧めします。私は直前くらいにテストをした際になかなかうまくいかず(いくら受験用アプリ以外の他のアプリを落としても、そう判断されない)、かなり焦りました。とりあえず再起動したら改善したので、今後受ける方のご参考になればと思います。 また、試験本番の事前準備(ディスプレイを外したり、部屋においてあるものに毛布かけたり)もそれなりに時間がかかりました。当日は早め(遅くとも試験開始時刻の1時間前)に準備を始めたほうが良いと思います。 そして、試験中は集中して問題を解いてればいいのですが、変に不正と思われないか、突然家族が部屋に入ろうとしてきたりしないかと、かなり緊張しながら進めてました。緊張感は会場で受ける以上だった気がします。 総じて、会場までいかなくてもいいのは楽なものの、在宅受験もそれはそれで大変なところもあるなという感じです。受験のための環境を自宅で用意できるか、自宅でも集中して試験を進められるかなどをもって、受験場所を判断するのが良いと思います。 教材と試験問題の比較 あまり教材と全く同じ問題は出なかったような気がします。 ただ、各種教材で得られた知識によって解ける問題が多く、勉強すればするだけしっかり結果に表れるとも感じました。 難易度は黒本や参考書と同じくらいでしたが、全くわからない問題もありました。おそらく、今後何回受けたとしても私が全問自信をもって回答できる日は来ないと思います。 受験後(今) 受験直後に合否は分かり、半日後くらいにスコアレポートが参照できるようになりました。 916点でした!かなり時間をかけたので、合格して本当にうれしかったです(かつ、もう一度受けるような事態にならず安心しました…)。 せっかくそれなりに知識はまとまったので、今後もしっかりアップデートを追いかけながら、理解度を維持・向上していこうと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Let's Encryptの更新(手動)

Let's Encryptの手動更新の方法(備忘録) ホントは自動更新したいけどcronがうまく機能しないので仕方なく手動でやる(気が向いたら自動更新も調べる) rootユーザーで入る [ec2-user@ip-172-31-36-245 git_toreka]$ sudo -i 下記コマンドを打つ [root@ip-172-31-36-245 ~]# /usr/local/bin/certbot-auto renew --post-hook "sudo service httpd restart" こんな感じで出たらOK Upgrading certbot-auto 1.11.0 to 1.14.0... Replacing certbot-auto... Your system is not supported by certbot-auto anymore. certbot-auto and its Certbot installation will no longer receive updates. You will not receive any bug fixes including those fixing server compatibility or security problems. Please visit https://certbot.eff.org/ to check for other alternatives. Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/torekabodymake.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificates are not due for renewal yet: /etc/letsencrypt/live/torekabodymake.com/fullchain.pem expires on 2021-07-10 (skipped) No renewals were attempted. No hooks were run. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2021-07-10と3ヶ月後の日付が書いてあるので成功してる(はず) 自動更新ができるようになるまではとりあえずコレで行きます。 少し前にやったことがどんどん忘れていってしまうので、なにかやったらこうやって簡単にでも記録するようにします。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSアソシエイト試験に向けて1(概要とサーバー立ち上げまで)

はじめに 去年辺りから気になっていたけれどもインフラなのと課金のシステムがよくわからなかったのでハードルの高さを感じていたAWSですが、先日JAWS DAYSというイベントの初心者向けハンズオンに参加したことと、アプリ作るにもデプロイ先のこと何か1つでもわかっておかないと苦労するなということを感じていたこと、今の自分はあまりにも知識がないというのをTwitterでご指摘頂いてるに加え、先日の面接でも「資格取る気ないの?」と落胆された感じで聞かれたので、それならば基本情報技術者と一緒に資格を取る過程で知識をつけようじゃないかということでAWSソシューションアーキテクトアソシエイト試験を受けてみようと思い立ったので、以後記録をつけていきたいと思います。 元々興味はある分野ですし、このあたりの仕組みがわかってれば理解できるところも増えようという期待を込めてがんばります。 教材 JAWS DAYS 2021初心者ハンズオン資料 これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版) 深度によって今後ホワイトペーパーとかブラックベルトと呼ばれるものもやることになると思います。 アカウントの作り方 必要なもの メールアドレス クレカ・デビットカード SMS認証用の端末 MFA認証用の端末・及びアプリ(Google Authenticator等) 上記のものを用意してフォームの指示に従えばOK。 作成後、IAM→MFA→MFAを有効化で仮想デバイス設定からMFAを有効化して二重認証にする。 アカウント作成において注意すること 住所は英語仕様で書く → 住所を英語仕様に変換してくれるサイト MFAを有効化の仮想MFAデバイスの設定の際、MFAコードは以下のように入力する → MFAコードの更新を待って、MFAコード1には更新前のコードを入れてMFAコード2の部分には更新後のコードを入れる。 ex. 更新前に111444のコードで123444のコードに更新された場合、MFA1=111444、MFA2=123444 ルートユーザーとユーザーの作成 アカウントを作った段階ではルートユーザーのみ(権限をすべて持っている)なので、権限をある程度制限したログインユーザーを必要に応じて作る。 IAM(Identity and Access Management)について 簡潔に言うとグループやそれに所属するユーザー(AWSを利用するログインユーザー)などにどんな権限(ポリシー)がどれくらい付与されているかという関係性。 また、グループやユーザーとは別にサーバーやプログラマーに付与されるログイン情報(ロール)にポリシーが付与されることもある。 ロールについてもう少し掘り下げると公式に以下のような記述がある。 IAM ロールは、特定のアクセス権限を持ち、アカウントで作成できる IAM アイデンティティです。IAM ロールは、 AWSで許可/禁止する操作を決めるアクセス権限ポリシーが関連付けられている AWS アイデンティティであるという点で、IAM ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。IAM ロール 上記はロールの一例で、ユーザーはAWSを利用する(=AWSリソースにアクセスできる)特定のユーザーであり、そこに特定のポリシーを付与することで権限をコントロールするが、ロールはアクセス権に関するポリシー諸々をロールとしてAWSリソースへのアクセス権がないユーザー・アプリケーション・サービスに対して持たせることでアクセス権の委任ができるという仕組みになる。 つまり、ユーザーはAWSリソースを扱うことを前提に作られるのでそれに応じた役割(ポリシーの付与によって決まる)が与えられているのに対して、役割を与えられてないユーザー等にある一定の役割を与えられるようなものとなんとなく理解しておく。 ユーザーはコンソールのIAMの項目から追加できる。 追加ユーザーの情報は例えばアクセス権限であるならこのように表示される。 IAMユーザーの画像 AdministratorAccessポリシーはルートに次ぐ権限を与えるもので、IAMUserChangePasswordはパスワード変更を認可するポリシーである。 CloudTrailについて AWSインフラストラクチャでのアクションに対するログを残せる機能。 例えばEC2サーバーを削除したというアクションに対して 誰が(ユーザーAが) 何を(EC2サーバーCを) どこから(どのPCから) いつ(何年何日何時何分に) 行った?(削除した) のようなログを残せる。 実際にはAWSの各サービスのAPIエンドポイントに対するアクセスへの記録を行っているようだ。 注意としては、ログの記録は無料だが、保管は以下の条件のものは有料になるのでこの機能を不用意にONにすると課金対象になる可能性は高いが、実際に使う際にはONにすることを推奨されている。 ちなみにOFF(証跡の作成をしていない)でも管理イベントのログは記録され90日間保管されていてこれには料金はかからない。 課金対象になる条件 管理イベント以外のイベントのログの保管 管理イベントでも90日以上保管したい場合は有料 S3やCloudWatchを使用して、無料枠で設定されている範囲の利用が確認された場合 2つ目のTrail(証跡)を作成する ログの保管にはS3あるいはCloudyWatchというサービスを使用するのですが、それらがバケット量に対しての従量課金かつ入出力も従量課金となるのでそこで無料の枠を超えると課金が発生するという仕組みのようです。 バゲットを適宜削除すれば防げる……ようですがログはもう常に発生するものなので下手に設定して忘れた頃に課金が……となるので現時点では設定しません。 後ほどS3についてしっかりやるタイミングがあるみたいなのでそこを終えたら戻って設定します。 どうなったら課金対象になるの? というシチュエーション例については公式の以下のページが参考になります。 AWS CloudTrail の料金 Budgetsについて AWSを使う上での予算の設定ができる機能。 ルートユーザー以外のユーザーは通常アクセス権限がないのでルートユーザーでログインして、マイアカウントのIAMユーザー/ロールによる請求情報へのアクセスの項目でIAMアクセスのアクティブ化にチェックを入れておく。 なお、予算を超えたら通知もできるが監視頻度は1日ごとになるのでリアルタイムではないということに注意しないといけない。 CostExplorerについて AWSについて発生した課金額をサービス別にグラフにして確認することができる。 アカウント作成当日には機能しない。 以上ここまでがアカウント作成時に確認しておくべき項目とハンズオンイベントの際に教えていただいたところです。 CloudTrailに触らず、またEC2でサーバーを立てたりと余計なことをしていない限りここまでで課金が発生することはないです。 セキュリティーグループについて サーバーを立てて見る前にセキュリティグループについて確認をしておきます。 セキュリティグループは簡単に言うとどのIPアドレスからのアクセスを許可しますかというルールのようなものです。 その前にAWSを利用する上でのツールをざっと確認しておきます。 AWSマネジメントコンソール ブラウザからAWSの各種設定へとアクセスできるもの。 大体まずはここからはじまる。 立てたサーバーを操作するソフト(GUIツール) いわゆるGUIツール。 例えばWindowsサーバーを立てた場合PowerShell、LinuxであるならばMacのTerminalなどのSSH接続ができるツールを使う。 AWS CLI コマンドラインやターミナルから複数のAWSサービスを制御・管理することができるツール。 AWSが用意してくれているのでインストールして使う Git リポジトリに上がってる環境設定をそのまま持ってくることもできるのでその場合は使う。 ハンズオンでは事前に用意された環境をGitで複製して環境構築をしました。 CloudShell AWSが用意してくれているブラウザから利用できるGUIツール。 GitとAWS CLIがプリインストールされている。 セキュリティーグループを考えてみる ハンズオンで用意された前提条件は以下の通り。 AWS Cloud上で展開されているサービスにアクセスする インターネットゲートウェイを通してVPC内のリソースへアクセスがパスされる ALB(アプリケーションロードバランサー)へアクセスがパスされる ALBは負荷分散の役割を持ち、EC2で立てた2台のサーバーのどちらかへアクセスをパスする 「Hello JAWS!!」とブラウザに表示するようにサーバーからレスポンスが返ってくる さて、何もしていないとALBのセキュリティグループはアクセスを拒否してしまいます。 なので新しくセキュリティグループを作成してALBにそれを適用しないといけません。 ハンズオンではまず全アクセス許可から手順が始まりました。 マネジメントコンソールからEC2を選択肢、セキュリティグループの項目を選択しそこから作ることができる。 また後ほどサーバーを立てるが、そこでもセキュリティグループを作ることができる。 あとは画面の指示に従って セキュリティグループ名 セキュリティグループの説明欄 VPC の3点を定義して次にインバウンドルールを設定します。 インバウンドルールでは 通信方式 プロトコル ポート 許可するIPアドレス ルールの説明 を定義できます。 例えばHTTPで許可するIPアドレスを0.0.0.0/0にするとHTTP通信による全IPアドレスからのアクセスをすべて許可するというルールになります。 インバウンドルールを作ったらセキュリティーグループは作成完了なのでこれを適用します。 作成したセキュリティルールを適用はロードバランサーから行えます。 EC2のホーム画面まで戻ってロードバランサーを選択、セキュリティグループの編集から先程作成したルールをチェックして保存すればOKです。 なお今回は用意された環境においての話なのでセキュリティグループの作成と適用だけでアクセス許可ができましたが、VPCへのアクセスになるので実際の場合は以下の点も確認や設定が必要だそうです。 VPCにインターネットゲートウェイが存在する(今回は用意されていた) ALBの属するサブネットのルートテーブルにおいてVPC外のIPアドレスの通信の向き先がインターネットゲートウェイになっている 同じく同上のサブネットにおいて関連付けられているネットワークACLがVPCとの通信を拒否していない サブネットはネットワーク上のネットワーク、例えると配達などにおいて荷物を承った場合、その事業所から実際に配達を行う場所へ直接配達するのではなく、中継を経て配達場所の事業者に荷物をパスしてから配達が行われるようにネットワーク間の通信を最適化するための仕組み。 例えばIPアドレスひとつとってもそのIPアドレスは様々な端末で使用していてアクセスもそれに比例して膨大な数がやり取りされている中で、データが目的の端末を見つけるのはそのままだと難しいというのは何となく分かる。 そこで、サブネットマスクと呼ばれるもの利用してこれをルーティングしてやるということになる。 これをサブネット化という。 例えば荷物をある会社のある人物宛に送ったとする。 すると、配達人はこのままでは膨大な人数の従業員から当該人物を探し出さないといけない。 ここで部署を指定してやるとどうだろうか? すると部署にまず荷物が届き、その部署がそこに所属している当該人物へ荷物を渡すというフローが取れる。 この場合の部署がサブネットマスク、当該人物がIPアドレスということになる。 実際だと IPアドレス = 192.0.2.15 サブネットマスク = 255.255.255.0 とした場合、まずデータが192.0.2.15のIPアドレス宛で届く。 するとルーターは192.0.2のネットワークへデータを転送する。 その後、192.0.2のネットワーク内のルーターが255.255.255.0を二進法を使って変換し「15」という数値を導き出す。 改めてIPアドレスを見てみると192.0.2.15となっていて192.0.2がネットワークであったことから残りの15が目的のアドレスだったということになり、データは当該IPアドレスへと到着する。 という流れになるようだ。 参考:サブネットとは?| サブネット化の仕組み 閑話休題、これで要件に応じて許可する通信方式及びIPアドレスの設定ができるようになった。 ここまでの話はリソース外からのアクセスについての話だったが、セキュリティグループの特徴として同じセキュリティグループを持つリソース同士の通信は許可されるというものがあるのでもしリソース間同士での通信を許可しない場合は別にセキュリティグループをそれぞれ作らないといけない。 サーバー立ち上げ ここまで来たらサーバーを立ち上げてみます。 ルート、もしくは権限を付与された(今回はAdministratorAccessポリシーを付与されたユーザー)ユーザーでログインしてコンソールからEC2を選択して進んでいきます。 サーバーの選択 上記のようにOS・サーバー・アプリケーションを含んだマシンイメージを選択できます。 これいつも忘れるので改めてまた書きますが、こういうのをIaaS(Instructure as a Service)といいます。 Instructureなのでサーバー(Cloudなので仮想サーバーということになりますが)などの機材やネットワーク、つまりはインフラ周りまでまるっと含んでCloudで提供しますよっていうサービスになります。 つまり、開発に関するリソースとインフラは提供するけれどそれ以外のことは自分たちで用意してくださいなというサービスです。 OSは提供に含まれるのかはプラットフォームによりけりみたいですが、今回のEC2の場合は含まれているケースになりますね。 これがSaaS(Software as a Service)になると要はSoftwareまでベンダー(提供する側)が用意していてユーザーはそれをインターネット上で使うだけというものになってきます。 つまり、ユーザーが提供されたサービスに対してあれこれとできるのはSoftwareの機能の範疇くらいかベンダーに許可された範囲に限定されることになります。 よくわかる例としてはEXCELソフトとしてOfficeのEXCELはパッケージソフトとしてPCにインストールして使いますが(一部機能はオンライン上でもできますが、あくまで例として)、Googleスプレッドシートはそれをせずともブラウザで編集・保存までできます。 こういうソフトウェアの機能をインターネット上で提供しているのをSaaSというみたいですね。 で、PaaS(Platform as a Service)になるとSaaSに比べていくらか自由度が増します。 SaaSからSoftware部分を差っ引いている、あるいはIaaSの状態から開発の自由度が制限されたような状態がPaaSになるみたいです。 SaaSではないので、プログラム(Softwareになる部分)は自前で用意できかつそれだけ用意すれば開発ができるが、IaaSに比べてデータベース設定や実行環境に制限があるというイメージでしょうか。 つまり、ユーザー側から利用する際に求めれられる知識の高い順は IaaS > PaaS > SaaS ということになり、同時にそれは開発の自由度の高い順かつ提供されているリソースが少ない順になるということになります。 参考: SaaS、PaaS、IaaSとは。3分で理解するそれぞれの違いとクラウド基礎知識について 閑話休題、とりあえずマシンは無料枠のものを選択します。 今回はLinux2を選びました。 インスタンスタイプの選択 無料枠は1つしかないのでt2_microを選択。 要はここで先程のマシンのスペックが決まるわけですね。 インスタンスの詳細設定 作るインスタンスに関する細かい設定です。 とりあえずdefaultの状態で先へ進みます。 ストレージ 同上。 タグ 作成するインスタンスがどういうものかのタグ付けですね。 Category-経費精算システム のように設定する場面はありそう。 セキュリティグループ 先述した通りセキュリティグループの設定になります。 今回はSSH接続でアクセス制限なしという状態で作りました 確認とキーペア 最後にこれまでの設定の確認とインスタンスに接続するための鍵の作成です。 キーペアの名前を入れてダウンロードボタンを押して、インスタンスの作成を押せば完了です。 このように作成されたインスタンスが表示されます。 注意点 キーペアの保存場所はPrivateな領域にしないといけない → このあとVSCodeでインスタンスに接続してみるのですが、この際作ったキーペアの保存場所を指定する必要があります。 例えばこのときにWindowsであるならC:\User以下のような保護された領域以外を指定するとVSCodeがエラーを吐いて接続が完了できません。 他のGUIツールの場合はわかりませんが、秘密鍵になるのでなるべくPrivateな領域に入れておきましょうということなのかもしれませんね。 不要なインスタンスは削除する(課金されたくないor無料枠を無駄にしたくない) → 無料枠の消費はインスタンスを起動している時間で計算するので、無駄にインスタンスを稼働していると無料枠が減ってしまいます。 同時にこの段階では大丈夫だと思いますが、例えばCloudTrailを有効にしたインスタンスを作り、その後不要になったがそのままにしていたなんて状態の場合は普通に課金対象になり得るので無駄にお金を払ってしまうことになります。 なので、今回のように試しにサーバーを立ててみたなんて時はすぐに削除したほうが丸いです。 インスタンスの削除はインスタンスの状態から行うことができます。 逆に言うと手軽に削除できるので重要なインスタンスには終了保護の設定をして解除しない限りはインスタンス終了ボタンがブランクになるようにしたほうがいいということになりますね。 インスタンスへの接続 最後にインスタンスへ接続してみます。 Udemyの講座本編ではTera Termが紹介されてますが今後のことを考えるとVSCodeから接続できるほうが便利なので今回はそちらで試してみました。 やってることは同じです(フロー的にはMacにおけるTerminalでの接続に近い)。 参考: VSCodeを使ってAWS EC2のソースコードを編集する Remote-SSHプラグインをインストール VSCodeの拡張機能であるRemote-SSHをインストールするだけでOKです。 インストールしたら左のメニューにアイコンが出るのでクリック SSH通信でインスタンスにアクセスを試みる アイコンをクリックしたらリモートエクスプレス欄をSSH Targetsにして+マークをクリックします。 するとEnter SSH Connection Commandと出るのでそこに ssh -i "キーペアファイルへのパス" ユーザー名(Linuxならec2-userなど)@インスタンスのパブリックDNSまたはパブリックIPアドレス を入力してEnter。 するとSSHのconfigファイルを指定してくれと言われるので任意のものを指定。 そんなの作ってないよって人は任意の場所に作るといいです。 私はC:\Users\~\.ssh\configのようにユーザーフォルダ直下に作っています。 先程もありましたがキーペアは必ずPrivateな領域に保存して、そこを指定してください。 問題なくいくとHosts Added!とアナウンスが出るのでOpen Configを押してみましょう。 こんな形式のファイルが表示されると思います。 あとでキーペアの場所を変更したい等々あった場合はこのファイルを編集することになります。 ちなみにHostの部分は任意に変更できるので実際の開発の際はどの開発環境なのかわかるように変えることになります。 あとはSSH TARGETSにあるホスト名を右クリックしてConnect to Host in Current Windowsを選択。 ここで問題がなければあとは指示に従って勧めていけば下記のような画面になります。 キーペアエラーはこのタイミングで出るので、もしうまく行かなかったらキーペアの保存場所を確認してみましょう。 これでインスタンス内部のディレクトリに入れたので実際の開発に使うファイルなどにアクセスして開発を進めたり、下のターミナルからインスタンスを操作できるようになりました。 おわり これでひとまず今後学習を進めていく上での必要最低限の準備が整ったので以後、どんどん進めて行きたいと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSのEC2でReactアプリをGithubからクローンして、EC2でアプリを起動するまで(nginx)

環境 MacOS BigSur 11.2.3 事前に *AWSのアカウント作成が終わっている方向けの内容です。 *AWSアカウントの初期設定まとめの内容も実施推奨です。 目的 ・ローカルでcreate-react-appで作成したアプリをGithubへpush、 アプリをEC2にclone、ブラウザからEC2へのアクセスして、アプリを表示させます。 ・シンプルな構造で、AWSの主要サービスの理解を深める。 ・本編で作成した環境は今後も拡張していき学習の効率化を図る。 以下の方が対象になります create-react-appでReactアプリ作成したことがある。 AWSのEC2でReactアプリを起動してみたい。 Git/Githubが使える。 簡単なvim操作ができる。 1.VPCの作成 AWS マネジメントコンソールからVPCを検索します。 *VPCはAWSクラウド内に独自にネットワークを構築できるサービスです。 VPCを作成していきます。 VPCの名前は任意で構いませんが、今回はmy-react-vpc-1で作成し、 IPv4 CIDR ブロック情報は10.0.0.0/2としています。 その他の項目はデフォルト値で作成します。 2.パブリックサブネット作成 サイドバーメニューのサブネットから作成します。 サブネット名はmy-react-public-subnet-1で作成します。 作成したVPCを選択、アベイラビリティゾーン(ap-northeast-1a)を選択。 *IPv4 CIDRブロックは10.0.0.0/24を指定します。 先ほどのVPCを指定していきます。 3.プライベートサブネットを作成 同様の手順で、サブネット名my-react-private-subnet-1で作成していきます。 本記事ではプライベートサブネットにEC2やRDSは配置しませんが、今後の拡張のため作成しています。 作成したVPCを選択、アベイラビリティゾーン(ap-northeast-1a)を選択。 *IPv4 CIDRブロックは10.0.2.0/24を指定します。 4.インターネットゲートウェイを作成 *インターネットゲートウェイはVPCとインターネット間の通信を可能にするために必要です。 名前タグはmy-react-internet-gw-1を入力、 インターネットゲートウェイの作成をクリックします。 作成したゲートウェイは、すでに作成しているVPCにアタッチします。 5.EC2インスタンス作成 インスタンスを作成していきます。 EC2はクラウド内で提供されるコンピューター(リソース)です。 後に作成するReactアプリはこのEC2にクローンします。 検索窓でEC2を検索します。 インスタンスを起動します。 マシンイメージはAmazon Linux 2 AMIを選択。 インスタンスタイプはt2.microを選択。 次のステップをクリックします。 続いて、ネットワークはVPCを選択し、サブネットはmy-react-public-subnet-1、 自動割り当てパブリックIPを有効にします。 その他の項目はデフォルト値で次のステップに進みます。 ストレージの追加もデフォルト値で次のステップに進みます。 次のステップでタグを追加します。キーにName、値はmy-react-web-server-1として次のステップへ。 続いて、新しいセキュリティグループを作成します。 セキュリティグループ名と説明はmy-react-sg-1として、 ルールを追加します。 ルールはタイプにHTTPを指定、プロトコルはTCPを選択、ポートは80を指定します。 入力が終わったら、起動と確認へ進みます。 設定に間違いがないことを確認し、起動をクリックします。 インスタンスの起動前にキーペアの作成画面が表示されるので、キーペアを新規作成します。 作成したキーペアはご自身のPCに保存します。(このキーファイルは安全な場所に保管してください) インスタンスの作成をクリックしてインスタンスの表示をクリック。 実行中になっていればインスタンスの作成は完了です。 6.ルートテーブルの編集 VPC IDがmy-react-vpc-1のルートテーブルを選択、 ルートの編集をクリックし、ルートを追加していきます。 追加するルートの送信先は0.0.0.0/0、ターゲットはInternet Gatewayを選択、 すでに作成しているmy-react-internet-gw-1を選択し、ルートを保存します。 7.作成したEC2でreactアプリを起動する Gitを使うので事前にご自身のPCにnpmをインストールします。 Terminal npm install -g npm EC2にSSH接続 SSH接続する際に先ほど作成したプライベートキーファイルが必要になります。 このキーペアファイルは権限を変更しないとエラーになるので、あらかじめchmodで権限変更しておきます。 Terminal chmod 400 キーペアファイルのパス chmod 400 Downloads/my-react-key-pare-1.pem キーペアの権限が変更されているか確認します。 Terminal ls -l my-react-key-pare-1.pem 以下のように-r--------となっていれば権限変更されています。 EC2へ接続します。 Terminal ssh -i <キーファイルを指定> ec2-user@<EC2のパブリックIPv4アドレス> ssh -i Downloads/my-react-key-pare-1.pem ec2-user@10.0.1.1 *EC2のパブリックIPv4アドレスはEC2コンソール画面から確認できます。 接続の際に以下の内容を聞かれるので、yesを入力します。 Are you sure you want to continue connecting (yes/no/[fingerprint])? yes 以下のEC2が表示されればSSH接続完了できてます。 EC2への外部からのアクセスをローカルホストにつなげるようにする 現在の設定ではアプリケーションをクローンして起動しても、 localhost:3000で起動することしかできないので、 nginx を使って「外部からのアクセスをローカルホストにつなげる」仕組みを用意します。 nginx をリバースプロキシとして用い、ポート80へのアクセスをlocalhostの3000ポートに振り向けるようにします。 nginxをインストール *EC2にSSH接続した状態で以下コマンドを実行します。 権限ユーザーの切り替え EC2 sudo su - root EC2のパッケージをアップデート EC2 yum update -y nginxをインストール EC2 yum install nginx -y ↑これを実行すると、nginx の install 時に Amazon Linux 2だとエラーになるので、 エラーメッセージの指示に従い、以下を実行。 EC2 sudo amazon-linux-extras install nginx1.12 nginxを起動します。 EC2 sudo systemctl start nginx.service 以下のコマンドでnginxのstatusを確認します。 EC2 sudo systemctl status nginx.service Acrive: active (running)となっていれば起動しています。 Gitをインストールします。 EC2 sudo yum -y install git *あらかじめ、ご自身のPCでcreate-react-appでアプリを作成し、ご自身のGithubリポジトリへpushしてください。 EC2にアプリをクローン EC2 git clone <https://github.com/<your sample app repository> Githubのユーザー名とパスワードを聞かれるので入力してクローンします。 アプリケーションのビルドにnode.jsが必要なのでインストールします。 EC2 curl -sL https://rpm.nodesource.com/setup_14.x | bash - yum install -y nodejs npmとnodeがインストールされていることを確認します。 下記のようにバージョンが表示されれば無事インストールされています。 EC2 npm -v 6.13.4 node -v v13.5.0 アプリケーションのディレクトリへ移動します。 EC2 cd アプリケーションディレクトリ 必要なパッケージをインストールして、ビルドします。 EC2 npm install npm run build EC2でアプリケーションを実行しEC2のパブリックIPv4アドレスに接続。 アプリケーション起動 EC2 npm run start その後、ブラウザのアドレスバーにEC2のパブリックIPアドレスを入力してみる。 しかし、このままでは下記エラーが表示されてしまうので、 EC2の下記パスにnginxの設定ファイルがあるのでvimで編集していきます。 EC2 vim /etc/nginx/nginx.conf 以下のlocationを追加します。 /etc/nginx/nginx.conf server { location / { # WEBリクエストをローカルホスト3000番ポートへリダイレクト proxy_pass http://localhost:3000/; } } ファイルの編集が完了したらnginxを再起動します。 EC2 sudo systemctl restart nginx 再度、アプリケーションを起動。 EC2 npm run start アプリが起動している状態で、対象のEC2インスタンスのパブリックIPv4アドレスを ブラウザに入力してアクセスします。 ロゴが表示されれば成功です! 最後までお読みいただきありがとうございます! ご指摘などありましたら、お気軽にコメントください^^ この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSでWebアプリをデプロイする方法(Java)⑩

参考サイト:https://qiita.com/hiren/items/2a4f1b55c99ebfb3fd08 制作物のデプロイ 制作物を特定のディレクトリに配置し、アクセスできるようにします 利用環境 OS:MacOS ブラウザ:Chrome Java:11.0.2 Tomcat:9.0.44 前提条件 Apacheがインストールできている状態 まだ、Apacheがインストールできていない方はこちら Javaがインストールできている状態 まだ、Javaがインストールできていない方はこちら Tomcatがインストールできている状態 まだ、Tomcatがインストールできていない方はこちら WARファイルを作成する Eclipseを起動し、プロジェクトを右クリックし、[エクスポート]→[WARファイル]を選択、宛先を[デスクトップ]にして[完了]を選択 WARファイルを配置する まずは、ローカルにあるWARファイルをリモートのディレクトリに移動します ※直接デプロイ先に移動することもできますが、その場合権限変更を行わなければいけないため以下の手順で実行します ローカル→リモート(tmpディレクトリ)→rootアカウントでのログイン→リモート(デプロイ先) ローカル→リモート(tmpディレクトリ) scp -i "/Users/koyamatakumi/Documents/Development/practice/aws/myserverkey.pem" /Users/koyamatakumi/Desktop/sukkiriShop.war ec2-user@13.115.141.44:/tmp リモートに接続 ssh -i "/Users/koyamatakumi/Documents/Development/practice/aws/myserverkey.pem" ec2-user@13.115.141.44 rootアカウントでのログイン sudo -i リモート(tmpディレクトリ→デプロイ先) mv /tmp/sukkiriShop.war /opt/apache-tomcat/webapps ブラウザから確認 URLに[ http://13.115.141.44:8080/sukkiriShop-mvc-java.war/WelcomeServlet ]を入力し、Enter 下記画面が表示できれば成功 AWSでWebアプリをデプロイする方法⑪ RDSのDBインスタンスを作成する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CDK Pipelines 作ったけどSynthがうまくいかない

環境 aws-cdk 1.96.0 事象・経緯 ローカル環境から、cdk deploy を行い、成功。 自動化するためにCDK Pipelinesを作成したのに User: arn:aws:sts::xxxxxxxxx:assumed-role/HOGEHOGE/PIYOPIYO is not authorized to perform: cloudformation:GetTemplate on resource: のようなエラーで落ちる。試しにadmin権限をcodebuildのroleにあてても、 not authorized の文字・・・。 そんな中検索していたら以下の解決策が。 解決 cdk.json に、以下のように context の中に "@aws-cdk/core:newStyleStackSynthesis": "true" を追加する。 cdk.json "context": { "@aws-cdk/core:newStyleStackSynthesis": "true" }
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GitHub Actions 踏み台サーバからECSへデプロイ

背景 GitHub ActionsのDeploy to Amazon ECSを使ってデプロイしようとしたのだが、管理ポリシーでユーザーにIP制限をかけていたので、ECRへのログインが失敗した。調べていると以下の記事を見つけた。 この参考記事ではタイトルにある通りEC2へデプロイしている。本記事ではEC2を踏み台サーバにし、ECSへデプロイできるか動作検証したものである。 1. 踏み台サーバをたてる ECRへのログインとECS Fargateのタスク実行権限を許可するロールをアタッチしたEC2を起動する。gitとdockerをインストールしておく。 2. GitHubへのSSH接続用の公開鍵・秘密鍵を生成 こちらの記事を参考にした。 メモ用に以下に記しておく。 $ cd ~/.ssh $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/ec2-user/.ssh/id_rsa. Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub. $ ls authorized_keys id_rsa id_rsa.pub 3. 公開鍵をGitHubに登録 id_rsa.pubを以下のように登録する。 3-1. settingsを選択 3-2. SSH and GPG keysを選択 3-3. New SSH keysを選択 3-4. 公開鍵を貼り付ける 4. Gitリポジトリを作成する リポジトリはこちらの記事で作成したものを使う。 5. GitHub Actionsのyamlファイルを作成する 冒頭にも書いた通り、こちらの記事で紹介されているyamlファイルをECS用に少し書き換えるだけである。 yamlファイルで使用している変数をまとめた。 AWS_ACCESS_KEY_ID AWSのアクセスキーID(Secretsに登録) AWS_SECRET_ACCESS_KEY AWSのシークレットキー(Secretsに登録) PRIVATE_KEY EC2ログイン用のSSHキー(Secretsに登録) DNS_NAME EC2のDNS名*1(Secretsに登録) account_id AWSのアカウントID git_repository_name GitHubのリポジトリ名 git_user_name GitHubのユーザー名 ecr_repository_name ECRのリポジトリ名 cluster_name ECSのクラスター名 task_difinition_name ECSのタスク定義の名前 subnet_id サブネットID security_group_id セキュリティグループID *1:DNS名と書いてしまったが、ユーザー名も含んでいる。例えば、ec2-user@ec2-52-123-123-12.ap-northeast-1.compute.amazonaws.comという値をSecretsに格納する。 name: TestDeploy on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: test-clone env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }} DNS_NAME: ${{ secrets.DNS_NAME }} run: | curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install --update -i /usr/local/aws-cli -b /usr/local/bin printf "$AWS_ACCESS_KEY_ID\n$AWS_SECRET_ACCESS_KEY\nap-northeast-1\njson\n" | aws configure aws configure list echo "$PRIVATE_KEY" > private_key && chmod 600 private_key sudo ssh -o StrictHostKeyChecking=no -i private_key $DNS_NAME ' ssh -o StrictHostKeyChecking=no -T git@github.com if [ -d git_repository_name ]; then rm -rf git_repository_name fi git clone git@github.com:git_user_name/git_repository_name.git cd git_repository_name aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin account_id.dkr.ecr.ap-northeast-1.amazonaws.com docker build -t ecr_repository_name . docker tag ecr_repository_name:latest account_id.dkr.ecr.ap-northeast-1.amazonaws.com/ecr_repository_name:latest docker push account_id.dkr.ecr.ap-northeast-1.amazonaws.com/ecr_repository_name:latest aws ecs run-task --cluster cluster_name \ --launch-type FARGATE \ --platform-version 1.4.0 \ --task-definition task_difinition_name \ --network-configuration "awsvpcConfiguration={subnets=[subnet_id],securityGroups=[security_group_id],assignPublicIp=ENABLED}" ' 参考記事
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

fargateコンテナに入りたい時はECSexecを使おう

1. 初めに 初投稿です!未経験からエンジニアに就職を目指しているshotaと申します。 ポートフォリオ作りでインフラの勉強の為、fargateを利用したデプロイをしていたのですが、データのやりとりが中々上手くいきませんでした。 ローカルでは問題ないのに... こういった場合、コンテナの中に入ってローカルとの差分を見るのは一つの選択肢にあるのかなと思います。 ecs(ec2)ならec2インスタンスにSSH or SSMでログインしてdockerコマンドで直接ログインする方法があると思います。 ですが,ecs(fargate)の場合は今までに公式的なログイン方法はありませんでした。 そこで、どうにか方法が無いか調べていると、awsからセッションマネージャーを利用して、SSMエージェント経由でクライアントからコンテナへのアクセスができるという素敵なコンテンツが提供されているのを知りました。 https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html クラスメソッドさんもとても分かりやすく紹介していました。 https://dev.classmethod.jp/articles/ecs-exec/ 使用できる条件があるので公式を見てくれたらと思います。 ECSexecは現在マネジメントコンソールの使用はサポートされていません。(4月11日現在) aws-cliも対応しているバージョンを上の記事から対応するものをインストールしていただければと思います。 以降、公式の通りにはなるかと思いますが、簡単な順序を書いていきたいと思います。 この記事はハンズオン形式ではありませんので適宜解釈をしていただければと思います。 2. 方法 初めにiamの権限の付与をします { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*" } ] } このiamポリシーをタスクロールにアタッチするのですが、既存のタスクロールがある方はそこに追記する形で問題ないかと思います。(名前は適宜変更した方が分かりやすいと思います) 次に、入りたいコンテナのtaskに先ほどのタスクロールを設定します。 あとは、コマンドライン上で--enable-execute-commandを使えるようにするために足りていないものがあれば公式を参考にダウンロードしてください。 私は既にサービスを立ち上げていたのでupdate-serviceコマンドを使用し、再デプロイしました。 $ aws ecs update-service \ --cluster クラスターの名前 \ --service サービスの名前 \ --enable-execute-command 成功していれば、ターミナル上に "enableExecuteCommand": true, の表示が出ているかと思いますので,grepなりsedなりで探しましょう。 これで、お目当てのコンテナに入ることができます! $ aws ecs execute-command \ --cluster あなたのクラスター \ --task あなたのtaskid \ --container コンテナの名前 \ --interactive \ --command "/bin/sh" コンテナにインストールされているシェルしか使えないので注意しましょう。 3. おわりに これでfargateでもコンテナにログインを簡単にすることができますね! 私でも簡単にできたので、もっとecsexecが広まって欲しいなと思い、この記事を書きました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS 認定 セキュリティ – 専門知識(AWS Certified Security - Specialty)に合格したので勉強方法を書いておく

前回の投稿(AWS認定ソリューションアーキテクトプロフェッショナルに一発で合格したので勉強方法を書いておく)から早1年も立ってしまいました。 昨年は、いろいろと仕事、プライベート両方でイベントが多く、あまり勉強に力を入れることができていませんでした。 昨年末から、某大手SIerに転職をし、環境も変わり心機一転ということでAWSを含め勉強の意欲が高まっています。 転職とはいっても、前も今も変わらずAWSメインでやってます! そんなこんなで、先日AWS認定セキュリティ – 専門知識(AWS Certified Security - Specialty)(SCS)に合格したので、勉強方法を備忘として書いておきます。参考になれば幸いです。 ちなみに今回も一発合格ということで、無敗記録更新です。 前提 職業:現在インフラエンジニア6年目でAWSをメインに設計構築をするようになって、2年くらい。 最近はもっぱらオンプレミスからAWSへの移行などのコンサルをやることが多いです。 AWSをやる前は、VMwareやWindows、Linuxなどいろいろやってましたが、 今では、AWSが得意!と言えるくらいになってます。 他のAWS関連の資格:ソリューションアーキテクトアソシエイト(SAA)(2018年取得)           SysOpsAdministratorアソシエイト(SOA)(2019年取得) ソリューションアーキテクトプロフェッショナル(SAP)(2020年取得) 勉強期間:2ヶ月くらい 私の場合、集中して長時間時間を取るということが苦手で、ほぼ毎日15分〜30分程度の時間をとってやっていました。 とはいえ、平日はできない日もたびたび、ゆるく長くという感じで勉強しています。 試験について 前回取得したSAPに比べると出題範囲が少し狭い、問題文、回答文がそこまで長くない(たぶん)という感じで、難易度はSAPより低いかなと感じました。とはいえ、専門知識の試験ですので、求められる知識量は高く、しっかりとした対策が必要です。 SAPよりSCSを先に取ったほうが良いともおっしゃる方がいらっしゃるようですが、実際に受けてみて、なるほどなと感じました。私自身はSAPの前にSCSを取るべきとまでは言いませんが、SAPで求められる知識の範囲とかぶっているということと、セキュリティに関する知識はSAPでもかなり出題されるとうことから、先に取得するのはありかと思います。 勉強している中でも、SAPと範囲がかぶっているがゆえにすでに知っていることというのが多々出てきました。 SAPの前後どちらでも問題ないと思います。どちらにしろ勉強した箇所が次の試験に役に立ちます。 言わずもがなかと思いますが、SAAの知識は必須です。 試験までに何をやるか 1.AWS 認定試験に備えるを参照する これは基本です。どの試験にも共通しますが、出題範囲、見るべきドキュメント、トレーニングが列挙されています。 基本的に私の勉強方法は以下URLのリンク先を潰していくことがメインとなります。 2.試験ガイド、サンプル問題を読む 出題される分野、配分、問題の形式をしっかり読みましょう。 配分は以下のとおりです。 分野 1: インシデント対応 12% 分野 2: ログ収集と監視 20% 分野 3: インフラストラクチャのセキュリティ 26% 分野 4: ID とアクセスの管理 20% 分野 5: データ保護 22% 合計 100% 試験ガイド サンプル問題 3.公式トレーニングを受ける 無料でデジタルトレーニングが受けられます。 分野ごとの基本的な解説、練習問題、模擬試験を受けることができますので、イントロとしてはちょうど良いレベル感です。ただし、このトレーニングを受けたからといって試験に受かるというわけではなく、更に深堀りして勉強することが必要です。 Exam Readiness: AWS Certified Security - Specialty (Japanese) 基礎的なところであれば、以下からやってもよいかもしれません。 AWS セキュリティの基礎 (第 2 版) 4.参考書を読む 以下本を購入しました。 本試験の試験でキーとなるサービスを中心にわかりやすく解説されており、非常にためになると思います。 AWSのセキュリティサービスに慣れ親しんでいないという方は、こちらから初めて見るのもありかと思います。 私の場合、すでにSAPや実務で把握しているサービスが多かったため、あまりこの本には時間をさきませんでした。 また、本だけで合格するかというと微妙なところですので、本はあくまで導入として使用し、より詳細な箇所は他ドキュメントを参考にして勉強する必要があると感じました。 5.問題集を解く aws WEB問題集で学習しようのサイトにて、SCSの問題を2周しました。 やはり、問題集を解くことが一番ためになります。試験で求められる知識をチェックできる、間違えた問題から苦手な分野、深堀りすべきドキュメントが参照できるというところがあるので、一番おすすめです。 6.ホワイトペーパー、よくある質問、BlackBeltを見る 全体的に軽く目を通すレベルでよいかなと思います。 参考にしたよくある質問 ・AWS Identity & Access Management (IAM) ・AWS Single Sign-On ・AWS Organizations ・AWS Security Hub ・Amazon GuardDuty ・Amazon Inspector ・AWS Config ・AWS Shield ・AWS CloudTrail ・AWS ウェブアプリケーションファイアウォール (WAF) ・Amazon Macie ・AWS Key Management Service (KMS) ・AWS Certificate Manager ・AWS Secrets Manager ・Amazon Detective ・Amazon VPC ・AWS Direct Connect ・AWS Route 53 ・AWS Artifact 参考にしたホワイトペーパー ・セキュリティの柱 – AWS Well Architected フレームワーク ・アマゾン ウェブ サービス: セキュリティプロセスの概要 ・AWS のセキュリティのベストプラクティス ・大規模環境でのセキュリティ: AWS ロギング ・AWS Key Management のベストプラクティス ・AWS セキュリティインシデント対応ガイド ・DDoS に対する AWS のベストプラクティス ・スケーラブルでセキュアなマルチ VPC の AWS ネットワークインフラストラクチャを構築する ・セキュリティ & コンプライアンスクイックリファレンスガイド BlackBelt 以下のSecurity, Identity & Complianceの分野を一通り見ました。 基本なにかの作業をしながら、知らないワードが出たら注視って感じで見ていました。 知らないサービスがあればBackBeltから入ってもいいかもしれません。 最後に 初の専門知識分野ということでしたが、しっかりと準備した結果無事に合格することができました。 問題も想定していた難易度で、SAPより解く時間もそれほどかかりませんでした。 全体の中でフラグの付いた回答が25問くらい。それ例外は自信を持って回答できたので、全体的に解きやすい問題が多かった印象です。 結果、914点 まあまあ良いスコアではないでしょうか。 SCSに合格し、勉強意欲がますます高まってきました。 とりあえず次は以下を目指します。 ・DeveloperAssociateを取得後DevOpsProを取る。プラクティショナー取っていないので、最後にプラクティショナーを取って、専門知識以外は全制覇したいです。 ・AzureExpert、GCPProを取る。 マルチクラウド対応のアーキテクトになりたいなぁ。。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS cognitoのEメールのカスタマイズ

AWS CognitoのEメールのカスタマイズ 概要 AWS SESで特定のSESリージョンでメール認証する ※ドメイン認証は不要 AWS CognitoのEメールカスタマイズから認証したメールアドレスを選択する AWS Cognitoで使えるSESリージョンを確認する AWS cognito Eメールで設定できるSESリージョンは現時点(2021/03)で以下の3リージョンのみ バージニア オレゴン アイルランドAWS Cognito>ユーザープール>メッセージのカスタマイズから選択できるSESリージョンが確認できる 上記3つのどれかのリージョンで新しくメールの認証を行う AWS SESによるメールアドレスの認証 メールアドレスの認証 ※これは単なるAWS SESのメール認証の手順 AWS SESを開く対象のリージョンに変更する「Verify a New Email Address」を押下する ポップアップが表示されるので認証したいメールアドレスを登録する メールを送信すると以下のメッセージが表示される 認証されるのに最大1時間ぐらいかかると。 私がこちらの作業を行った際は5,6分で認証はできました。 このようなメッセージが認証に設定したメールアドレスに届く このメールに入っている認証メールを押下すると現時点(2021/03)ではこちらのサイトに飛ばされます ※認証はされている AWS SESの画面で認証したメールアドレスを確認すると、 以下ののように認証されていることが確認できる。 Verification StatusがverifiedになっていればOK AWS CognitoのEメールカスタマイズの画面でメールアドレスを選択 AWS Cognito側AWS cognitoのEメールカスタマイズの画面に戻ると、 認証したメールアドレスが選択肢に表示されることが確認できる。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

TerraformでAWS環境にApacheサーバを作成

最近Terraformを触ることが多かったので復習を兼ねて試してみました。 ほぼTerraformだけでApacheサーバの起動まで行います。 環境 Terraform v0.14.10 aws provider v3.36.0 事前準備 tfstate用のS3バケット作成 今回tfstateファイルの保存先にS3を指定しますので、事前にそれ用のS3バケットを作成しておきます。 Terraformで作成することも出来るのですが、公式で「Terraformはインフラを管理する管理ツールなので、Terraformが使用するインフラは、Terraformが管理するインフラの外側に存在するのが理想です。(DeepL翻訳)」と言われています。Terraformを修正するときに誤って破損させたりすることを避けるためですね。 https://www.terraform.io/docs/language/settings/backends/s3.html#multi-account-aws-architecture SSHアクセス用の公開鍵・秘密鍵作成 作成するEC2インスタンスにアクセス出来るよう鍵を作成しておきます。 $ ssh-keygen -C "" 実装 以下に作成したコードを記載します。 ディレクトリ構成 . ├── aws_instance.tf ├── aws_internet_gateway.tf ├── aws_key_pair.tf ├── aws_route_table.tf ├── aws_route_table_association.tf ├── aws_security_group.tf ├── aws_subnet.tf ├── aws_vpc.tf ├── files │ └── user_data.sh └── main.tf main.tf terraform { required_version = "~> 0.14" backend "s3" { bucket = "XXXXX" # 作成したバケット名 region = "ap-northeast-1" key = "terraform.tfstate" encrypt = true } } provider "aws" { region = "ap-northeast-1" } # VPC resource "aws_vpc" "test" { cidr_block = "10.0.0.0/16" tags = { Name = "test-vpc" } } # サブネット resource "aws_subnet" "test" { vpc_id = aws_vpc.test.id cidr_block = "10.0.1.0/24" availability_zone = "ap-northeast-1a" map_public_ip_on_launch = true tags = { Name = "test-subnet" } } # インターネットゲートウェイ resource "aws_internet_gateway" "test" { vpc_id = aws_vpc.test.id tags = { Name = "test-igw" } } # ルートテーブル resource "aws_route_table" "test" { vpc_id = aws_vpc.test.id route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.test.id } tags = { Name = "test-route-table" } } resource "aws_route_table_association" "test" { subnet_id = aws_subnet.test.id route_table_id = aws_route_table.test.id } # キーペア resource "aws_key_pair" "test" { key_name = "test-key" public_key = "ssh-rsa XXXXX" # 事前に作成した公開鍵を貼り付ける } # EC2インスタンス resource "aws_instance" "apache" { ami = "ami-06098fd00463352b6" # AmazonLinux 2 (x86) instance_type = "t3.nano" subnet_id = aws_subnet.test.id user_data = file("./files/user_data.sh") key_name = aws_key_pair.test.key_name vpc_security_group_ids = [ aws_security_group.web.id, aws_security_group.ssh.id ] tags = { Name = "test-server" } } # セキュリティグループ resource "aws_security_group" "web" { name = "web" vpc_id = aws_vpc.test.id ingress { description = "allow http" from_port = "80" to_port = "80" protocol = "tcp" cidr_blocks = ["x.x.x.x/32"] # 必要なIP制限を設定 } egress { from_port = "0" to_port = "0" protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } resource "aws_security_group" "ssh" { name = "ssh" vpc_id = aws_vpc.test.id ingress { description = "allow ssh" from_port = "22" to_port = "22" protocol = "tcp" cidr_blocks = ["x.x.x.x/32"] # 必要なIP制限を設定 } egress { from_port = "0" to_port = "0" protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } user_data.sh #!/bin/bash sudo yum update -y sudo yum install -y httpd sudo systemctl start httpd sudo systemctl enable httpd 確認 実際にアクセスしてみます。 $ ssh -i ~/test_rsa ec2-user@x.x.x.x Warning: Permanently added 'x.x.x.x' (ECDSA) to the list of known hosts. Last login: Sat Apr 10 17:25:59 2021 from p6403009-ipoe.ipoe.ocn.ne.jp __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ [ec2-user@ip-10-0-1-137 ~]$ ブラウザでのHTTPアクセスでApacheのテストページが見えて、SSHでのアクセスも事前に作成した秘密鍵を使って問題なく出来ました。 まとめ 事前のS3バケット作成を除いてTerraformのみでApacheサーバの起動までを行いました。 インフラ環境をコード化するのは楽しいですね。引き続き精進したいと思います。 参考 https://registry.terraform.io/providers/hashicorp/aws/latest/docs https://www.amazon.co.jp/dp/B07XT7LJLC
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSでWebアプリをデプロイする方法(Java)⑨

参考サイト:https://qiita.com/hiren/items/2a4f1b55c99ebfb3fd08 Tomcatのインストール TomcatをインストールすることでJavaサーブレットを動かせる環境を整えます 利用環境 OS:MacOS ブラウザ:Chrome 前提条件 Apacheがインストールできている状態 まだ、Apacheがインストールできていない方はこちら Tomcatをインストールする 接続する 下記のsshコマンドを入力して接続します ※キーペアのファイルのパスと、ec2-user@以降は、変更して使用してください ssh -i "/Users/koyamatakumi/Documents/Development/practice/aws/myserverkey.pem" ec2-user@13.115.141.44 接続確認 下記のように表示されていれば、接続完了です SSHでの操作とrootユーザーへの切り替え rootユーザーのサインイン ソフトウェアのインストールはrootユーザーで行います 下記コマンドを入力し、rootユーザーへサインインします sudo -i Tomcatをインストールするためのユーザーを追加する useradd -s /sbin/nologin tomcat Tomcatのダウンロード ディレクトリを移動、curlコマンドでURLを入力し、コンソールからURLにリクエストを送り、ダウンロード cd /usr/local/src/ wget https://downloads.apache.org/tomcat/tomcat-9/v9.0.44/bin/apache-tomcat-9.0.44.tar.gz ダウンロードしたファイルを解凍して配置 ファイルを解凍、配置、所有者変更 tar -xzvf ~/apache-tomcat-9.0.44.tar.gz mv ~/apache-tomcat-9.0.44 /opt chown -R tomcat:tomcat /opt/apache-tomcat-9.0.44 省略可 Tomcatのシンボリックリンク作成 yumを用いたインストールを行っていない為、将来手動でTomcatバージョンを変更する際にも設定に影響が少なくなるようにシンボリックリンクを作成します。 ln -s /opt/apache-tomcat-9.0.44 /opt/apache-tomcat chown -h tomcat:tomcat /opt/apache-tomcat Tomcatログシンボリックリンク作成 展開したTomcat本体内に生成されるログファイルを他ミドルウェアと同階層のディレクトリ(/var/log 配下)にて参照できるようにシンボリックリンクを生成 ln -s /opt/apache-tomcat/logs /var/log/tomcat chown -h tomcat:tomcat /var/log/tomcat Tomcatの設定 Tomcatコマンドの登録 TomcatをOSにサービスとして登録する為、ルート権限でUnitを作成 vi /usr/lib/systemd/system/tomcat.service [i]キーを押し、下記内容を貼り付け、[esc]キーを押し、「wq」を入力し[Enter] /usr/lib/systemd/system/tomcat.service(新規作成) # Systemd unit file for default tomcat # # To create clones of this service: # DO NOTHING, use tomcat@.service instead. [Unit] Description=Apache Tomcat Web Application Container After=syslog.target network.target [Service] Type=oneshot PIDFile=/opt/apache-tomcat/tomcat.pid RemainAfterExit=yes #EnvironmentFile=/etc/tomcat/tomcat.conf #Environment="NAME=" #EnvironmentFile=-/etc/sysconfig/tomcat ExecStart=/opt/apache-tomcat/bin/startup.sh ExecStop=/opt/apache-tomcat/bin/shutdown.sh ExecReStart=/opt/apache-tomcat/bin/shutdown.sh;/opt/apache-tomcat/bin/startup.sh SuccessExitStatus=143 User=tomcat Group=tomcat [Install] WantedBy=multi-user.target Tomcatの自動起動設定 systemctl enable tomcat.service Tomcat自動起動設定確認 Loadedの(/usr/lib/systemd/system/tomcat.service;の後がenabledであれば自動起動が有効 systemctl status tomcat.service Tomcatを起動する ApacheとTomcatを起動する(先にApacheを起動する) systemctl start httpd.service systemctl start tomcat.service 起動確認 systemctl status tomcat.service ブラウザから確認 セキュリティグループの設定変更 AWSコンソールにアクセスし、EC2インスタンを開く インスタンスを選択し、[セキュリティ]タブを選択 セキュリティグループ名(sg-0dd4fe160059aa368 (my-webserver-sg))を選択する [インバウンドルールを編集]を選択 [ルールを追加]を選択し、タイプを[カスタムTCP]、ポート範囲を[8080]、ソースを[0.0.0.0/0]を選択し、右下のオレンジ色の[ルールを保存]を選択 ブラウザから確認 URLに[ http://13.115.141.44:8080 ]を入力し、Enter 下記画面が表示できれば成功 AWSでWebアプリをデプロイする方法⑩ 制作物のデプロイ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSでWebアプリをデプロイする方法(Java)⑧

Javaのインストール JavaをインストールすることでJavaを動かせる環境を整えます 利用環境 OS:MacOS ブラウザ:Chrome 前提条件 Apacheがインストールできている状態 まだ、Apacheがインストールできていない方はこちら Javaをインストールする 接続する 下記のsshコマンドを入力して接続します ※キーペアのファイルのパスと、ec2-user@以降は、変更して使用してください ssh -i "/Users/koyamatakumi/Documents/Development/practice/aws/myserverkey.pem" ec2-user@13.115.141.44 接続確認 下記のように表示されていれば、接続完了です SSHでの操作とrootユーザーへの切り替え rootユーザーのサインイン ソフトウェアのインストールはrootユーザーで行います 下記コマンドを入力し、rootユーザーへサインインします sudo -i ダウンロード wget https://d3pxv6yz143wms.cloudfront.net/11.0.2.9.3/java-11-amazon-corretto-devel-11.0.2.9-3.x86_64.rpm 下記の画面になればダウンロード完了 インストール sudo yum localinstall java-11-amazon-corretto-devel-11.0.2.9-3.x86_64.rpm 確認 java -version 下記の画面になれば成功 AWSでWebアプリをデプロイする方法⑨ Tomcatのインストール
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】AWS VPCとは何か

プログラミング勉強日記 2021年4月11日 AWS VPCとは  VPCは Virtual Private Cloudの頭文字をとったもので、ユーザ専用のプライベートなクラウド環境・設定を提供するサービスのこと。AWSを利用する場合は、必ずVPCでクラウド環境をコントロールしている。  VPCを設定すると、AWSのサービスの間の連携やインターネットに接続しないプライベートなネットワークの構築などを設定することができる。ネットワーク設定を簡単にカスタマイズできるのがVPCの強み。  AWSは基本的にVPCが必須であるが、すぐに使えるVPCとしてDefault VPCが用意されている。AWS VPCはデフォルトのままでも使用できるが、設定を抽象化したコンポーネントを使用して細かく設定することで、様々な環境構築が可能になる。 AWS VPCの用途  AWS VPCは用途によって外部ネットワークとの組み合わせが変わってくる。  用途としては、インターネット向けシステムやオンプレ向けシステム、インターネットとオンプレミス向けのシステムがある。  インターネット向けシステムは、その名の通りインターネットを経由するシステムを提供する用途で使われる。オンプレミスは、サーバーやソフトウェアなどの情報システムを管理して運用する従来のサーバー運用形態を指す。インターネット向けとオンプレミス向けシステムの両方の接続をVPCに設定する構成がインターネットとオンプレミス向けシステムである。 AWS VPCのメリット  クラウド上で仮想ネットワークを簡単に構築できること、インターネットを使わない通信もできること、便利なコンポーネントが多くカスタマイズ性が高いことがメリットとしてあげられる。  AWS VPCを使用するとAWSの仮想サーバーやデータベースといったAWSのクラウドサービスで構築されるネットワークを構築することができるので、時間やコストをかけることなく仮想上のネットワーク構築ができる。  AWS VPCは専用のネットワークの中に複数のサブネットワークを作ることができる。サブネットワークはインターネットに接続することも接続しないこともできる。なので外部からアクセスする必要のないシステムのセキュリティを高めることもできる。  コンポーネントを組み合わせることで、簡単にネットワークの構築が可能である。ただ、構築する環境によってもコンポーネントが変わるので、様々な環境のネットワークを構築する場合はデメリットにもなり得る。 参考文献 【AWS】VPCとは?特徴や利用するメリット・デメリットを紹介 AWSのVPCって何?メリットや使えるシーンなど徹底解説!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む