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を選択。
ここで問題がなければあとは指示に従って勧めていけば下記のような画面になります。
キーペアエラーはこのタイミングで出るので、もしうまく行かなかったらキーペアの保存場所を確認してみましょう。
これでインスタンス内部のディレクトリに入れたので実際の開発に使うファイルなどにアクセスして開発を進めたり、下のターミナルからインスタンスを操作できるようになりました。

おわり

これでひとまず今後学習を進めていく上での必要最低限の準備が整ったので以後、どんどん進めて行きたいと思います。