What's New Qiita

20201116のAWSに関する記事は18件です。

  • 投稿日：2020-11-16T23:31:05+09:00

【AWS】Basic認証付き静的ページをS3でホスティングするまで(CodeBuildによるデプロイも含む)

概要

タイトルの通りです。
ソースコードはCodeCommitで管理をしている前提です。

大まかな流れ

  • リポジトリ作成
  • S3バケット作成
  • CodeBuildでビルドプロジェクトを作成
  • CodePipelineの作成
  • Lambda関数の作成
  • CloudFront Distributionの作成

あまり躓く箇所がない場合、注意点のみ記述し、詳細な手順は割愛させて頂きます。

リポジトリ、S3バケットの作成

リポジトリの構成は以下の形として解説していきます。 

.
├── buildspec.yml
└── public  # このディレクトリ内をS3へ展開します。
    └── index.html
  • 複数のAWSアカウントでCodeCommitを使用しており、コードをプッシュする際に「Please make sure you have the correct access rights and the repository exists.」と表示されてしまう場合。
    • sshコンフィグファイルにそれぞれの接続情報を記載します。
~/.ssh/config
Host git-codecommit.*.amazonaws.com  # AWSアカウント1
  User SSH キーID  # AWSアカウント1に登録されているもの
  IdentityFile ~/.ssh/認証鍵

Host git-codecommit.*.amazonaws.com  # AWSアカウント2
  User SSH キーID  # AWSアカウント2に登録されているもの
  IdentityFile ~/.ssh/認証鍵
    • リモートリポジトリを登録する際に、SSHキーIDを含めたURLを登録します。
$ git remote add origin ssh://SSH キーID@git-codecommit.us-west-1.amazonaws.com/v1/repos/repo-name
  • CloudFront経由で配信するため、S3バケットに対するパブリックアクセスは全てブロック、静的ウェブサイトホスティングは無効で問題ありません。

CodeBuildでビルドプロジェクトを作成

リポジトリのMasterブランチに変更が加わった際に、publicディレクトリ内のファイルをS3へ展開させるためのプロジェクトを作成します。
今回は複雑なことは特にしませんので、マネジメントコンソールからぽちぽち作成していきましょう。

buildspec.yml
version: 0.2

phases:
  build:
    commands:
      - aws s3 sync public s3://bucket-name --delete

ビルドプロジェクトの作成が完了すると、新しいサービスロールが作成されるかと思います。
ビルド時にs3 syncを実行するため、サービスロールへS3へのアクセス権を付与してあげましょう。

CodePipelineの作成

こちらもコンソールからぽちぽち作成していきます。
ソースステージではCodeCommitのリポジトリを、ビルドステージでは先ほど作成したビルドプロジェクトを指定します。デプロイステージはスキップします。

Lambda関数の作成

CloudFrontアクセス時にBasic認証を行う関数を作成します。
CloudFrontと関連付けるため、us-east-1(バージニア北部)リージョンで関数を作成して下さい。

CloudFrontをトリガーとするため、関数作成時にポリシーテンプレートからロールを作成して下さい。
アタッチするポリシーは「基本的なLambda@Edgeのアクセス権限(CloudFrontトリガーの場合)」を選択します。
create_lambda_01.jpg

関数コード

index.js
'use strict';
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;
    const authUser = 'username';  # 適宜書き換えて下さい。
    const authPass = 'password';  # 適宜書き換えて下さい。
    const authString = 'Basic ' + new Buffer(authUser + ':' + authPass).toString('base64');

    if (typeof headers.authorization == 'undefined' || headers.authorization[0].value != authString) {
        const body = 'Unauthorized';
        const response = {
            status: '401',
            statusDescription: 'Unauthorized',
            body: body,
            headers: {
                'www-authenticate': [{key: 'WWW-Authenticate', value:'Basic'}]
            },
        };
        callback(null, response);
    }
    callback(null, request);
};

最後にアクションから新しいバージョンを発行します。

CloudFront Distributionの作成

Web用のDistributionを作成していきます。
項目が多いため、変更を加える必要がある部分のみ解説していきます。

create_distribution_02.jpg

  • Origin Domain Name

    • コードが展開されるS3バケットを指定して下さい。

  • Restrict Bucket Access

    • CloudFrontを経由したアクセスにのみ、バケット内のオブジェクトへのアクセスを許可します。
    • 許可する識別子を作成し、対象となるバケットポリシーを更新します。

  • Viewer Protocol Policy

    • HTTPでアクセスした場合、HTTPSへリダイレクトします。

  • Lambda Function Associations

    • 先ほど作成したLambda関数のARNを指定します。

  • Default Root Object

    • index.htmlを指定します。

以上となります。
この記事を作成するにあたり、参考とさせて頂きましたQiita内の記事を下記へ記載致します。

https://qiita.com/Junpei_Takagi/items/0ff85de3bf2de3aaf4eb
https://qiita.com/m4fg/items/80db7ce0050e5f3ab801
https://qiita.com/NaokiIshimura/items/46994e67b712831c3016

最後までお読み頂きありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T21:25:03+09:00

AWS EC2でAmazon Linuxを作成、ログイン

AWS EC2でAmazon Linuxを作成、ログインする。

AWSにログイン、サービス＞EC2＞インスタンスを起動
image.png

Amazon Linux 2 を、64bit(x86)のまま「選択」をクリック

デフォルトのまま、「確認と作成」をクリック

インスタンスが作成されるので、「パブリック IPv4 アドレス」のIPを確認。

Macのターミナル、WindowsならTeraTerm等のソフトでssh接続。

ssh -i testkey.pem ec2-user@[IPアドレス]

でログイン。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T21:09:16+09:00

AWSのコスト管理 ~DBRとCURの違い~

比較表

DBR CUR
Name Detailed Billing Report AWS Cost and Usage Reports
名前 詳細請求レポート AWSコストおよび使用状況レポート
固定列 ある ない
ファイル構成 単一 統合されたファイルのセット

CURのメリット

  • 個々のコストを詳細に確認できる
  • 統合されたファイルのセット
    • すべての使用状況の広告申込情報を含むデータファイルのセット
    • すべての割引を含む個別のデータファイル（該当する場合）
    • 単一のレポートに属するすべてのデータファイルを一覧表示するマニフェストファイル

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T19:20:31+09:00

SquidでAWS EC2をフォワードプロキシにする

はじめに

AWS EC2にSquidをインストールして、フォーワードプロキシとして利用する手順です。
EC2のOSのバージョンは、Amazon Linux 2です。

手順

1. EC2にSquidをインストールする

スクリプト
sudo yum update -y

# Squidをインストールする
sudo yum install squid -y

# Squidを起動する
sudo systemctl start squid

# Squidの起動とサーバーの起動を連携する
sudo systemctl enable squid

２. Squidの設定をする

スクリプト
export VPC_IP=[Squidを利用するVPCのCidrBlock]
# Squidで利用するポート番号
# 今回は8080とする
export SQUID_PORT=8080

sudo sed -i "s#10.0.0.0\/8#${VPC_IP}#g" /etc/squid/squid.conf
sudo sed -i "s/acl localnet src 172.16.0.0\/12/# acl localnet src 172.16.0.0\/12/g" /etc/squid/squid.conf
sudo sed -i "s/acl localnet src 192.168.0.0\/16/# acl localnet src 192.168.0.0\/16/g" /etc/squid/squid.conf
sudo sed -i "s/acl localnet src fc00::\/7/# acl localnet src fc00::\/7/g" /etc/squid/squid.conf
sudo sed -i "s/acl localnet src fe80::\/10/# acl localnet src fe80::\/10/g" /etc/squid/squid.conf

sudo sed -i "s/acl Safe_ports port 2/# acl Safe_ports port 2/g" /etc/squid/squid.conf
sudo sed -i "s/acl Safe_ports port 48/# acl Safe_ports port 48/g" /etc/squid/squid.conf
sudo sed -i "s/acl Safe_ports port 5/# acl Safe_ports port 5/g" /etc/squid/squid.conf
sudo sed -i "s/acl Safe_ports port 7/# acl Safe_ports port 7/g" /etc/squid/squid.conf
sudo sed -i "s/http_port 3128/http_port${SQUID_PORT}/g" /etc/squid/squid.conf

cat <<EOS | sudo tee -a /etc/squid/squid.conf
forwarded_for off
request_header_access X-Forwarded-For deny all
request_header_access Via deny all
request_header_access Cache-Control deny all
reply_header_access X-Forwarded-For deny all
reply_header_access Via deny all
reply_header_access Cache-Control deny all
EOS
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T18:11:18+09:00

AWS Chatbotを使ってヘルスチェックアラートをSlackに送る

AWS Chatbot

AWS Chatbotを使うことで、これまでSlackへの通知をLambdaで実装する必要があったのですが、簡単にAWSコンソールを触ることで連携が可能となります。
今回はRoute 53のヘルスチェックエラーをChatbotを使ってSlackに通知を送るよう実装しました。

参考：AWS Chatbot

AWS Chatbot は、Slack チャンネルや Amazon Chime チャットルームで AWS のリソースを簡単にモニタリングおよび操作できるようにしてくれるインタラクティブエージェントです。

手順

  1. SNS（Amazon Simple Notification Service）でトピックの作成
  2. AWS Chatbotでクライアントの設定
  3. AWS ChatbotでSlackチャンネルを設定
  4. Route53でヘルスチェックの作成

SNS（Amazon Simple Notification Service）でトピックの作成

トピックは名前を決めるくらいなのですが、リージョンをバージニア北部（us-east-1）で作成します。
参考：ヘルスチェックを作成または更新するときに指定する値
他のリージョンはヘルスチェックアラートに設定できないので注意

image.png

AWS Chatbotでクライアントの設定

クライアントを設定をクリックするとSlackの画面に飛ぶのでログイン後（ログイン済みの場合は不要）連携を許可します。
image.png

AWS ChatbotでSlackチャンネルを設定

名前を決め、投稿するチャンネルを選択します。
image.png

image.png

Route53でヘルスチェックの作成

ヘルスチェックは通常の作成します。
今回はhttpstat.usを利用しました。このサイトは
httpstat.us/200だとhttpステータス200を
httpstat.us/503だとhttpステータス503を返すように任意のステータスをスラッシュ以後に書くと帰ってくるので非常に便利で、今回はテスト用に利用させていただきました。
image.png

アラームを作成して、通知先を先程作成したSNSトピックを選択します。上述したとおり、バージニア北部にSNSトピックがないとここに現れないので注意が必要です。
image.png

設定完了

以上で設定完了です。
ヘルスチェックアラートは以下のようなSlackが飛んできます。
メッセージ内容はうまい具合にやってくれて、画像も添付してくれます。

スクリーンショット 2020-11-16 18.05.24.png

困ったこと

Chatbotはメッセージを上述のようにデフォルトできれいに送信してくれる一方カスタムができません。
なので緊急度の高いメッセージでも@channelや@someoneなどつけることができません。通知設定はSlack側でコントロールするか、カスタマイズが必要な場合はやはり自前でLambdaを利用する必要がありそうです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T17:40:17+09:00

AWS 認定ソリューションアーキテクト対策メモ

2020 年 10 月時点 目次 1. AWS Well-Architected フレームワークの構成 2. リージョンとアベイラビリティゾーン 3. ネットワークサービス Amazon VPC（Amazon Vitual Private Cloud） Amazon Route 53 AWS CloudFront 4. コンピューティングサービス Amazon EC2（Amazon Elastic Compute Cloud） Amazon ECS（Amazon Elastic Container Service） AWS Lambda 5. 運用支援サービス Amazon CloudWatch AWS CloudTrail AWS Config 6. ストレージサービス Amazon EBS（Amazon Elastic Block Store） Amazon EFS（Amazon Elastic File System） Amazon S3（Amazon Simple Storage Service） Amazon FSx for Windows AWS Storage Gateway AWS Snow Family 7. データベースサービス Amazon RDS（Amazon Relational Database Service） Amazon Redshift Amazon DynamoDB Amazon ElastiCache 8. セキュリティとアイデンティティ Amazon Cognito AWS IAM（AWS Identity and Access Management） AWS Organizations AWS KSM（AWS Key Management Service） AWS CloudHSM（AWS Cloud Hardware Security Module） AWS ACM（AWS Certificate Manager） 9. アプリケーションサービス Amazon SES（Amazon Simple Email Service） Amazon SNS（Amazon Simple Notification Service） Amazon SQS（Amazon Simple Queue Service） Amazon API Gateway Amazon SWF（Amazon Simple Workflow） AWS Step Functions 10. 開発者ツール AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS CodePipeline AWS CodeStar 11. プロビジョニングサービス AWS Elastic Beanstalk AWS OpsWorks AWS CloudFormation 12. 分析サービス Amazon EMR（Amazon Elastic MapReduce） AWS Glue 13. ETL ツール Amazon Kinesis 1. AWS Well-Architected フレームワークの構成 AWS Well-Architected フレームワークホワイトペーパー フレームワークの 5 本柱 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 チェックリスト ▲ ページの上部へ移動 2. リージョンとアベイラビリティゾーン リージョン 地理的に離れた地域 オハイオ（us-east-2）、東京（ap-northeast-1）など 初期はバージニア北部（us-east-1） アベイラビリティーゾーン（AZ） データセンターの集合 地理的、電源的に独立 ap-northeast-1a、ap-northeast-1c など ローカルリージョン DR（Disaster Recovery：災害復旧）を目的としたリージョン 大阪 など エッジロケーション 地理的に近いエッジロケーションから低レイテンシーなサービスを提供 Amazon CloudFront や Amazon Route 53 など AWS のサービス グローバルサービス IAM CloudFront Route 53 など リージョンサービス VPC DynamoDB Lambda など アベイラビリティーゾーンサービス VPC のサブネット EC2 RDS など ▲ ページの上部へ移動 3. ネットワークサービス Amazon VPC（Amazon Vitual Private Cloud） VPC 仮想プライベートクラウド DNS hostnames オプション EC2 インスタンス作成時にパブリック DNS ホスト名が割り当てられる デフォルト：有効 サブネット VCP 内に最大 200 個作成可能 ネットマスクは /16 ～ /28 の範囲で作成可能 IP アドレス数：(32:1, 31:2, 30:4, 29:8,) 28:16, 27:32, 26:64, 25:128, 24:256 IP アドレスの最初の 4 つと最後の 1 つは AWS 側で予約されている パブリックサブネット ルートテーブルにインターネットゲートウェイを設定 内外両方向で通信が可能 プライベートサブネットでのインターネット接続 パブリックサブネットに NAT ゲートウェイを設定し、パブリックサブネットとプライベートサブネットを接続 外向きのみ通信が可能 ルートテーブル メインルートテーブル VPC に設定されたルートテーブルのこと サブネットのルートテーブルが未設定の場合に使用される イーターネットゲートウェイ（IGW） VPC とインターネットとの間で通信ができるようになる インターネットが接続できない場合、以下を確認する インターネットゲートウェイが VPC または サブネット に設定されている EC2 にパブリック IP アドレスが付与されている セキュリティグループで許可されている ネットワーク ACL で拒否していない Elastic IP（EIP） 固定のグローバル IP アドレス 課金対象 EC2 にアタッチされていない場合 EC2 にアタッチされているが EC2 が停止している場合 VPC エンドポイント インターネットを介さずに、VPC と他の AWS サービスをプライベート接続できる Gatway 型 ルートテーブルに指定されたターゲットを追加し、ゲートウェイ経由で AWS の API エンドポイントにアクセス S3 と DynamoDB アクセス制御はゲートウェイのアクセスポリシー Interface 型 サービスのエンドポイント と ENI を PrivateLink でリンク S3 と DynamoDB 以外の大半 アクセス制御はセキュリティグループ NAT ゲートウェイ マネージド型サービス パブリックサブネットに配置 Elastic IP が必要 NAT インスタンス NAT 用の AMI からインスタンスを生成（実態は EC2） 利用者側で運用する VPC ピアリング接続 VPC 間をプライベート接続 別リージョン、別アカウントの VPC への接続が可能 アドレス範囲が重複する VPC との接続はできない セキュリティ ネットワーク ACL サブネットへのアクセスを制御（サブネット単位） アウトバウンド（デフォルト：全て許可） インバウンド（デフォルト：全て許可） ステートレス 戻りのトラフィックの考慮が必要 ルール番号の小さい方から順番に適用される セキュリティグループ インスタンスへのアクセスを制御（インスタンス単位） アウトバウンド（デフォルト：全て許可） インバウンド（デフォルト：全て拒否） ステートフル 戻りのトラフィックの考慮は必要ない 仮想プライベートネットワーク（VPN） （IPsec）VPN 接続（インターネット経由） Direct Connect と比べて、[品質]：低い、[速度]：遅い、[コスト]：安い カスタマーゲートウェイ VPN 接続におけるカスタマー側のゲートウェイ 仮想プライベートゲートウェイ（VGW） VPN 接続（または Direct Connect）における VPC 側のゲートウェイ [オンプレミス][カスタマーGW]―[VPN接続]―[VGW][VPC] AWS Direct Connect（DX） 専用線での接続 VPN と比べて、[品質]：高い、[速度]：早い、[コスト]：高い Direct Connect ゲートウェイ（DXGW） 仮想インターフェース（VIF）と VGW 間に設置 VIF－VGW 間を 1 対 1 ではなく 多 対 多 で接続することができる [オンプレミス][カスタマーGW]―[DX]―[VIF][DXGW][VGW][VPC] AWS Transit Gateway（TGW） 複数の VPC や DXGW と接続してトラフィックをルーティングする L3 ルーターサービス 中央ハブを介して VPC とオンプレミスネットワークを接続 ネットワークが簡素化され、複雑なピア接続関係がなくなる VPC フローログ ENI のトラフィックをキャプチャ CloudWatch Logs または S3 に保存 VPC、サブネット、ENI 単位で取得 Amazon Route 53 Route 53 マネージド型サービス 権威 DNS サービス タイプ パブリックホストゾーン インターネットのトラフィックのルーティング方法 プライベートホストゾーン（VPC 内） VPC 内でのトラフィックのルーティング方法 Zone Apex サブドメインを含まない最上位のドメイン Route 53 のホスト名 DNS レコードタイプ NS レコード 管理を委託している DNS サーバ ホストゾーン作成時に AWS のネームサーバが自動で設定 A レコード ドメイン名から IP アドレスを参照 CNAME レコード ドメイン名から別のドメイン名を参照 Zone Apex が設定できない フェイルオーバー時 など Alias レコード AWS 独自のレコード ドメイン名から AWS リソースを参照 ルーティングポリシー シンプルルーティング 加重ルーティング 複数のリソースに対して指定した加重でルーティング AB テスト Blue／Green デプロイメント 位置情報ルーティング ユーザーの位置に応じたルーティング 国内に限定したアクセス など 地理的近接性ルーティング リソースとユーザーの距離に応じたルーティング リソースの移動 など レイテンシールーティング レイテンシーの最も低いリージョンにルーティング フェイルオーバールーティング アクティブ側のヘルスチェックが失敗した時にスタンバイ側にルーティング サーバーダウン時のフェイルオーバー、Sorry コンテンツ など 複数値回答ルーティング 異なる IP アドレスを複数登録し、ランダムでルーティング ヘルスチェック失敗時にルーティングしない トラッフィックフロー ルーティングポリシーを GUI で設定 AWS CloudFront CloudFront マネージド型サービス Content Delivery Network（CDN） エッジロケーション（1 次キャッシュサーバー） リージョン別エッジキャッシュ（2 次キャッシュサーバー） オリジンサーバー EC2、ELB、S3、オンプレミス コンテンツには WEB または RTMP（ストリーミング）が選択可能 SSL/TLS 署名付き URL 有効期限指定 ユーザーが Cookie を許可していない場合や RTMP を使用したい場合 など 署名付き Cookie 現在のオブジェクト URL を変更したくない場合 など カスタムエラーページ Sorry コンテンツ gzip 圧縮機能 リクエストヘッダーにAccept-Encoding: gzipが含まれる場合、gzip に圧縮してリソースを返却 転送速度の向上 コスト削減 地域制限（地理的ブロッキング） 特定の地域からのアクセスを遮断 国内に限定したアクセス など 動的コンテンツキャッシュ OAI（Origin Access Identity） オリジンへの直アクセスを遮断 特定のユーザーのみにコンテンツを配信 など ▲ ページの上部へ移動 4. コンピューティングサービス Amazon EC2（Amazon Elastic Compute Cloud） EC2 IaaS ハイパーバイザー型 支払方法 オンデマンド 使用した時間に対して課金 リザーブド 最大 75 % オフ 1 年間や 2 年間 などのように長期間利用する場合に使用 1 年間か 3 年間の期間を決めて支払 初期予算に応じて、全額前払い、一部前払い、前払いなしといった払い方が可能 不要になったらマーケットで販売（残りの期間に対して価格を設定） スケジュールドリザーブド（使用可能なリージョンのみ） 日次、週次、月次でスケジューリングされた買い方が可能 毎週金曜のみ利用する など 提供クラス Standard インスタンスファミリー、OS、テナンシー、支払オプションの変更を途中から変更できない convertible インスタンスファミリー、OS、テナンシー、支払オプションの変更を途中から変更できる スポット 最大 90 % オフ スポット価格が入札価格より低い場合に利用可能 スポット価格が入札価格を上回ると強制終了 一時的な作業や Auto Scaling などで利用 AMI（Amazon Machine Image） OS やソフトウェアがインストールされているマシンイメージ AMI の実態は EC2 構成情報 と スナップショット マイ AMI、Marketplace、コミュニィ AMI から設定 ルートデバイス EBS EC2 インスタンスにアタッチして利用するストレージ データ永続化（停止してもデータは消えない） Instance Store（エフェメラルディスク） EC2 インスタンスに内蔵されているストレージ 揮発性（停止するとデータは消える） インスタンスタイプ t2.micro（インスタンスファミリー + インスタンス世代 + インスタンスサイズ） インスタンスファミリー t, m：汎用 c　 ：コンピューティング最適化 r　 ：メモリ最適化 など IAM ロール ユーザーデータ EC2 インスタンス作成時に 1 度だけスクリプトを実行する セキュリティグループ キーペア プレイスメントグループ 単一の AZ 内の EC2 インスタンスを論理的にグループ化 EC2 インスタンス間の通信速度を高速化 インスタンス Dedicated（占有ホスト） 物理的にサーバーを占有するインスタンス 起動するハードウェアを固定 コンプライアンス要件でサーバーが他の利用者と同居できない場合 など ホストに対する課金 ハードウェア専有インスタンス 他の AWS アカウントに属するインスタンスから物理的に分離 同じ AWS アカウントのインスタンスとはハードウェアを共有する可能性がある（Dedicated は共有しない） インスタンスに対する課金 Elastic Load Balancing（ELB） マネージド型サービス 高可用なロードバランサー ロードバランサーの種類 Classic Load Balancer（CLB）L4, L7 レイヤー 標準的なロードバランシング 以前の世代 Application Load Balancer（ALB）L7 レイヤー CLB に加えて設定したパスや HTTP ヘッダー などのルーティングに従って振り分け HTTP／HTTPS トラフィックの負荷分散 Network Load Balancer（NLB）L4 レイヤー 毎秒数百万のリクエストを処理できる高性能なロードバランサー 低レイテンシーで高スループットが必要な場合に利用 TCP／TLS／UDP トラフィックの負荷分散 自動スケーリング ELB 自体が負荷に応じて自動スケーリング（冗長性） セキュリティ機能 SSL/TLS セキュリティグループ ヘルスチェック 失敗した場合は振り分け対象から除外 スティッキーセッション アクセスするユーザーごとに特定のサーバーに振り分け セッション中に同じユーザーからのアクセスを全て同じ EC2 インスタンスに送信する など Connect Draining インスタンスの登録を解除しても指定した時間の間はリクエストの接続を保持する クロスゾーン負荷分散 各 AZ のインスタンス毎に均等振り分け（通常は AZ 毎に均等振り分け） プレウォーミング申請 急激な負荷が予めわかっている場合、ELB を事前にスケールできる 申請は AWS サポートから行う（サポートプランは Business または Enterprise で可能） VM Import/Export 仮想マシンイメージをオンプレミスから　AMI または EC2 インスタンスとしてインポート Amazon EC2 Auto Scaling ヘルスチェックやスケジュールに基づいて EC2 インスタンスを起動または終了 耐障害性、可用性、コスト効率の向上 水平スケーリング（スケールアウト／スケールイン） 起動設定 Auto Scaling 時に起動する EC2 インスタンスを定義する AMI インスタンスタイプ ロール セキュリティグループ キーペア など Auto Scaling グループ Auto Scaling 対象の EC2 インスタンスをまとめたグループ 起動設定または起動テンプレート VPC、サブネット ロードバランサー ヘルスチェック ヘルスチェックのタイプ EC2（running であるか） ELB（ELB 側のヘルスチェック） ヘルスチェックの猶予期間 新しいインスタンスが起動してからヘルスチェックを再開するまでの時間 デフォルト：300 秒 希望する容量／最小キャパシティ／最大キャパシティ ターゲット追跡スケーリングポリシー（スケーリングポリシー） メトリックスとターゲット値を設定 平均 CPU 使用率 など 起動または停止時の SNS による通知 起動するインスタンスにタグ付け スケーリングプラン ターゲット追跡スケーリング 特定のメトリクスとターゲット値に基づいて増減 メトリックス 平均 CPU 使用率 平均ネットワーク入力 平均ネットワーク出力 ターゲット毎の ALB リクエスト数 シンプルスケーリング 特定の CloudWatch アラームとターゲット値に基づいて増減 ステップスケーリング 特定の CloudWatch アラームとターゲット値に基づいて段階的に増減 アラーム超過のサイズに基づいてインスタンス数を動的にスケーリング 50% なら 1 台追加、60% なら 2 台追加、70% なら 3 台追加 など 予定されたアクション スケジュールによるスケーリング インスタンスのスケールイン保護 新しく起動したインスタンスを保護する スケールイン保護を有効化する前に作られたインスタンスは個別に保護を行う 終了ポリシー Closest To Next Instance Hour（次の請求時間に最も近い） Newest Instance（新しいインスタンス） Oldest Instance（古いインスタンス） Oldest Launch Configuration（古い起動設定） Oldest Launch Template（古い起動テンプレート） デフォルト優先順位：古い起動設定 > 次の請求時間 > ランダム クールダウン 次のスケーリングが開始されるまでの待機時間 スケールアウト／インの繰り返しを防ぐ デフォルト：300 秒 ウォームアップ 新しいインスタンスが Auto Scaling グループのメトリック対象となるまでの待ち時間 手動スケーリング Desired capacity（希望する容量）を追加設定 Auto Scaling の起動失敗時はプロセスを終了する Amazon Auto Scaling EC2 以外も対象 スケーリング可能なリソースを選択 EC2 Auto Scaling グループ ECS DynamoDB テーブル Aurora リードレプリカ など 動的スケーリング 予測スケーリング Amazon ECS（Amazon Elastic Container Service） ECS Docker コンテナサービス オーケストレーション（様々なシステムやサービスの配置、設定、管理を自動化） 用語 Cluster タスクまたはサービスの論理グループ Docker コンテナを起動させるインスタンスの集合体 クラスターテンプレート（Fargate または EC2） VPC、サブネット、タグ、インスタンス数 などを設定 Service クラスター内で、タスク定義から指定した数のインスタンスを同時に実行して維持 起動タイプ、タスクの起動数、ELB などを設定 ELB により、サービス内のコンテナにトラフィックを分散 Auto Scaling により、サービス内のタスク数を調整 Task Definition タスクとコンテナを定義する Task タスク定義に基づいて起動するコンテナの集合 起動タイプ、メモリ、CPU、コンテナ などを設定 起動タイプ EC2 Fargate 完全マネージド型サービス EKS（Amazon Elastic Container Service for Kubernetes） 完全マネージド型サービス AWS で kubernetes 環境を構築 クラスタのプロビジョニングやスケール などの設定が不要 ECR（Amazon Elastic Container Registry） 完全マネージド型サービス Docker コンテナレジストリ AWS CLI などで Docker イメージをレジストリに登録 デフォルト暗号化 または KMS 暗号化でイメージを暗号化 AWS Lambda Lambda 完全マネージド型サービス サーバーレスで任意のコードが実行可能 自動的にスケールアウト Lambda アプリケーション Lambda 関数、イベントソース、およびその他のリソースを組み合わせたもの Lambda 関数 Blueprint（設計図） サンプルコード トリガー API Gateway S3 イベント DynamoDB ストリーム など 送信先 SNS トピック SQS キュー Lambda 関数 など メモリに応じて CPU スペックが決定 リクエストの数とコードの実行時間に基づいて課金 ディスク容量：512 MB タイムアウト：最長 15 分 同時実行数：1000 Service Quotas から上限の緩和が可能 レイヤー Lambda 関数の共通処理を共有化できる仕組み RDS Proxy RDS Proxy を使用しない場合 Lambda 関数は呼び毎に RDS へ新しいコネクションを生成するが、同時接続数の上限があるため、利用が限られる RDS Proxy によりコネクションを再利用できるようになる Lambda@Edge ユーザーに近いエッジロケーションで Lambda 関数を実行できる バージニア北部リージョンで CloudFront をトリガーとする Lambda 関数を作成する ▲ ページの上部へ移動 5. 運用支援サービス Amazon CloudWatch CloudWatch アラーム 監視しているメトリックスが閾値に達した場合にアクションを起こす CPU 使用率の閾値を 90% 以上で 3 分間継続した場合にメールを送信する など メトリックス、監視期間、閾値 などを設定 トリガー 閾値の範囲外 閾値の範囲内 データ不足 アクション SNS で通知 Auto Scaling EC2 アクション（停止、再起動、削除 など） インスタンス別メトリックスを選択する CloudWatch Logs 様々なログを統合的に収集するサービス アプリケーションログやシステムログを監視する など 用語 ロググループ ログストリームの集合 ログストリーム ログの集合 事前に送信元に IAM ロールを設定する VPC フローログ や CloudTrail から指定のロググループに出力 EC2 に CloudWatch Logs エージェントをインストールしてログを出力 CloudWatch Events AWS サービスのイベントまたはスケジュールによりアクションを起こす イベントソース イベントパターン スケジュール ターゲット イベント発火時に呼び出すターゲット メトリックス 標準メトリックス CPU 使用率 など カスタムメトリックス メモリ使用率、ディスク使用率 など EC2 基本モニタリング デフォルト 5 分間隔でモニタリンググラフが表示 無料 詳細モニタリング 1 分間隔でモニタリンググラフが表示 追加料金 AWS CloudTrail CloudTrail マネージド型サービス AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービス マネージメントコンソールや SDK API、CLI による操作をログとして記録 ログは S3 に保存 ログファイルの SSE-KMS 暗号化 CloudWatch Logs との連携 イベントタイプ 管理イベント AWS リソースで実行された管理オペレーション EC2 の起動、S3 バケットの作成 など データイベント リソース上またはリソース内で実行されたリソース操作 S3 バケット内のデータの操作、Lambda 関数の実行 など AWS Config Config AWS リソースの設定を評価、監査、審査できるサービス リソース定義のコンプライアンスチェック（定義がルールに準拠しているか） SNS または CloudWatch Events による設定変更の通知 ログは S3 に保存 データの保持期間 30 日 ～ 7 年間 ▲ ページの上部へ移動 6. ストレージサービス Amazon EBS（Amazon Elastic Block Store） EBS ブロックストレージ EC2 や RDS の保存領域 ストレージタイプ 汎用 SSD（General Purpse SSD : gp2） 仮想デスクトップ、低レイテンシーなアプリケーション、開発・テスト環境 などに利用 バースト機能 最大 IOPS：16,000 最大スループット：250 MiB/秒 プロビジョンド IOPS SSD（PIOPS : io1） 高スループットが必要なアプリケーション、大規模データーベース 最大 IOPS：64,000 最大スループット：1,000 MiB/秒 スループット最適化 HDD（st1） ビッグデータ、データーウェアハウス、ログ処理 高スループット 低コスト 最大 IOPS：500 最大スループット：500 MiB/秒 コールド HDD（sc1） アクセス頻度が低い大量データを保存、アーカイブ 低コスト 最大 IOPS：250 最大スループット：250 MiB/秒 マグネティック 旧世代 HDD [EC2] 1 ― 多 [EBS] の関係 高可用性（SLA 99.99 %） AZ 内で自動的に冗長化 スナップショット 増分バックアップ（差分取得） 非同期で取得 整合性を保つため、静止点を設けることが推奨されている（停止してから取得） リージョン間でコピーが可能 同じ AZ の EC2 にのみアタッチ可能 EBS 最適化 EC2 ― EBS 間通信に専用ネットワークを使用し、パフォーマンスを向上させる ボリュームサイズの拡張は可能、縮小は不可 ボリュームサイズの拡張後は OS 内でも作業が必要（パーティション拡張） 暗号化（スナップショットも暗号化） EBS 作成時に暗号化の設定が必要 既にインスタンスが起動している場合、スナップショットを取得し、EBS の再作成時に暗号化 RAID 0 ボリュームの I/O パフォーマンスが向上 RAID 1 ボリュームのミラーリング EBS ボリューム間でミラーリング EC2 インスタンスで利用するためには、アタッチ ⇒ ファイルシステムの作成 ⇒ マウント の作業を行う Amazon EFS（Amazon Elastic File System） EFS 完全マネージド型サービス ファイルサーバー 複数の EC2 インスタンスから同時接続が可能 容量、性能はスケーラブル 複数の AZ で冗長化されている セキュリティグループ、マウントターゲットを介して EC2 に接続 NFSv4 プロトコルを使用 ライフサイクル管理 最後のアクセスから一定日数が経過したら低頻度アクセスのストレージに移動 デフォルト暗号化 パフォーマンスモード（I/O 性能） 汎用パフォーマンスモード（デフォルト） 一般的な用途に利用する 最大 I/O パフォーマンスモード 何百、何千のクライアントからの同時アクセス など スループットを優先し、レイテンシーが多少長い モードの変更は不可 スループットモード（スループット性能） バーストスループットモード（デフォルト） 容量に応じてスループットが上昇する 一時的に処理性能を向上させるバースト機能を持つ プロビジョニングスループットモード スループットを指定する より高いスループットを必要とする場合に利用する モードの変更は可能（24 時間あける） 従量課金 Amazon S3（Amazon Simple Storage Service） S3 完全マネージド型サービス オブジェクトストレージ 高耐久性 高可用性 標準では 3 箇所のAZ に冗長化される 結果整合性 容量制限なし（従量制） 用語 バケット オブジェクトの保存場所 バケット名はグローバルで一意にする オブジェクト データ自体 メタデータ オブジェクトの属性情報 ストレージクラス スタンダード 頻繁にアクセスされるデータ インテリジェント（Intelligent-Tiering） データのアクセス頻度に応じて、最もコスト効率の良いストレージに移動 標準低頻度アクセス（Standard-IA） アクセス頻度は低いが、すぐにデータが取り出せるデータ 1 ゾーン低頻度アクセス（One Zone-IA） アクセス頻度は低いが、すぐにデータが取り出せる、重要ではないデータ 1 箇所の AZ に保存 Glacier アーカイブ 数分から数時間で取り出し Glacier Deep Archive ほとんどアクセスしないアーカイブ（1 年に 1、2 回程度） 数時間で取り出し（12 時間） Glacier よりもコストが安い マルチパートアップロード 大容量オブジェクトをいくつかのパートに分けてアップロード ライフサイクル 移行アクション 古くなったら移動 現在のバージョン：作成日からの日数に応じてストレージを変更 以前のバージョン：古いバージョンになってからの日数に応じてストレージを変更 有効期限アクション 削除マーカー または 完全削除 現在のバージョン：以前のバージョンとして保存、現バージョンは削除マーカー 以前のバージョン：完全に削除 バージョニング機能 静的 Web サイトホスティング Sorry ページ Route53 との連携はバケット名とドメイン名を合わせる（Cloud Front は不要） アクセス制御 バケットポリシー バケット、ファイル単位でアクセス制御 JSON 形式で定義 ACL バケット、ファイル単位でアクセス制御 優先度：バケットポリシー > バケット ACL > ファイル ACL IAM ポリシー ユーザー単位で S3 を含む AWS リソースへのアクセス制御 JSON 形式で定義 事前署名付き URL（期限付き URL） 最大 7 日 暗号化 SSE-S3 SSE-KMS CSE イベント処理 S3 のイベントに応じてアクションを実行 SNS、SQS、Lambda ファイルアップロード時に Lambda 関数を起動して、DyanmoDB にファイル名を格納する など Transfer Acceleration 長距離のクライアントとバケット間で高速かつ安全なファイル転送を行う CloudFront のエッジロケーションを利用 CORS クロスドメイン接続を許可 XML 形式で定義 クロスリージョンレプリケーション リージョン間でレプリケーション バージョニングの有効化が必要 S3 select CSV や JSON 形式のオブジェクトから、SQL を利用してデータを検索 Amazon S3 Glacier Glacier アーカイブ 取り出しに時間がかかる アップロードは AWS CLI や AWS SDK を利用 任意期のファイル名は設定できない 用語 ボールド バケットに相当 アーカイブ オブジェクトに相当 イベントリ メタに相当 ジョブ 取り出しオプション 高速（expedited） 1 ～ 5 分 標準（standard） 3 ～ 5 時間 大容量（bulk） 5 ～ 12 時間 最も安価 Glacier Select Glacier 上のデータに対してクエリを実行し、結果を S3 に出力する データの暗号化 SSL による転送 最低保持期間：90 日 ボールドロック 保存されたアーカイブの上書きや削除を禁止 Amazon FSx for Windows Amazon FSx for Windows 完全マネージド型サービス SMB プロトコルを使用した NTFS ファイルシステム 最大数百万の IOPS で処理が可能 ミリ秒未満のレイテンシー マルチ AZ ストレージタイプ SSD HDD デフォルト暗号化 Amazon FSx for Lustre 完全マネージド型サービス スーパーコンピュータ向けの並列分散ファイルシステム 1 秒間に最大で数百ギガバイトのスループット 百万単位の IOPS AWS Storage Gateway Storage Gateway オンプレミス環境と AWS クラウドを接続し、ハイブリットクラウドストレージを提供 ファイルゲートウェイ オンプレミスのファイルをオブジェクトとして S3 に格納 SMB または NFS で接続 S3 の機能であるライフサイクルやバージョニングなどが利用できる ボリュームゲートウェイ オンプレミスのディスクデータをスナップショットとして S3 に格納 iSCSI を使用して接続 キャッシュ型ボリュームゲートウェイ プライマリストレージは S3 頻繁にアクセスするデータはキャッシュしてローカルに保持 保管型ボリュームゲートウェイ プライマリストレージはオンプレミス 定期的にクラウドにバックアップ テープゲートウェイ 物理テープの代替として S3、Glacier に格納 iSCSI ベースの 仮想テープライブラリ（VTL）として使用 データ暗号化 SSL/TLS AWS Snow Family Snowball の専用機器を使用し、オンプレミスと S3 間で、高速な大量のデータ転送ができる AWS Snowball 50 TB、80 TB のデータ移送 AWS Snowball Edge 100 TB のデータ移送 AWS Snowmobile 100 PB のデータ移送 ▲ ページの上部へ移動 7. データベースサービス Amazon RDS（Amazon Relational Database Service） RDS 完全マネージド型サービス RDB Amazon Aurora MySQL MariaDB PostgreSQL Oracle Microsoft SQL Server インスタンスサイズ m ：標準 r, x：メモリ最適化クラス t　：バースト可能クラス インスタンスストレージ 汎用（SSD） プロビジョンド IOPS（SSD） マグネティック ストレージの自動スケーリング マルチ AZ マスター／スレーブ構成 フェイルオーバー 通常は 60 ～ 120 秒 リードレプリカ 異なる AZ でも構築可能 マスターとリードレプリカ間は非同期 最大 5 つ作成可能 自動バックアップ 1 日 1 回自動で取得 最大 35 日分保存 トランザクションログも保存 S3 に保存される インスタンス削除時に自動バックアップは自動で削除される 手動バックアップ 1 リージョン当たり 100 個まで取得可能 スナップショット取得時に短時間の I/O 中断 インスタンス削除時に手動バックアップは手動で削除が必要 リストア リストア スナップショット（バックアップ）から RDS インスタンスを新規作成 ポイントインタイムリカバリ 直近 5 分から 35 日前までの任意の状態で RDS インスタンスを新規作成 セキュリティグループ SSL/TLS データ暗号化 DB インスタンス、自動バックアップ、リードレプリカ、スナップショット が暗号化 途中からから有効にできない IAM データベース認証 IAM ユーザーとロールを介して、データベースの認証を行う シャーディング 水平分割 負荷分散方法 Amazon Aurora クラウド向けに構築された、MySQL や PostgreSQL と互換性のある分散型 RDB MySQL、PostgreSQL DB クラスタ データストレージ（クラスタボリューム） 3 箇所の AZ に 各 2 つずつのディスク、計 6 箇所に冗長化 容量は自動拡縮 Aurora サーバーレス 最小と最大のキャパシティーに基づいてリソースを自動的にスケール 特定の時期だけ DB へのアクセスが増加する場合など Aurora レプリカ 1 つのクラスタに最大 15 個まで設置可能 障害時にプライマリに昇格（フェイルオーバー） エンドポイント クラスタエンドポイント プライマリーインスタンスに接続 読み書き可能 読み取りエンドポイント レプリカインスタンスに接続 読み取りのみ可能 インスタンスエンドポイント 特定のインスタンスに接続 プライマリー 読み書き可能 レプリカインスタンス 読み取りのみ可能 カスタムエンドポイント 任意のインスタンスをグルーピングしてアクセス レプリカインスタンスを WEB 用、バッチ用に分けるなど Amazon Redshift Redshift 完全マネージド型サービス データウェアハウス RDB 列指向型 DB psql が利用可能 9 種類の圧縮エンコードをサポート ストレージからの転送量減でパフォーマンスを向上 シングル AZ 配置のみサポート Redshift クラスター リーダーノード クエリのエンドポイント ゾーンマップ 1 MBブロックのメタデータをリーダーノードのメモリ上に格納 各ブロックの最大／最小値を保持 検索を高速化 コンピュータノード クエリの並列実行（MPP） CPU、メモリ、ストレージ ノードスライス 最小単位 シェアードナッシング 各ノードごとにディスクを持つことで性能を向上 各ノードがディスクを共有しない Redshift Spectrum S3 バケット内のデータに対して直接クエリを実行 スナップショット クラスターのポイントインタイム 自動バックアップ 8 時間毎 または 5 GB 変更毎に自動取得 インスタンス削除時に自動バックアップは自動で削除される 手動バックアップ インスタンス削除時に手動バックアップは手動で削除が必要 クロスリージョンスナップショット 増分の変更をセカンダリ / DR リージョンにコピー プライマリリージョンに影響が及んだ場合に最新のデータからクラスターを復元できる 拡張 VPC ルーティング COPY（インポート）と UNLOAD（エクスポート）トラフィックを VPC 経由でルーティング セキュリティグループや ACL などの VPC の機能が利用できるようになる Amazon DynamoDB DynamoDB 完全マネージド型サービス NoSQL キーバリュー型データモデル 3 箇所の AZ に冗長化 容量無制限 用語 プライマリキー パーティションキー パーティションキー + ソートキー（複合プライマリーキー） セカンダリインデックス ローカルセカンダリインデックス（LSI） 元テーブルと同じパーティションキーと別の属性をソートキーとしたインデックス 新しく設定するキー：ソートキー 複合プライマリーキーの設定が必要 テーブル作成時のみ設定が可能 グローバルセカンダリインデックス（GSI） 元テーブルとは異なるプライマリーキーとソートキーのインデックス 新しく設定するキー：パーティションキー、ソートキー いつでも設定可能 キャパシティーモード プロビジョンド 使用するキャパシティをあらかじめ設定 キャパシティ Read Capacity Unit（RCU） Write Capacity Unit（WCU） オンデマンド 従量課金 自動スケーリング キャパシティを増減 保存時の暗号化 有効期限 TTL（Time to Live） レコードごとにに有効期限を設定 有効期限が過ぎると48 時間以内に削除 DynamoDB Stream データ変更のイベント処理 最大 24 時間の追加・更新・削除の変更履歴を保持 Consistent Read（読み取り一貫性） 結果整合性のある読み込み（デフォルト） 強力な整合性のある読み込み 3 つの AZ に保存されたデータのみを読み込む DynamoDB Accelerator（DAX） インメモリ型キャッシュクラスタ [EC2]―[DAX]―[DynamoDB] 数ミリ秒 ～ マイクロ秒での処理が可能 SQS 連携でアクセス集中を緩和 ユースケース セッション管理 ログ処理 Kinesis Data Streams で処理されたデータの蓄積 など Amazon ElastiCache ElastiCache 完全マネージド型サービス インメモリデータベース NoSQL キーバリューストア（KVS） エンジン Memcached マルチスレッド 永続性なし スナップショット機能なし フェールオーバーなし 可用性を考慮し複数のAZに作成 スケーリング スケールアウト／スケールイン ノードにデータが再マッピングされるまでキャッシュミスが増加 スケールアップ／スケールダウン クラスタの再作成が必要（データは全て削除） ユースケース シンプルなキャッシュシステムを利用したい場合 データが消えても問題ない場合 キャッシュリソースの増減が頻繁に発生する場合 Redis シングルスレッド（１コア）で動作 永続性あり クラスター毎にスナップショットが取得可能（S3 に格納） 多種のデータ型を持つ フェールオーバーあり 可用性あり ユースケース 多様なデータ型を利用したい場合 データを永続化させたい場合 障害時のフェイルオーバーやバックアップ／リストアが必要な場合 ユースケース セッションを管理 ゲームユーザーの行動データの解析 ▲ ページの上部へ移動 8. セキュリティとアイデンティティ Amazon Cognito Cognito WEB アプリケーションやモバイルアプリケーションの認証などを行うサービス ユーザープール アプリケーションのサインアップやサインインを提供 Facebook、Google でのソーシャルサインイン SAML MFA 機能 ユーザーディレクトリとユーザープロファイルの管理 ID プール 外部ユーザーが AWS サービスを一時的に使えるように AWS 認証情報を取得 AWS IAM（AWS Identity and Access Management） IAM IAM グループ IAM ユーザーの集合 1 ユーザー 10 グループまで参加可能 ポリシーを付与する IAM ユーザー AWS を操作するユーザー ユーザー名、パスワード AWS マネージメントコンソールにサインイン アクセスキー、シークレットキー CLI や API での認証 IAM グループに所属させる ポリシーを付与する MFA 認証 ルートユーザーは使用せずに極力 IAM ユーザーで AWS 操作を行う IAM ロール AWS サービスやアプリケーションに権限を付与 アクセスキーとシークレットキーが不要になる ポリシーを付与する IAM ポリシー AWS サービスやアプリケーションに対しての操作権限を定義する JSON 形式で権限を定義 Effect Allow or Deny "Effect": "Allow" など Action AWS サービス、操作 "Action": "ec2:GetConsoleScreenshot" など Resource AWS リソース "Resource": "arn:aws:ec2:*:000000000000:instance/*" など 5 世代までバージョン管理が可能 インラインポリシー IAM グループ、IAM ユーザー、IAM ロールに対して個別にポリシーを設定 一時的に権限を付与する時などに使用（通常は IAM ポリシーを使用） タグを利用することにより柔軟な権限管理が可能 STS（AWS Security Token Service） AWS サービスのアクセスに使用できる一時的な認証情報を取得 SDK を使用して認証情報を取得する アクセスキー シークレットアクセスキー セッショントークン 有効期間 IAM ユーザーの認証情報：15 分 ～ 36 時間（デフォルト：12 時間） ルートユーザーの認証情報：15 分 ～ 1 時間（デフォルト：1 時間） ユースケース AWS サービスへの一時的なアクセス ID フェデレーション（シングルサインオン） SAML 2.0 Microsoft Active Directory OPNE ID ソーシャルサービス AWS Organizations Organizations 複数の IAM アカウントを組織として一元管理 複数の AWS アカウントの請求書が 1 つに統合 組織としての使用状況を統合的に管理する 複数のアカウントに跨ってポリシーを集中管理する など AWS KSM（AWS Key Management Service） KMS 完全マネージド型サービス 暗号化に使用するマスター鍵の管理とカスタマーキーの暗号を行う 従量課金 AWS マネージド型キー AWS が管理 カスタマー管理型のキー カスタマーが管理 キーのタイプ 対称（共通鍵暗号方式） 非対称（公開鍵暗号方式） Server-Side Encryption（SSE） SSE-S3 S3 で管理された鍵を使用 AES-256 SSE-KMS KMS で管理された鍵を使用 SSE-C ユーザーが用意した鍵を使用 AES-256 Client-Side Encryption（CSE） 多くの場合は SDK を利用して暗号化 エンベロープ暗号化 Data を CDK で暗号化し、CDK を CMK で暗号化する Customer Master Key（CMK） データキーを暗号化／複合化 Customer Data Key（CDK） データを暗号化／複合化 AWS CloudHSM（AWS Cloud Hardware Security Module） CloudHSM VPC 内の占有ハードウェアで鍵を管理 国際的なセキュティ標準（FIPS 140-2 のレベル 3）に準拠 セキュリティのコンプライアンスが厳しい場合に利用 AWS ACM（AWS Certificate Manager） 証明書のプロビジョニング AWS 自身が認証局となって SSL/TLS 証明書を発行するサービス 証明書リクエスト パブリック証明書のリクエスト プライベート証明書（オレオレ証明書）のリクエスト 事前にプライベート CA を作成 証明書リクエストの検証方法 DNS E メール ACM の証明書の有効期限は 13 ヶ月 自動更新 連携可能なサービス ELB CloudFront API Gateway　など プライベート認証機関 プライベートの CA （ルート認証局／中間認証局）を作成 ▲ ページの上部へ移動 9. アプリケーションサービス Amazon SES（Amazon Simple Email Service） SES 完全マネージド型サービス E メールサービス（E メールを送受信） ドメインまたは E メールアドレスを登録して利用する（承認が必要） SDK から API を使用して送信することも可能 送受信時にウィルスやマルウェアを検知 SMS（ショートメッセージサービス）は利用できない Amazon SNS（Amazon Simple Notification Service） SNS 完全マネージド型サービス Pub/Sub メッセージングサービス プッシュ型 用語 トピック Publisher（配信者）からの通知を受信するエンドポイント タイプ Standard メッセージの順序付けはベストエフォート 少なくとも 1 回のメッセージ（2 回以上の配信もある） サブスクリプション：SQS、Lambda、HTTP、SMS、E メール、モバイルアプリケーション FIFO（先入れ先出し、先出し）（デフォルト） メッセージの順序付け 1 回のみメッセージを配信 サブスクリプション：SQS 暗号化、アクセスポリシー、タグ、CloudWatch Logs など サブスクリプション Subscriber（購読者）のエンドポイントに通知を送信する プッシュ通知 SMS Amazon SQS（Amazon Simple Queue Service） SQS 完全マネージド型サービス メッセージキューイングサービス プル型 ポーリング EC2 や Lambda からメッセージをポーリング 用語 タイプ Standard（デフォルト） メッセージの順序付けはベストエフォート 少なくとも 1 回のメッセージ（2 回以上配信もある） FIFO（先入れ先出し、先出し） メッセージの順序付け 1 回のみメッセージを配信 可視性タイムアウト 他のクライアントのメッセージ受信をタイムアウトまで防ぐ 範囲：0 ～ 12 時間 デフォル：30 秒 メッセージ保持期間 保持期間経過後にメッセージは削除される 範囲：1 ～ 14 日間 デフォルト：4 日 遅延キュー（キューの配信遅延） キューに送られてきたメッセージを一定時間見えなくする 範囲：0 ～ 15 分 最大メッセージサイズ 範囲：1 K ～ 256 K より大きいサイズは S3 や DynamoDB に保存し、パスやキーを送る メッセージ受信待機時間 メッセージが受信可能になるまでポーリングが待機 範囲：0 ～ 20 秒 デフォルト：0 秒 ショートポーリング（デフォルト） 即レスポンスを返す 回数：多、コスト：高 ロングポーリング メッセージがない場合はタイムアウトまでポーリング 回数：少、コスト：低 推奨 メッセージタイマー（メッセージの配信遅延） 個別のメッセージを一定時間見えなくする タイプがスタンダードのキューのみ利用可能 遅延キューより優先される 範囲：0 ～ 15 分 デッドレターキュー 処理できなかったメッセージを別のキューに移動 他のキューを選択 保持可能なメッセージ数 無制限 アクセスポリシー、暗号化、タグ など 優先度付きキュー 優先度の高いキューと優先度の低いキューを用意して優先度付け ユースケース 分散システムにおけるマイクロサービス間の連携 Amazon API Gateway API Gateway 完全マネージド型サービス API の作成、管理、運用を行うサービス API HTTP Websocket REST エンドポイント エッジ最適化 CloudFront のエッジロケーションにルーティング リージョン リージョンにルーティング プライベート VPC 内部でのルーティング オートスケール 従量課金 認証 Amazon SWF（Amazon Simple Workflow） SWF 完全マネージド型サービス ワークフローを構築、実行するためのサービス EC2 や オンプレミス上で実行するタスクを重複なく順番に実行する 実行が長時間に及ぶタスクをワークフローで自動化 用語 Domain（SWF） Workflow Execution や Task List を管理 Workflow Execution（SWF） ワークフローのインスタンス WorkflowStarter ワークフローを開始する 開始する毎に WorkflowExecution が作成される Desider 次の実行するタスクを決める SWF の Task List（Desider 用）をポーリングし、次のアクティビティを指定 Activity 個別のタスクを実行 SWF の Task List（Activity 用）をポーリングし、タスクを実行 AWS Step Functions Step Functions 完全マネージド型サービス ワークフローを構築、実行するためのサービス ワークフローが視覚的に確認できる 新規の場合は SWF ではなく、Step Functions の利用が推奨されている 用語 ステートマシーン ワークフロー JSON 形式で定義を行う アクティビティ EC2 や Lambda でタスクを実行したいときに使用 ロール、CloudWatch Log など ▲ ページの上部へ移動 10. 開発者ツール AWS CodeCommit CodeCommit マネージド型サービス ソースコードを管理する Git リポジトリサービス AWS CodeBuild CodeBuild マネージド型サービス ソースコードのビルド／テスティングサービス ユニットテストが可能 Java、Python、Ruby、Node.js、Docker などに対応 ソースコード取得元： CodeCommit、GitHub、Bitbucket、S3 など buildspec.yml にビルド仕様を定義する ビルドに掛かった時間の従量課金 AWS CodeDeploy CodeDeploy マネージド型サービス ビルドされたモジュール（アーティファクト）のデプロイサービス EC2、Lambda、オンプレミスにデプロイ EC2 や オンプレにデプロイする場合は CodeDeploy エージェントをインストールする appspec.yml にデプロイ仕様を定義する デプロイ方式 AllAtOnce すべてのサーバーに同時にデプロイ リリース時間は最短 ダウンタイム発生 HalfAtAtime 半分のサーバーにデプロイ 対象のサーバーを ELB から切り離し OneAtAtime 関連するサーバーを 1 つずつ ELB から切り離してデプロイ リリース時間は最長 Auto Scaling に対応 AWS CodePipeline CodePipeline CodeCommit、CodeBuild、CodeDeploy の一連の開発プロセスを自動化 GUI により現在の作業状況が視覚化 Jenkins や GitHub などの別のサービスを挟むことも可能 リリース承認プロセスを挟むことも可能 承認されるまで自動化を一時停止 AWS CodeStar CodeStar 　- CI/CD 環境を自動構築 ▲ ページの上部へ移動 11. プロビジョニングサービス AWS Elastic Beanstalk Elastic Beanstalk WEB アプリケーション環境を自動構築 EC2、セキュリティグループ、ELB、Auto Scaling、CloudFormation、CloudWatch アラーム など ヘルスチェック モニタリング レスポンス時間 CPU 使用率 など デプロイ方式 Rolling（ローリング） 既存インスタンスの一部にデプロイ 残りのインスタンスも同様に順次デプロイ Rolling with additional batch（追加バッチとローリング） インスタンスをいくつか新規に作成してデプロイ 次に既存インスタンスに順次デプロイ 残った既存インスタンスを終了 Immutable（変更不可） 必要な分のインスタンスを新規に作成してデプロイ 最後に既存のインスタンスをすべて終了 Traffic-splitting（トラフィックの分類） 必要な分のインスタンスを新規に作成してデプロイ 次に既存インスタンスに順次デプロイ 全てのインスタンスにトラフィックを送り、問題がなかったインスタンスを利用 　（新規に作成されたインスタンスが優先） All at Once（１回にすべて） 全ての既存のインスタンスを一気にデプロイ ユースケース RDS を利用した WEB アプリケーションの構築 処理時間が長いワークプロセスを実行するための環境を構築 AWS OpsWorks OpsWorks Chef や Puppet を利用した構成管理サービス 用語 Chef Chef レシピの設定に応じて、サーバ設定や更新を自動化するツール Chef-Client ローカルモード 各インスタンスがレシピを持ち自身にレシピを適用する Chef-Client/Server モード マスターサーバーを用意してレシピやレシピの適用状況などを管理する OpsWorks Stacks Chef-Client ローカルモードで Chef を利用する スタック OpsWorks のトップエンティティ スタック内で複数のレイヤーが作成可能 レイヤー インスタンスの特性ごとに作成する Chef レシピをマッピングする インスタンス レイヤーを指定して EC2 を起動するとレシピが適用される OpsWorks for Chef Automate Chef-Client/Server モードで Chef を利用する Chef Automate Chef を統合的に利用する機能 マスターサーバー／クライアントサーバー cookbook を登録した上でクライアントサーバーを起動すると クライアントサーバーにレシピが適用される OpsWorks for Puppet Enterprise Puppet と呼ばれる構成管理ツールを使用してサーバの設定、管理、プロビジョニングの自動化を行う AWS CloudFormation CloudFormation テンプレートファイルを利用して AWS リソースを構築 スタック テンプレートファイルで定義された AWS リソース群 テンプレート JSON または YAML 形式で記述 Resources（必須） AWS リソース Parameters 起動時に選択する値を定義する Mappings 実行環境（リージョンなど）に応じて変わる値を定義する Ref Parameters または Resources からの参照 FindInMap Mappings からの参照 ドリフト Stack で起動したリソースとテンプレートを比較し、差分を検出する 現在のリソースの変更点を確認し、テンプレートを更新 StackSets 組織およびリージョンに対して同一の Stack を作成 デザイナー テンプレートを GUI で作成 ▲ ページの上部へ移動 12. 分析サービス Amazon EMR（Amazon Elastic MapReduce） EMR Hadoop、Hbase、Presto、Spark といったオープンソース型フレームワークを使用して、膨大な量のデータを処理・分析するサービス 分散処理フレームワーク 分散処理に必要な EC2 の調達・破棄など 伸縮自在性 EC2 を必要に応じて増減 デフォルトでは解析完了時にリソース開放 コスト スポットインスタンスのオプション EMRFS S3 を HDFS のように扱える AWS Glue Glue 完全マネージド型サービス データの抽出や変換、ロードなどが行えるサービス ETL（Extract Transform Load） オートスケール 従量課金 ▲ ページの上部へ移動 13. ETL ツール Amazon Kinesis Amazon Kinesis Data Streams 完全マネージド型サービス 大量に流れてくるログデータや IoT データ（ストリーミングデータ）をリアルタイムに収集、処理、分析できる ストリームデータをリアルタイムのグラフに表示するなど Kinesis Data Firehose よりデータロードが早い 用語 プロデューサー データレコードを Kinesis Data Streams にデータを送信する Amazon Kinesis エージェント AWS SDK Amazon Kinesis Producer Library (KPL) コンシューマ Amazon Kinesis Data Streams からデータレコードを取得して処理する Amazon Kinesis Data Analytics Amazon Kinesis Data Firehose Amazon Kinesis Client Library (KCL) データレコード Kinesis data stream に保存されるデータ シーケンス番号、パーティションキー、データ BLOB で構成 シーケンス番号 シャード内のパーティションキーごとのシーケンス番号 パーティションキー パーティションキーをもとに各シャードへ分離 データ BLOB 最大：1 MB 保存期間 デフォルト：24 時間 最大：7 日間 シャード ストリーム内の一意に識別されたデータレコードのシーケンス シャード数に応じてスループットを調整（スケールアップ） 暗号化 Kinesis Data Firehose 完全マネージド型サービス 大量のログデータなどを S3、Redshift、Elasticsearch に配信でき、分析用途などで使用する ゼロ管理 暗号化 配信前のデータ圧縮（GZIP、ZIP、SNAPPY） Kinesis Data Analytics 完全マネージド型サービス リアルタイムのストリーミングデータを SQL などでフィルタリングして出力できる Kinesis Video Streams 完全マネージド型サービス 動画の分析、機械学習、再生などを行うために、AWS へストリーミングできる ビデオチャットや P2P のメディアストリーミングなど ▲ ページの上部へ移動
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T17:38:15+09:00

AWS 認定ソリューションアーキテクト対策メモ

このページは自身が学習しながらメモに残したもの（2020 年 10 月時点）であり、以降はサービスの変更や内容の誤りなどがあった場合でも、更新しないことを予めお詫びいたします。
基本をしっかり押さえて、ハンズオンやサンプル問題などを実施することが大事だと考えます。

目次

1. AWS Well-Architected フレームワークの構成

  • AWS Well-Architected フレームワークホワイトペーパー
    • フレームワークの 5 本柱
      • 運用上の優秀性
      • セキュリティ
      • 信頼性
      • パフォーマンス効率
      • コスト最適化
  • チェックリスト

▲ ページの上部へ移動

2. リージョンとアベイラビリティゾーン

  • リージョン
    • 地理的に離れた地域
    • オハイオ（us-east-2）、東京（ap-northeast-1）など
    • 初期はバージニア北部（us-east-1）
  • アベイラビリティーゾーン（AZ）
    • データセンターの集合
    • 地理的、電源的に独立
    • ap-northeast-1a、ap-northeast-1c など
  • ローカルリージョン
    • DR（Disaster Recovery：災害復旧）を目的としたリージョン
    • 大阪 など
  • エッジロケーション
    • 地理的に近いエッジロケーションから低レイテンシーなサービスを提供
    • Amazon CloudFront や Amazon Route 53 など
  • AWS のサービス
    • グローバルサービス
      • IAM
      • CloudFront
      • Route 53 など
    • リージョンサービス
      • VPC
      • DynamoDB
      • Lambda など
    • アベイラビリティーゾーンサービス
      • VPC のサブネット
      • EC2
      • RDS など

▲ ページの上部へ移動

3. ネットワークサービス

Amazon VPC（Amazon Vitual Private Cloud）

  • VPC
    • 仮想プライベートクラウド
    • DNS hostnames オプション
      • EC2 インスタンス作成時にパブリック DNS ホスト名が割り当てられる
      • デフォルト：有効
    • サブネット
      • VCP 内に最大 200 個作成可能
      • ネットマスクは /16 ～ /28 の範囲で作成可能
        • IP アドレス数：(32:1, 31:2, 30:4, 29:8,) 28:16, 27:32, 26:64, 25:128, 24:256
      • IP アドレスの最初の 4 つと最後の 1 つは AWS 側で予約されている
      • パブリックサブネット
        • ルートテーブルにインターネットゲートウェイを設定
        • 内外両方向で通信が可能
      • プライベートサブネットでのインターネット接続
        • パブリックサブネットに NAT ゲートウェイを設定し、パブリックサブネットとプライベートサブネットを接続
        • 外向きのみ通信が可能
    • ルートテーブル
      • メインルートテーブル
        • VPC に設定されたルートテーブルのこと
          • サブネットのルートテーブルが未設定の場合に使用される
    • イーターネットゲートウェイ（IGW）
      • VPC とインターネットとの間で通信ができるようになる
      • インターネットが接続できない場合、以下を確認する
        • インターネットゲートウェイが VPC または サブネット に設定されている
        • EC2 にパブリック IP アドレスが付与されている
        • セキュリティグループで許可されている
        • ネットワーク ACL で拒否していない
    • Elastic IP（EIP）
      • 固定のグローバル IP アドレス
      • 課金対象
        • EC2 にアタッチされていない場合
        • EC2 にアタッチされているが EC2 が停止している場合
    • VPC エンドポイント
      • インターネットを介さずに、VPC と他の AWS サービスをプライベート接続できる
      • Gatway 型
        • ルートテーブルに指定されたターゲットを追加し、ゲートウェイ経由で AWS の API エンドポイントにアクセス
        • S3 と DynamoDB
        • アクセス制御はゲートウェイのアクセスポリシー
      • Interface 型
        • サービスのエンドポイント と ENI を PrivateLink でリンク
        • S3 と DynamoDB 以外の大半
        • アクセス制御はセキュリティグループ
    • NAT ゲートウェイ
      • マネージド型サービス
      • パブリックサブネットに配置
      • Elastic IP が必要
    • NAT インスタンス
      • NAT 用の AMI からインスタンスを生成（実態は EC2）
      • 利用者側で運用する
    • VPC ピアリング接続
      • VPC 間をプライベート接続
      • 別リージョン、別アカウントの VPC への接続が可能
      • アドレス範囲が重複する VPC との接続はできない
  • セキュリティ
    • ネットワーク ACL
      • サブネットへのアクセスを制御（サブネット単位）
      • アウトバウンド（デフォルト：全て許可）
      • インバウンド（デフォルト：全て許可）
      • ステートレス
        • 戻りのトラフィックの考慮が必要
      • ルール番号の小さい方から順番に適用される
    • セキュリティグループ
      • インスタンスへのアクセスを制御（インスタンス単位）
      • アウトバウンド（デフォルト：全て許可）
      • インバウンド（デフォルト：全て拒否）
      • ステートフル
        • 戻りのトラフィックの考慮は必要ない
  • 仮想プライベートネットワーク（VPN）
    • （IPsec）VPN 接続（インターネット経由）
    • Direct Connect と比べて、[品質]：低い、[速度]：遅い、[コスト]：安い
    • カスタマーゲートウェイ
      • VPN 接続におけるカスタマー側のゲートウェイ
    • 仮想プライベートゲートウェイ（VGW）
      • VPN 接続（または Direct Connect）における VPC 側のゲートウェイ
    • [オンプレミス][カスタマーGW]―[VPN接続]―[VGW][VPC]
  • AWS Direct Connect（DX）
    • 専用線での接続
    • VPN と比べて、[品質]：高い、[速度]：早い、[コスト]：高い
    • Direct Connect ゲートウェイ（DXGW）
      • 仮想インターフェース（VIF）と VGW 間に設置
      • VIF－VGW 間を 1 対 1 ではなく 多 対 多 で接続することができる
    • [オンプレミス][カスタマーGW]―[DX]―[VIF][DXGW][VGW][VPC]
  • AWS Transit Gateway（TGW）
    • 複数の VPC や DXGW と接続してトラフィックをルーティングする L3 ルーターサービス
    • 中央ハブを介して VPC とオンプレミスネットワークを接続
    • ネットワークが簡素化され、複雑なピア接続関係がなくなる
  • VPC フローログ
    • ENI のトラフィックをキャプチャ
    • CloudWatch Logs または S3 に保存
    • VPC、サブネット、ENI 単位で取得

Amazon Route 53

  • Route 53
    • マネージド型サービス
    • 権威 DNS サービス
    • タイプ
      • パブリックホストゾーン
        • インターネットのトラフィックのルーティング方法
      • プライベートホストゾーン（VPC 内）
        • VPC 内でのトラフィックのルーティング方法
    • Zone Apex
      • サブドメインを含まない最上位のドメイン
      • Route 53 のホスト名
    • DNS レコードタイプ
      • NS レコード
        • 管理を委託している DNS サーバ
        • ホストゾーン作成時に AWS のネームサーバが自動で設定
      • A レコード
        • ドメイン名から IP アドレスを参照
      • CNAME レコード
        • ドメイン名から別のドメイン名を参照
        • Zone Apex が設定できない
        • フェイルオーバー時 など
      • Alias レコード
        • AWS 独自のレコード
        • ドメイン名から AWS リソースを参照
    • ルーティングポリシー
      • シンプルルーティング
      • 加重ルーティング
        • 複数のリソースに対して指定した加重でルーティング
        • AB テスト
        • Blue／Green デプロイメント
      • 位置情報ルーティング
        • ユーザーの位置に応じたルーティング
        • 国内に限定したアクセス など
      • 地理的近接性ルーティング
        • リソースとユーザーの距離に応じたルーティング
        • リソースの移動 など
      • レイテンシールーティング
        • レイテンシーの最も低いリージョンにルーティング
      • フェイルオーバールーティング
        • アクティブ側のヘルスチェックが失敗した時にスタンバイ側にルーティング
        • サーバーダウン時のフェイルオーバー、Sorry コンテンツ など
      • 複数値回答ルーティング
        • 異なる IP アドレスを複数登録し、ランダムでルーティング
        • ヘルスチェック失敗時にルーティングしない
  • トラッフィックフロー
    • ルーティングポリシーを GUI で設定

AWS CloudFront

  • CloudFront
    • マネージド型サービス
    • Content Delivery Network（CDN）
    • エッジロケーション（1 次キャッシュサーバー）
    • リージョン別エッジキャッシュ（2 次キャッシュサーバー）
    • オリジンサーバー
      • EC2、ELB、S3、オンプレミス
    • コンテンツには WEB または RTMP（ストリーミング）が選択可能
    • SSL/TLS
    • 署名付き URL
      • 有効期限指定
      • ユーザーが Cookie を許可していない場合や RTMP を使用したい場合 など
    • 署名付き Cookie
      • 現在のオブジェクト URL を変更したくない場合 など
    • カスタムエラーページ
      • Sorry コンテンツ
    • gzip 圧縮機能
      • リクエストヘッダーにAccept-Encoding: gzipが含まれる場合、gzip に圧縮してリソースを返却
      • 転送速度の向上
      • コスト削減
    • 地域制限（地理的ブロッキング）
      • 特定の地域からのアクセスを遮断
      • 国内に限定したアクセス など
    • 動的コンテンツキャッシュ
    • OAI（Origin Access Identity）
      • オリジンへの直アクセスを遮断
      • 特定のユーザーのみにコンテンツを配信 など

▲ ページの上部へ移動

4. コンピューティングサービス

Amazon EC2（Amazon Elastic Compute Cloud）

  • EC2
    • IaaS
    • ハイパーバイザー型
    • 支払方法
      • オンデマンド
        • 使用した時間に対して課金
      • リザーブド
        • 最大 75 % オフ
        • 1 年間や 2 年間 などのように長期間利用する場合に使用
        • 1 年間か 3 年間の期間を決めて支払
        • 初期予算に応じて、全額前払い、一部前払い、前払いなしといった払い方が可能
        • 不要になったらマーケットで販売（残りの期間に対して価格を設定）
        • スケジュールドリザーブド（使用可能なリージョンのみ）
          • 日次、週次、月次でスケジューリングされた買い方が可能
          • 毎週金曜のみ利用する など
        • 提供クラス
          • Standard
            • インスタンスファミリー、OS、テナンシー、支払オプションの変更を途中から変更できない
          • convertible
            • インスタンスファミリー、OS、テナンシー、支払オプションの変更を途中から変更できる
      • スポット
        • 最大 90 % オフ
        • スポット価格が入札価格より低い場合に利用可能
        • スポット価格が入札価格を上回ると強制終了
        • 一時的な作業や Auto Scaling などで利用
    • AMI（Amazon Machine Image）
      • OS やソフトウェアがインストールされているマシンイメージ
      • AMI の実態は EC2 構成情報 と スナップショット
      • マイ AMI、Marketplace、コミュニィ AMI から設定
      • ルートデバイス
        • EBS
          • EC2 インスタンスにアタッチして利用するストレージ
            • データ永続化（停止してもデータは消えない）
        • Instance Store（エフェメラルディスク）
          • EC2 インスタンスに内蔵されているストレージ
            • 揮発性（停止するとデータは消える）
    • インスタンスタイプ
      • t2.micro（インスタンスファミリー + インスタンス世代 + インスタンスサイズ）
      • インスタンスファミリー
        • t, m：汎用
        • c　 ：コンピューティング最適化
        • r　 ：メモリ最適化 など
    • IAM ロール
    • ユーザーデータ
      • EC2 インスタンス作成時に 1 度だけスクリプトを実行する
    • セキュリティグループ
    • キーペア
    • プレイスメントグループ
      • 単一の AZ 内の EC2 インスタンスを論理的にグループ化
      • EC2 インスタンス間の通信速度を高速化
  • インスタンス
    • Dedicated（占有ホスト）
      • 物理的にサーバーを占有するインスタンス
      • 起動するハードウェアを固定
      • コンプライアンス要件でサーバーが他の利用者と同居できない場合 など
      • ホストに対する課金
    • ハードウェア専有インスタンス
      • 他の AWS アカウントに属するインスタンスから物理的に分離
      • 同じ AWS アカウントのインスタンスとはハードウェアを共有する可能性がある（Dedicated は共有しない）
      • インスタンスに対する課金
  • Elastic Load Balancing（ELB）
    • マネージド型サービス
    • 高可用なロードバランサー
    • ロードバランサーの種類
      • Classic Load Balancer（CLB）L4, L7 レイヤー
        • 標準的なロードバランシング
        • 以前の世代
      • Application Load Balancer（ALB）L7 レイヤー
        • CLB に加えて設定したパスや HTTP ヘッダー などのルーティングに従って振り分け
        • HTTP／HTTPS トラフィックの負荷分散
      • Network Load Balancer（NLB）L4 レイヤー
        • 毎秒数百万のリクエストを処理できる高性能なロードバランサー
        • 低レイテンシーで高スループットが必要な場合に利用
        • TCP／TLS／UDP トラフィックの負荷分散
    • 自動スケーリング
      • ELB 自体が負荷に応じて自動スケーリング（冗長性）
    • セキュリティ機能
      • SSL/TLS
      • セキュリティグループ
    • ヘルスチェック
      • 失敗した場合は振り分け対象から除外
    • スティッキーセッション
      • アクセスするユーザーごとに特定のサーバーに振り分け
      • セッション中に同じユーザーからのアクセスを全て同じ EC2 インスタンスに送信する など
    • Connect Draining
      • インスタンスの登録を解除しても指定した時間の間はリクエストの接続を保持する
    • クロスゾーン負荷分散
      • 各 AZ のインスタンス毎に均等振り分け（通常は AZ 毎に均等振り分け）
    • プレウォーミング申請
      • 急激な負荷が予めわかっている場合、ELB を事前にスケールできる
      • 申請は AWS サポートから行う（サポートプランは Business または Enterprise で可能）
  • VM Import/Export
    • 仮想マシンイメージをオンプレミスから　AMI または EC2 インスタンスとしてインポート
  • Amazon EC2 Auto Scaling
    • ヘルスチェックやスケジュールに基づいて EC2 インスタンスを起動または終了
    • 耐障害性、可用性、コスト効率の向上
    • 水平スケーリング（スケールアウト／スケールイン）
    • 起動設定
      • Auto Scaling 時に起動する EC2 インスタンスを定義する
      • AMI
      • インスタンスタイプ
      • ロール
      • セキュリティグループ
      • キーペア など
    • Auto Scaling グループ
      • Auto Scaling 対象の EC2 インスタンスをまとめたグループ
      • 起動設定または起動テンプレート
      • VPC、サブネット
      • ロードバランサー
      • ヘルスチェック
        • ヘルスチェックのタイプ
          • EC2（running であるか）
          • ELB（ELB 側のヘルスチェック）
        • ヘルスチェックの猶予期間
          • 新しいインスタンスが起動してからヘルスチェックを再開するまでの時間
          • デフォルト：300 秒
      • 希望する容量／最小キャパシティ／最大キャパシティ
      • ターゲット追跡スケーリングポリシー（スケーリングポリシー）
        • メトリックスとターゲット値を設定
        • 平均 CPU 使用率 など
      • 起動または停止時の SNS による通知
      • 起動するインスタンスにタグ付け
      • スケーリングプラン
        • ターゲット追跡スケーリング
          • 特定のメトリクスとターゲット値に基づいて増減
          • メトリックス
            • 平均 CPU 使用率
            • 平均ネットワーク入力
            • 平均ネットワーク出力
            • ターゲット毎の ALB リクエスト数
        • シンプルスケーリング
          • 特定の CloudWatch アラームとターゲット値に基づいて増減
        • ステップスケーリング
          • 特定の CloudWatch アラームとターゲット値に基づいて段階的に増減
            • アラーム超過のサイズに基づいてインスタンス数を動的にスケーリング
            • 50% なら 1 台追加、60% なら 2 台追加、70% なら 3 台追加 など
      • 予定されたアクション
        • スケジュールによるスケーリング
      • インスタンスのスケールイン保護
        • 新しく起動したインスタンスを保護する
        • スケールイン保護を有効化する前に作られたインスタンスは個別に保護を行う
      • 終了ポリシー
        • Closest To Next Instance Hour（次の請求時間に最も近い）
        • Newest Instance（新しいインスタンス）
        • Oldest Instance（古いインスタンス）
        • Oldest Launch Configuration（古い起動設定）
        • Oldest Launch Template（古い起動テンプレート）
        • デフォルト優先順位：古い起動設定 > 次の請求時間 > ランダム
      • クールダウン
        • 次のスケーリングが開始されるまでの待機時間
        • スケールアウト／インの繰り返しを防ぐ
        • デフォルト：300 秒
      • ウォームアップ
        • 新しいインスタンスが Auto Scaling グループのメトリック対象となるまでの待ち時間
    • 手動スケーリング
      • Desired capacity（希望する容量）を追加設定
    • Auto Scaling の起動失敗時はプロセスを終了する
  • Amazon Auto Scaling
    • EC2 以外も対象
    • スケーリング可能なリソースを選択
      • EC2 Auto Scaling グループ
      • ECS
      • DynamoDB テーブル
      • Aurora リードレプリカ など
    • 動的スケーリング
    • 予測スケーリング

Amazon ECS（Amazon Elastic Container Service）

  • ECS
    • Docker コンテナサービス
    • オーケストレーション（様々なシステムやサービスの配置、設定、管理を自動化）
    • 用語
      • Cluster
        • タスクまたはサービスの論理グループ
        • Docker コンテナを起動させるインスタンスの集合体
        • クラスターテンプレート（Fargate または EC2）
        • VPC、サブネット、タグ、インスタンス数 などを設定
      • Service
        • クラスター内で、タスク定義から指定した数のインスタンスを同時に実行して維持
        • 起動タイプ、タスクの起動数、ELB などを設定
        • ELB により、サービス内のコンテナにトラフィックを分散
        • Auto Scaling により、サービス内のタスク数を調整
      • Task Definition
        • タスクとコンテナを定義する
        • Task
          • タスク定義に基づいて起動するコンテナの集合
        • 起動タイプ、メモリ、CPU、コンテナ などを設定
    • 起動タイプ
      • EC2
      • Fargate
        • 完全マネージド型サービス
  • EKS（Amazon Elastic Container Service for Kubernetes）
    • 完全マネージド型サービス
    • AWS で kubernetes 環境を構築
    • クラスタのプロビジョニングやスケール などの設定が不要
  • ECR（Amazon Elastic Container Registry）
    • 完全マネージド型サービス
    • Docker コンテナレジストリ
    • AWS CLI などで Docker イメージをレジストリに登録
    • デフォルト暗号化 または KMS 暗号化でイメージを暗号化

AWS Lambda

  • Lambda
    • 完全マネージド型サービス
    • サーバーレスで任意のコードが実行可能
    • 自動的にスケールアウト
    • Lambda アプリケーション
      • Lambda 関数、イベントソース、およびその他のリソースを組み合わせたもの
    • Lambda 関数
      • Blueprint（設計図）
        • サンプルコード
      • トリガー
        • API Gateway
        • S3 イベント
        • DynamoDB ストリーム など
      • 送信先
        • SNS トピック
        • SQS キュー
        • Lambda 関数 など
    • メモリに応じて CPU スペックが決定
    • リクエストの数とコードの実行時間に基づいて課金
    • ディスク容量：512 MB
    • タイムアウト：最長 15 分
    • 同時実行数：1000
      • Service Quotas から上限の緩和が可能
  • レイヤー
    • Lambda 関数の共通処理を共有化できる仕組み
  • RDS Proxy
    • RDS Proxy を使用しない場合
      • Lambda 関数は呼び毎に RDS へ新しいコネクションを生成するが、同時接続数の上限があるため、利用が限られる
    • RDS Proxy によりコネクションを再利用できるようになる
  • Lambda@Edge
    • ユーザーに近いエッジロケーションで Lambda 関数を実行できる
    • バージニア北部リージョンで CloudFront をトリガーとする Lambda 関数を作成する

▲ ページの上部へ移動

5. 運用支援サービス

Amazon CloudWatch

  • CloudWatch アラーム
    • 監視しているメトリックスが閾値に達した場合にアクションを起こす
    • CPU 使用率の閾値を 90% 以上で 3 分間継続した場合にメールを送信する など
    • メトリックス、監視期間、閾値 などを設定
    • トリガー
      • 閾値の範囲外
      • 閾値の範囲内
      • データ不足
    • アクション
      • SNS で通知
      • Auto Scaling
      • EC2 アクション（停止、再起動、削除 など）
        • インスタンス別メトリックスを選択する
  • CloudWatch Logs
    • 様々なログを統合的に収集するサービス
    • アプリケーションログやシステムログを監視する など
    • 用語
      • ロググループ
        • ログストリームの集合
      • ログストリーム
        • ログの集合
    • 事前に送信元に IAM ロールを設定する
    • VPC フローログ や CloudTrail から指定のロググループに出力
    • EC2 に CloudWatch Logs エージェントをインストールしてログを出力
  • CloudWatch Events
    • AWS サービスのイベントまたはスケジュールによりアクションを起こす
    • イベントソース
      • イベントパターン
      • スケジュール
    • ターゲット
      • イベント発火時に呼び出すターゲット
  • メトリックス
    • 標準メトリックス
      • CPU 使用率 など
    • カスタムメトリックス
      • メモリ使用率、ディスク使用率 など
  • EC2
    • 基本モニタリング
      • デフォルト
      • 5 分間隔でモニタリンググラフが表示
      • 無料
    • 詳細モニタリング
      • 1 分間隔でモニタリンググラフが表示
      • 追加料金

AWS CloudTrail

  • CloudTrail
    • マネージド型サービス
    • AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービス
    • マネージメントコンソールや SDK API、CLI による操作をログとして記録
    • ログは S3 に保存
    • ログファイルの SSE-KMS 暗号化
    • CloudWatch Logs との連携
    • イベントタイプ
      • 管理イベント
        • AWS リソースで実行された管理オペレーション
        • EC2 の起動、S3 バケットの作成 など
      • データイベント
        • リソース上またはリソース内で実行されたリソース操作
        • S3 バケット内のデータの操作、Lambda 関数の実行 など

AWS Config

  • Config
    • AWS リソースの設定を評価、監査、審査できるサービス
    • リソース定義のコンプライアンスチェック（定義がルールに準拠しているか）
    • SNS または CloudWatch Events による設定変更の通知
    • ログは S3 に保存
    • データの保持期間
      • 30 日 ～ 7 年間

▲ ページの上部へ移動

6. ストレージサービス

Amazon EBS（Amazon Elastic Block Store）

  • EBS
    • ブロックストレージ
    • EC2 や RDS の保存領域
    • ストレージタイプ
      • 汎用 SSD（General Purpse SSD : gp2）
        • 仮想デスクトップ、低レイテンシーなアプリケーション、開発・テスト環境 などに利用
        • バースト機能
        • 最大 IOPS：16,000
        • 最大スループット：250 MiB/秒
      • プロビジョンド IOPS SSD（PIOPS : io1）
        • 高スループットが必要なアプリケーション、大規模データーベース
        • 最大 IOPS：64,000
        • 最大スループット：1,000 MiB/秒
      • スループット最適化 HDD（st1）
        • ビッグデータ、データーウェアハウス、ログ処理
        • 高スループット
        • 低コスト
        • 最大 IOPS：500
        • 最大スループット：500 MiB/秒
      • コールド HDD（sc1）
        • アクセス頻度が低い大量データを保存、アーカイブ
        • 低コスト
        • 最大 IOPS：250
        • 最大スループット：250 MiB/秒
      • マグネティック
        • 旧世代 HDD
    • [EC2] 1 ― 多 [EBS] の関係
    • 高可用性（SLA 99.99 %）
      • AZ 内で自動的に冗長化
    • スナップショット
      • 増分バックアップ（差分取得）
      • 非同期で取得
      • 整合性を保つため、静止点を設けることが推奨されている（停止してから取得）
      • リージョン間でコピーが可能
    • 同じ AZ の EC2 にのみアタッチ可能
    • EBS 最適化
      • EC2 ― EBS 間通信に専用ネットワークを使用し、パフォーマンスを向上させる
    • ボリュームサイズの拡張は可能、縮小は不可
    • ボリュームサイズの拡張後は OS 内でも作業が必要（パーティション拡張）
    • 暗号化（スナップショットも暗号化）
      • EBS 作成時に暗号化の設定が必要
      • 既にインスタンスが起動している場合、スナップショットを取得し、EBS の再作成時に暗号化
    • RAID 0
      • ボリュームの I/O パフォーマンスが向上
    • RAID 1
      • ボリュームのミラーリング
      • EBS ボリューム間でミラーリング
    • EC2 インスタンスで利用するためには、アタッチ ⇒ ファイルシステムの作成 ⇒ マウント の作業を行う

Amazon EFS（Amazon Elastic File System）

  • EFS
    • 完全マネージド型サービス
    • ファイルサーバー
    • 複数の EC2 インスタンスから同時接続が可能
    • 容量、性能はスケーラブル
    • 複数の AZ で冗長化されている
    • セキュリティグループ、マウントターゲットを介して EC2 に接続
    • NFSv4 プロトコルを使用
    • ライフサイクル管理
      • 最後のアクセスから一定日数が経過したら低頻度アクセスのストレージに移動
    • デフォルト暗号化
    • パフォーマンスモード（I/O 性能）
      • 汎用パフォーマンスモード（デフォルト）
        • 一般的な用途に利用する
      • 最大 I/O パフォーマンスモード
        • 何百、何千のクライアントからの同時アクセス など
        • スループットを優先し、レイテンシーが多少長い
      • モードの変更は不可
    • スループットモード（スループット性能）
      • バーストスループットモード（デフォルト）
        • 容量に応じてスループットが上昇する
        • 一時的に処理性能を向上させるバースト機能を持つ
      • プロビジョニングスループットモード
        • スループットを指定する
        • より高いスループットを必要とする場合に利用する
      • モードの変更は可能（24 時間あける）
    • 従量課金

Amazon S3（Amazon Simple Storage Service）

  • S3
    • 完全マネージド型サービス
    • オブジェクトストレージ
    • 高耐久性
    • 高可用性
      • 標準では 3 箇所のAZ に冗長化される
    • 結果整合性
    • 容量制限なし（従量制）
    • 用語
      • バケット
        • オブジェクトの保存場所
        • バケット名はグローバルで一意にする
      • オブジェクト
        • データ自体
      • メタデータ
        • オブジェクトの属性情報
    • ストレージクラス
      • スタンダード
        • 頻繁にアクセスされるデータ
      • インテリジェント（Intelligent-Tiering）
        • データのアクセス頻度に応じて、最もコスト効率の良いストレージに移動
      • 標準低頻度アクセス（Standard-IA）
        • アクセス頻度は低いが、すぐにデータが取り出せるデータ
      • 1 ゾーン低頻度アクセス（One Zone-IA）
        • アクセス頻度は低いが、すぐにデータが取り出せる、重要ではないデータ
        • 1 箇所の AZ に保存
      • Glacier
        • アーカイブ
        • 数分から数時間で取り出し
      • Glacier Deep Archive
        • ほとんどアクセスしないアーカイブ（1 年に 1、2 回程度）
        • 数時間で取り出し（12 時間）
        • Glacier よりもコストが安い
    • マルチパートアップロード
      • 大容量オブジェクトをいくつかのパートに分けてアップロード
    • ライフサイクル
      • 移行アクション
        • 古くなったら移動
        • 現在のバージョン：作成日からの日数に応じてストレージを変更
        • 以前のバージョン：古いバージョンになってからの日数に応じてストレージを変更
      • 有効期限アクション
        • 削除マーカー または 完全削除
        • 現在のバージョン：以前のバージョンとして保存、現バージョンは削除マーカー
        • 以前のバージョン：完全に削除
    • バージョニング機能
    • 静的 Web サイトホスティング
      • Sorry ページ
      • Route53 との連携はバケット名とドメイン名を合わせる（Cloud Front は不要）
    • アクセス制御
      • バケットポリシー
        • バケット、ファイル単位でアクセス制御
        • JSON 形式で定義
      • ACL
        • バケット、ファイル単位でアクセス制御
        • 優先度：バケットポリシー > バケット ACL > ファイル ACL
      • IAM ポリシー
        • ユーザー単位で S3 を含む AWS リソースへのアクセス制御
        • JSON 形式で定義
    • 事前署名付き URL（期限付き URL）
      • 最大 7 日
    • 暗号化
      • SSE-S3
      • SSE-KMS
      • CSE
    • イベント処理
      • S3 のイベントに応じてアクションを実行
      • SNS、SQS、Lambda
      • ファイルアップロード時に Lambda 関数を起動して、DyanmoDB にファイル名を格納する など
    • Transfer Acceleration
      • 長距離のクライアントとバケット間で高速かつ安全なファイル転送を行う
      • CloudFront のエッジロケーションを利用
    • CORS
      • クロスドメイン接続を許可
      • XML 形式で定義
    • クロスリージョンレプリケーション
      • リージョン間でレプリケーション
      • バージョニングの有効化が必要
    • S3 select
      • CSV や JSON 形式のオブジェクトから、SQL を利用してデータを検索

Amazon S3 Glacier

  • Glacier
    • アーカイブ
    • 取り出しに時間がかかる
    • アップロードは AWS CLI や AWS SDK を利用
    • 任意期のファイル名は設定できない
    • 用語
      • ボールド
        • バケットに相当
      • アーカイブ
        • オブジェクトに相当
      • イベントリ
        • メタに相当
      • ジョブ
        • 取り出しオプション
          • 高速（expedited）
            • 1 ～ 5 分
          • 標準（standard）
            • 3 ～ 5 時間
          • 大容量（bulk）
            • 5 ～ 12 時間
            • 最も安価
    • Glacier Select
      • Glacier 上のデータに対してクエリを実行し、結果を S3 に出力する
    • データの暗号化
    • SSL による転送
    • 最低保持期間：90 日
    • ボールドロック
      • 保存されたアーカイブの上書きや削除を禁止

Amazon FSx for Windows

  • Amazon FSx for Windows
    • 完全マネージド型サービス
    • SMB プロトコルを使用した NTFS ファイルシステム
    • 最大数百万の IOPS で処理が可能
    • ミリ秒未満のレイテンシー
    • マルチ AZ
    • ストレージタイプ
      • SSD
      • HDD
    • デフォルト暗号化
  • Amazon FSx for Lustre
    • 完全マネージド型サービス
    • スーパーコンピュータ向けの並列分散ファイルシステム
    • 1 秒間に最大で数百ギガバイトのスループット
    • 百万単位の IOPS

AWS Storage Gateway

  • Storage Gateway
    • オンプレミス環境と AWS クラウドを接続し、ハイブリットクラウドストレージを提供
    • ファイルゲートウェイ
      • オンプレミスのファイルをオブジェクトとして S3 に格納
      • SMB または NFS で接続
      • S3 の機能であるライフサイクルやバージョニングなどが利用できる
    • ボリュームゲートウェイ
      • オンプレミスのディスクデータをスナップショットとして S3 に格納
      • iSCSI を使用して接続
      • キャッシュ型ボリュームゲートウェイ
        • プライマリストレージは S3
        • 頻繁にアクセスするデータはキャッシュしてローカルに保持
      • 保管型ボリュームゲートウェイ
        • プライマリストレージはオンプレミス
        • 定期的にクラウドにバックアップ
    • テープゲートウェイ
      • 物理テープの代替として S3、Glacier に格納
      • iSCSI ベースの 仮想テープライブラリ（VTL）として使用
    • データ暗号化
    • SSL/TLS

AWS Snow Family

  • Snowball の専用機器を使用し、オンプレミスと S3 間で、高速な大量のデータ転送ができる
  • AWS Snowball
    • 50 TB、80 TB のデータ移送
  • AWS Snowball Edge
    • 100 TB のデータ移送
  • AWS Snowmobile
    • 100 PB のデータ移送

▲ ページの上部へ移動

7. データベースサービス

Amazon RDS（Amazon Relational Database Service）

  • RDS
    • 完全マネージド型サービス
    • RDB
      • Amazon Aurora
      • MySQL
      • MariaDB
      • PostgreSQL
      • Oracle
      • Microsoft SQL Server
    • インスタンスサイズ
      • m ：標準
      • r, x：メモリ最適化クラス
      • t　：バースト可能クラス
    • インスタンスストレージ
      • 汎用（SSD）
      • プロビジョンド IOPS（SSD）
      • マグネティック
    • ストレージの自動スケーリング
    • マルチ AZ
      • マスター／スレーブ構成
      • フェイルオーバー
        • 通常は 60 ～ 120 秒
    • リードレプリカ
      • 異なる AZ でも構築可能
      • マスターとリードレプリカ間は非同期
      • 最大 5 つ作成可能
    • 自動バックアップ
      • 1 日 1 回自動で取得
      • 最大 35 日分保存
      • トランザクションログも保存
      • S3 に保存される
      • インスタンス削除時に自動バックアップは自動で削除される
    • 手動バックアップ
      • 1 リージョン当たり 100 個まで取得可能
      • スナップショット取得時に短時間の I/O 中断
      • インスタンス削除時に手動バックアップは手動で削除が必要
    • リストア
      • リストア
        • スナップショット（バックアップ）から RDS インスタンスを新規作成
      • ポイントインタイムリカバリ
        • 直近 5 分から 35 日前までの任意の状態で RDS インスタンスを新規作成
    • セキュリティグループ
    • SSL/TLS
    • データ暗号化
      • DB インスタンス、自動バックアップ、リードレプリカ、スナップショット が暗号化
      • 途中からから有効にできない
    • IAM データベース認証
      • IAM ユーザーとロールを介して、データベースの認証を行う
    • シャーディング
      • 水平分割
      • 負荷分散方法
  • Amazon Aurora
    • クラウド向けに構築された、MySQL や PostgreSQL と互換性のある分散型 RDB
    • MySQL、PostgreSQL
    • DB クラスタ
      • データストレージ（クラスタボリューム）
    • 3 箇所の AZ に 各 2 つずつのディスク、計 6 箇所に冗長化
    • 容量は自動拡縮
    • Aurora サーバーレス
      • 最小と最大のキャパシティーに基づいてリソースを自動的にスケール
      • 特定の時期だけ DB へのアクセスが増加する場合など
    • Aurora レプリカ
      • 1 つのクラスタに最大 15 個まで設置可能
      • 障害時にプライマリに昇格（フェイルオーバー）
    • エンドポイント
      • クラスタエンドポイント
        • プライマリーインスタンスに接続
        • 読み書き可能
      • 読み取りエンドポイント
        • レプリカインスタンスに接続
        • 読み取りのみ可能
      • インスタンスエンドポイント
        • 特定のインスタンスに接続
        • プライマリー
          • 読み書き可能
        • レプリカインスタンス
          • 読み取りのみ可能
      • カスタムエンドポイント
        • 任意のインスタンスをグルーピングしてアクセス
        • レプリカインスタンスを WEB 用、バッチ用に分けるなど

Amazon Redshift

  • Redshift
    • 完全マネージド型サービス
    • データウェアハウス
    • RDB
    • 列指向型 DB
    • psql が利用可能
    • 9 種類の圧縮エンコードをサポート
      • ストレージからの転送量減でパフォーマンスを向上
    • シングル AZ 配置のみサポート
    • Redshift クラスター
      • リーダーノード
        • クエリのエンドポイント
        • ゾーンマップ
          • 1 MBブロックのメタデータをリーダーノードのメモリ上に格納
          • 各ブロックの最大／最小値を保持
          • 検索を高速化
      • コンピュータノード
        • クエリの並列実行（MPP）
        • CPU、メモリ、ストレージ
        • ノードスライス
          • 最小単位
    • シェアードナッシング
      • 各ノードごとにディスクを持つことで性能を向上
      • 各ノードがディスクを共有しない
    • Redshift Spectrum
      • S3 バケット内のデータに対して直接クエリを実行
    • スナップショット
      • クラスターのポイントインタイム
      • 自動バックアップ
        • 8 時間毎 または 5 GB 変更毎に自動取得
        • インスタンス削除時に自動バックアップは自動で削除される
      • 手動バックアップ
        • インスタンス削除時に手動バックアップは手動で削除が必要
    • クロスリージョンスナップショット
      • 増分の変更をセカンダリ / DR リージョンにコピー
      • プライマリリージョンに影響が及んだ場合に最新のデータからクラスターを復元できる
    • 拡張 VPC ルーティング
      • COPY（インポート）と UNLOAD（エクスポート）トラフィックを VPC 経由でルーティング
      • セキュリティグループや ACL などの VPC の機能が利用できるようになる

Amazon DynamoDB

  • DynamoDB
    • 完全マネージド型サービス
    • NoSQL
    • キーバリュー型データモデル
    • 3 箇所の AZ に冗長化
    • 容量無制限
    • 用語
      • プライマリキー
        • パーティションキー
        • パーティションキー + ソートキー（複合プライマリーキー）
      • セカンダリインデックス
        • ローカルセカンダリインデックス（LSI）
          • 元テーブルと同じパーティションキーと別の属性をソートキーとしたインデックス
          • 新しく設定するキー：ソートキー
          • 複合プライマリーキーの設定が必要
          • テーブル作成時のみ設定が可能
        • グローバルセカンダリインデックス（GSI）
          • 元テーブルとは異なるプライマリーキーとソートキーのインデックス
          • 新しく設定するキー：パーティションキー、ソートキー
          • いつでも設定可能
    • キャパシティーモード
      • プロビジョンド
        • 使用するキャパシティをあらかじめ設定
        • キャパシティ
          • Read Capacity Unit（RCU）
          • Write Capacity Unit（WCU）
      • オンデマンド
        • 従量課金
    • 自動スケーリング
      • キャパシティを増減
    • 保存時の暗号化
    • 有効期限 TTL（Time to Live）
      • レコードごとにに有効期限を設定
      • 有効期限が過ぎると48 時間以内に削除
    • DynamoDB Stream
      • データ変更のイベント処理
      • 最大 24 時間の追加・更新・削除の変更履歴を保持
    • Consistent Read（読み取り一貫性）
      • 結果整合性のある読み込み（デフォルト）
      • 強力な整合性のある読み込み
        • 3 つの AZ に保存されたデータのみを読み込む
    • DynamoDB Accelerator（DAX）
      • インメモリ型キャッシュクラスタ
      • [EC2]―[DAX]―[DynamoDB]
      • 数ミリ秒 ～ マイクロ秒での処理が可能
    • SQS 連携でアクセス集中を緩和
    • ユースケース
      • セッション管理
      • ログ処理
      • Kinesis Data Streams で処理されたデータの蓄積 など

Amazon ElastiCache

  • ElastiCache
    • 完全マネージド型サービス
    • インメモリデータベース
    • NoSQL
      • キーバリューストア（KVS）
    • エンジン
      • Memcached
        • マルチスレッド
        • 永続性なし
        • スナップショット機能なし
        • フェールオーバーなし
          • 可用性を考慮し複数のAZに作成
        • スケーリング
          • スケールアウト／スケールイン
            • ノードにデータが再マッピングされるまでキャッシュミスが増加
          • スケールアップ／スケールダウン
            • クラスタの再作成が必要（データは全て削除）
        • ユースケース
          • シンプルなキャッシュシステムを利用したい場合
          • データが消えても問題ない場合
          • キャッシュリソースの増減が頻繁に発生する場合
      • Redis
        • シングルスレッド（１コア）で動作
        • 永続性あり
        • クラスター毎にスナップショットが取得可能（S3 に格納）
        • 多種のデータ型を持つ
        • フェールオーバーあり
          • 可用性あり
        • ユースケース
          • 多様なデータ型を利用したい場合
          • データを永続化させたい場合
          • 障害時のフェイルオーバーやバックアップ／リストアが必要な場合
    • ユースケース
      • セッションを管理
      • ゲームユーザーの行動データの解析

▲ ページの上部へ移動

8. セキュリティとアイデンティティ

Amazon Cognito

  • Cognito
    • WEB アプリケーションやモバイルアプリケーションの認証などを行うサービス
    • ユーザープール
      • アプリケーションのサインアップやサインインを提供
      • Facebook、Google でのソーシャルサインイン
      • SAML
      • MFA 機能
      • ユーザーディレクトリとユーザープロファイルの管理
    • ID プール
      • 外部ユーザーが AWS サービスを一時的に使えるように AWS 認証情報を取得

AWS IAM（AWS Identity and Access Management）

  • IAM
    • IAM グループ
      • IAM ユーザーの集合
      • 1 ユーザー 10 グループまで参加可能
      • ポリシーを付与する
    • IAM ユーザー
      • AWS を操作するユーザー
      • ユーザー名、パスワード
        • AWS マネージメントコンソールにサインイン
      • アクセスキー、シークレットキー
        • CLI や API での認証
      • IAM グループに所属させる
      • ポリシーを付与する
      • MFA 認証
      • ルートユーザーは使用せずに極力 IAM ユーザーで AWS 操作を行う
    • IAM ロール
      • AWS サービスやアプリケーションに権限を付与
      • アクセスキーとシークレットキーが不要になる
      • ポリシーを付与する
    • IAM ポリシー
      • AWS サービスやアプリケーションに対しての操作権限を定義する
      • JSON 形式で権限を定義
        • Effect
          • Allow or Deny
          • "Effect": "Allow" など
        • Action
          • AWS サービス、操作
          • "Action": "ec2:GetConsoleScreenshot" など
        • Resource
          • AWS リソース
          • "Resource": "arn:aws:ec2:*:000000000000:instance/*" など
      • 5 世代までバージョン管理が可能
      • インラインポリシー
        • IAM グループ、IAM ユーザー、IAM ロールに対して個別にポリシーを設定
        • 一時的に権限を付与する時などに使用（通常は IAM ポリシーを使用）
      • タグを利用することにより柔軟な権限管理が可能
  • STS（AWS Security Token Service）
    • AWS サービスのアクセスに使用できる一時的な認証情報を取得
    • SDK を使用して認証情報を取得する
      • アクセスキー
      • シークレットアクセスキー
      • セッショントークン
    • 有効期間
      • IAM ユーザーの認証情報：15 分 ～ 36 時間（デフォルト：12 時間）
      • ルートユーザーの認証情報：15 分 ～ 1 時間（デフォルト：1 時間）
    • ユースケース
      • AWS サービスへの一時的なアクセス
      • ID フェデレーション（シングルサインオン）
        • SAML 2.0
          • Microsoft Active Directory
        • OPNE ID
          • ソーシャルサービス

AWS Organizations

  • Organizations
    • 複数の IAM アカウントを組織として一元管理
    • 複数の AWS アカウントの請求書が 1 つに統合
    • 組織としての使用状況を統合的に管理する
    • 複数のアカウントに跨ってポリシーを集中管理する など

AWS KSM（AWS Key Management Service）

  • KMS
    • 完全マネージド型サービス
    • 暗号化に使用するマスター鍵の管理とカスタマーキーの暗号を行う
    • 従量課金
    • AWS マネージド型キー
      • AWS が管理
    • カスタマー管理型のキー
      • カスタマーが管理
    • キーのタイプ
      • 対称（共通鍵暗号方式）
      • 非対称（公開鍵暗号方式）
  • Server-Side Encryption（SSE）
    • SSE-S3
      • S3 で管理された鍵を使用
      • AES-256
    • SSE-KMS
      • KMS で管理された鍵を使用
    • SSE-C
      • ユーザーが用意した鍵を使用
      • AES-256
  • Client-Side Encryption（CSE）
    • 多くの場合は SDK を利用して暗号化
    • エンベロープ暗号化
      • Data を CDK で暗号化し、CDK を CMK で暗号化する
      • Customer Master Key（CMK）
        • データキーを暗号化／複合化
      • Customer Data Key（CDK）
        • データを暗号化／複合化

AWS CloudHSM（AWS Cloud Hardware Security Module）

  • CloudHSM
    • VPC 内の占有ハードウェアで鍵を管理
    • 国際的なセキュティ標準（FIPS 140-2 のレベル 3）に準拠
    • セキュリティのコンプライアンスが厳しい場合に利用

AWS ACM（AWS Certificate Manager）

  • 証明書のプロビジョニング
    • AWS 自身が認証局となって SSL/TLS 証明書を発行するサービス
    • 証明書リクエスト
      • パブリック証明書のリクエスト
      • プライベート証明書（オレオレ証明書）のリクエスト
        • 事前にプライベート CA を作成
    • 証明書リクエストの検証方法
      • DNS
      • E メール
    • ACM の証明書の有効期限は 13 ヶ月
      • 自動更新
    • 連携可能なサービス
      • ELB
      • CloudFront
      • API Gateway　など
  • プライベート認証機関
    • プライベートの CA （ルート認証局／中間認証局）を作成

▲ ページの上部へ移動

9. アプリケーションサービス

Amazon SES（Amazon Simple Email Service）

  • SES
    • 完全マネージド型サービス
    • E メールサービス（E メールを送受信）
    • ドメインまたは E メールアドレスを登録して利用する（承認が必要）
    • SDK から API を使用して送信することも可能
    • 送受信時にウィルスやマルウェアを検知
    • SMS（ショートメッセージサービス）は利用できない

Amazon SNS（Amazon Simple Notification Service）

  • SNS
    • 完全マネージド型サービス
    • Pub/Sub メッセージングサービス
    • プッシュ型
    • 用語
      • トピック
        • Publisher（配信者）からの通知を受信するエンドポイント
        • タイプ
          • Standard
            • メッセージの順序付けはベストエフォート
            • 少なくとも 1 回のメッセージ（2 回以上の配信もある）
            • サブスクリプション：SQS、Lambda、HTTP、SMS、E メール、モバイルアプリケーション
          • FIFO（先入れ先出し、先出し）（デフォルト）
            • メッセージの順序付け
            • 1 回のみメッセージを配信
            • サブスクリプション：SQS
        • 暗号化、アクセスポリシー、タグ、CloudWatch Logs など
      • サブスクリプション
        • Subscriber（購読者）のエンドポイントに通知を送信する
    • プッシュ通知
    • SMS

Amazon SQS（Amazon Simple Queue Service）

  • SQS
    • 完全マネージド型サービス
    • メッセージキューイングサービス
    • プル型
    • ポーリング
      • EC2 や Lambda からメッセージをポーリング
    • 用語
      • タイプ
        • Standard（デフォルト）
          • メッセージの順序付けはベストエフォート
          • 少なくとも 1 回のメッセージ（2 回以上配信もある）
        • FIFO（先入れ先出し、先出し）
          • メッセージの順序付け
          • 1 回のみメッセージを配信
      • 可視性タイムアウト
        • 他のクライアントのメッセージ受信をタイムアウトまで防ぐ
        • 範囲：0 ～ 12 時間
        • デフォル：30 秒
      • メッセージ保持期間
        • 保持期間経過後にメッセージは削除される
        • 範囲：1 ～ 14 日間
        • デフォルト：4 日
      • 遅延キュー（キューの配信遅延）
        • キューに送られてきたメッセージを一定時間見えなくする
        • 範囲：0 ～ 15 分
      • 最大メッセージサイズ
        • 範囲：1 K ～ 256 K
        • より大きいサイズは S3 や DynamoDB に保存し、パスやキーを送る
      • メッセージ受信待機時間
        • メッセージが受信可能になるまでポーリングが待機
        • 範囲：0 ～ 20 秒
        • デフォルト：0 秒
        • ショートポーリング（デフォルト）
          • 即レスポンスを返す
          • 回数：多、コスト：高
        • ロングポーリング
          • メッセージがない場合はタイムアウトまでポーリング
          • 回数：少、コスト：低
          • 推奨
      • メッセージタイマー（メッセージの配信遅延）
        • 個別のメッセージを一定時間見えなくする
        • タイプがスタンダードのキューのみ利用可能
        • 遅延キューより優先される
        • 範囲：0 ～ 15 分
      • デッドレターキュー
        • 処理できなかったメッセージを別のキューに移動
        • 他のキューを選択
      • 保持可能なメッセージ数
        • 無制限
    • アクセスポリシー、暗号化、タグ など
    • 優先度付きキュー
      • 優先度の高いキューと優先度の低いキューを用意して優先度付け
    • ユースケース
      • 分散システムにおけるマイクロサービス間の連携

Amazon API Gateway

  • API Gateway
    • 完全マネージド型サービス
    • API の作成、管理、運用を行うサービス
    • API
      • HTTP
      • Websocket
      • REST
    • エンドポイント
      • エッジ最適化
        • CloudFront のエッジロケーションにルーティング
      • リージョン
        • リージョンにルーティング
      • プライベート
        • VPC 内部でのルーティング
    • オートスケール
    • 従量課金
    • 認証

Amazon SWF（Amazon Simple Workflow）

  • SWF
    • 完全マネージド型サービス
    • ワークフローを構築、実行するためのサービス
    • EC2 や オンプレミス上で実行するタスクを重複なく順番に実行する
    • 実行が長時間に及ぶタスクをワークフローで自動化
    • 用語
      • Domain（SWF）
        • Workflow Execution や Task List を管理
      • Workflow Execution（SWF）
        • ワークフローのインスタンス
      • WorkflowStarter
        • ワークフローを開始する
        • 開始する毎に WorkflowExecution が作成される
      • Desider
        • 次の実行するタスクを決める
        • SWF の Task List（Desider 用）をポーリングし、次のアクティビティを指定
      • Activity
        • 個別のタスクを実行
        • SWF の Task List（Activity 用）をポーリングし、タスクを実行

AWS Step Functions

  • Step Functions
    • 完全マネージド型サービス
    • ワークフローを構築、実行するためのサービス
    • ワークフローが視覚的に確認できる
    • 新規の場合は SWF ではなく、Step Functions の利用が推奨されている
    • 用語
      • ステートマシーン
        • ワークフロー
        • JSON 形式で定義を行う
      • アクティビティ
        • EC2 や Lambda でタスクを実行したいときに使用
    • ロール、CloudWatch Log など

▲ ページの上部へ移動

10. 開発者ツール

AWS CodeCommit

  • CodeCommit
    • マネージド型サービス
    • ソースコードを管理する Git リポジトリサービス

AWS CodeBuild

  • CodeBuild
    • マネージド型サービス
    • ソースコードのビルド／テスティングサービス
    • ユニットテストが可能
    • Java、Python、Ruby、Node.js、Docker などに対応
    • ソースコード取得元： CodeCommit、GitHub、Bitbucket、S3 など
    • buildspec.yml にビルド仕様を定義する
    • ビルドに掛かった時間の従量課金

AWS CodeDeploy

  • CodeDeploy
    • マネージド型サービス
    • ビルドされたモジュール（アーティファクト）のデプロイサービス
    • EC2、Lambda、オンプレミスにデプロイ
    • EC2 や オンプレにデプロイする場合は CodeDeploy エージェントをインストールする
    • appspec.yml にデプロイ仕様を定義する
    • デプロイ方式
      • AllAtOnce
        • すべてのサーバーに同時にデプロイ
        • リリース時間は最短
        • ダウンタイム発生
      • HalfAtAtime
        • 半分のサーバーにデプロイ
        • 対象のサーバーを ELB から切り離し
      • OneAtAtime
        • 関連するサーバーを 1 つずつ ELB から切り離してデプロイ
        • リリース時間は最長
    • Auto Scaling に対応

AWS CodePipeline

  • CodePipeline
    • CodeCommit、CodeBuild、CodeDeploy の一連の開発プロセスを自動化
    • GUI により現在の作業状況が視覚化
    • Jenkins や GitHub などの別のサービスを挟むことも可能
    • リリース承認プロセスを挟むことも可能
      • 承認されるまで自動化を一時停止

AWS CodeStar

  • CodeStar 　- CI/CD 環境を自動構築

▲ ページの上部へ移動

11. プロビジョニングサービス

AWS Elastic Beanstalk

  • Elastic Beanstalk
    • WEB アプリケーション環境を自動構築
      • EC2、セキュリティグループ、ELB、Auto Scaling、CloudFormation、CloudWatch アラーム など
      • ヘルスチェック
      • モニタリング
        • レスポンス時間
        • CPU 使用率 など
    • デプロイ方式
      • Rolling（ローリング）
        • 既存インスタンスの一部にデプロイ
        • 残りのインスタンスも同様に順次デプロイ
      • Rolling with additional batch（追加バッチとローリング）
        • インスタンスをいくつか新規に作成してデプロイ
        • 次に既存インスタンスに順次デプロイ
        • 残った既存インスタンスを終了
      • Immutable（変更不可）
        • 必要な分のインスタンスを新規に作成してデプロイ
        • 最後に既存のインスタンスをすべて終了
      • Traffic-splitting（トラフィックの分類）
        • 必要な分のインスタンスを新規に作成してデプロイ
        • 次に既存インスタンスに順次デプロイ
        • 全てのインスタンスにトラフィックを送り、問題がなかったインスタンスを利用 　（新規に作成されたインスタンスが優先）
      • All at Once（１回にすべて）
        • 全ての既存のインスタンスを一気にデプロイ
    • ユースケース
      • RDS を利用した WEB アプリケーションの構築
      • 処理時間が長いワークプロセスを実行するための環境を構築

AWS OpsWorks

  • OpsWorks
    • Chef や Puppet を利用した構成管理サービス
    • 用語
      • Chef
        • Chef レシピの設定に応じて、サーバ設定や更新を自動化するツール
      • Chef-Client ローカルモード
        • 各インスタンスがレシピを持ち自身にレシピを適用する
      • Chef-Client/Server モード
        • マスターサーバーを用意してレシピやレシピの適用状況などを管理する
    • OpsWorks Stacks
      • Chef-Client ローカルモードで Chef を利用する
      • スタック
        • OpsWorks のトップエンティティ
        • スタック内で複数のレイヤーが作成可能
      • レイヤー
        • インスタンスの特性ごとに作成する
        • Chef レシピをマッピングする
      • インスタンス
        • レイヤーを指定して EC2 を起動するとレシピが適用される
    • OpsWorks for Chef Automate
      • Chef-Client/Server モードで Chef を利用する
      • Chef Automate
        • Chef を統合的に利用する機能
        • マスターサーバー／クライアントサーバー
        • cookbook を登録した上でクライアントサーバーを起動すると クライアントサーバーにレシピが適用される
    • OpsWorks for Puppet Enterprise
      • Puppet と呼ばれる構成管理ツールを使用してサーバの設定、管理、プロビジョニングの自動化を行う

AWS CloudFormation

  • CloudFormation
    • テンプレートファイルを利用して AWS リソースを構築
    • スタック
      • テンプレートファイルで定義された AWS リソース群
      • テンプレート
        • JSON または YAML 形式で記述
        • Resources（必須）
          • AWS リソース
        • Parameters
          • 起動時に選択する値を定義する
        • Mappings
          • 実行環境（リージョンなど）に応じて変わる値を定義する
        • Ref
          • Parameters または Resources からの参照
        • FindInMap
          • Mappings からの参照
      • ドリフト
        • Stack で起動したリソースとテンプレートを比較し、差分を検出する
        • 現在のリソースの変更点を確認し、テンプレートを更新
    • StackSets
      • 組織およびリージョンに対して同一の Stack を作成
    • デザイナー
      • テンプレートを GUI で作成

▲ ページの上部へ移動

12. 分析サービス

Amazon EMR（Amazon Elastic MapReduce）

  • EMR
    • Hadoop、Hbase、Presto、Spark といったオープンソース型フレームワークを使用して、膨大な量のデータを処理・分析するサービス
    • 分散処理フレームワーク
    • 分散処理に必要な EC2 の調達・破棄など
      • 伸縮自在性
        • EC2 を必要に応じて増減
        • デフォルトでは解析完了時にリソース開放
      • コスト
        • スポットインスタンスのオプション
    • EMRFS
      • S3 を HDFS のように扱える

AWS Glue

  • Glue
    • 完全マネージド型サービス
    • データの抽出や変換、ロードなどが行えるサービス
    • ETL（Extract Transform Load）
    • オートスケール
    • 従量課金

▲ ページの上部へ移動

13. ETL ツール

Amazon Kinesis

  • Amazon Kinesis Data Streams

    • 完全マネージド型サービス
    • 大量に流れてくるログデータや IoT データ（ストリーミングデータ）をリアルタイムに収集、処理、分析できる
    • ストリームデータをリアルタイムのグラフに表示するなど
    • Kinesis Data Firehose よりデータロードが早い
    • 用語
      • プロデューサー
        • データレコードを Kinesis Data Streams にデータを送信する
        • Amazon Kinesis エージェント
        • AWS SDK
        • Amazon Kinesis Producer Library (KPL)
      • コンシューマ
        • Amazon Kinesis Data Streams からデータレコードを取得して処理する
        • Amazon Kinesis Data Analytics
        • Amazon Kinesis Data Firehose
        • Amazon Kinesis Client Library (KCL)
      • データレコード
        • Kinesis data stream に保存されるデータ
        • シーケンス番号、パーティションキー、データ BLOB で構成
          • シーケンス番号
            • シャード内のパーティションキーごとのシーケンス番号
          • パーティションキー
            • パーティションキーをもとに各シャードへ分離
          • データ BLOB
            • 最大：1 MB
        • 保存期間
          • デフォルト：24 時間
          • 最大：7 日間
      • シャード
        • ストリーム内の一意に識別されたデータレコードのシーケンス
        • シャード数に応じてスループットを調整（スケールアップ）
    • 暗号化

  • Kinesis Data Firehose

    • 完全マネージド型サービス
    • 大量のログデータなどを S3、Redshift、Elasticsearch に配信でき、分析用途などで使用する
    • ゼロ管理
    • 暗号化
    • 配信前のデータ圧縮（GZIP、ZIP、SNAPPY）

  • Kinesis Data Analytics

    • 完全マネージド型サービス
    • リアルタイムのストリーミングデータを SQL などでフィルタリングして出力できる

  • Kinesis Video Streams

    • 完全マネージド型サービス
    • 動画の分析、機械学習、再生などを行うために、AWS へストリーミングできる
    • ビデオチャットや P2P のメディアストリーミングなど

▲ ページの上部へ移動

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T15:55:49+09:00

DynamoDBのDocumentClient使用時にValidationExceptionでハマった

JavaScriptに慣れていない私が、AWS Lambdaでイベントから年(year)を受け取り、Dynamo DBに問い合わせるコードを書いていたところ、Lambda側のテストでValidationExceptionが発生しました。

const AWS = require("aws-sdk");
AWS.config.update({region: "ap-northeast-1"});
let docClient = new AWS.DynamoDB.DocumentClient();

exports.handler = function(event, context){
    // イベントから渡された年を変数に設定（設定されていない場合は2020年に設定）
    let input_year = 0;
    if (event.year == ""){
      input_year = 2020;
    }else{
      input_year = event.year;
    }

    // DynamoDBクエリ用のパラメータを設定
    let params = {
      TableName: 'xxxxxxxxxxx',
      KeyConditionExpression: '#yr = :hkey',
      ExpressionAttributeNames:{ "#yr": "year" },
      ExpressionAttributeValues: { ':hkey': input_year }
    };

    // クエリを実施（ここでエラー）
    docClient.query(params, function(err, data) {
      if (err) {
        console.log(err);
      } else {
        console.log("Query succeeded.");
      }
      context.done(null, resultMap);
    });
  }
};

↓実行結果

ValidationException: One or more parameter values were invalid: Condition parameter type does not match schema type

怪しそうなところ

    let input_year = 0;
    if (event.year == ""){
      input_year = 2020; // 数値
    }else{
      input_year = event.year; // 文字列
    }

数字と文字列が混在してるのはやばいんじゃない？（コーディングしたのは自分）

検証

上記の部分を、以下に置き換えて実行しました。

    let input_year = 2020; // 数値にしたところ成功

    let input_year = '2020'; // 文字列にしたところエラー

今回はDBのyearを数値で設定していたため、変数の型とDBの型を統一し、数値にしてあげる必要がありそうです。

修正後

    let input_year = 0;
    if (event.year == ""){
      input_year = 2020;
    }else{
      input_year = parseInt(event.year, 10); // 数値に変換したところエラーがなくなった
    }

余談

なぜか、修正前のコードでも、APIGatewayから叩くとエラーにならなかったんですよね、謎。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T15:26:50+09:00

EC2に自動デプロイ後、変更が反映されていないときの対処法

内容としてはタイトルにある通りですが、EC２に自動デプロイを行った際に変更が反映されておらず、めちゃめちゃ焦りました。
今後同じことがあったときに焦ることがないよう、備忘録として残しておきます。

環境

AWS EC2
Ruby 2.6.5
Rails 6.0.3.3
capistrano

結論

EC2インスタンスを再起動する。
自動デプロイを複数回行うと変更が反映されないことがあるためその際はインスタンスの再起動を行います。
再起動手順についてはこちらの記事にわかりやすく解説されています。

最後に

インスタンスの再起動を行った際はデータベースとNginxの再起動も忘れずに行うこと！

1.EC2インスタンスにログイン

ターミナル
hoge@MacBook ~ % cd .ssh  
hoge@MacBook .ssh % ssh -i ダウンロードした鍵の名前.pem ec2-user@該当EC2インスタンスと紐付けたElastic IP

2.データーベース(今回はmariaDB)とNginxの再起動を行う

ターミナル
[ec2-user@ip-173-41-45-198 ~]$ sudo systemctl restart mariadb 
[ec2-user@ip-173-41-45-198 ~]$ sudo systemctl restart nginx
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T13:15:51+09:00

Auroraのカスタムエンドポイントからインスタンスを減らすとアクセス不能になる

※本件、カスタムエンドポイントで確認。
（Reader Endpointで同様に起こるかは未確認）

Auroraにはオートスケーリング機能があり、一定時間高い負荷がかかると自動的にインスタンスが増える仕組みになっています。

しかしながら、この設定を戻す時（インスタンスが減る時）にアクセス不能になる不具合があります。

Auroraを減らす前は以下のように正常にANSER SECTIONが返ってきますが、

$ dig xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26437
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com. IN A

;; ANSWER SECTION:
xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME xxxxx003.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com.
xxxxx003.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.151.166
;; Query time: 4 msec

;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Mon Nov 16 10:15:54 2020
;; MSG SIZE  rcvd: 151

手動でカスタムエンドポイントから増えたインスタンスを削除すると、ANSWER SECTIONが返ってこない状態になります。（約15分間、返ってきたりこなかったりする）

$ dig xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43227
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:
;xxxxx-ro-service.cluster-custom-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com. IN A

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Mon Nov 16 10:33:18 JST 2020
;; MSG SIZE  rcvd: 108

AWSに本件を質問したところ、以下の回答でした。
（2020/11/16現在、まだ改善はされていない様子）

カスタムエンドポイントからインスタンスを削除した際、
しばらくAレコードが返却されなくなるのは、恐れ入りますが、
現在の仕様となっております。

したがって、こちらを発生させないようにすることはできません。
ご期待に沿えない回答となり申し訳ございません。

代替案としては、変更後のカスタムエンドポイントを別に作成いただき、
アプリケーション側でエンドポイントを切り替えることで変更する方法が考えられます。
アプリケーション側の改修が必要となってしまい恐縮ですが、
ご検討いただけますと幸いです。

なお、こちらの仕様については、他のお客様からも機能改善のご要望をいただいており、
現在サービス担当部署にて検討中となっております。
具体的な日時等詳細は未定ですが、
本ケースもサービス担当部署へフィードバックさせていただきました。

回避方法

ワークアラウンドとして、カスタムエンドポイントをもう一つコピーしておき、以下の手順で都に戻します。

  • アプリケーション側でコピーしたカスタムエンドポイントに切り替える
  • カスタムエンドポイントから増えてしまったAuroraをエントリから外す
  • 増えてしまったAuroraを削除する
  • ↑の15分後に、アプリケーション側で元のカスタムエンドポイントに戻す
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T12:07:32+09:00

[AWS] Ubuntu EC2インスタンスに意図的に負荷をかけ、CloudWatchでメトリクスを確認する

検証などのため、意図的にEC2インスタンスに負荷をかけたい場合があります。今回は、Ubuntuインスタンスで試す機会がありましたので、手順をまとめておきます。前回の記事(メモリ使用率をCloudWatchに連携) はこれをまとめるための長い前振りでした．．．

CPU

stress-ngコマンド、あるいはopensslコマンドで負荷をかけることが可能です。

インストール手順：

$ sudo apt-get update
$ sudo apt install stress-ng
$ sudo apt install openssl

stress-ngコマンドの実行オプション：

$ stress-ng --cpu <vCPU数> -l <CPU使用率> -t <実行時間>

CPU負荷をかける場合
・-cpu： CPUの負荷試験を行う場合に指定する。CPUのコア数を指定する。
・-l： CPUの使用率を指定する。指定した数字(%)の負荷がかけられる。
・-t： 実行時間を指定する。
      数字のみの場合は秒数指定、数字の後に m, h, dを付けると分、時間、日の指定となる。

例として、t3a.mediumインスタンス(vCPU数2)でコマンド実行した結果は以下のようになります。指定した90%まで使用率が上昇していることが確認できます。

$ stress-ng --cpu 2 -l 90 -t 15m

image.png

他にはopensslコマンドを使う方法もあります。本来アルゴリズム速度を計測するものですが、CPUを100%使うため負荷テスト代わりに使うことができます。

$ openssl speed -multi <vCPU数>

t3a.mediumインスタンスで試したところ25分ほど使用率が100%になりました。

image.png

メモリ

メモリもstress-ngコマンドで負荷をかけることが可能です。CloudWatchで確認するためには事前に 前回記事の手順 でエージェントの設定をしておきます。

$ stress-ng -m <ワーカー数> --vm-bytes <メモリ消費量> -t <実行時間>

メモリ負荷をかける場合
・-m： 負荷をかけるワーカー数。急激にかけるのでなければ1を指定するとよい。
・--vm-bytes： 
      メモリ消費量を指定する。数字の後に単位を付けて
      b(バイト), k(キロバイト), m(メガバイト), g(ギガバイト), %(割合)での指定が可能。
      ワーカー数を増やした場合、この指定 × ワーカー数の負荷がかかるので注意。
・-t： 実行時間を指定する。
      数字のみの場合は秒数指定、数字の後に m, h, dを付けると分、時間、日の指定となる。

t3a.mediumインスタンス(メモリ4GiB)で試した結果です。

$ stress-ng -m 1 --vm-bytes 3072M --timeout 600

image.png

メモリは100%指定しても、CloudWatch上は100%まで記録されることはありませんでした。ぎりぎりをテストするならバイト指定で調整する必要がありそうです。

$ stress-ng -m 1 --vm-bytes 100% --timeout 1200
stress-ng: info:  [9730] dispatching hogs: 1 vm
stress-ng: info:  [9730] successful run completed in 1200.02s (20 mins, 0.02 secs)

image.png

ワーカー数が1であれば、実メモリ量以上を指定した場合はエラーになります。あまりインスタンスサイズより大きな負荷をかけると異常の原因になる （ マニュアルに記載あり： Note that this can cause systems to trip the kernel OOM killer on Linux systems if not enough physical memory and swap is not available. ) ので注意して下さい。

$ stress-ng -m 1 --vm-bytes 3889M --timeout 120
stress-ng: info:  [9215] dispatching hogs: 1 vm
stress-ng: error: [9233] stress-ng-vm: gave up trying to mmap, no available memory
stress-ng: info:  [9215] successful run completed in 10.01s

ディスク

ディスクもstress-ngコマンドが対応しています。

$ stress-ng -d <ワーカー数> --hdd-bytes <ディスク使用量> -t <実行時間> --temp-path <作業ディレクトリ>

ディスク負荷をかける場合
・-m： 負荷をかけるワーカー数。急激にかけるのでなければ1を指定するとよい。
・--vm-bytes： 
      メモリ消費量を指定する。数字の後に単位を付けて
      b(バイト), k(キロバイト), m(メガバイト), g(ギガバイト), %(割合)での指定が可能。
      ワーカー数を増やした場合、この指定 × ワーカー数の負荷がかかるので注意。
・-t： 実行時間を指定する。
      数字のみの場合は秒数指定、数字の後に m, h, dを付けると分、時間、日の指定となる。
・--temp-path： 一時ファイルを作成するディレクトリ
      指定しない場合は現在の作業ディレクトリが消費されます。

同じインスタンスで試したところ disk_io, disk_writeは上昇しましたが、disk_readは上昇が少なめでした。

$ stress-ng -d 1 --hdd-bytes 2048M -t 1200 --temp-path /tmp

image.png

ディスク使用率を見ると、一時ファイルを作成して削除しているような様子が伺えます。

image.png

ネットワーク

ネットワークはstress-ngコマンドが対応していないため、今回はS3に同じファイルのPUTとGETを繰り返すスクリプトを作成して試しました。

※ダミーの1GBファイルを作成
$ dd if=/dev/zero of=1G.dummy bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.81233 s, 373 MB/s

$ ls -la 1G.dummy
-rw-r--r-- 1 ubuntu ubuntu 1048576000 Nov 16 02:59 1G.dummy

※指定した回数繰り返すシェルスクリプト
$ cat stress_test.sh
#!/bin/bash
cnt=1
while [ $cnt -le $1 ]; do
    aws s3 cp 1G.dummy s3://<バケット名>/1G.dummy
    aws s3 cp s3://<バケット名>/1G.dummy .
    cnt=`expr $cnt + 1`
done

$ ./stress_test.sh 10
upload: ./1G.dummy to s3://<バケット名>/1G.dummy
download: s3://<バケット名>/1G.dummy to ./1G.dummy
Completed 265.2 MiB/1000.0 MiB (86.6 MiB/s) with 1 file(s) remaining
※以下省略※

これを実行すると NetworkIn, NetworkOutが上昇していることが確認できました。

image.png

この時のディスクIOです。右半分が今回のスクリプトによるもので、stress-ngの方が負荷かけられているのが分かります。

image.png

以上です。今回は負荷といってもストレステストほどの負荷ではなく、メトリクスの上限まで負荷を上げる程度の確認でしたが、CloudWatchメトリクスをそれぞれ上昇させられることが確認できました。

参考資料

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T11:30:09+09:00

【AWS認定試験】SAA-C02取得しました

はじめに

先日、SAA(AWS認定ソリューションアーキテクトアソシエイト)に合格した為、やったことを残します。

勉強期間

SAA取得を目指すまでのAWS経験や勉強内容は以下に記載があります。
新卒1年目が1.5ヶ月でAWS認定 クラウドプラクティショナーを取得するまで

SAAの勉強を始めたのが10月頃なので約1ヶ月の勉強期間で行ったことを記載します。

試験対策

Udemy

正直、SAAを意識して行った対策はこれだけです。
これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）

講座を聞きながら、ハンズオンをあまり使ったことのないリソースだけ行いました。
その後、付属の模擬問題を行いました。

1週目はすべての回答を読み込み、わからなかった内容をメモしました。
2週目以降は間違えた問題だけ読み込みました。

計3~4周したと思います。

アプリもあるので、落としておいて出先で勉強するのもお勧めです。

テスト環境で構築

個人的にAWSアカウントを作成していくつかのハンズオンで構築を行いました。
こちらのハンズオンがおすすめです。
モダンウェブアプリケーションを構築する

個人的に理解できていなかったECS,ECR,Fargateの役割や、
CodeCommit,CodeDeploy,CodePipelineのCI/CDパイプラインが理解できました。

そのほかにも模擬問題を受けてみてよくわからないリソースはハンズオンを見つけて作ってみることをお勧めします。

よく出た(印象に残った)リソース

  • S3

    • Standerd,Glacier,Deep Archive,IA,One Zone-IAの違い

  • EBS

    • 汎用SSD,プロビジョンドIOPS,スループット最適化HDD,cold HDDの使い分け

  • Route53

    • レコードタイプ(特にCNAMEとALIASのサポートされるサービスの違い)
    • ルーティングポリシー

  • ファイルストレージ(EFSとFSx)

    • NFSならEFS,SMBならFSxみたいな話

  • SQS

    • 基本的なことはもちろんだが、メッセージ送信が失敗した場合の挙動なども知っておくべき

  • ELB

    • ALB,NLBの違い。どのレイヤーの通信ならこっちなど。

また、Udemyの模擬問題集であるような、具体的な数字についての言及(SQSのキューの保持期間など)は少ないように感じました。
AWSは日々仕様が改善されるのでそれを考慮しているのかもしれません。
リソースの「できないこと」という制限事項も同様の理由で少ない印象でした。

試験本番について

受験方法

ピアソンVUEが在宅受験での日本語対応を行っていたので、活用しました。

以下に詳細を書いたので、ご参照ください。
【AWS認定試験】日本語で自宅受験をしてみてトラブった話

解き方の方針

本番の試験を受けるとわかるのですが、4択のうち「これはないだろう」と分かる回答が2つほどあります。

それが除外できると後悩むのは二択なので、そこから絞り込めると正解率が高くなります。

問題文がおかしいと感じたら

試験を受けていると問題文がおかしいと感じることがありました。
そういう場合は問題文を英語に戻すことをお勧めします。

私の場合は「IAMユーザ」が「IAMロール」と翻訳されており、非常に悩みました。

まとめ

中級の試験らしく、プラクティショナーよりは難しいと感じました。
しかし、しっかりと対策を行い、ある程度のAWSでの経験があれば十分合格できる試験だと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T10:35:24+09:00

【AWS認定試験】日本語で自宅受験をしてみてトラブった話

はじめに

SAA(AWS認定 ソリューションアーキテクトアソシエイト)を自宅受験してみました！！

トラブルなどもあったので、体験記として受験される方の参考にちょっとでもなればなと思います。

自宅受験の背景

10月某日。
資格を受けることにしました。

「予約して試験日決めないと勉強しないぞ！」というのはわかっていたので予約しようと認定ページにアクセスしました。

すると...

予約画面.png

ピアソンVUEのオンライン試験日本語対応しとるやん！！！

以前から「自宅受験受けてみたいな！！！」と思っていたのですが、ネックになるのはやはり言葉の壁。
翻訳などを使っていいというところもあるようなのですが、そこまでするくらいならテストセンターで受けるわ、となっていたのでめちゃめちゃありがたいです。

2020-09-16から日本語に対応しているみたいですね。

https://d1.awsstatic.com/ja_JP/training-and-certification/docs-certification-guide/Online-Proctoring_Exam-Guide.pdf

日本語で受けられるんだったら家で受けたほうが楽じゃね？と思い予約しました。。。

試験前にやったこと

事前準備

環境整備

自宅受験する際には指定された環境を用意する必要があります。
要件は以下のページに記載があります。

https://www.pearsonvue.co.jp/aws/onvue

注意したほうがよさそうだなと感じた部分をいくつかピックアップします。

  • (必須レベル)会社のPCでは受験しない

    • 試験の為にソフトをインストールするのですが、不正防止のため他のアプリケーションが実行しているかを検知します。したがって、会社PCの設定を変更する必要が出てきて面倒なので持っている方は自分のPCで受験すべきです。
    • ちなみに、Win10で受けました。

  • 安定した通信ができる環境

    • 試験中は常にカメラをつけておく必要があります。そのため、安定した通信ができる環境が望ましいです。
    • 私は無線で受験しましたが、有線のほうが望ましいです

  • 空調整備

    • 試験中はエアコンのリモコンや窓などに触れることが許されません。したがって空調管理は自動でしてくれる設定がいいと思います。

  • 部屋

    • 扉を閉めて誰も入ってこない部屋が条件です。私はたまたま家に空き部屋があったのでそちらを使いました。
    • 360度全方向を試験官に見せることになります。そのためポスターなどが貼ってある場合は外したほうがいいです。

  • 持ち込めるもの

    • 眼鏡(録画機能のないもの)
    • スマホ(試験中は利用不可)
    • 身分証明書

  • 持ち込めそうで持ち込めないもの

    • 水分
    • ティッシュ
    • 腕時計
    • 薬(目薬や常備薬含む)

試験途中はトイレ含む途中退出が許可されないので、事前に済ませる必要があります。

私が受けたお手本のような部屋。

iOS の画像.jpg

システムテスト

ピアソンホームページからシステムテストが行えます。
試験前システムテスト.png

押すとこのような画面に遷移します。

test.png

1のチェックを入れ、2でアクセスコードをコピーし3でダウンロードを押します。

実行ファイルが落ちるので、実行します。

test2.png

実行したらこんな画面が出てくるので、まず右上から「日本語」を選択し、アクセスコードを入力、電話番号（本番ではSMSでやり取りするため携帯推奨）を入力します。

3.png

入力したら「マイク・カメラ・回線」のチェックになります。
カメラはPCのデフォルトのものを使いました。

チェックが終わり次第、テスト環境の確認に移ります。
実際のテストと同じ環境にしてみて大丈夫かの確認を行います。
4.png
エラーになると実行中のアプリケーションが出てきます。
アプリケーションがバックグラウンドで動いていたりしたらここでアウトになるので、必ず確認しましょう。

サンプル試験が実行されればOKです。
適当に答えて終了します。

試験当日

試験開始30分前になったら試験会場(部屋)に移動します。

持ち物は以下です。

  • スマートフォン
  • 身分証明書(運転免許証を利用しました)
  • 受験するPC

まず、AWS認定ホームページにアクセスします。
awshome.png

「ピアソンVUE試験の管理」を選択すると、ピアソンのダッシュボードにリダイレクトされます。
ダッシュボードから、対象の試験をクリックして、ピアソンVUEアプリケーションを起動します。

その後の流れは以下です。

  1. ピアソンVUEアプリケーションに電話番号を入力(携帯番号)

  2. SMSで携帯電話にピアソンVUEの写真撮影のためのリンクが送られてくるのでタップ

  3. 顔写真を撮るように言われるので自撮り

    • ブラウザのカメラアクセスを許可

  4. 免許証の表面と裏面を撮る

    • 文字がつぶれないように注意
    • インカムでしか撮れなかったので工夫が必要
    • スマホの裏のカメラで撮る方法があれば教えてください
    • 手で免許を持って撮りました...

  5. 受験する部屋を前後左右から写真を撮る

  6. PCにて試験官がアサインされるのを待つ

  7. 試験官から部屋をゆっくり360°撮るように言われる

    • PCを持ってその場で一回りしました。
    • 机の下も撮るように言われます。

  8. 腕を見せて時計をしていないことを確認してもらう

  9. (眼鏡をしている人は)眼鏡をカメラ前まで持っていき、録画機能が付いていないことを確認される。

  10. 全ての準備が終わり次第、試験官が試験を開始する。あとは試験を頑張るだけです

試験中に起きたトラブル

問題を解いている最中に試験が中止されました。

試験途中、裏でSkypeが自動的に起動し、それを検知したピアソンVUEアプリが試験を自動的に中断したのです。
4.png

すぐさま'OK'を選択し、Skypeを終了させました。

すると「試験を再開します。しばらくお待ちください。」という画面が表示されました。

その後、試験が再開されることはありませんでした...。

試したこと

  1. チャットで試験官にアプローチ

    • メッセージを送った途端にチャットウィンドウを消され、こちらからコンタクトをとることができなくなりました。

  2. ひたすら待機

    • 画面内の枠から自分の顔が出てしまうと試験が中止される可能性があったので、動くにも動けない状態でした

  3. アプリの再起動

    • 試験終了時刻になった為、アプリを再起動。(ここでアクセスコードをメモらないと試験に入れなくなるので注意)

アプリの再起動を行うと試験官との対話が行えるようになり、状況を説明することができました。

ピアソンVUE側も試験を再開できていない状況がおかしいようで、アプリのシステムトラブルということでその日は中止となりました。

後日

中止された試験はキャンセル対応ということになり、試験が一回分無料になるクーポンをもらいました。
(今後も同じような対応がされるとは限りません)

ちなみに、AWS側では不合格となっていました。(後日取り消されました)
result.png

再試験

1週間後に再度受験を行いました。
本来、不合格の場合は再試験までに14日の間を空ける必要があるのですが、特例で待ち期間なしで受けられました。

再試験では中止にならないように

  • 「アプリのバックグラウンド実行を許可」をオフ
  • 20GBのディスク空き容量の確保

を念のため行いました。
今度はトラブルも起きず、無事終了しました。

結果は合格でした。

所感

自宅受験は環境さえ整えられるのであればおすすめです。
何より、自宅という環境の為、比較的落ち着いて試験が受けられます。

日本語もしっかりと通じましたし、問題が起きた時のサポートもよかったです。
また利用したいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T09:38:27+09:00

AWS EC2 第2回EC2 InstanceへのSSH接続

はじめに

前回EC2 Instanceの起動を行いました。
EC2 Instanceを起動後、そのサーバーに対して何を実行させるか？によって実施する内容は色々とありますが、まずはEC2 Instanceへ接続しないことには話は始まりません。
従いまして、今回はそのEc2 InstanceへSSH接続します。

今回実施する内容

EC2 InstanceへSSH接続します。
SSH接続図.jpg

参考

Tutorial: Getting started with Amazon EC2 Linux instances

インスタンスのライフサイクル

用語

特になし

EC2 Instanceの起動、開始、停止、再起動、終了

EC2 Instanceの状態遷移させるにあたり、「起動」、「開始」、「停止」、「再起動」、および「終了」という表現がありますので、これを説明します。
これらは、インスタンスの画面から「インスタンスの状態」で変更することができます。

詳しくは、「インスタンスのライフサイクル」を見てもらえればと思いますが、ザクっと４つをイメージで覚えるとよいと思います。

状態 説明
起動 EC2 Instanceを作ること。PCを買ったと思えばよいかと思います。
開始 EC2 Instanceの電源を入れて立ち上げること。PCを起動するイメージです。
停止 EC2 Instanceの電源を切ること。PCをシャットダウンするイメージです。
再起動 EC2 Instanceを停止して開始すること。PCの再起動のイメージです。
終了 EC2 Instanceを破棄すること。PCを捨てるイメージです。

基本的には、「開始」、「停止」、「再起動」だけ使えばよく、新たにEC2 Instanceを作成したいときには「起動」、EC2 Instanceを破棄したくなったら「終了」でよいと思います。

なお、「終了」すると、構築したEC2 Instanceがなくなってしまうため、バックアップを作成することもできますが、まずは終了を誤ってしないようにしておくことがよいと思います。

EC2の画面の「アクション」→「インスタンスの設定」→「終了保護を変更」で、「有効化」にチェックしておくと誤って終了しようとしてもできないようになっています。
終了保護.jpg

SSH接続

  1. EC2 Instanceの開始
    EC2コンソール画面上で、起動するEC2 Instanceのチェックボックスをチェックして、「インスタンスの状態」→「インスタンスの開始」を選択する。

  2. パブリックIPv4アドレスの確認
    起動すると、EC2 InstanceにパブリックIPv4アドレスが割り当てられます。EC2コンソール画面の下に該当の情報がでますので、それを確認する。
    IPアドレスを固定にするElastic IPアドレスも使用可能ですが、わずかですが費用がかかるため、初期設定中はまだ使わなくてもよいかなと思います。

  3. SSH接続
    2のパブリックIPv4アドレスに接続します。
    SSH接続できるなら何でもよいのでしょうが、私は「Tera Term」を使用します。
    ホスト：上記で確認したパブリックIPv4アドレス
    サービス：SSH
    TCPポート：22
    SSHバージョン：SSH2
    IPバージョン：AUTO
    で接続します。
    SSH login.jpg

    「セキュリティ警告」が表示されますが、「続行」を押して続けます。
    SSH認証画面が表示されます。ここで、以下を設定してOKを押すと、SSH接続できます。
    ユーザー名：ec2-user
    パスフレーズ：なし
    認証方式：「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し、ファイルを開くボタンを押して、EC2 Instance起動時に作成したキーペアを設定する。
    SSH接続.jpg

    デフォルトでは、SSH接続は、キーペアで接続してパスワードはないようです。

Internet gatewayやセキュリティ

デフォルトだと、上記の通りすんなりとSSH接続できてしまいますが、セキュリティがざるかといえばそうでもなく、いたるところに設定があります。

Internet gateway

「今回実施する内容」の図で、Internetから、AWS Cloudに接続するにあたり、最初に「Internget gateway」が設定されています。
AWSのサービスから、VPC（Vertual Private Cloud）を選択して、VPCコンソール画面を表示させます。
左側のメニューから「インターネットゲートウェイ」を選択すると、インターネットゲートウェイIDとそれに関連づくVPC IDがリストされます。
作成したEC2 Instanceに関連づくVPC IDをクリックすると、詳細が表示され、そこにあるルートテーブルをクリックするとルートテーブルが表示されます。
ルートテーブル.jpg

ここで、1つ目はターゲットがローカルとなっています。VPC内で複数存在する場合のゲートウェイかと思います。
２つ目は、0.0.0.0/0でターゲットはインターネットゲートウェイIDとなっています。
デフォルトではどのIPアドレスからの接続も許容するという設定と思います。

セキュリティ

AWSのサービスからEC2コンソール画面を表示させます。
左側のメニューから「セキュリティグループ」を選択すると、セキュリティグループのリストが表示されます。
この中で、セキュリティグループ名が「launch-wizard-X」（Xは数字）のものがあると思いますが、これがEC2 Instance起動時にデフォルトで作成されるセキュリティグループです。このセキュリティグループIDをクリックすると、詳細が表示されます。そこにインバウンドルールがあり、プロトコルがTCPでポート範囲が22でソースが0.0.0.0/0（IPアドレスはなんでも可）の設定となっており、SSHだけが通るルールがあります。

インバウンドルール.jpg

ここで、デフォルトでは、SSH接続だけ許容する設定になっていることがわかります。

アウトバウンドについては、なんでも可になっています。デフォルトで何か外にでていくことはないので、これでよいのかなとは思います。

おわりに

今回は、SSH接続の仕方について説明しました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T09:38:27+09:00

AWS EC2 第2回EC2 Instance(Amazon Linux2)へのSSH接続

はじめに

前回EC2 Instanceの起動を行いました。
EC2 Instanceを起動後、そのサーバーに対して何を実行させるか？によって実施する内容は色々とありますが、まずはEC2 Instanceへ接続しないことには話は始まりません。
従いまして、今回はそのEc2 InstanceへSSH接続します。

今回実施する内容

EC2 InstanceへSSH接続します。
SSH接続図.jpg

環境

AMI: Amazon Linux 2 AMI (HVM), SSD Volume Type - ami-05f4d5a411fcc68e0 (64 ビット Arm)

参考

Tutorial: Getting started with Amazon EC2 Linux instances

インスタンスのライフサイクル

AWS EC2 EC2 Instance (Amazon Linux AMI)の作成2
この記事のもととなるEC2 Instance (Amazon Linux2)構築の記事です。

用語

特になし

EC2 Instanceの起動、開始、停止、再起動、終了

EC2 Instanceの状態遷移させるにあたり、「起動」、「開始」、「停止」、「再起動」、および「終了」という表現がありますので、これを説明します。
これらは、インスタンスの画面から「インスタンスの状態」で変更することができます。

詳しくは、「インスタンスのライフサイクル」を見てもらえればと思いますが、ザクっと４つをイメージで覚えるとよいと思います。

状態 説明
起動 EC2 Instanceを作ること。PCを買ったと思えばよいかと思います。
開始 EC2 Instanceの電源を入れて立ち上げること。PCを起動するイメージです。
停止 EC2 Instanceの電源を切ること。PCをシャットダウンするイメージです。
再起動 EC2 Instanceを停止して開始すること。PCの再起動のイメージです。
終了 EC2 Instanceを破棄すること。PCを捨てるイメージです。

基本的には、「開始」、「停止」、「再起動」だけ使えばよく、新たにEC2 Instanceを作成したいときには「起動」、EC2 Instanceを破棄したくなったら「終了」でよいと思います。

なお、「終了」すると、構築したEC2 Instanceがなくなってしまうため、バックアップを作成することもできますが、まずは終了を誤ってしないようにしておくことがよいと思います。

EC2の画面の「アクション」→「インスタンスの設定」→「終了保護を変更」で、「有効化」にチェックしておくと誤って終了しようとしてもできないようになっています。
終了保護.jpg

SSH接続

  1. EC2 Instanceの開始
    EC2コンソール画面上で、起動するEC2 Instanceのチェックボックスをチェックして、「インスタンスの状態」→「インスタンスの開始」を選択する。

  2. パブリックIPv4アドレスの確認
    起動すると、EC2 InstanceにパブリックIPv4アドレスが割り当てられます。EC2コンソール画面の下に該当の情報がでますので、それを確認する。
    IPアドレスを固定にするElastic IPアドレスも使用可能ですが、わずかですが費用がかかるため、初期設定中はまだ使わなくてもよいかなと思います。

  3. SSH接続
    2のパブリックIPv4アドレスに接続します。
    SSH接続できるなら何でもよいのでしょうが、私は「Tera Term」を使用します。
    ホスト：上記で確認したパブリックIPv4アドレス
    サービス：SSH
    TCPポート：22
    SSHバージョン：SSH2
    IPバージョン：AUTO
    で接続します。
    SSH login.jpg

    「セキュリティ警告」が表示されますが、「続行」を押して続けます。
    SSH認証画面が表示されます。ここで、以下を設定してOKを押すと、SSH接続できます。
    ユーザー名：ec2-user
    パスフレーズ：なし
    認証方式：「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し、ファイルを開くボタンを押して、EC2 Instance起動時に作成したキーペアを設定する。
    SSH接続.jpg

    デフォルトでは、SSH接続は、キーペアで接続してパスワードはないようです。

Internet gatewayやセキュリティ

デフォルトだと、上記の通りすんなりとSSH接続できてしまいますが、セキュリティがざるかといえばそうでもなく、いたるところに設定があります。

Internet gateway

「今回実施する内容」の図で、Internetから、AWS Cloudに接続するにあたり、最初に「Internget gateway」が設定されています。
AWSのサービスから、VPC（Vertual Private Cloud）を選択して、VPCコンソール画面を表示させます。
左側のメニューから「インターネットゲートウェイ」を選択すると、インターネットゲートウェイIDとそれに関連づくVPC IDがリストされます。
作成したEC2 Instanceに関連づくVPC IDをクリックすると、詳細が表示され、そこにあるルートテーブルをクリックするとルートテーブルが表示されます。
ルートテーブル.jpg

ここで、1つ目はターゲットがローカルとなっています。VPC内で複数存在する場合のゲートウェイかと思います。
２つ目は、0.0.0.0/0でターゲットはインターネットゲートウェイIDとなっています。
デフォルトではどのIPアドレスからの接続も許容するという設定と思います。

セキュリティ

AWSのサービスからEC2コンソール画面を表示させます。
左側のメニューから「セキュリティグループ」を選択すると、セキュリティグループのリストが表示されます。
この中で、セキュリティグループ名が「launch-wizard-X」（Xは数字）のものがあると思いますが、これがEC2 Instance起動時にデフォルトで作成されるセキュリティグループです。このセキュリティグループIDをクリックすると、詳細が表示されます。そこにインバウンドルールがあり、プロトコルがTCPでポート範囲が22でソースが0.0.0.0/0（IPアドレスはなんでも可）の設定となっており、SSHだけが通るルールがあります。

インバウンドルール.jpg

ここで、デフォルトでは、SSH接続だけ許容する設定になっていることがわかります。

アウトバウンドについては、なんでも可になっています。デフォルトで何か外にでていくことはないので、これでよいのかなとは思います。

おわりに

今回は、SSH接続の仕方について説明しました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T09:32:36+09:00

Glue Studio【AWS】

はじめに

この記事では、2020年9月23日にリリースされた Glue Studio を利用して GUI ベースで Glue ジョブの作成と実行そしてモニタリングを行います。

AWS Glue

AWS Glue は、Apache Spark のパワーを使用して分析用のデータセットを準備および処理するサーバーレス環境を提供します。

      AWS Glue Documentation
      Optimize memory management in AWS Glue

AWS Glue Studio

AWS Glue Studio は、AWS Glue の新しいビジュアルインターフェースです。これにより、抽出、変換、読み込み (ETL) デベロッパーは、AWS Glue ETL ジョブを簡単に作成、実行、および監視できるようになります。シンプルなビジュアルインターフェイスを使用して、データを移動および変換し、AWS Glue で実行するジョブを作成できるようになりました。次に、AWS Glue Studio のジョブ実行ダッシュボードを使用して ETL 実行を監視し、ジョブが意図したとおりに動作していることを確認できます

      What is AWS Glue Studio?

AWS Big Data Blog の Making ETL easier with AWS Glue Studio を参考にして Glue Studio でのジョブの作成と実行を行います。

1. Start creating a Job

    1. Click either the Jobs on the navigation panel or Create and manage jobs, and start creating a job.
スクリーンショット (18).png
    2. Choose the Blank graph and click the Create button.
スクリーンショット (98).png

2. Adding Data source

    3. Choose the (+) icon.

 On the Node properties tab,
    4. For Name, enter input.
    5. For Node type, choose S3(Glue Data Catalog table with S3 as the data source.).
スクリーンショット (47).png
 On the Data source properties - S3 tab,
 (make a Data Catalog with Crawler beforehand)
    6. For Database, pyspark_input
    7. For Table, titanic_data_csv
    8. For Partition predicate, leave blank.
スクリーンショット (48).png
  On the Output schema tab,
    9. Check the Schema.
スクリーンショット (49).png

3. Adding Transform

    10. Choose the input node.
    11. Choose the (+) icon.
 On the Node properties tab,
    12. For Name, enter transform.
    13. For Node type, choose the Custom transform.
    14. For Node parents, choose the input.
スクリーンショット (50).png
 On the Transform tab,
    15. For Code block, write Python code of PySpark.
スクリーンショット (76).png
  On the Output schema tab,
    16. Check the Schema.
スクリーンショット (52).png
By adding Custom transform, a next node to receive the DynamicFrameCollection is added automatically.

 On the Node properties tab,
    17. For Name, enter receive (The word "recieve" is spelled wrong.)
    18. For Node type, choose the SelectFromCollection.
    19. For Node parents, choose the transform.
スクリーンショット (53).png
スクリーンショット (54).png
スクリーンショット (55).png

4. Adding Data target

    20. Choose the receive node.
    21. Choose the (+) icon.

 On the Node properties tab,
    22. For Name, enter output.
    23. For Node type, choose the S3(Output data directly in an S3 bucket.).
    24. For Node parents, choose the receive.
スクリーンショット (56).png
 On the Data target properties - S3,
    25. For Format, choose the CSV.
    26. For Compression Type, None.
    27. For S3 Target Location, enter S3 location in the format s3://bucket/prefix/object/ with a trailing slash (/).
    28. For Partition, leave blank.
スクリーンショット (57).png
 On the Output schema tab,
    29. Check the Schema.
スクリーンショット (58).png

5. Script

スクリーンショット (75).png
スクリーンショット (60).png

6. Configuring the job

    30. IAM Role: AmazonS3FullAccess / AWSGlueConsoleFullAccess
スクリーンショット (61).png
    31. For Job Bookmark, choose Disable.
    32. For Number of retries, optionally enter 1.
スクリーンショット (62).png

    33. Choose save.
    34. When the job is saved, choose Run.
スクリーンショット (63).png

7. Monitoring the job

    35. In the AWS Glue Studio navigation panel, choose Monitoring.
スクリーンショット (67).png
スクリーンショット (71).png
スクリーンショット (72).png
    35. In the Glue console, check the Glue Job.
スクリーンショット (74).png

ジョブの作成と実行そしてモニタリングを行うことができました。

以上で主題は終了しましたが、実際に Glue というサービスを利用することでどのようなことが出来るのかを簡単に示しておきます。
このアーキテクチャは、Glue を利用したバッチ処理を行うデータ処理基盤の例です。


1. S3にデータが置かれることがCloudWatchのトリガーとなり、CloudWatchが
　ターゲットとするStep Functionsが起動
2. Step FunctionsはLambdaから関数を受け取り、GlueのクローラとPySparkの
　ジョブをS3に対し実行
3. PySparkにより変換されたデータをS3に出力

まとめ

Glue Studio を利用して GUI ベースで Glue ジョブの作成と実行を行ってみました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T03:20:04+09:00

VPC内のLambdaからはSES向けのVPCエンドポイントを使用してもBoto3ではメールを送信できない

初めに

本記事はタイトルについて検証を行った詳細を記載します

書くきっかけですが、最近久しぶりにVPCと戯れることになりました。
VPCを使った構成ですんなり行った思い出はなく、実際に沼にハマりました。

ポイントをまとめましたので、どなたかのお役にたてば嬉しいです

結論だけ知りたい方は最後まで飛ばしてください

検証を行うことになった背景

VPC内のLambdaからメールを送る
ただこちらを行いたいだけでした

アーキテクチャとしては以下となります
RDS→Lambda(VPC内)→SES→ユーザー

あまり見ないアーキテクチャですね
RDS Proxyがリリースされてから、LambdaとRDSの組み合わせは使用する頻度が多くなりました
DynamoDBだけでは辛い部分もあるので、今後こちらのアーキテクチャは増えるようになるのではないでしょうか

実装するに当たって、どのようにVPCから外へ出るか調べていました
すると、2020年5月にSES向けのVPCエンドポイントがリリースされているじゃありませんか

これは簡単に実装が終わるなと試してみたところ、Lambdaでタイムアウトが発生しました
これが長い検証の始まりです...

検証内容

CloudWatchには以下のように表示されていました

Task timed out after 30.03 seconds

VPCの外に出れていないようです

1. SESの設定を疑う

まずはSESの検証が正しく行われているかテスト送信を行い確認です
サンドボックス環境にありましたので、何か影響があるのかもしれないと考えていました

テスト送信はコンソールから簡単に行えます
手順はこちら

送信元から送信先へ想定通りにメールが送信されました

SESのコンソールからは正しく送信が行えることが確認できましたので、別の原因を探します

2. 権限周り

ロールか、セキュリティーグループの設定の問題だろうと思い、まずはガバガバの設定を行いました
とりあえずVPCの外に出れるか確認です

  1. セキュリティーグループのインバウンドとアウトバウンドで全ての通信を許可
  2. ロールに以下ポリシーを追加
"ses:SendEmail","ses:SendRawEmail"を全てのリソースから許可
AWSLambdaVPCAccessExecutionRole
VPCFullAccess
SESFullAccess

それでもタイムアウトは改善されませんでした

3. ロジックの問題

次に行ったのはSESへ送信するロジックの見直しです
python3.8でBoto3を使っていました
ソースはこちらを参考にしています

ロジックに問題があるのか、設定に問題があるのか切り分けるためにまずはVPCの外にLambdaを作成し、同じソースコードで送信を行いました

すると、VPCの外にあるLambdaからはメールを送信できました
ソースに問題はなく、おそらくVPC関連の問題だということがこれまでの検証でわかりました

4. エンドポイントを指定する?

VPC内のLambdaからSQSを利用する場合ですがエンドポイントを指定する必要があります
手順には記載がありませんでしたが、これと同じでSESもエンドポントを指定する必要があるのではないかと疑いました

boto3ではclientを生成時に引数でエンドポイントを指定することができます
公式

VPCエンドポイントのURLを追加してみました

import boto3
ses_client = boto3.client('ses', region_name='ap-northeast-1', endpoint_url='com.amazonaws.region.email-smtp')

こちらで送信を試してみたところ以下エラーが発生しました

[ERROR] ValueError: Invalid endpoint: com.amazonaws.ap-northeast-1.email-smtp

エンドポイントとして無効なようです

5. Lambda(VPC内)→Lambda（VPC外）→SES

もうやけくそに近くなってきました
SES向けのVPCエンドポイントはどうやら使えないようだと思い別のアプローチをすることにしました

2020年10月にLambdaがPrivateLinkに対応していました

これを試したところ問題なくメールの送信まで行えました
でもスマートじゃない...

6. SMTPインターフェース...?

海外の方がAmazon SES SMTP インターフェイスを使用した E メールの送信をすればいけるよ!
と教えてくれているのを見つけました

リージョンごとにユーザー名とパスワードが必要になります。

うーん微妙...
boto3で送りたい...

7. サポートへ問い合わせ

もう自らの知識ではどうにもならないと判断し、問い合わせを行いました
以下回答の抜粋です

VPCエンドポイントがサポートされておりますのは「1.SES SMTP インターフェースを使う」方法となります。
一方、お客様が実施しようとしている Boto3のsend_emailメソッドを使う方法は「2.SES API(AWSCLI,AWS SDK) を使う」となり、VPCエンドポイントには対応しておりません。
「2.SES API(AWSCLI,AWS SDK) を使う」場合には以下のいずれかにて対応いただければと存じます。
・LambdaをVPC外で起動する
・LambdaをVPC内に起動し、NAT Gateway を配置して Lambda からインターネットへ接続できるようにする

まじか!!!
どこにもBoto3じゃあかんとは書いてなかったやんけ!!!
という気持ちでしたが、無事解決できてよかったです
サポートの方に感謝

このあとNAT Gatewayでの方法を試してメールが届くことを確認しました

結論

  • VPC内LambdaからBoto3を使ってメールを送信する場合はNATゲートウェイを使用してインターネット接続を行う必要がある
  • SES向けのVPCエンドポイントを使う場合はBoto3は使えない(タイムアウトになる)
  • SES向けのVPCエンドポイントを使う場合はAmazon SES SMTP インターフェイスを使用する必要がある

組み合わせ

SES向け VPCエンドポイント 送信方法
方法1 使用 SMTPインターフェース
方法2 不使用 NATゲートウェイ + Boto3

サポートに聞くのが強い

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-16T00:59:21+09:00

AWS Lambdaでpythonプログラムの定期実行

はじめに

AWSのlambdaを使用して、スケジュール実行のプログラムを設置しました。
lambdaの基本的なことで意外とつまったので残しておきます。
AWSのアカウントは作成しているものとしています。

MAC OS X
python 3.6

対象

・lambdaを触ったことのない方
・とりあえず何か動かして見たい方

lambdaとは

スクリプトを実行することが出来るサーバーレスのサービスです。
サーバレスと言ってもスクリプトの実行時にのみサーバを起動するイメージです。

呼び出しはAWSの空いているサーバから行われるため、実行するサーバーは都度違います。
（固定IPを割り当てたサブネットにlambdaを設置して実行することでIPを固定にすることは出来ます）

無料使用枠が月ごとに100万件の無料リクエストと1秒あたり40万GBのコンピューティング時間あるので、たいてい無料枠で動かせます。WebやIOTのバックエンドのAPIとしても使えるのでめちゃくちゃ便利なサービスですね。

簡易的なスクリプト作成

pythonでLambdaのスクリプトを作成する場合、 lambda_function.py という名前で作成しなければいけません。
その中の lambda_handler という関数が呼ばれるようになっているので、lambda_handler関数も用意します。

lambda_function.py
# -*- coding:utf-8 -*-

# lambda実行時に呼ばれる関数。引数はevent,contextがデフォルトっぽいです。
# 引数なくてもいいっぽいですが、書いておきます。
def lambda_handler(event, context):
    print('テスト実行')

このスクリプトをzip形式に圧縮します。

bash
$ zip function.zip lambda_function.py

MACの場合はエクスプローラー上で圧縮すると.DS_Storeファイルが入ってlambda_function.pyを読み込めないのでコマンドで圧縮します。

Lambda関数の作成

AWSのコンソール画面から「Lambda」→「関数の作成」を選択。
関数名を入れて、ランタイムは今回はPython 3.6にします。

スクリーンショット 2020-11-15 23.18.48.png

入力できたら、「関数の作成」ボタンをクリックします。
これで関数ができたので、先ほどのスクリプトをアップロードします。
右下の「アクション」ボタンから「.zipファイルをアップロード」で先ほどのzipファイルをアップロードします。

スクリーンショット 2020-11-15 23.22.16.png

スクリーンショット 2020-11-16 0.26.26.png

テストを実行

右上のテストをクリックして、イベント名を入力します。
下の配列は関数に渡すイベント引数ですが、今回は使用していないので、変更せずにそのまま作成します。

スクリーンショット 2020-11-16 0.30.29.png

作成したテストを選択された状態でテストボタンをクリックしてください。

スクリーンショット 2020-11-16 0.33.35.png

関数コードの下に実行結果が出てきてるので成功です。

スクリーンショット 2020-11-16 0.34.34.png

定期実行のイベント作成

デザインナーの「トリガーを追加」ボタンをクリック。

トリガー：EventBridge(CloudWatch Events)
ルール：新規ルール
ルールタイプ：スケジュール式
スケジュール式：cron(30 1 * * ? *)
※このスケジュール式は午前10時30分に実行されます。
　式の時間はUTC時間なので、設定したい時間から9時間マイナスした時間で設定します。
　cron(分 時 日 月 曜日 コマンド)

スクリーンショット 2020-11-16 0.46.30.png

「追加」ボタンをクリックして、これで設定完了です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧