これだけでOK！ AWS 認定ソリューションアーキテクト のメモ

オリジナルアプリをデプロイする時に、「これだけでOK！ AWS 認定ソリューションアーキテクト」をudemyをメモ程度に残す。大事なところだけメモしますので、流し読み推奨。

セクション1 まずは知ってみる

コースの概要

AWSの概要を7分で話す。まだちんぷんかんぷん。

1.小テスト

実際のテストを3問見れる。質問の意味が分からず、一旦3問とも飛ばした。
文章形式になっているのでサーバ構築経験がないと答えづらいとのこと。

2.AWSアカウント登録

丁寧に登録方法を紹介。しっかりと画像がついているのでわかりやすい。
クレカ登録。一部有料枠が必要なので。基本的にはお金がかからないようにして下さる。
AWS課金は怖いと聞くので、注意しよう。

3.AWSでサーバーを構築してみる①

サーバーを買ってきて構築すること → オンプレミス
(クラウドの対義語)

AWSは、サーバーを立ち上げるのに数分で無料で今すぐにでも利用できるのが大きな特徴とのこと。
要は、クラウド上でサーバーを作るのは手軽で早いよ！といったところか。

windowsがベースで進む。

EC2の体験に進む。地域の変更で「東京へ」

インスタンスタイプの設定で、「メモリ」「CPU」「ストレージ」「ネットワークパフォーマンス」等を選べる。目的に応じて変えよう。

ステップ 2: インスタンスタイプの選択
ステップ 3: インスタンスの詳細の設定
→ 変更なし
ステップ 4: ストレージの追加
→ 変更なし
ステップ 5: タグの追加(インスタンスタイプの名前、用途、権限を分けることができる)
→ name を 設定し sample などの名前を振る
ステップ 6: セキュリティグループの設定(アクセス制御)
→ 変更なし
確認ボタン
キーペアの作成
→ 適宜名前を決めダウンロード

0.0.0.0/0 はフルオープンで誰でもアクセスできる。IPが決まっていたら制御できる。フルオープンなので、「全世界に開かれていますよーと警告が出る」

インスタンスを作成するとpendingになり、数分経つとrunnningになる。
オンプレミスだとサーバー構築に時間がかかるけど、数分でサーバーを構築できる。というのは理解できた。

ECSインスタンス操作は、MacかWindowsかで操作方法が変わる。windowsはTeraTermを使うとのこと。Macのため割愛。

1. 【MACの方向け】AWSでサーバーを構築してみる②

ダウンロードした pem を sshフォルダにいれる。

chmod 400 udemy-sample.pem等で 自分だけアクセスできるようにする。その後、下記のように接続。

ssh -i "udemy-sample.pem" [email protected]

ssh → ssh接続するコマンド
i → 秘密鍵ファイルを指定
"udemy-sample.pem" ec2-user@hogehoge → 秘密鍵を指定+ログインユーザー名@パブリックIPアドレス(hogehoge)を指定してアクセス。

接続ボタン押して、表示される ssh -i 省略 を押すと動画より早くアクセスできた。

5 .sshの基礎

sshとは、 「リモートマシンの操作ツール」

SSH → クライアントとリモートマシンの間の通信を暗号化するプロトコル
SSHコマンド → SSH方式によってリモートマシン上でコマンドを実行するコマンド
SSHクライアント → SShによるリモートマシン操作を支援するコマンドプロンプトのソフトフェア

基本書式

ssh[オプション]ホスト名[コマンド]
を使って操作していく。

オプション一覧

『 -i 』：秘密鍵ファイル(identifyファイル)を指定
『 -l 』：ログインユーザ名を指定
『 -p 』：ポート番号を指定
『 -x 』：X11の転送を有効化
『 -1 』：SSHのプロトコルバージョン１を使用
『 -2 』：SSHのプロトコルバージョン2を使用
『 -4 』：IPv4を使用

コマンド一覧

『 ls 』：フォルダ/ファイル一覧を表示
『 cd 』：フォルダの場所を移動
『 pwd 』：現在のフォルダ位置を表示
『 cp 』：フォルダ/ファイルをコピー
『 mv 』：フォルダ/ファイルを移動
『 rm 』：フォルダ/ファイルを削除
『 mkdir 』：フォルダを作成

コマンドは分かる人は多いがオプションはどうだろう。

セクション2 Day1 対応の実施

6. Day1対応の実施

・ルートアカウントの利用を停止
→普段使うことはないので管理者権限を使う

・多要素認証を有効化する
→ 認証の仕組みがデフォルトだと無効なので、有効化する必要がある。会社で使うときはなおさら。

・AWS Cloud Trailを有効化する
→アクセスログを取っていく仕組み。セキュリティ上使う必要あり。

・AWSの請求レポートを有効化する
→ 請求レポート

ダッシュボードからIAMを検索。

ルートアカウントの MFA を有効化→ MFAを有効化する。(省略)
google authenticatorを使って二段階認証。すごい(小並感)

7.個々のIAMのユーザーの作成

プログラムによるアクセス
AMSマネジメントコンソールへのアクセス
共にチェック。

個々の IAM ユーザーの作成

IAMで検索→ 個々の IAM ユーザーの作成 → ユーザーの管理 → admin(adminアクセスにアタッチ) → タグ(role admin) で設定

ユーザー別に作成

先程のadminをクリック → アクセス権限の追加 → 既存のポリシーを直接アタック → AdministratorAccess にチェック → IAMユーザーが完成

パスワードポリシー

パスワードを任意の制約で設定。特に追加はしなかった。

8. Day1 対応の実施③

ログの取得。S3を登録する、

9. Day1 対応の実施 ④

請求のアラート設定。

マイ請求ダッシュボードにいき、IAM ユーザー/ロールによる請求情報へのアクセス(オリアプの際は使わないと判断しスルーしました)

Costexplolerにいき起動後、アラートを受け取るをチェック、

ダッシュボードから CloudWatchを検索 → リージョンをバージニア北部に変更→ 左上の「請求」をクリック→ アラームを作成 → Currencyを JP に変更

新しいトピックの選択→ アラート名、アドレスの登録、アラートの選択。

作成ボタンを押し、リージョンを東京に戻す。

完了。

ここまで終えて

設定量が多かった。ユーザーごとに管理を分けるというのが新鮮だった。

セクション3 AWSの仕組み

・オンプレサーバーではなくクラウドなので、時間もコストも少なく運用可能。
・ブロックパーツのように自分の好きなパーツを組みあせて構成を実現する仕組み
・アンマネージド型とマネージド型がある

・リージョン→ 東京や香港やムンバイなど地理的に離れた領域。AWSのデータセンターがある大まかな場所のようなもの(日本には東京と大阪にある)
・アベイラビリティーゾーン(AZ)→ 各リージョンの中にあるデータセンターのようなもの→ リージョン内でAZは繋がっている。(低レイテンシー) 。AZは1つの複数の物理的なデータセンターで繋がっている。よって1つのAZ内のみでAWSを使っているとサービス停止とかでリスク高い。そのため、複数AZで分けるのが信頼性の高いシステム構成。

・エッジロケーション → キャッシュデータを利用する際に更に小さなエンドポイントとなる拠点

・AWSの操作

1.AWSマネジメントコンソール 
2.インスタンス操作 (SSH等)
3.AWS (CLI操作)

アソシエイト試験概要

AWSの操作ができるかじゃなくて、アーキテクチャ設計ができるか？が結構重要とのこと。

細かい点は省略

AWSの全体像

範囲など説明のため省略

セクションIAM

13.IAMの概要

執筆中です