Amazon Web Services クラウドプラクティショナー

AWSのようなクラウドサービスプラットフォームからインターネット経由でITリソースをオンデマンドで利用できるサービスの総称

AWSクラウドコンピューティングの6つのメリット

故障に備えた設計（Design for Failure）をすれば、何も故障しない

Design for Faillure を実現するためには、単一障害点( single Point Of Failure、SPOF )をなくすることが必要

・１つのデータセンターのみで運用しない

・単一のインスタンスのみで構成しない

コンポーネントの分離

システムのコンポーネントを疎結合にすればするほど、スケーリングが大規模にうまくいく

弾力性の実装

弾力性は伸縮性とも言い、リソースの性能を柔軟にスケールアウトしたり、スケールインすることが可能。弾力性は次の３つの方法を用いる

並列化を考慮する

クラウドでは繰り返し可能なプロセスを極めて容易に構築できるため、できるだけ並列化を実施し、さらに可能であれば自動化することを推奨

 39頁

動的コンテンツデータをコンピュータの近くに

例えば、データウェアハウスアプリケーションの場合、データセットをクラウドに移行し、次にデータセットに対して並列クエリを実行することが望ましい。

• リレーショナルデータベースを用いてデータを保管、検索するWebアプリケーションの場合は、データベースとアプリケーションサーバーをクラウドに１度にまとめて移行するのが良い
• 静的コンテンツは、CDNなどのサービスを利用して配布しておくのも良い

AWSによる優れた設計のフレームワークとは、信頼性、セキュリティ、効率、コスト効果が高いシステムを設計しクラウドで運用するために作られたアーキテクチャのベストプラクティス。以下はAWS Well-Architectedフレームワークの５本柱

AWSとユーザが責任を負う部分が明確に分かれ、それぞれがセキュリティを共有して守っていくことをAWS責任共有モデルと呼ぶ

マネージドなサービスを利用することでAWSがマネージしてくれる部分はユーザーの責任範囲からAWSの責任範囲へと移管される（図）

AWSが責任を持つ範囲の考え方

キーペアは、EC2などのインスタンスへのログインで利用する。現在ではセキュリティを高めるため、公開鍵認証方式を用いてキーペアによってログイン認証を行うのが一般的。キーペアの秘密鍵の管理はユーザーの責任（図２）

各ユーザーは、アクセスキーとシークレットアクセスキーを作成・保持する。このペアをコマンドライン（AWS CLI）操作や、プログラム（AWS SDK）の認証情報として利用する。アクセスキーとシークレットアクセスキーの値を環境変数や認証ファイル内に格納して利用する。権限の強いアカウントからAPIキーを生成せず、そのCLIやプログラムで利用する範囲の権限のみに付与する。現在はAPIキーの利用は推奨されておらずIAMロール（詳細は後述）の利用が推奨されている

セキュリティのベストプラクティス

下記４点はユーザーの責任

第三者認証

AWSは、コンピュータのセキュリティに関する様々な規格や規制に準拠しているかどうかについて、第三者の監査機関による検査を受けている。そのレポートをユーザーにAWS Artifactにて提供している。AWS Artifactは、無料でセルフサービス型の、AWSコンプライアンスレポートのダウンロードサービス。ISO、PCI、SOCなどの第三者による監査レポートをダウンロードできる（図１、２）

IAM（AWS Identity and Access Management）は、ユーザーのAWSクラウドリソースへのアクセス管理サービス。IAMにより、

AWSのユーザーとグループを作成および管理し、アクセス権を使用してAWSリソースへのアクセスを許可あるいは拒否できる

 59頁

オンプレミスでは中央集権的なファイアウォールを１つ、外部ネットワークの前に設定していたのに対して、AWSでは、各インスタンス毎に個別のファイアウォール設定を行えるセキュリティグループという機能がある。同一の目的で利用するサーバー群に対して同一の設定を適用することも可能（図）

 61頁

個人情報漏洩保険

• 個人情報漏洩保険の適用範囲は、その個人情報が日本国内にあることが支払い条件となっている
• 海外リージョンの方がストレージ価格が安くても、個人情報漏洩保険を適用するためにもデータは日本国内に置くことが望ましい
• 個人情報が含まれるデータはリージョン間コピーなどを行わないように注意

 62頁

AWS Shield

AWS WAF

Webサイト上のアプリケーションに特化したファイアウォール。主に、ユーザーからの入力を受け付けたり、リクエストンに応じて動的なページを生成したりするタイプのWebサイトを不正な攻撃から守る役割をはたす。一般的なファイアウォールと異なり、データの中身をアプリケーションレベルで解析できるのが特徴

どのトラフィックをWebアプリケーションに許可、またはブロックするかのWAFの定義をユーザー自身で行う必要がある。SQLインジェクションまたはクロスサイトスクリプトのような一般的な攻撃パターンをブロックするカスタムルール、および特定のアプリケーションのために設計されるルールをAWS WAFに作成できる

Inspector

AWSのEC2上にデプロイされたアプリケーションのセキュリティとコンプライアンスを向上させるための、脆弱性診断を自動で行うことができるサービス。評価が実行された後、重大性の順に結果を表示した詳細なリストがInspectorによって作成される

AWSには現在１８０を超えるサービスがある。AWSではこれらのサービスから必要なものを選択して繋ぎ合わせることでシステムを構築する

AWSサービスのカテゴリー

AWSの各サービスは主に以下のカテゴリーに分けられる（図）

AWSサービスをどこで使うのか

AWSが提供しているグローバルインフラストラクチャは、リージョンとアベイラビリティゾーンを中心に提供されている

エッジロケーション

AWSには、リージョンとは違う場所に、全世界で現在２００か所以上のエッジロケーションがある。

EC2の概念

EC2はAmazon Elastic Compute Cloudの略で、頭文字がEと２つのCなのでEC2と呼ばれる。AWSのサービスでは「Elastic」という言葉が多く出てくる。これは「弾力性がある」「伸縮自在な」という意味

EC2の特徴

１．EC2稼働に対しての料金

OS,リージョン、インスタンスによって料金が異なる。この料金が１時間単位で課金される。Amazon Linux、Ubuntuでは１秒単位の課金。

EC2インスタンスが起動中の時間が課金対象となり、停止中は課金が停止される

２．データ転送料金

リージョンの外にデータを転送した場合に、データ転送料金が発生する。データ転送料金はリージョンによって異なる。

インターネットからAmzon EC2へのデータ転送受信（イン）には課金されない

３．ストレージ料金

厳密にはEC２の料金ではなく、EBS（Amazon Elastic Block Store。EC2 にアタッチ可能なブロックレベルのストレージサービス）の料金。

EBSに対しての課金は、１GBあたりの、プロビジョニング（図１）した料金。

１．ファミリ

EC2インスタンスを何に使用するか、用途（ユースケース）によって選択する

２．世代

バージョン。

３．サイズ

性能のレベルを表す

４．インスタンスタイプの選び方

必要としているコンピューティング処理が最も早く完了するインスタンスタイプを選択することがベストプラクティス

１．クリックスタートAMI

AWSがあらかじめ用意しているAMI。Amazon Linux、Windows、Ret hatなどのOSとモジュールがインストール済みで用意されている

２．マイAMI

お客様が作成するAMI。起動中のEC2を選択してイメージを作成する。マイAMIは他のアカウントと共有することも、公開することも可能

３．AWS Marketplace

ソフトウェアやミドルウェアがすでにインストールされている構成済みのパートナーベンダーが提供しているAMI。ソフトウェアは提供ベ

ンダーによってテスト済みの状態で提供される。ソフトウェアによっては、ライセンス料金が、EC2の従量課金に加算されるものもある

４．コミュニティAMI

一般公開されているAMI。クイックスタート、マイAMI、Marketplaceに適したAMIがない場合はコミュニティAMIから選択する

●　オンデマンドインスタンス

料金オプションを使わずにEC2インスタンスを起動すると、オンデマンドインスタンスの単価が適用される（定価料金）。秒単位、時間単位の課金により、必要なときに必要なインスタンスを起動できる。運用を開始してすぐのタイミングなど、インスタンスタイプの変更が必要な場合はオンデマンドインスタンスを使用

●　リザーブドインスタンス

１年または３年の使用期間を事前設定することで、割引を受けることができる料金。３年・全額払いが最も割引率が高い選択（図１）

●　スポットインスタンス（図２，３）

市場取引の変動のように、未使用のEC2キャパシティの量が多いときはスポット料金が下がり、少ないときは上がる。このスポットインスタンスに対して支払っても良い金額をリクエスト料金という。スポット料金がリクエスト料金を下回るとスポットインスタンスは起動し、上回るとAWSによって終了される。処理途中で終了しても問題ないユースケースに向いている

●　Dedicated Hosts

EC2 インスタンスを起動できるお客様専用の物理サーバー

●　ハードウェア専有インスタンス

アカウント専用のハードウェアでEC2を実行。Dedicated Hostsとは違いインスタンス単位で料金が発生。専有追加料金が必要

●　Savings Plans

1 年または 3 年の期間に特定の量の処理能力 (USD/時間で測定) を使用する契約を結ぶことにより、オンデマンドに比べて大幅に節約できます

EC2インスタンスの起動

ELBの概要

ELBの特徴

１．Application Load Balancer

HTTP/HTTPSのリクエストを負荷分散する用途で選択する

２．Network Load Balancer

HTTP/HTTPS以外のTCPプロトコルを使用する場合に選択する

３．Classic Load Balancer

以前のタイプのロードバランサー。以前の構成との互換性のために残されている

Auto Scalingの概念

Auto Scalingの設定

Auto Scalingを実現するためには３つの要素を設定する。「何を」「どこで」「いつ」

●　ターゲットポリシー

Auto ScalingグループのEC2インスタンス平均CPU使用率などを決めておくことで、AWSが最小数と最大数の間でEC2インスタンスを調整

最も簡単な設定方法（図３）

●　シンプルポリシー

CloudWatchのアラームに基づいて、Auto Scalingアクションを実行する。「その後待機」はクールダウンと呼ばれる機能（図４）

●　ステップポリシー

複数段階でのインスタンスの追加、削除を設定できる（図５）

アプリケーションデプロイの自動化

４．ロードバランサーの種類にApplication Load Balancerを選択（図２）

５．ステップ１：ロードバランサーの設定（図３）

1. ロードバランサーの名前を入力（ロードバランサーのDNS名に反映される）
2. スキームに[インターネット向け] を選択
3. リスナーに[HTTP] を選択
4. アベイラビリティゾーンは２箇所配置
5. VPCは試すだけであればデフォルトのまま

・ロードバランサー名「DemoELB」

・ステップ１：ロードバランサーの設定ではAZを２箇所選択

　subnet-46a8b21d - ap-northeast-1c 

　subnet-5fdf7417 - ap-northeast-1a

６．ステップ２：セキュリティ設定の構成では、SSLの証明書の設定を行う（今回は検証なのでこの設定は行わない）（図４）

７．ステップ３：セキュリティグループの設定では、既存のセキュリティグループを選択する（図５）

・「新しいセキュリティグループを作成する」を選択して以下を作成。セキュリティグループ「load-balancer-wizard-1」

------------------------------------------------------------------------------------------------

[タイプ]     [プロトコル]     [ポート範囲]     [ソース]

HTTP          TCP　　　　　80　　　　　　カスタム、0.0.0.0/0, ::/0　　

SSH            TCP　　 　   　22　　　　　　カスタム、0.0.0.0/0

８．ステップ４：ルーティングの設定（図６）

1. ターゲットグループを新たに設定する。名前は[DemoTargetGroup] 、プロトコルは[HTTP]、ポートは[８０]
2. ヘルスチェックは、プロトコルは[HTTP]、パスはデフォルトのまま、間隔は[10秒]

９．ステップ５：ターゲットの登録。設定の確認画面で問題なければそのまま作成する（図７）

１．EC２ダッシュボードで左ペインから起動設定を選択し、[起動設定の作成] をクリック（図８）

・起動設定名「DemoAutoScaling」

４．詳細設定（図１１）

1. 起動設定の名前を入力する
2. Auto Scalingで起動されたEC2インスタンスで、Webアプリケーションを自動デプロイするために、ユーザーデータを設定する

・▶高度な詳細 ＞ ユーザーデータ で「テキストで」を選択して以下を記載

#!/bin/bash -ex
yum -y update
yum -y install httpd
systemctl start httpd.service
systemctl enable httpd.service
AZ=`curl --silent http://169.254.169.254/latest/meta-data/placement/availability-zone`
INSTANCE_ID=`curl --silent http://169.254.169.254/latest/meta-data/instance-id`
IP_ADDRESS=`curl --silent http://169.254.169.254/latest/meta-data/public-ipv4`
echo $AZ >> /var/www/html/index.html
echo $INSTANCE_ID >> /var/www/html/index.html
echo $IP_ADDRESS >> /var/www/html/index.html

５．ストレージの追加 ー デフォルトの８GBのままで設定（図１２）

６．セキュリティグループの設定（図１3、１４）

1. Application Load Balancerから80番ポートでアクセスできるように設定された、既存のセキュリティを選択する
   ・ELBで新規に作成したセキュリティグループ「load-balancer-wizard-1」を選択
2. キーペアを選択。新たなキーペアを作成してもよい
   ・キーペア (ログイン) は既存のキーペア（aws_user）を選択

７．[この起動設定を使用してAuto Scalingグループを作成] ボタンをクリック（図１５）

・参考書の「この起動設定を使用してAuto Scalingグループを作成する」ボタンは無かったので、「起動設定の作成」ボタンを押下

８．引き続きAuto Scalingグループを作成

・起動設定一覧で作成した起動設定を選択し「アクション▼」から「 Auto Scalingグループの作成」を選択。遷移先画面では起動設定

に作成した起動設定名が指定されていた。

１．Auto Scalingグループの詳細設定

1. Auto Scalingグループの名前を入力する（図１６）
   ・Auto Scalingグループ「DemoAutoScalingGroup」
2. 開始時のインスタンス数を設定する
   ・インスタンス数の入力項目は無かった
3. ネットワークを設定する。デフォルトのVPCとサブネットを選択。ただしApplication Load Balancerと同じVPCにする必要がある
   ・VPCはELBで設定時と同じVPCがデフォルト表示されていたが、サブネットは未選択だった。ELBで選択したAZ２件を選択
4. 画面下部の[高度な詳細] でApplication Load Balancerのターゲットグループを設定。（図１７）
   これでApplication Load BalancerのターゲットとしてAuto Scalingグループ内のEC2インスタンスが登録された
   ・詳細オプションでは、「既存のロードバランサーにアタッチ」を選択して、ELBで登録したターゲットグループ名「DemoTargetGroup」をアタッチする
5. ヘルスチェックのタイプはEC2を選択。EC2のステータスが正常かどうかヘルスチェックを行う
   ヘルスチェックをELBとすれば、ELBのヘルスチェックに失敗したときに、Auto ScalingからEC2インスタンスをデタッチさせて終了させる

２．スケーリングポリシーの設定（スケールアウト）

1. アラームの設定。Auto ScalingのEC2インスタンス平均CPU使用率60%以上を閾値としてアラームを設定（図１８）
   この設定はAuto Scalingグループの一連の設定の中で行うが、アラームはCloudWatchに作成される
2. スケールアウトするアクションでは、２段階の追加アクションを設定（図１９）
   Auto ScalingのEC2インスタンス平均CPU使用率60%から80%の間で1インスタンスの追加、80%以上で2インスタンスの追加で設定

・参考には「スケーリングポリシーの設定」とあったが「グループサイズとスケーリングポリシーを設定する」に変更されている。

とりあえず「希望する容量＝２、最小キャパシティ＝２、最大キャパシティ＝４」で設定。EC2インスタンスは２台生成された。

・スケーリングポリシー - 省略可能では、メトリクスタイプ：平均CPU使用率、ターゲット値：60、ウォームアップする秒数：60、

「スケールインを無効にしてスケールアウトポリシーのみを作成する」をOFFのままに設定

・インスタンスのスケールイン保護 - 省略可能では、「インスタンスのスケールイン保護を有効にする」をOFFのままにした

３．スケーリングポリシーの設定（スケールイン）

1. アラームの設定。Auto ScalingのEC2インスタンス平均CPU使用率40%以下を閾値としてアラームを設定（図２０）
2. スケールインするアクションでも、２段階の削除アクションを設定（図２１）
   Auto ScalingのEC2インスタンス平均CPU使用率20%から40%の間で1インスタンスの削除、20%以下で2インスタンスの削除で設定

・スケールインの詳細設定欄は見つからなかった

４．通知の設定。Auto Scalingアクション実行時、通知することが可能。（図２２）

５．タグの設定（図２３）

1. Auto Scalingグループそのものと、Auto Scalingによって起動したEC2インスタンスにタグを付けることができる
2. EC2ダッシュボードで見分けがつきやすいように、「Name」キーに「DemoASG」と設定

６．確認。設定を確認して作成する（図２４）

ステップスケーリングの追加

【Auto Scaling グループの作成】※ここまでの手順と違うところを以下に明記

　・グループサイズは全て[1]のままにする

　・スケーリングポリシー - 省略可能で「なし」を設定

　・タグで「Name」キーに「Demo ASG Step」と設定

【CloudWatchアラートの作成】

　1. CloudWatchで[アラームの作成]をクリック

　2. [メトリクスの選択]をクリック

　3. 名前空間から[EC2] ＞ [Auto Scaling グループ別] をクリック

　4. 標準メトリクスから[CPUUtilization]にチェックをいれ[メトリクスの選択]をクリック

　5. メトリクス欄で以下を設定

　・メトリクス名：CPUUtilization

　・AutoScalingGroupName：DemoAutoScalingGroup

　・統計：平均値

　・期間：1分

　6. 条件欄で以下を設定

　・しきい値の種類：静的

　・CPUUtilization が次の時...：より大きい

　・... よりも：60

　・▶その他の設定 ＞ アラームを実行するデータポイント：2/3

　・▶その他の設定 ＞ 欠落データの処理：欠損データを見つかりませんとして処理

　7. [次へ]をクリック

　8. 通知欄でで以下を設定

　・アラーム状態トリガー：アラーム状態

　・SNSトピックの選択：既存の SNS トピックを選択

　・通知の送信先：Default_CloudWatch_Alarms_Topic

　9. [次へ]をクリック

　10. 名前と説明を追加欄で以下を設定

　・アラーム名「Demo Auto Scaling Alert」

　・アラームの説明 - オプション：未入力

　11. [次へ]をクリック

　12. [アラームの作成]をクリック

【ポリシーを追加】

　1. Auto Scaling グループ一覧から選択して自動スケーリングタブで「ポリシーを追加」ボタンを押下

　2. スケーリングポリシーを作成欄で以下を設定

　・ポリシータイプ：ステップスケーリング

　・スケーリングポリシー名「Increase Group Size」

　・CloudWatchアラート：先に作成したアラート「Demo Auto Scaling Alert」を選択

　・アクションを実行で以下の様に設定

　[1] 次のとき:[60] <= CPUUtilization < [80]

　[2] 次のとき: [80] <= CPUUtilization < +無限大

　メトリクスに含める前にウォームアップする秒数：[10]

　3. [作成]をクリック

　4. 作成されたポリシーには以下のように表示される

　ポリシータイプ:ステップスケーリング

　アラームのしきい値を超過:次のメトリクスディメンションに対して 60 秒間の 3 連続期間で CPUUtilization > 60

　アクションを実行:

　60 <= CPUUtilization < 80 のときの 1 キャパシティユニットの 追加

　80 <= CPUUtilization < +無限大 のときの 2 キャパシティユニットの 追加

　インスタンスには以下のものが必要です:各ステップの後に 10 秒 秒間ウォームアップする

EC2インスタンスの一覧を見ると、DemoASGのタグが付いたEC2インスタンスが２つのアベイラビリティゾーンで１つずつ起動していることが確認できる（図２５）

EC2インスタンスの一覧を見ると、DemoASGのタグが付いたEC2インスタンスが２つのアベイラビリティゾーンで１つずつ起動していることが確認できた

ELBのターゲットグループを見ると、２つのインスタンスが「healthy」ステータスになっていることが確認できる（図２６）

ELBのターゲットグループのターゲットタブを見ると、２つのインスタンスが「healthy」で有ることが確認できた

Auto Scalingグループを見ると、インスタンス数が「２」になっている。そしてターゲットグループ同様に２つのインスタンスが「healthy」ヘルスステータスになっていることが確認できる（図２７）

Auto Scalingグループを見ると、インスタンス数が「２」で、インスタンス管理タブのインスタンス一覧はヘルスステータスが「healthy」だった

ELBのDNS名をコピーしてブラウザのURLに入力してアクセスしてみる（図２８）

ELBのDNS名をコピーしてブラウザからアクセスできた

EC2インスタンスにアクセスでき、アベイラビリティゾーン、インスタンスID、バプリックIPアドレスが表示される（「起動設定の作成－４．詳細設定－ユーザーデータの設定」によるもの）（図２９）

ブラウザに”ap-northeast-1a i-08b8fecea79f2cc05 18.179.14.136”と表示された”と表示された

ブラウザ画面を更新すると、もう１つのインスタンスにリクエストが送信されて、アベイラビリティゾーン、インスタンスID、バプリックIPアドレスがかわったことが確認できる。つまり、負荷分散がされているということ（図３０）

ブラウザ画面を更新すると、もう１つのインスタンスにリクエストが送信され、"ap-northeast-1c i-0eb46bf556993a49f 54.249.12.198"と表示された

CloudWatchのアラームを見てみると、２つのアラームが作成されいることが確認できる

CPU使用率40%以下のアラームが「アラーム」の状態になっている（図３１）

CloudWatchの左側で「アラート」をクリック。２つのアラームが作成されいることが確認できた

Auto Scalingで起動している２つのEC2インスタンスそれぞれにSSHでログインし、「$ yes > /dev/null」コマンドで負荷をかける。

CloudWatchのメトリクスを見ると、CPU使用率が上がっていくことが確認できる（図３２）

「$ yes > /dev/null」実行。CloudWatchの左側で「メトリックス」を選択。「すべてのメトリックス」タブで「EC2　＞　Auto Scaling グループ別　＞　cpuutilization」の順に選択してCPU使用率のグラフを確認

CloudWatchのアラームを見ると、CPU使用率60%以上のアラームが「アラーム」の状態になる（図３３）

CloudWatchの左側で「アラート」では以下の状態だった

・3 分内の3データポイントのCPUUtilization > 60　　：アラーム状態

・15 分内の15データポイントのCPUUtilization < 45　：OK

Auto Scalingグループを見ると、「希望するインスタンス数」と「インスタンス数」が「３」になっている（図３４）

しばらく経過してAuto Scalingグループを見ると、「希望する容量」と「インスタンス」が「４」になった

実際に起動しているインスタンスも「３」になっている（図３５）

実際に起動しているインスタンスも「４」になった

このままにしていると平均CPU使用率が80%を超える（図３６）

参考書のように２段階設定（ Warning、Critical）ができなくなっている

 さらに２インスタンス追加のオートスケールアクションが実行されて、EC2インスタンスは「５」になる（図３７）

スキップした

プロセスをkillすると平均CPU使用率がさがる（図３８）

プロセスをkillすると平均CPU使用率がさがった

スケールインアクションによりEC2インスタンスが削除されたことを確認（図３９）

しばらく経過してスケールアウトした２台のEC2インスタンスがスケールインされたことを確認

Lambdaの特徴

（Ａ）1 か月のコンピューティング料金

１．実行時間を秒に換算

　合計コンピューティング (秒) = 3,000,000回 × 1 秒/1回の処理時間 = 3,000,000 秒

２．メモリ使用量をGBに換算

　合計コンピューティング (GB-秒) = 3,000,000秒 × 512 MB ÷ 1024 = 1,500,000 GB-秒

３．無料枠を減算した使用量

　1,500,000 GB-秒 – 400,000 GB-秒の無料利用枠 = 1,100,000 GB-秒

４．1 か月のコンピューティング料金

　 1 か月のコンピューティング料金 = 1,100,000 × 0.00001667 USD = 18.34 USD

（Ｂ）1 か月のリクエスト料金

１．無料枠を減算した請求リクエスト数

　3,000,000 件のリクエスト – 1,000,000 件の利用無料枠のリクエスト = 2,000,000 件の請求リクエスト

２．100 万件あたりの1 か月のリクエスト料金

　1 か月のリクエスト料金 = 2,000,000 × 0.2 USD ÷ 1,000,000 = 0.40 USD

（Ｃ）合計月額料金

合計料金 = コンピューティング料金 ＋ リクエスト料金 = 18.34 USD ＋ 0.40 USD = 18.74 USD/月

EBSは、Amazon Elastic Block Storeの略。EC2インスタンスにアタッチして使用するブロックストレージボリューム。次の特徴がある

• EC2インスタンスのボリュームとして使用
• アベイラビリティゾーン内でレプリケート
• ボリュームタイプの変更が可能
• 容量の変更が可能
• 高い耐久性のスナップショット
• ボリュームの暗号化
• 永続的ストレージ

EC2インスタンスのボリュームとして使用

アベイラビリティゾーン内でレプリケート

ボリュームタイプの変更が可能

容量の変更が可能

EBSは、確保しているストレージ容量に対して課金が発生する。ストレージ容量は使用を開始した後にもオンライで増やすことができる

高い耐久性のスナップショット

EBSは同じアベイラビリティゾーン内の複数サーバー間で自動的にレプリケートされるが、そのアベイラビリティゾーンが使えなくなったとき、EBSも使えなくなる。EBSのスナップショットを作成すると、S3の機能を使ってスナップショットが保存される。
　S3は複数のアベイラビリティゾーンの複数の施設に自動的に冗長化される。耐久性はイレブンナイン（9.999999999%）で、EBSのスナップショットもイレブンナインの耐久性ということ

ボリュームの暗号化

EBSの暗号化を有効にすればボリュームが暗号化される。ボリュームを暗号化すると、そのボリュームから作成されたスナップショットも暗号化される。EC2インスタンスからデータの暗号化／復号化は透過的に行われるので、プログラムやユーザーから追加の操作を行う必要はない

永続的ストレージ

 EBSはインスタンスのホストとは異なるハードウェアで管理されているので、インスタンスを一旦停止して再開したときも、EBSに保存されたデータは残っている。

Amazon Simple Storage Serviceの略。Sが３つ並ぶのでS3.インターネット対応の完全マネージド型のオブジェクトストレージ

S3の特徴

S3のセキュリティ

・他の特定のAWSアカウントにオブジェクトの [ 一覧を許可｜書き込みを許可｜読み込みを許可 ]できる

・誰にでもオブジェクトの [ 一覧を許可｜書き込みを許可｜読み込みを許可 ]できる

・アクセスコントロールリストはバケットに対しても個別のオブジェクに対しても設定できる

・次のコードは、AWS CLI コマンドでアップロードして読み取り許可を設定する例
　aws s3 cp sample.mp3 s3://bucket/sample.mp3 --recursive --acl public-read --region ap-northeast-1

・アクセスコントロールリストのバケット単位、オブジェクト単位より、より細かい設定が可能

・特定のIPアドレスからの、tmp/以下のオブジェクトに読み取りアクセスのみ許可や

・誰からでもバケット全体へアクセスできるように設定することも可能

・IAMユーザーに対してアクセス権を設定できる

・AWSサービスにS3へのアクセス権を設定する際にもIAMポリシーが使える

・IAMポリシーをアタッチしたIAMロールを作成し、そのロールをEC2インスタンスに設定することで、そこで動作するプログラムに対してS3へのアクセス許可を与えられる

S3にはhttp/httpsでアクセスすることが可能。仮想ホスト形式ではリージョンを省略することができる
・仮想ホスト形式
http://bucket.s3.amazon.com ／ https://bucket.s3.amazon.com

・パス形式

http://s3-ap-northeast-1.amazonaws.com/bucket ／ https://s3-ap-northeast-1.amazonaws.com/bucket

S3に保存するデータの暗号化方法には、次の３種類がある
・S3のキーを使用したサーバーサイト暗号化

・KMS（AWS上で暗号化のためのキーを作成・管理し、暗号化を制御）を使用したサーバーサイド、またはクライアントサイド暗号化

・お客様独自のキーを使用したサーバーサイド、またはクライアントサイド暗号化

S3の料金

S3の料金は主に次の３要素

ストレージクラスを指定しない場合のデフォルトのストレージクラス

アクセス頻度の少ないオブジェクトを格納することで、S3のトータルコストを下げることができる

東京リージョンの料金は0.019USD/GB。ストレージ料金は標準ストレージよりも安価だが、リクエスト料金が標準ストレージよりも上がる

アクセスする頻度が少なく、複数のアベイラビリティゾーンに冗長化される可用性を必要としないオブジェクトを保存する場合に使用

アクセスすることはほとんどなくても削除はできないデータ

オブジェクトにアクセスするときは数時間かかる取り出し作業が必要

S3のユースケー

• アプリケーションのデータ保存
• HTML、CSS、JavaScript、画像、動画ファイルなどの静的コンテンツも配信
• データバックアップの保存
• ログデータ、センサーデータなどの保存
• ビックデータのステージング（Redshift、Athena、EMR）
• クロスリージョンレプリケーションによるDR対策

使用容量分に課金される

VPCの概要

 VPCはAmazon Virtual Private Cloudの略。AWSクラウド内にプライベートなネットワーク環境を構築することができる。お客様は標準的なネットワーク構成項目を設定でき、ネットワーク構成やトラフィックを完全にコントロールすることができる。AWSのサービスの中にはVPC内で利用するものとVPC外で利用するものがある。以下は主な機能要素

• VPC
• サブネット
• インターネットゲートウェイ
• ルートテーブル
• セキュリティグループ
• ネットワークACL
• NATゲートウェイ（NATインスタンス）

VPCの作成

 VPCは、リージョンを選択して複数のアベイラビリティゾーンをまたがって作成する。VPCを作成するときIPアドレスの範囲をCIDRで定義する

サブネット

VPCで設定したアドレス範囲をサブネットに分けて定義する。サブネットを作成するときにアベイラビリティゾーンとIPアドレス範囲を定義する。同一VPC内の他のサブネットと重複はできない。サブネットの最初の４つと最後の１つはAWSで予約されていて使えない

• xxx.xxx.xxx.0:　　ネットワークアドレス
• xxx.xxx.xxx.1:　　VPCルータ用
• xxx.xxx.xxx.2:　　AWSで予約
• xxx.xxx.xxx.3:　　将来の利用のためにAWSで予約
• xxx.xxx.xxx.255:　ネットワークブロードキャストアドレス

インターネットゲートウェイ

VPCとパブリックインターネットを接続するためのゲートウェイ。VPCにつき１つのみ作成できる。インターネットゲートウェイ自体が水平スケーリングによる冗長性と高い可用性を持っているため単一障害点にはならない

ルートテーブル

サブネットの経路をルートテーブルで設定する。ルートテーブルはVPCを選択して作成する。続いてエントリを設定してサブネットに関連づける

パブリックサブネットとプライベートサブネット

特別な要件がない最小構成は各アベイラビリティゾーンに２つの役割でサブネットを分割。その２つの役割は、インターネットに対して直接ルートを持つパブリックサブネットと、ルートを持たないプライベートサブネット

●　パブリックサブネット
　・インターネットゲートウェイに対してのルートを持つルートテーブルに関連付けられている

　・パブリックサブネット内のインスタンスなどのリソースは、外部との直接通信ができる

●　プライベートサブネット

　・インターネットゲートウェイに対してのルートを持たないルートテーブルに関連付けられている

　・プライベートサブネット内のインスタンスは外部アクセスから保護できる

　・各サブネットの間にローカル接続のルートがあるので、プライベートサブネット内のリソースはサブネット内のリソースと通知できる

セキュリティグループ

１つのセキュリティグループを複数のインスタンスに設定することができる。セキュリティグループの送信元はCIDRでIPアドレス範囲を指定するか、他のセキュリティグループのIDを指定することができる。セキュリティグループはVPCを指定して作成する。デフォルトではインバウンド（受信）へのアクセスがすべて拒否されているので、許可（ホワイトリスト）するものだけを設定する

ネットワークACL

ネットワークACL（アクセスコントロールリスト）はサブネットに対して設定する仮想ファイアウォール機能。サブネット内のすべてのリソースに対してのトラフィックに影響がある。デフォルトですべてのインバウンドとアウトバウンドが許可されているので、拒否（ブラックリスト）の設定を行う

構成例：基本構成でWebサーバーを起動

ここではVPCを作ってパブリックサブネット内でEC2サーバーを起動して、インターネット経由でブラウザからアクセスしてみる。

最小の推奨構成例として、２つのアベイラビリティゾーン上にパブリックサブネットを１つづつ、プライベートサブネットを１つ

づつ作成する（図１）

ハイブリッド環境構成

既存のオンプレミス環境の拡張先としてAWSを使うことができる。オンプレミスとクラウドの両方を活用する構成をハイブリッド環境構成という

Amazon CloudFrontはエッジロケーションを使い、最も低いレイテンシー（遅延度）のコンテンツ配信ネットワークサービス

CloudFrontの特徴

Amazon Route 53はエッジロケーションで利用されるDNSサービス。一般的なDNSサービス同様に、ドメインに対してのIPアドレスをマッピングしてユーザーからの問い合わせに回答する

Route 53 の主な特徴

・シンプルルーティング

 問い合わせに対して、単一のIPアドレス情報を回答

・レイテンシーベースのルーティング／Geo DNS

１つのドメインに対して複数のDNSレコードを用意しておき、地理的な場所を近くしてレイテンシー（遅延度）が低くなるようにルーティングを行う 

・加重ラウンドロビン

１つのドメインに対して複数のDNSレコードを用意しておき、割合を決める。その割合に応じて回答する

・複数地回答

複数のレコードからランダムに回答する

RDSの概要

RDSはAmazon Relational Database Service の略。使用できるデータベースエンジンは次の６つ

• Amazon Aurora
• MySQL
• PostgreSQL
• MariaDB
• Oracle
• Microsoft SQL Server

RDSとEC2の違い

EC2で起動したサーバーにデータベースエンジンをインストールするより、RDSでデータベースエンジンを使用することで、次の３つの管理タスクから解放され開発に注力できるようになる

• メンテナンス
• バックアップ
• 高可用性

Amazon Auroraの概要

MySQL、PostgreSQLのインターフェース機能を持っており、MySQL、PostgreSQLを使用しているアプリケーションはAuroraをそのまま使用できる可能性が高い。Auroraの利用する主なメリットは次のとおり

• バックアップが非常に強固
• スタンバイにアクセスできる（リードレプリカがマスター昇格する）
• リードレプリカは15個作成できる
• RDS MySQLに比べて5倍の性能
• ディスク容量を見込んで確保しなくても自動で増加する

DMS

AWS Database Migration Service の略。オンプレミスの従来のデータベースからRDSにデータを継続的に移行できる。移行時のシステムダウンタイムも最小限に抑えられ、異なったデータベースエンジンでも移行が可能

Amazon DynamoDB はNoSQL型の高いパフォーマンスを持ったフルマネージド型のデータベースサービス。フルマネージド型とは

• データベースサーバーのOSも、データベースエンジンも、テーブルの破損なども、気にしなくてよい
• DynamoDBを使用するときはテーブルの作成から始める
• データベースサーバーとしてインスタンスを作成する必要がない
• 最低限の設定では、テーブル名とプライマリキーを決めれば使い始められる
• DynamoDBを使用するときはリージョンを選択する
• DynamoDBにテーブルを作って、そこにアイテムと呼ばれるデータを保存すると、自動的に複数のアベイラビリティゾーンの複数の施設で同期され保存される
• データ容量は無制限で、使用している容量のみが課金対象となる
• 性能はお客様が決めることができる
• 書き込みと読み込みのキャパシティユニットを設定する。キャパシティユニットはオートスケールさせることもできる

DynamoDBとRDSの違い

・RDSはリレーショナルデータベース

・トランザクションをコミットにより確定できるので、厳密な確定処理をすることにむいている

・大量のデータ更新や読み込みを必要とする処理に向いてない

・垂直スケーリングができる（１つのインスタンスで処理を行う）

・データはSQL型のテーブル形式（図１）

・DynamoDBは非リレーショナルデータベースやNoSQLと言われている

・厳密なトランザクションを必要とする処理や、複雑なクエリには向かない

・大量のアクセスがあってもパフォーマンスを保ったまま処理ができる

・水平スケーリングができる

・NoSQL型のテーブル形式。１つのデータはアイテム（項目）として扱う。キーとして設定している属性と値さえあれば、

　それ以外の属性は動的で自由（図２）

・Amazon Redshift

高速でシンプルなデータウェアハウスサービス。データ分析に使用。大規模なデータ分析にも対応

・Amazon ElastiCache

インメモリデータストアサービス。RDSやDynamoDBのクエリ結果のキャッシュや、アプリケーションのセッション情報を管理する用途に使用

・Amazon Neptune

フルマネージドなグラフデータベースサービス。SNS、レコメンデーション(提案)エンジン、経路案内、物流最適化などのアプリケーション機能に使用

各インスタンスの現在の状態、情報をモニタリングするサービス。CloudWatchは標準メトリクスという、AWSが管理している範囲の情報を、お客様側での追加の設定なしで収集している。メトリクスデータはダッシュボードで可視化でき、アラーム設定することもできる

CloudWatchの特徴

・EC2の回復

EC2のホストに障害が発生したときに自動で回復させる

・Auto Scalingの実行

Auto Scalingポリシーでは、CloudWatchアラートに基づいて、スケールイン／スケールアウトのアクションを実行する

・SNSへの通知

Amazon Simple Notification Service によりSNSへ通知することができる 

保存期間について

・60秒未満のデータポイントは３時間

・1分（詳細モニタリング）のデータポイントは15日間

・5分（標準）のデータポイントは63日間

・1時間のデータポイントは455日間

・任意の保存期間を設定できる。消去しないことも可能

Trushed Advisor は、お客様のAWSアカウント環境の状態を自動的にチェックして回り、ベストプラクティスに対してどうであったかを示すアドバイスをレポートする。チェックする視点は次の5つ

• コスト最適化
• パフォーマンス
• セキュリティ
• フォールトトレランス（耐障害性）
• サービス制限

コスト最適化

ここを見直せばコストを最適化できる、という視点でチェックしたアドバイスがレポートされる。コスト最適化では、具体的にどれくらい月額コストが下がるかという金額も計算されて提示される

パフォーマンス

システムのパフォーマンスを低下させる原因となる設定や選択がされていないかチェックする

EC2に実装している処理に対してリソースが不足している可能性がある場合、対象の処理が最も早く完了するインスタンスタイプに変更することが推奨される

セキュリティグループのルールが多いとそれだけネットワークトラフィックが制御されることになる。ルールをまとめることができないか、対象のインスタンスにそれだけのポートを必要とする機能を多くインストールしてないか、インスタンスを分けることはできないかを検討する

CloudFrontにキャッシュを持つことで、S3から直接配信するよりもパフォーマンスが向上する

セキュリティ

セキュリティリスクのある環境になっていないかをチェックする

誰でもアクセスできるS3パケットがないかチェックする

リスクの高い特定のポートが、送信元無制限でアクセス許可されているセキュリティグループをピックアップする。悪意あるアクセスによって攻撃され、データが漏洩する可能性がある

EBSやRDSのスナップショットは必要なアカウント間のみで共有するようにする

運用するための最低権限を設定したIAMユーザーを作成して、ルーアカウントにもIAMユーザーにもMFAを設定する

フォールトトレランス（耐障害性）

耐障害性がないかチェックする。耐障害性を高めるためのアドバイスを提供

EBSのスナップショットが作成されていない、または最後に作成されてから時間が経過したことがチェックされる

複数のアベイラビリティゾーンでバランス良く配置されているかがチェックされる。ELBではクロスゾーン負荷分散やConnection Draining（セッション完了を待ってから切り離す機能）が無効になっているロードバランサーがないかもチェックされる

マルチAZになっていないデータベースインスタンスがチェックされる

サービス制限

AWSアカウントを作った最初の時点では以下の理由でソフトリミット（いくつかのサービス制限された状態）されている。

緩和申請によって制限を超えることができるサービスもある

• 誤った操作による意図しない請求を回避する
• 不正アクセスによる意図しない請求を回避する

下図は東京リージョンでは、EC2オンデマンドインスタンスの制限が20になっていて、今現在は１インスタンスしか起動していないので問題ないというレポート（図１）サービス制限を上回りそうな予定がある場合は、事前にAWSへ申請を行う（図２）

CloudTrail

AWS CloudTrail では、AWSアカウント内のすべてのAPI呼び出しを記録され、監視や調査に使用される。CloudTrail と似たサービスに、

AWS Config がある。AWS Config はAWSリソースの変更を記録する。誰がいつ何を変更したかが自動で記録される

CloudFormation

AWS CloudFormation は、AWSの各リソースを含めた環境を自動作成／更新／管理する

• JSON形式またはYAML形式で記述されたテンプレートから、Stackというリソースの集合体を作成
• CloudFomation を使用することで、同一のAWS環境を何度でも自動で構築できる
• CloudFomation では、自動的なプロビジョニング（構築して準備）をコードをお用いて行える
• コードはAWS CodeCommitなどのリポジトリでバージョン管理できる

Elastic Beanstalk

AWS Elastic Beanstalk では、Webアプリケーションの構築を簡単にAWSに構築する

• CloudFomationと違ってテンプレートを作成する必要がない
• 設定パラメータを提供することで、ApacheやNginx、IIS、各言語の実行環境もあわせて簡単に構築できる
• AWSのすべてのサービスを網羅しているわけではない
• アプリケーションの継続デプロイのための高性能な機能を有している

使った分だけの従量課金

必要なときに必要なリソースを使って、使った分にだけ費用が発生する。資本の支出を変動費にすることができる。この消費モデルを組織全体で受け入れることにより、コスト最適化が進む

課金体系

サービスによって用途が違うので、課金方式も違う。同じサービスでもリージョンによって料金が異なることもある

多彩な料金モデル

要件に応じて最適な料金モデルを選択することでコストを最適にできる

• EC2の購入オプション
• S3ストレージクラス
• EBSボリュームタイプ

請求書

どのサービスでどれくらいコストが発生しているかは、請求書で確認できる。請求書は月の途中でも確認できる（図１）

各サービスを展開すると、さらに詳細な情報を確認できる。以下はEC2の東京リージョンの料金$10.44の内訳（図２）

• 東京リージョンでt2.microのLinuxを0.608時間使っている（$0.01）
• t2.microのLinuxのリザーブドインスタンスを前払いなしで672時間分使っている（$8.33）
• EBSのスナップショットと使っているボリュームに対しての課金も発生している（$2.10）

コストエクスプローラーとコスト配分タグ

AWSの各サービスの中には、タグ（キーと値の組み合わせ）を付けることができるサービスがあり、このタグをコスト分析のために有効化したのがコスト配分タグ。このコスト配分タグで分けた結果はコストエクスプローラーで可視化したり、CSV形式でダウンロードしたりできる

請求アラーム

請求金額もCloudWatchメトリクスの１つ。そのためアラートを設定してアクションを実行することができる

設定予算を超えると予測されたときアラームを発信する、AWS Budgets というサービスもある

コストと使用状況レポート

コストと使用状況レポートを設定すると、アカウントとそのIAMユーザーが使用した各サービスカテゴリのAWS使用状況が、時間単位または日単位の明細項目として記録できる。また、使用状況のデータを日単位または時間単位で集計することも可能

AWS Organizations

AWS Organizations を使うと、複数アカウントを一括管理できる

一括請求（コンソリデーティッドビリング）

Organizations の一括請求を使用すことで、複数アカウントの請求を１つの請求にまとめることができる。請求書はアカウントごとに確認できる

AWSアカウントには４つのサポートプランがある。お客様は適切なサポートプランを選択することで、運用の安全性を保ち、エスカレーションパス（問い合わせ先）を確保できる

・AWSアカウントを作ったときに提供される無料サポートプラン

・技術サポートは、AWSサービスの稼働状況をモニタリングしているヘルスチェックについてのサポートのみ

・Trusted Advisor は最低限必要な項目のみ

・29USDか使用料の3%の大きいほう

・技術サポートを作成できるユーザーは１ユーザー（9:00～18:00）

・構成要素についてのアーキテクチャサポート

・Trusted Advisor は最低限必要な項目のみ

・100USDか使用料に応じた計算式の大きいほう

・技術サポートを作成できるユーザーは無制限（24時間）

・アーキテクチャはユースケースのガイダンス

・Trusted Advisor は全項目

・サポートAPIの使用可

・サードパーティソフトウェアのサポート

・15,000USDか使用料に応じた計算式の大きいほう

・技術サポートを作成できるユーザーは無制限（24時間）

・アプリケーションのアーキテクチャサポート

・Trusted Advisor は全項目

・サポートAPIの使用可

・サードパーティソフトウェアのサポート

・テクニカルアカウントマネージャー（TAM）

・サポートコンシェルジュ

・ホワイトグローブケースルーティング

・管理ビジネス評価

AWS簡易見積もりツール

月の請求金額見込みがどれくらいになるかを事前に計算しておくことができる。AWS料金計算ツールが発表されたため、当サービスは終了予定

TCO計算ツール

AWSへの移行、導入を検討している際に、オンプレミスで構築した場合とのコスト比較をレポートしてくれるツール

機械などの構成部分や組み合わせの単位を指す。IT用語としては何らかの機能を持ったプログラム部品のことをいう

ノード

レプリケーション

（レプリケート）

80

(166)

アカウント作成（ルートアカウント）

◯手順参考先

サイト － AWSを無料で利用する方法を実際にやってみて注意点まとめてみた。リンク　＞　AWS アカウント作成の流れ

◯ハマった事

特になし

◯メモ

フルネームは本名をローマ字で入力。住所は英語表記で記入する。

◯参考書

３-２　AWSクラウドのセキュリティ（49頁）　＞　管理プレートの保護　 

EC2インスタンス生成

◯手順参考先

サイト － AWSを無料で利用する方法を実際にやってみて注意点まとめてみた。リンク　＞　＞　EC2でサーバーを作る

◯ハマった事

EC2インスタンスにPuttyからログインする際、

・IPにはパブリックIPを指定する

・秘密鍵にはPEMファイルから変換したPPKファイルを指定する。変換はPuTTYgenツールで可能

・アカウトは固定

◯メモ

・Puttyセッション一覧：aws_user_name

・ストレージ確認（ルートデバイス：/dev/xvda）

$ df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/xvda1      8.0G  1.5G  6.6G  19% /

◯参考書

５-１　EC2　＞　EC2インスタンスの起動（109頁）

請求アラート設定

◯手順参考先

サイト － AWSを無料で利用する方法を実際にやってみて注意点まとめてみた。リンク　＞　＞　【請求アラート設定】

◯ハマった事

特になし

◯メモ

アカウント名をクリック　＞　マイ請求ダッシュボード　＞　左下の「請求書」　＞　右端の「＋すべて展開」をクリックすることで、

詳細な情報（使用時間、使用容量、金額など）を確認できる

◯参考書

１０-２　請求ダッシュボード　＞　請求アラーム（274頁）

AWS Budgets

◯手順参考先

YouTube － AWS Budgetsで予算を管理しよう - serverworks（ 5:54）　リンク

◯ハマった事

アラート枠が表示されなかった・・

◯メモ

予算額の80％を超えたらアラートメールを送信してくれる。全体のほかサービス単位でも登録可能。登録は２件まで無料。

◯参考書

１０-１　AWS料金モデル　＞　請求アラーム（274頁）

アラームの作成（CloudWatch）

◯手順参考先

サイト － AWSを無料で利用する方法を実際にやってみて注意点まとめてみた。リンク　＞　アラームの作成

◯ハマった事

「概算合計請求額」クリック後の一覧には明細がなぜか表示されないので、「全てチェックボックス」をオンして「メトリクスの選択」をクリックする

遷移先のメトリクス名には「EstimatedCharges」と表示されていて、当サイトの内容と一致した

◯メモ

リージョンを「US East (バージニア北部)」にする必要がある

設定金額は100以上にした

◯参考書

９-１　CloudWatch　＞　CloudWatchの特徴（246頁）　＞　SNSへの通知

１０-１　AWS料金モデル　＞　請求アラーム（274頁）

◯その他

YouTube － 【AWS Black Belt Online Seminar】Amazon CloudWatch（47:14）リンク

アカウントを解約　　※最後にやる

◯手順参考先

AWS アカウントを解約するにはどうすればよいですか?

◯ハマった事

◯メモ

◯参考書

Auto Scaling

◯手順参考先

ELBとAuto Scalingを使用したスケーラブルなWebアプリケーション（133頁）

◯ハマった事

・AMIの選択で「Amazon Linux 2」を選びたいが見つからない。インスタンス生成時のAMI選択画面で無料利用枠の

　AMI ID (64 ビット x86のほう) で検索した

・ステップスケーリングの追加でスケールアウトされなかった

◯メモ

133頁にメモを追記

◯参考書

５-３　Auto Scaling　＞　アプリケーションデプロイの自動化（131頁）

ELBとAuto Scalingを使用したスケーラブルなWebアプリケーション（133頁）

VPCの作成

◯手順参考先

構成例：基本構成でWebサーバーを起動（201頁）

YouTube － 【AWS Black Belt Online Seminar】Amazon VPC（52：33） リンク

◯ハマった事

・VPCを作成する開始画面を間違えた

誤：サービス ＞ VPC 遷移先の「VPC ウィザードの起動」ボタン

正：サービス ＞ VPC 遷移先のリージョン別のリソースの下にある「VPC」リンク先の「VPCを作成」ボタン

◯メモ

201頁にメモを追記

◯参考書

７-１　VPC　＞　構成例：基本構成でWebサーバーを起動（201頁）

◯その他

YouTube － 【AWS Black Belt Online Seminar】Amazon VPC（52：33） リンク

IAMユーザの設定

◯手順参考先

YouTube － 管理用IAMユーザーを作成しよう - serverworks（7:43） リンク

◯ハマった事

特になし

◯メモ

【IAMグループの作成】※管理者権限を持つIAMグループ

　1. IAM ＞ グループ ＞ 新しいグループの作成 の順にクリック
　2. グループ名「Administrator」、ポリシーのアタッチ：AdministratorAccess

【IAMユーザーの作成 】

　1. IAM ＞ ユーザー ＞ ユーザーを追加 の順にクリック

　2. ユーザー名「my_user」

　3. AWS アクセスの種類を選択：AWS マネジメントコンソールへのアクセスをオン。それ以外はデフォルトのまま

　4. [次のステップ:アクセス権限]をクリック

　5. 先程作成したグループ名「Administrator」をONにして[次へ] をクリック

　6. タグの追加は指定なし

　7. [ユーザーの作成] をクリックして、[.csvのダウンロード] をクリック

　8. ダウンロードファイルに記載されたURLにアクセスし、記載されたユーザー、パスワードをコピーしてサインインする

【MFAの設定】

　1. 画面右上のユーザーをクリック ＞ マイセキュリティ資格情報 の順にクリック

　2. [MFAデバイスの割り当て] をクリック

　3. 割り当てる MFA デバイスのタイプを選択：仮想 MFA デバイス を選択

　4. iphoneにインストールした「Google Authenticator（オーセンティケーター）」アプリケーションにQRコードを読み込ませる　

　　※インストール面倒だからやらない

　5. MFAコード１、MFAコード２を入力して「MFAの割り当て] をクリック

【MFAの確認】

　1. サインアウトする

　2. サインインして、ユーザー、パスワードとMFAコードをん入力

【AWS Security Token Service（STS）について】

・一時的なセキュリティ認証情報を発行する仕組み

・認証情報とはアクセスキーID、シークレットアクセスキー、セキュリティトークンのこと

・有効期限に数分から数時間のタイマーを設定できる

・リクエストに応じて動的に生成する

【IAMロールの仕組みについて】

　1. IAMロールをアタッチしたECインスタンス上のアプリケーションがAWSリソースにアクセスする場合、

　　IAMロールがAWS STSに対してAWSリソースへのアクセス権限のリクエストを行う

　2. AWS STSは有効期限付きの認証情報をIAMロールに返却する

　3. アプリケーションは受け取った一時的認証情報を使ってAWSリソースにアクセス可能になる

　※生成された認証情報は有効期限付きなのでIAMロールを使用するとセキュリティー上ののリスクを軽減出来る

 ◯参考書

３-３　IAM（59頁）

◯その他

YouTube － IAMロール - serverworks（7：26） リンク　補足：IAMロールの仕組み、クロスアカウントアクセス、IDフェデレーション

YouTube － くろかわこうへいのAWS講座IAM編#1（15:10） リンク　補足：スイッチロール、IAM関連の用語

YouTube － くろかわこうへいのAWS講座IAM編#2（  4:48） リンク　補足：ポリシー（JSON）ｍの構文について

サイト － IAMのスイッチロールを理解したい リンク　補足：スイッチロールの設定手順

ボリュームの変更

◯手順参考先

サイト －EC2 EBS ボリュームサイズ拡張のやりかた リンク 

◯ハマった事

特になし

◯メモ

 ※以下の手順はインスタンス実行中 AND ボリュームアタッチ済みの状態でも可能

1. 現状の確認

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  482M     0  482M   0% /dev
tmpfs          tmpfs     492M     0  492M   0% /dev/shm
tmpfs          tmpfs     492M  408K  492M   1% /run
tmpfs          tmpfs     492M     0  492M   0% /sys/fs/cgroup
/dev/xvda1     xfs       8.0G  2.4G  5.7G  30% /
tmpfs          tmpfs      99M     0   99M   0% /run/user/1000

　--------------------------------------------------------------------------------------------------

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└-xvda1 202:1    0   8G  0 part /

2. ボリューム ＞ 対象ボリュームを選択 ＞ アクション ＞ ボリュームの変更の順にクリック

3. サイズを変更して[変更]をクリック

4. OSファイルシステムを拡張する　※OS起動時にEBSのサイズに合わせてパーティションサイズを変更するツール

$ which growpart
/usr/bin/growpart

　--------------------------------------------------------------------------------------------------

$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=20967391 end=20971487

　--------------------------------------------------------------------------------------------------

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  10G  0 disk
└xvda1 202:1    0  10G  0 part /

5. この段階ではまだ df -h しても変わってない

$ df -h | grep xvda1
/dev/xvda1      8.0G  2.4G  5.7G  30% /

6. XFSファイルシステムとext4ファイルシステムで対応するコマンドが違うので、まずはファイルシステム確認

$ df -hT | grep xvda1
/dev/xvda1     xfs       8.0G  2.4G  5.7G  30% /      ※xfs

　--------------------------------------------------------------------------------------------------

　XFSファイルシステムの場合

$ sudo xfs_growfs -d /
meta-data=/dev/xvda1             isize=512    agcount=4, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=2096635, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2096635 to 2620923

　--------------------------------------------------------------------------------------------------

　ext4ファイルシステムの場合

$ sudo resize2fs /dev/xvda1

7./dev/xvda1のサイズが10Gに変更された

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  482M     0  482M   0% /dev
tmpfs          tmpfs     492M     0  492M   0% /dev/shm
tmpfs          tmpfs     492M  464K  492M   1% /run
tmpfs          tmpfs     492M     0  492M   0% /sys/fs/cgroup
/dev/xvda1     xfs        10G  2.4G  7.7G  24% /
tmpfs          tmpfs      99M     0   99M   0% /run/user/1000
tmpfs          tmpfs      99M     0   99M   0% /run/user/0

◯参考書

６-１　EBS（165頁） 

ボリュームの追加

◯手順参考先

サイト －EC2インスタンスに追加でEBSボリュームをアタッチする リンク 

◯ハマった事

特になし

◯メモ

1. 現状の確認

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  482M     0  482M   0% /dev
tmpfs          tmpfs     492M     0  492M   0% /dev/shm
tmpfs          tmpfs     492M  464K  492M   1% /run
tmpfs          tmpfs     492M     0  492M   0% /sys/fs/cgroup
/dev/xvda1     xfs        10G  2.4G  7.7G  24% /
tmpfs          tmpfs      99M     0   99M   0% /run/user/1000
tmpfs          tmpfs      99M     0   99M   0% /run/user/0

　--------------------------------------------------------------------------------------------------

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  10G  0 disk
└-xvda1 202:1    0  10G  0 part /

2. ボリューム ＞ ボリュームの作成 の順にクリック

3. サイズを[2]Gに変更

4. アベイラビリティゾーンを追加するEC2インスタンスと同じにする

5. [ボリュームの作成]をクリック

6. 画面更新てし追加されたボリュームの状態がavailableであることを確認

7. 追加されたボリュームを選択 ＞ アクション ＞ ボリュームのアタッチ の順にクリック

8. 以下を設定して[アタッチ]をクリック

・インスタンス：i-0533de072937bcead

・デバイス：/dev/sdf

9. アタッチしたボリュームの状態がin-useであることを確認

10. 追加されたことおを確認。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  10G  0 disk
└-xvda1 202:1    0  10G  0 part /
xvdf    202:80   0   2G  0 disk       ※ sdfはxvdfで表示される

11. ファイルシステムを作成

$ sudo mkfs -t xfs /dev/xvdf     ※xvda1と同じxfsを指定
meta-data=/dev/xvdf              isize=512    agcount=4, agsize=131072 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=524288, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0ボリュームのマウント

12. ファイルシステムが作成された事を確認

$ sudo file -s /dev/xvdf
/dev/xvdf: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

13. マウントポイントを作成しマウントする

$ sudo mkdir /data
$ sudo mount /dev/xvdf /data

14. 使用可能になったことを確認

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  482M     0  482M   0% /dev
tmpfs          tmpfs     492M     0  492M   0% /dev/shm
tmpfs          tmpfs     492M  468K  492M   1% /run
tmpfs          tmpfs     492M     0  492M   0% /sys/fs/cgroup
/dev/xvda1     xfs        10G  2.4G  7.7G  24% /
tmpfs          tmpfs      99M     0   99M   0% /run/user/1000
tmpfs          tmpfs      99M     0   99M   0% /run/user/0
/dev/xvdf      xfs       2.0G   35M  2.0G   2% /data         ※使用可能になった

15. root以外にも出力権限を付与

$ ls -l / | grep data
drwxr-xr-x   2 root root    6 Mar 27 02:41 data
$ sudo chmod 777 -R /data

16. 確認

$ cd /data
$ dd if=/dev/zero of=1G.dummy bs=1M count=1000
$ ls
1G.dummy

17. EC2いスタンスを停止→開始した状態では、アンマウントされるので、自動でマウントするように設定

$ sudo vi /etc/fstab
/dev/xvdf   /data       xfs    defaults,nofail   0   2       ※この行を追加
$ sudo mount -a

　※EC2いスタンスを停止→開始した状態でもマウントされている事を確認できた

◯参考書

 ６-１　EBS（165頁）

EC2インスタンスからS3へのアクセス設定

◯手順参考先

サイト － Amazon EC2(Amazon linux)から直接S3へのファイルコピー リンク

◯ハマった事

特になし

◯メモ

【EC2インスタンス】

　1. 以下の設定を行いEC2インスタンスを生成

　・ネットワーク：デフォルト

　・サブネット：アベイラビリティゾーンのデフォルトサブネット

　・タグ：Name:EC2S3

　2. S3へコピーするテストファイルの準備

$ sudo su root
# yum -y update
# cd /home
# mkdir ./test-share
# cd ./test-share
# touch test.txt
# ls -l

【ロール】

　1. IAM ＞ ロール ＞ ロールの作成 の順にクリック

　2. 以下の設定を行い[ロールの作成]をクリック

　・ユースケース：EC2

　・ポリシー：AmazonS3FullAccess

　・ロール名「Demo_Role_EC2S3」

　3. EC2コンソール ＞ EC2を選択 ＞ アクション ＞ セキュリティ ＞ IAM ロールを変更 の順にクリック

　4. ロール名「Demo_Role_EC2S3」を選択して[保存]をクリック

【S3バケット】

　1. S3 ＞ バケットを作成 の順にクリック

　2. 以下の設定を行い[バケットを作成]をクリック

　・バケット名「demo-1142-bkt」

　・AWSリージョン：東京

　・その他はすべてデフォルト

　3. AWS CLIでS3へデータをコピー

$ sudo su root
# cd /home/test-share/
# aws s3 cp test.txt s3://demo-1142-bkt
upload: ./test.txt to s3://demo-1142-bkt/test.txt
# aws s3 ls s3://demo-1142-bkt/test.txt
2021-03-28 12:29:19          0 test.txt

◯参考書

６-２　S3（170頁）

複数サービスを用いてWeb サイトをインターネット上に公開

1. Amazon Simple Storage Service（S3）＆静的ウェブサイトホスティング
2. AWS Cloud9でindex.htmlを作成
3. Amazon CloudFrontで画像をキャッシュ
4. Route 53 を使い、独自ドメインでWebサイトを公開
5. AWS Certificate ManagerでHTTPS アクセス

◯手順参考先

サイト － 初心に戻って AWS で静的 Web サイトを作成する リンク

１．Amazon Simple Storage Service（S3）＆静的ウェブサイトホスティング

◯ハマった事

特になし

◯メモ

【S3バケット】

　1. S3 ＞ バケットを作成 の順にクリック

　2. 以下の設定を行い[バケットを作成]をクリック

　・バケット名「demo-some-serv.ml」

　・AWSリージョン：東京

　・パブリックアクセスをすべて ブロック：OFF

　・その他はすべてデフォルト

【静的ウェブサイトホスティング】

　1. バケット名「demo-some-serv.ml」を選択 ＞ プロパティタブ ＞ 静的ウェブサイトホスティングの [編集] の順にクリック

　2. 以下の設定を行い [変更の保存] をクリック

　・静的ウェブサイトホスティング：有効にする

　・ホスティングタイプ：静的ウェブサイトをホストする（デフォルト）

　・インデックスドキュメント：index.html

　・エラードキュメント - オプション：error.html

　・リダイレクトルール – オプション：なし

【バケットポリシーを作成】

　1. バケット名「demo-some-serv.ml」を選択 ＞ アクセス許可タブ ＞ バケットポリシーの [編集する] の順にクリック

　2.  以下を埋め込み [変更の保存] をクリック。Resourceにはバケット名を指定する

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "PublicReadGetObject",
          "Effect": "Allow",
          "Principal": "*",
          "Action": [
              "s3:GetObject"
          ],
          "Resource": [
              "arn:aws:s3:::demo-some-serv.ml/*"
          ]
      }
  ]
}

 　3. バケット名「demo-some-serv.ml」に”パブリックにアクセス可能”、アクセス許可の概要に"⚠公開"と表示される事を確認

【ファイルアップロード】

　1. index.htmlをバケットにアップロード

　2. error.htmlをバケットにアップロード

【確認】

　1.  バケット名「demo-some-serv.ml」を選択 ＞ プロパティタブ ＞ 静的ウェブサイトホスティング へ移動

　2. バケットウェブサイトエンドポイントのURLをクリック。 index.htmlの内容がブラウザに表示された事を確認

　http://demo-some-serv.ml.s3-website-ap-northeast-1.amazonaws.com

◯参考書

６-２　S3（170頁）

◯その他
YouTube －【AWS入門: フロントエンドエンジニアのための】#1 ~S3へのデプロイ~（13:28） リンク

２．AWS Cloud9でindex.htmlを作成

◯ハマった事

特になし

◯メモ

【Cloud9の起動】

　1. Cloud9 ＞ Create environment の順にクリック

　2. 以下の設定を行い [Next step] をクリック

　・Name：demo_some_service

　3. Configure settingsで以下の設定を行い [Next step] をクリック ※すべてデフォルト

　・Environment type：Create a new EC2 instance for environment (direct access)

　・Instance type：t2.micro (1 GiB RAM + 1 vCPU)

　・Platform：Amazon Linux 2 (recommended)

　・Cost-saving setting：After 30 minutes(default)

　4. [Create environment] をクリック

　5. Cloud9の画面に遷移する。EC2インスタンス一覧にはaws-cloud9-demo-some-service-XXXXXという名前で生成されていた

【Cloud9でindex.htmlを編集後、AWS CLIでS3へアップロード】

　1. windowsのindex.htmlをUTF-8に置換

　2. 作業ディレクトリを作成

$ mkdir temp
$ cd temp

　3. 左側メニューのtempディレクトリーを選択して、Fileタブの [Upload Local Files...] でindex.htmlをアップロード

　5. 左側メニューのindex.htmlを選択。右クリックして [OPEN] を選択

　6. 適当に編集を行う

　7. Fileタブの [Save] で保存

　8. Previewタブの Preview File index.html で表示を確認

　9. AWS CLIでS3へアップロード

$ aws s3 cp index.html s3://demo-some-serv.ml
upload: ./index.html to s3://demo-some-serv.ml/index.html

　10. 静的ウェブサイトホスティングのURL（バケットウェブサイトエンドポイント）でindex.htmlの変更を確認

【Cloud9でcssファイルと画像を設定し、AWS CLIでS3へアップロード】

　1. cssフォルダーとimgフォルダーを作成し、各々適当にファイルを格納。その一式を再帰的オプション（--recursive）を付けてS3へアップロード　

$ cd temp
$ mkdir css img
$ ls
css  img  index.html
$ aws s3 ls s3://demo-some-serv.ml
2021-04-05 11:52:03        121 error.html
2021-04-06 12:38:37        149 index.html
$ aws s3 cp . s3://demo-some-serv.ml  --recursive
$ aws s3 ls s3://demo-some-serv.ml --recursive
2021-04-05 11:52:03        121 error.html
2021-04-08 12:20:12        247 index.html
2021-04-08 12:20:12      21842 img/demo.JPG
2021-04-08 12:20:12          0 css/styles.css

【動作確認】

　静的ウェブサイトホスティングのURL（バケットウェブサイトエンドポイント）でindex.htmlの変更を確認

◯参考書

なし

◯その他

YouTube －AWS Cloud9とは？初心者向けに登録方法や使い方を紹介 （8:39） リンク　補足：はじめ方

YouTube －Cloud9とは？【分かりやすい解説シリーズ #27】【プログラミング】（6:44） リンク　補足：メリット・デメリット

３．Amazon CloudFrontで画像をキャッシュ

◯ハマった事

特になし

◯メモ

【CloudFrontの作成】

　1. CloudFront ＞ Create Distribution ＞ Get Started の順にクリック

　2. 以下の設定を行い [Create Distribution] をクリック

　＊Origin Settings

　　・Origin Domain Name：作成したS3バケットを選択

　　・Restrict Bucket Access：Yes　（S3コンテンツへのアクセスがCloudFront経由のみに限定される）

　　・Origin Access Identity：Create a New Identity　（S3コンテンツへアクセスするためのIdentityを作成する）

　　・Grant Read Permissions on Bucket：Yes, Update Bucket Policy　（アクセス許可を自動的に付与する）

　＊Default Cache Behavior Settings

　　・Viewer Protocol Policy：Redirect HTTP to HTTPS　（HTTPリクエストをHTTPSにリダイレクトする）

　＊Distribution Settings

　　・Default Root Object：index.html　（ルートURL（開始画面）を指定）

　3. 一覧でStatus：Deployed、state：Enabledになったら作成完了

　4. S3 ＞ アクセス許可タブ のバケットポリシーが更新されていることを確認

　　その他のパブリックアクセスはすべてブロックのまま、静的ウェブサイトホスティングは無効のままになっている

　　つまりS３コンテンツへのアクセスはCloudFront経由のみに限定された状態である

【動作確認】

　CloudFront一覧のDomain Name列の値をコピーして、ブラウザも貼り付けindex.htmlが表示され事を確認する

◯参考書

７-２　CloudFront（213頁）

◯その他

YouTube －【AWS入門: フロントエンドエンジニアのための】#2 ~CloudFrontの理解~（12：27） リンク　補足：メリット、導入手順

４．Route 53 を使い、独自ドメインでWebサイトを公開

◯ハマった事

Freenomでドメイン登録をPC、メールは携帯だと下記「Nameserverの設定 ＞ 3.」でエラーになる

◯メモ

 【Freenomでドメイン取得】

　1. freenonにアクセス
　　https://www.freenom.com/ja/index.html

　2. 「新しい無料ドメインを探します」と記載されている入力項目に「demo-some-serv」と入力

　3. 「.ml」の [今すぐ入手！] をクリック。何故か利用不可といわれる。「demo-some-serv.ml」で再検索

　4. [チェックアウト] をクリック

　5. [12 Months @ FREE] を選択して [Continue] をクリック

【Freenomでアカウントを作成 】

　1. メールアドレスを入力して [Verify My Email Address] をクリック

　2. 24時間以内にメールを確認しリンクをクリック

　3. 名前、住所等を入力して、同意にチェックして [Complete Order] をクリックして完了

【AWSで発行したNameserverをFreenomで発行したドメインに設定】

　1. Route 53 ＞ ホストゾーンの作成 で以下を設定して [ ホストゾーンの作成] をクリック

　・ドメイン名：demo-some-serv.ml　※Freenomで登録したドメイン

　・タイプ：パブリックホストゾーン

　2. freenom ＞ サインイン ＞ Services ＞ My Domains で表示される一覧 ＞ Manage Domain の順にクリック

　3. Management Toolsで「Nameservers」を選択 ＞ Use custom nameservers (enter below) の順にクリック

　4. Route 53 ＞ ホストゾーン ＞ demo-some-serv.ml の一覧を表示

　5. 一覧のタイプ列が「NS」の値列に記載された4件のNameserverをコピー

　6. コピーした4件をドメインに紐付けるため、freenom（上記「3.」）に入力して [change Nameservers] をクリック

◯参考書

７-３　Route 53（217頁）

◯その他

YouTube －【AWS入門: フロントエンドエンジニアのための】#3 ~Route 53の理解~（19:23） リンク　補足：Freenom、Route 53、ACMの設定

サイト － Freenomでのドメイン取得方法 リンク

５．AWS Certificate ManagerでHTTPS アクセス

◯ハマった事

特になし 

◯メモ

【AWS Certificate ManagerでCNAMEを発行】

　1. AWS Certificate Manager を表示

　2. リージョンを「バージニア北部」に変更

　3.  証明書のプロビジョニングの [今すぐ始める] をクイック 

　4. パブリック証明書のリクエストが選択された状態で [証明書のリクエスト] をクリックし、以下の設定を行い [次へ]

　・ドメイン名の入力項目：Freenomで登録したドメイン「demo-some-serv.ml」

　・[この証明書に別の名前を追加] をクリックした時の入力項目：*.demo-some-serv.ml　※www.demo-some-serv.mlなども保護される

　5. DNSの検証が選択された状態で [次へ] をクリック

　6. タグなし ＞ 確認  ＞ 確認とリクエスト の順にクリックすると、CNAME レコードの名前と値が表示される

　7. 検証状態は「検証保留中」であることを確認

【ACMで発行したCNAMEをRoute 53に設定】

　1. 別タブで、Route 53 ＞ ホストゾーン ＞ demo-some-serv.ml の一覧を表示

　2. [レコードを作成] をクリックして、以下の設定を行い、[レコードを作成] をクリックする

　・レコード名：上記「ACMの設定 ＞ 6.」のCNAME レコードの名前　※名前末尾の「.demo-some-serv.ml.」は削除する

　・レコードタイプ：CNAME

　・値：上記「ACMの設定 ＞ 6.」のCNAME レコードの値

　3. 数分すると上記「7.」の検証状態は「成功」、一覧の状況は「発行済み」に状態遷移する

【 CloudFrontの変更】

　1. CloudFront一覧 ＞ ID列の値（リンク） ＞ GeneralタブのEdit の順にクリック。以下の設定を行い [Yes, Edit] をクリック

　・Alternate Domain Names(CNAMEs)：demo-some-serv.ml

　・Custom SSL Certificate (example.com)：ONにして、リストボックスからdemo-some-serv.mlを選択

【Route 53のAレコード設定】

　1.  さきほど別タブで表示した、Route 53 ＞ ホストゾーン ＞ demo-some-serv.ml の一覧を表示

　2.  [レコードを作成] をクリックして、以下の設定を行い、[レコードを作成] をクリックする

　・レコード名：＜空白＞

　・レコードタイプ：A － IPv4

　・エイリアス：ON（値の右側にあるスイッチ）にして、各リストボックスで以下を選択

　・エイリアスのリストボックス - １行目：CloudFrontディストリビューションへのエイリアス

　・エイリアスのリストボックス - ２行目：米国東部（バージニア北部）

　・エイリアスのリストボックス - ３行目：CloudFrontのDomain Name

【動作確認】

　1. demo-some-serv.mlをブラウザも貼り付けindex.htmlが表示され事を確認する

　2. URL左側の鍵マークをクリックすると「この接続は保護されています」と表示されている

　3. URL左側の鍵マークをクリックして証明書を選択すると、発行元が「Amazon」になっている

　4. URLをテキストエディターに貼ると、スキームが「https」になっている

◯参考書

７-２　CloudFront ＞ CloudFrontの特徴（213頁）

◯その他

YouTube －【AWS入門: フロントエンドエンジニアのための】#3 ~Route 53の理解~（19:23） リンク　補足：Freenom、Route 53、ACMの設定

６．リソースの削除　12時間以内に削除すれば課金されない

◯ハマった事

特になし

◯メモ

　1. Aレコードを削除

　2. CNAMEレコードを削除

　3. ホストゾーンを削除

◯参考書

なし

◯その他

YouTube －【AWS入門: フロントエンドエンジニアのための】#3 ~Route53の理解~（19:23） リンク　補足：Freenom、Route53、ACMの設定

複数サービスを用いてRDSからS3へExportして＆AthenaからSQLを実行

1. RDSの構築 & EC2からRDSへ接続
2. RDSにデータ生成
3. RDSのデータをSnapsho
4. SnapshoをS3へExport（KMSでデータを暗号化）
5. Glueクローラでデータカタログを生成（KMSでデータを複合化）
6. AthenaでSQL取得
7. リソースの削除

１．RDSの構築 & EC2からRDSに接続

◯手順参考先

サイト － RDS for MySQLを構築しEC2からアクセスしてみる リンク

◯ハマった事

・RDSの作成時、VPC セキュリティグループでEC2と同じlaunch-wizard-1を選択し接続できなかった。正解：demo-athena-Secure

・サブネットグループはAZを２箇所設定する必要があるが、RDSとEC2のAZを一致させないと接続できなかった

◯メモ

【DB用セキュリティグループの作成】

　1. EC2 ＞ セキュリティグループ ＞ セキュリティグループの作成 の順にクリック

　2. 基本的な詳細に以下を設定する

　・セキュリティグループ名：demo-athena-Secure

　・説明：demo-athena-Secure

　・VPC：DB接続するEC2インスタンスと同じ

　3. インバウンドルール

　・タイプ：MYSQL/Aurora

　・ソース：カスタム｜DB接続するEC2インスタンスと同じセキュリティグループを指定

　4. [セキュリティグループの作成 ] をクリック

【DB用サブネットグループの作成】

　1. RDS ＞ サブネットグループ ＞ DB サブネットグループの作成 の順にクリック

　2. サブネットグループの詳細に以下を設定する

　・名前：demo-athena-subnet

　・説明：demo-athena-subnet

　・VPC：DB接続するEC2インスタンスと同じ

　3. サブネットを追加に以下を設定する

　・アベイラビリティーゾーン：DB接続するEC2インスタンスと同じ（２箇所）

　・サブネット：各アベイラビリティーゾーンのサブネット

　4. [作成] をクリック

【データベースの作成】※このときのバージョン：MySQL8.0.20

　1. RDS ＞ データベース ＞ データベースの作成 の順にクリックして、以下を設定

　・データベース作成方法を選択：標準作成

　・エンジンのオプション：MySQL

　・テンプレート：無料利用枠

　・DB インスタンス識別子：database-1（デフォルト）

　・マスターユーザー名：admin（デフォルト）

　・マスターパスワード：password

　・DB インスタンスサイズ：db.t2.micro 1GiB（デフォルト）

　・ストレージ：20GiB（デフォルトのまま。最小が20GiB）

　・VPC：DB接続するEC2インスタンスと同じ

　・サブネットグループ：demo-athena-subnet

　・パブリック・アクセス：なし（デフォルト）

　・VPC セキュリティグループ：既存の選択

　・既存の VPC セキュリティグループ：demo-athena-Secure

　・アベイラビリティゾーン：ap-northeast-1a

 　・データベース認証オプション：パスワード認証（デフォルト）

　2. [データベースの作成] をクリック 

【EC2からRDSに接続】

　1. EC2にログイン

　2. MySQLをインストール

$ sudo yum install mysql

　3. MySQLにログイン（パスワード：pssword）

$ mysql -u admin -p -h ＜RDSのエンドポイント＞

◯参考書

８-１　RDS（227頁）

２．RDSにデータを生成

◯手順参考先

サイト － MySQLでのサンプル用データベースの作成 リンク　備考：DB生成からINSERT

サイト － [MySQL] テーブルにファイルをインポートする リンク　備考：インポート手順

サイト － テストデータ生成 リンク　備考：テストデータの生成

◯ハマった事

ユーザーに権限を付与しないとインポートできない

サイト － amazon-web-services - mysqlimport:エラー:MySQL 8.0およびAmazon RDSで1227アクセスが拒否されました  リンク

◯メモ

【DB・テーブル生成およびデータ挿入：CREATE、INSERT】

　1. DB生成

mysql> create database sample;

　2. テーブル生成

mysql> create table staff
(
  id integer,
  name char(16),
  branch char(20),
  age integer
);

　3. データを挿入

mysql> INSERT INTO staff (id, name, branch, age) VALUES ('1','Tanaka','Tokyo','29');
mysql> INSERT INTO staff (id, name, branch, age) VALUES ('2','Yamada','Yokohama','31');
mysql> INSERT INTO staff (id, name, branch, age) VALUES ('3','Sugiura','Chiba','34');
mysql> INSERT INTO staff (id, name, branch, age) VALUES ('4','Yamano','Osaka','25');
mysql> INSERT INTO staff (id, name, branch, age) VALUES ('5','Nakajima','Yokohama','38');
mysql> INSERT INTO staff (id, name, branch, age) VALUES ('6','Suzuki','Tokyo','24');

　4. 確認

MySQL [sample]> select * from staff;
+------+----------+----------+------+
| id   | name     | branch   | age  |
+------+----------+----------+------+
|    1 | Tanaka   | Tokyo    |   29 |
|    2 | Yamada   | Yokohama |   31 |
|    3 | Sugiura  | Chiba    |   34 |
|    4 | Yamano   | Osaka    |   25 |
|    5 | Nakajima | Yokohama |   38 |
|    6 | Suzuki   | Tokyo    |   24 |
+------+----------+----------+------+

【インポート：mysqlimport】

　1. テーブル生成

mysql> create table staff_details
(
  id integer,
  email varchar(30),
  sex char(1),
  tel char(13),
  update_date char(8)
);

　2. 権限付与

mysql> GRANT SESSION_VARIABLES_ADMIN ON *.* TO 'admin'@'%';

　3. インポート

$ mysqlimport -u admin -p -h database-1.clmnt3uyc5io.ap-northeast-1.rds.amazonaws.com --local sample staff_details.tsv
sample.staff_details: Records: 100  Deleted: 0  Skipped: 0  Warnings: 0

◯参考書

なし

３．RDSからデータをSnapshot

◯手順参考先

◯ハマった事

特になし

◯メモ

　1. RDS ＞ データベース ＞  RDSを選択 ＞ アクション ＞スナップショットの取得 の順にクリック

　2. 以下を設定して [スナップショットを取得] をクリック

　・スナップショット名：demo-snapshot

　3. スナップショット一覧のステータスが利用可能になったら完了

◯参考書

特になし

４．SnapshotをS3へExport（KMSで暗号化）

◯手順参考先

YouTube －AWS Glueを使ってRDSから S3+Athena環境を作ってみよう #devio2020（22:49） リンク

◯ハマった事

RDSのステータスが「利用可能」でないとエクスポートを実行してもずっと「起動中」のままだった

◯メモ

【KMSの作成】

　1. Key Management Service  ＞ キーの作成 の順にクリック。以下の設定を行い[次へ] をクリック

　・キーのタイプ：対称

　・詳細オプション：KMS（デフォルト）

　２．以下の設定を行い[次へ] をクリック

　・エイリアス：demo_s3_kms

　3．キーの管理アクセス許可を定義、及びキーの使用アクセス許可を定義とも＜未指定＞のまま [次へ] をクリック

　4. [完了] をクリック

【S3バケットの作成】

　1. S3 ＞ バケットを作成 の順にクリック。以下を設定して [バケットを作成] をクリック

　・バケット名：demo-export-rds

　・AWS リージョン：アジア・パシフィック（東京）

　・上記以外：＜すべてデフォルト＞

【snapshotをExport】

　1. RDS ＞ スナップショット ＞ 一覧から選択 ＞ アクション ＞ Amazon S3 へのエクスポート の順にクリック。以下を設定

　・ 識別子：export-sample-for-athena

　・エクスポートされたデータ：すべて（デフォルト）

　・S3 バケット：demo-export-rds

　・IAM ロール：「新しいロールの作成」を選択

　・IAM ロール名：export-role

　・暗号化：demo_s3_kms

　2. [Amazon S3 へのエクスポート] をクリック

　3. スナップショット の一覧のステータスが「完了」になることを確認

　4. スナップショット の一覧のS3バケットのリンクをクリックして以下を確認

　・トップがDB名である

　・いくつかのJSONファイルが存在する

　・DB名下にテーブル名がすべて存在する

　・各テーブル名下にデータが存在する（parquet：パーケット形式）

◯参考書

６-２　S3 ＞ S3のセキュリティ ＞ 通信、保存データの暗号化（172頁）

５．Glueクローラでデータカタログを生成（KMSで復号化）

◯手順参考先

YouTube －AWS Glueを使ってRDSから S3+Athena環境を作ってみよう #devio2020（22:49） リンク

◯ハマった事

◯メモ

【Glueクローラの設定】

　1. Glue ＞ 左側メニューのクローラ ＞ クローラの追加 の順にクリック。以下を設定して [次へ]

　・クローラの名前：demo_Crawler を設定して [次へ]

　・Crawler source type：Data stores

　・Repeat crawls of S3 data stores：Crawl all foldersr を設定して [次へ]

　・データストアの選択：S3

　・接続：＜未指定＞

　・インクルードパス：S3バケット名 ＞ エクスポート名 ＞ DB名 の順にクリックして [次へ]

　　s3://demo-export-rds/export-sample-for-athena/sample

　・別のデータストアの追加：いいえ

　・IAM ロールの選択：IAM ロールを作成する

　・IAM ロール名　AWSGlueServiceRole-：crawler-role を設定して [次へ]

　・頻度：オンデマンドで実行 を選択して [次へ]

　2. [データベースの追加] をクリック。以下を設定

　・データベース名：demo-crawler-db を設定して [次へ]

　3. [完了] をクリック

【GlueクローラのIAM ロールに、暗号化されたS3バケットのデータを復号化する権限を設定】

　1. IAM ＞ ロール の順にクリック

　2. 一覧で「AWSGlueServiceRole-」で検索。「AWSGlueServiceRole-crawler-role」を選択

　3. インラインポリシーの追加 ＞ サービスの選択 の順にクリック

　4. サービスの検索で「kms」で検索

　5. アクションで「decrypt」で検索。「Decrypt」を選択

　6. リソース：すべてのリソース を選択

　7. [ポリシーの確認] をクリック

　8. 名前：demo-kms-decrypt

　9. [ポリシーの作成] をクリック

【Glueデータカタログの作成】

　1.  Glue ＞ 左側メニューのクローラ ＞ 一覧でクローラを選択 ＞ クローラの実行 の順にクリック

　2. ステータスが「Ready」になったら、左側メニューからテーブルを選択

　3. テーブルのかずだけデータカタログが作成されていることを確認

◯参考書

特になし

６．AthenaでSQL実行

◯手順参考先

YouTube －AWS Glueを使ってRDSから S3+Athena環境を作ってみよう #devio2020（22:49） リンク

◯ハマった事

クエリで「demo-crawler-db.sample_staff」と設定するとクエリ実行でエラー「extraneous input '-'」になる

どうやら「-：ハイフン」が使えないらしい（ サイト － テーブル、データベース、および列の名前 リンク ）

DB名を「"：ダブルコーテーション」で括った「"demo-crawler-db".sample_staff」では正常に実行できた

◯メモ

　1. S3 ＞ demo-export-rds ＞ export-sample-for-athena ＞ フォルダーの作成 の順にクリック

　・フォルダー名：result

　2. サービス：athena を選択

　3. 左側メニュー ＞ Database：demo-crawler-db を選択

　4. 右上に表示されているメッセージ内の「set up a query result location in Amazon S3.」をクリック

　5. Query result locationに「result」フォルダーを選択：s3://demo-export-rds/export-sample-for-athena/result/

　6. [save] をクリック

　7. sample_staffテーブルの「︙」をクリックして「Preview table」を選択

　8. 右上でサンプルクエリが実行され、右下にクエリー結果が表示されればOK

SELECT * FROM "demo-crawler-db"."sample_staff" limit 10;

　9. JOINしてみた

SELECT 
  a.id,
  a.name,
  b.email,
  b.update_date
FROM 
  "demo-crawler-db".sample_staff a
  INNER JOIN 
  "demo-crawler-db".sample_staff_details b
  ON a.id = b.id

◯参考書

特になし

７．ソースの削除　自分で作成したKMS（CMK）は毎日課金される。そして削除に最短7日間かかる

◯ハマった事

特になし

◯メモ

【KMSの削除】

　1. KMS ＞ 一覧から選択 ＞ キーにアクション ＞ キーの削除をスケジュール

　2. 待機期間 (日数)：7日後を選択して [削除をスケージュール] をクリック

　3. 削除をスケージュール後はAthenaで[ErrorCode: INTERNAL_ERROR_QUERY_ENGINE]エラーになった

◯参考書

特になし

◯その他

サイト －カスタマーマスターキー を削除する リンク

 またデータカタログが使用したいときはKMSの作成から再実行。以下は注意

・各サービスの既存名に＋１した名前で作成

・IAMロールは「新しいロールの作成」を選択する

・データーベース名にハイフンを使用しない

Athenaのポイント

◯参考先

YouTube － 【AWS Black Belt Online Seminar】Amazon Athena（1:00:43） リンク

Glueジョブ

◯手順参考先

サイト －AWS Glue のチュートリアルをやってみました  リンク

◯ハマった事

特になし

◯メモ

【GlueのIAMロールを生成】

　1. IAM ＞ ロール ＞ ロールを作成  の順にクリック。以下を設定して [次のステップ：アクセス権限]

　・信頼されたエンティティの種類を選択：AWS サービス

　・ユースケースの選択：Glue

　2. 以下のポリシーを選択して [次へ]

　・AWSGlueServiceRole

　・AmazonS3FullAccess

　3. 以下を設定して  [ロールの作成]

　・ロール名：AWSGlueServiceRoleDefaultCM　※ロール名は先頭にAWSGlueServiceRoleを付けるという命名規約があるらしい・・

【データの用意】

　1. S3 ＞ バケットを作成  の順にクリック。以下を設定して [バケットを作成]

　・バケット名：demo-export-tutorial

　・AWS リージョン：ap-northeast-1

　・他は全てデフォルト

　2. バケット一覧でdemo-export-tutorialを選択して各格納先フォルダーを作成

　・クロラーのINPUTデータ：crawler

　・Glueジョブのスクリプト：script

　・Glueジョブの一時ディレクトリ：temp

　・Glueジョブの結果：result

　3. s3://demo-export-tutorial/crawler/にクロラーのINPUTデータ（CSV）を格納

"id","name","branch","age"
"1","Tanaka","Tokyo","29"
"2","Yamada","Yokohama","31"
"3","Sugiura","Chiba","34"
"4","Yamano","Osaka","25"
"5","Nakajima","Yokohama","38"
"6","Suzuki","Tokyo","24"

【Glueジョブの生成】

　1. Glue ＞ 左側メニューのチュートリアル下のクローラの追加 ＞クローラの追加 の順にクリック

　2. 以下を設定して [次へ]

　・クローラの名前：Flight_Data_Crawler

　3. 以下を設定して [次へ]

　・Crawler source type：Data stores（デフォルト）

　・Repeat crawls of S3 data stores：Crawl all folders（デフォルト）

　4. 以下を設定して [次へ]

　・データストアの選択：S3

　・接続：未選択

　・クロールするデータの場所：自分のアカウントで指定されたパス（デフォルト）

　・インクルードパス：s3://demo-export-tutorial/crawler/　※配下のファイル全てにするため末尾に/を付与

　5. 以下を設定して [次へ]

　・別のデータストアの追加：いいえ

　6. 以下を設定して [次へ]

　・IAM ロール：既存の IAM ロールを選択して「AWSGlueServiceRoleDefaultCM」を設定

　7. 以下を設定して [次へ]

　・頻度：オンデマンドで実行

　8. [データベースの追加]をクリックして以下を設定して [次へ]

　・データベース名：flight_data_crawler_db

　9.  [完了]

　10. クローラ一覧でFlight_Data_Crawlerを選択して[クローラの実行]をクリック

　11. クローラ完了後、 左側メニューのチュートリアル下のテーブルの確認をクリックして、一覧に「crawler」が作成されている事を確認

　12. AthenaでDatabaseに「flight_data_crawler_db」があること、Tablesに「crawler」がある事を確認

【Glueジョブの作成】

　1. Glue ＞ 左側メニューのチュートリアル下のジョブの追加 ＞ジョブの追加 の順にクリック。以下を設定して [次へ]

　・名前：flight_conversion

　・IAMロール：AWSGlueServiceRoleDefaultCM

　・Type：Spark（デフォルト）

　・Glue version：Spark 2.4, Python 3 with improved job startup times (Glue Version 2.0 ) （デフォルト）

　・このジョブ実行：AWS Glue が生成する提案されたスクリプト

　・スクリプトファイル名：flight_conversion

　・スクリプトが保存されている S3 パス：s3://demo-export-tutorial/script

　・一時ディレクトリ：（デフォルト）：s3://demo-export-tutorial/temp

　・セキュリティ設定、スクリプトライブラリおよびジョブパラメータ (任意)

　　・参照されるファイルパス：なし

　　・作業者タイプ：標準

　　・作業者数：2

　・カタログオプション (任意)

　　・Use Glue data catalog as the Hive metastore：ON

　2.  データソースの選択。以下を設定して [次へ]

　・データソースの選択：crawler

　3.  変換タイプを選択します。以下を設定して [次へ]

　・スキーマを変更する：ON（デフォルト）　※「一致するレコードを検索する」は何故か選択できない

　4.  データターゲットの選択。以下を設定して [次へ]

　・データターゲットでテーブルを作成する：ON　※更新も出来るらしい

　・データストア：Amazon S3

　・形式：Parquet

　・接続：なし

　・ターゲットパス：s3://demo-export-tutorial/result

　5.  Output Schema Definition。とりあえず変更しないで [ジョブを保存してスクリプトを編集する]をクリック

　6. スクリプト編集画面に遷移される

　7. [保存]をクリック

　8. [ジョブの実行]をクリック

　9. ジョブ正常終了後、s3://demo-export-tutorial/resultにParquetファイルが生成されている事を確認

◯参考書

特になし

SageMaker

◯手順参考先

サイト － Amazon Athena を使用した SageMaker ノートブックからの SQL クエリの実行方法 リンク

◯ハマった事

Terminalをlogoutしてpython3を起動しようとしてエラーになった。Terminalのタブはそのままにしておく。

◯メモ

【ノートブックインスタンスの作成】

　1. SageMaker ＞ 左側メニューのノートブック の ノートブック インスタンス ＞ ノートブック インスタンスの作成 の順にクリック

　2. 以下を設定して [ノートブック インスタンスの作成]をクリック

　・ノートブックインスタンス名：demo-jupyter

　・ノートブックインスタンスのタイプ：ml.t2.medium（デフォルト）

　・Elastic Inference：なし（デフォルト）

　・IAM ロール：新しいロールの作成を選択

　　「IAM ロールを作成する」ダイアログが表示される　以下を設定して[ロールの作成]をクリック

　　・指定する S3 バケット - オプション：任意の S3 バケット

　3. ステータスが「InService」になるまで待機

【アクセスキーの作成】

　1. 右上のアカウント ＞ マイセキュリティ資格情報 ＞ アクセスキー ＞ 新しいアクセスキーの作成 の順にクリック

　2. アクセスキー IDとシークレットアクセスキーをエディターにコピペ

【JupyterでPython3の起動】

　1. 一覧から作成したインスタンスを選択

　2. アクション ＞ Jupyterを開く ＞ ブラウザの別ウィンドウでノートブックのインターフェイスが開く

　3. 右上の[NEW] から [Terminal] を選択 

　4. aws認証情報の更新を行う

sh-4.2$ aws configure
AWS Access Key ID [None]: *************************
AWS Secret Access Key [None]: **********************************
Default region name [ap-northeast-1]: ap-northeast-1
Default output format [None]: json

　5.  右上の[NEW] からAnacondaのPython3系環境 [conda_python3]を選択 

【Python3を実行】

　1. 左上のJupyterの右側の「Untitled」をクリックして以下を設定して[Rename]

　・Rename Notebook：demo_conda_python1

　2. 以下を入力して[Run]

# Athena JDBC ドライバーをインストール
import sys
!{sys.executable} -m pip install PyAthena

　3.以下を入力して[Run]

# AthenaにSQLを投げる
from pyathena import connect
import pandas as pd
conn = connect(s3_staging_dir='s3://demo-export-rds2/export-sample-for-athena2/temp_athena/',
               region_name='ap-northeast-1')

df = pd.read_sql("SELECT * FROM flight_data_crawler_db.crawler limit 10;", conn)
df

【あとかたづけ（アクセスキーの削除）※重要】

　1. Terminalで削除

sh-4.2$ rm -rf ~/.aws

　2. 右上のアカウント ＞ マイセキュリティ資格情報 ＞ アクセスキー ＞ アクションの削除 の順にクリック

◯参考書

特になし 

Lambdaを使用してEC2を自動で起動／停止

◯手順参考先

サイト － Amazon EMR とは？ リンク

◯ハマった事

・ソースをコードエディターに貼っただけでは反映されない。[Deploy] をクリック「Changes deployed」にする必要がある

・Cron式はUTCで評価されるので、CloudWatchのCronで指定する時間は「９時間マイナス」する必要がある

◯メモ

【ポリシーとロールの生成】

　1. IAM ＞ ポリシー ＞ ポリシーの作成 ＞ JSONタブの順にクリック。以下を設定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Start*",
        "ec2:Stop*"
      ],
      "Resource": "*"
    }
  ]
}

　2.  次のステップ:タグ ＞ 次のステップ:確認 の順にクリック。以下を設定して [ポリシーの作成] をクリック

　・名前：test_pol_lambda

　3.  IAM ＞ロール ＞ ロールの作成 の順にクリック。以下を設定して [次のステップ:アクセス権限] をクリック

　・信頼されたエンティティの種類を選択：AWS サービス

　・ユースケースの選択：Lambda

　4. フィルター「test_pol_lambda」を選択して

　5. 次のステップ:タグ ＞ 次のステップ:確認 の順にクリック。以下を設定して [ロールの作成] をクリック

　・名前：test_rol_lambda

【Lambdaの設定】

　1. Lambda ＞ 関数の作成 の順にクリック。以下を設定して [関数の作成] をクリック

　・オプション：一からの作成

　・関数名：test_ec2_lambda

　・ランタイム：Python 3.7

　・実行ロール：既存のロールを使用する：test_rol_lambda

　2. 以下のスクリプトを記入する（regionにアベイラビリティゾーン、instancesに起動するインスタンスIDを指定）

import boto3
region = 'ap-northeast-1'
instances = ['i-043b891ff9021deb4']
ec2 = boto3.client('ec2', region_name=region)

def lambda_handler(event, context):
    ec2.start_instances(InstanceIds=instances)
    print('started your instances: ' + str(instances))

　3. 設定タブ ＞ 一般設定 ＞ 編集 の順にクリック。以下を設定して [保存] をクリック

　・タイムアウト：10秒

　4. [Deploy] をクリック

　5. [テスト] ボタンを押下して、以下を設定して [作成] をクリック。再度 [テスト] ボタンを押下

　・イベントテンプレート：Hello World

　・イベント名：TestEvent

　6. Execution Resultタブが表示されエラーが無ければ完了

【CloudWatchの設定】

　1. Lambda ＞ 関数 ＞ test_ec2_lambda ＞ 関数の概要内の「＋トリガーを追加」の順にクリック。以下を設定して [追加] をクリック

　・トリガーの設定：EventBridge(CloudWatch Events)

　・ルール：新規ルール

　・ルール名：test_start_ec2

　・ルールタイプ：スケジュール式

　・スケジュール式：cron(25 16 ? * SUN *)

◯参考書

5-4　Lambda（150頁）

ア

◯手順参考先

◯ハマった事

◯メモ

◯参考書

無料枠のファイル数や容量等、AWS Budgets

サイト － AWS1年目無料期間でやったこととハマったこと

サイト － AWSで消し忘れを防止するためにチェックすべき７つのポイント

ELastic IPの取得、EC2インスタンスへの関連付け手順

Glueの概要等いろいろ

Glueの概要、ETL処理の実装方法