AWSソリューションアーキテクトプロフェッショナル取得のために学習していた時のアウトプットとしてまとめていたメモです

勉強方法

https://www.udemy.com/course/aws-53225/

• Udemyの模擬試験問題集をひたすら解く
• 受験時のAWSの実務経験は1.5年ほど、まとまった勉強時間が確保できなかったので、隙間時間での勉強がメイン
• 正解・不正解と問わず自分が理解できていない・覚えていない箇所をサービス別に整理・まとめていき記憶と理解を深める
  • 問題の解説を見ながら各サービスを毎に仕様やユースケースをまとめる
  • Slackの自分DMに書き溜めていくことでデスク（PC）や移動時間（スマホ）など、記入・見直しができるようにする
• サービス軸で整理することにより、単純な問題と解答の暗記ではなく、個々のサービスに対する体系的な理解が深まったと思います

---

オリジンに利用できるサービス

• NLB/ALB/EC2/EIP

標準ルーティングとカスタムルーティング

• 基本的には標準を利用。
• カスタムは、特定のEC2に特定のユーザ（クライアント）を紐づけたいなどの用途にて利用。

Contact Lens

• 通話内容を機械学習により分析できるサービス。
• 文字起こし、感情分析、キーワードでアラート通知など

UpdateContactAttributes API

https://aws.amazon.com/jp/about-aws/whats-new/2018/08/amazon-connect-adds-new-contact-api-to-set-contact-attributes/ 連絡先を更新したり属性を追加したりできます。連絡先の属性とは、連絡先に関するデータのキー値ペアであり、発信者名、電話した理由、受けたサービスの品質などが考えられます。これまでこうした属性は、通話がエージェントに接続される前に実行される対応フロー内でのみ設定できました。この新しい API を利用すると、購入者とやりとりしている間やその後に、CRM などのお使いのビジネスアプリからプログラム的に属性を追加したり更新したりできます。たとえば、コールバックする発信者を示す属性をエージェントが追加するケースや、通話の終了後にサービス品質をスコア付けするためにマネージャーが属性を更新するケースが考えられます。

要復習の問題

• https://cloud-license.com/exam/sap/022-016/

調べる・理解する

• Kubernetes Cluster Autoscalerとは

読むべき

• https://zenn.dev/tmrekk/articles/07f30b09c26b50

--- DataSync ---

• オンプレtoAWSまたはAWStoオンプレのデータ転送をするサービス。
• 転送先は、S3かEFS。

• オンプレ側のサーバにエージェントを導入して利用する。

• https://qiita.com/taddy3/items/2e77eb82af243f72d7ed

--- SQS ---

デッドレターキュー

• SQSにあるキューの処理が失敗した場合にPushされるキュー。
• 未使用の（＝元の）メッセージと、エラーメッセージがセットでプッシュされる。
• キューの順序性を維持する必要がある場合や無制限にリトライ処理をするような場合ではDLQの利用は推奨されない。

--- AWS Control Tower ---

できること

• ログ集約
• コントロール適用（コンフォーマンスパック）
• 通知
• ID一元管理
• AWSアカウントの作成・プロビジョニング

--- Redshift ---

Concurrency Scaling（同時実行スケーリング）

https://dev.classmethod.jp/articles/20190328-amazon-redshift-concurrency-scaling-new-launch/ - エンドポイントを変更せずに自動で新しいクラスターを追加できる機能。 - メインクラスタへのクエリの同時実行数を超過するとスケーリングクラスタにルーティングされる。 - スケーリングクラスタは、読み取り専用。

--- Kinesis Data Stream ---

全般

• 特定のニーズに合わせてストリーミングデータを処理、分析するカスタムアプリケーションを構築するためのサービス。
• データプロデューサーからすばやくデータを移動して、連続的にデータを処理し、データストアに送る前にデータを変換したり、メトリクスや分析をリアルタイムで実行したり、他の処理のためにさらに複雑なデータストリームを取得したりできる。
• データスループットのレベルでデータをストリーミングするために必要なインフラストラクチャ、ストレージ、ネットワーキング、設定を管理するため、ハードウェア、ソフトウェア、その他のサービスのプロビジョニング、デプロイ、継続的なメンテナンスを心配する必要がない。
• 3 つのアベイラビリティーゾーンでデータが同期的にレプリケートされるため、可用性とデータ耐久性が高い。

SQSとの違い

Kinesis Data Streams Amazon Kinesis Data Streams では、ビッグデータのストリーミングをリアルタイムで処理できる。レコードを並べ替えることができ、複数の Amazon Kinesis アプリケーションに対して同じ順序でレコードを読み取ったり再生したりできる。Amazon Kinesis クライアントライブラリは特定のパーティションキーに対するすべてのレコードを同じレコードプロセッサに提供し、同じ Amazon Kinesis データストリームから読み取る複数のアプリケーションの構築を容易にする。

使用する状況

• 関連する複数のレコードを同じ処理系に回す時
• 複数のアプリケーションが同じストリームを同時に使用する時
• レコードを数時間後に同じ順序で使用する時

Amazon SQS Amazon SQS は、コンピュータ間でやり取りされるメッセージを格納するための、信頼性のある、拡張性の高い、ホスティングされたキューを提供する。Amazon SQS を使用すると、分散したアプリケーションコンポーネント間でデータを簡単に移動でき、自動化されたワークフローのようなメッセージレベルでの確認/失敗セマンティクスを備えたメッセージを独立して処理するアプリケーションを構築できる。

使用する状況

• メッセージングセマンティクス (メッセージレベルの確認/失敗など) および可視性タイムアウト、例えば、作業項目のキューがあり、各項目の正常な完了を個別に追跡する時
• ジョブキューがあり、遅延のある個別のジョブをスケジュールする必要がある時
• 例えば、負荷の一時的な上昇や事業の自然な成長の結果として、バッファ要求や負荷が変化するような場合

概念

• シャード
  • スループットの単位で、データレコードが保存されるところ。
  • 1シャードは、1MB/秒のデータ入力と、2MB/秒のデータ出力をサポート。
  • また、各シャードは1秒あたり最大1,000件のPUTレコードをサポート。
  • 1 秒あたり最大 5 件の読み取りトランザクションをサポート。
    • 読み込みトランザクションは最大 10,000 レコードを提供でき、トランザクションあたり 10 MB の上限がある。
    • GetRecords では、1 つのシャードから最大 10 MB のデータを取得でき、呼び出しごとに最大 10,000 レコードを取得できる。
  • デフォルトでストリームに追加された時点から24時間アクセス可能。
    • 最大7日間まで上げることができる。
• レコード
  • データストリームに保存されるデータの単位。
  • シーケンス番号、パーティションキー、データ BLOB で構成される。
  • データBLOBの最大サイズは1MB。
• パーティションキー
  • レコードを分離してデータストリームの異なるシャードにルーティングするために使用する。
• シーケンス番号
  • 各レコードの一意の識別子。
  • データを Amazon Kinesis データストリームに追加すると、Amazon Kinesis によってシーケンス番号が割り当てられる。
  • シャード間では増加しない。

データの書き込み

• PutRecord, PutRecords, KPL, Kinesis Agentを使ってストリームにデータを追加する。
• Kinesis Producer Library (KPL)
  • Kinesis データストリームにデータを格納するのに便利な、高度な設定が可能なライブラリ。非同期処理。
  • PutRecordなどは同期処理。
• Kinesis Agent
  • データの収集および Amazon Kinesis データストリームへのデータの送信を容易にする、ビルド済みの Java アプリケーション。Linux ベースのサーバー環境にインストールして利用する。
• ストリームの容量制限を超えている間、PUT データの呼び出しは ProvisionedThroughputExceeded 例外で拒否される。

拡張ファンアウト (Enhanced fan-out)

コンシューマーとシャード間に論理的な 2 MB/秒スループットパイプを提供する Kinesis Data Streams コンシューマーのオプション機能。普通に複数のコンシューマーを設計すると、Kinesis Data Streams の性能制限を超えてしまう場合や、200ms以下のデータ提供速度を求める場合に利用する。

• コンシューマーはまず、コンシューマー自体を Kinesis Data Streams サービスに登録する必要がある。
• KCL を使用している場合、KCL version 2.x はコンシューマーの登録を自動で行う。
• 登録されると、すべての登録されたコンシューマーはプロビジョニングされた独自の論理的な拡張ファンアウトスループットを持つようになる。
• 次に、コンシューマーは HTTP/2 SubscribeToShard API を使用して、そのスループットパイプ内のデータを取得する。

データの読み取り

• Kinesis アプリケーション
  • Kinesis Data Streams からのデータを読み取って処理するデータコンシューマー。
  • Kinesis Data Analytics, Kinesis API, KCLを使用する。
• Kinesis Client Library (KCL)
  • データコンシューマー。
  • データストリームボリュームの変化への適応、ストリーミングデータの負荷分散、分散サービスの調整、データ処理の耐障害性などの複雑な問題に対応。
  • KCLは、各 Amazon Kinesis アプリケーションの Amazon DynamoDB テーブルを自動的に作成し、リシャーディングイベントやシーケンス番号チェックポイントなどの状態情報を追跡および管理する。
  • Kinesis アプリケーションをオートスケールグループの一部であるEC2インスタンス上で実行することで、アプリケーションの処理能力を自動的にスケールできる。
• Kinesis Connector Library
  • KCLとは言わない。
  • Amazon Kinesis Data Streams を AWS の他のサービスやサードパーティ製ツールと簡単に統合できるようになる。
  • Amazon DynamoDB、Amazon Redshift、Amazon S3、Elasticsearch に対するコネクタを利用できる。
• Kinesis Storm Spout
  • Amazon Kinesis Data Streams と Apache Storm を統合するライブラリ。
  • Kinesis Data Streamsからデータをフェッチし、そのデータをタプルとして送出する。
• ApproximateArrivalTimestamp
  • レコードが Amazon Kinesis によって正常に受信および保存された時に設定される。
• 容量制限を超えている間、READ データの呼び出しは ProvisionedThroughputExceeded 例外で拒否される

Data Streams の管理

• リシャーディング
  • シャードの分割や結合を使用してデータストリームをスケールするために使用するプロセス。
  • シャードの分割では、1 つのシャードが 2 つのシャードに分割されて、データストリームのスループットが上がる。
  • シャードの結合では、2 つのシャードが 1 つのシャードに結合されて、データストリームのスループットが下がる。
  • 一度に実行できるリシャーディングオペレーションは 1 つだけ。

セキュリティ

• アカウントとデータストリームの所有者のみが、自分が作成した Kinesis リソースにアクセスできる。
• HTTPS プロトコルを使用して SSL エンドポイント経由で、Kinesis からのデータの格納と取得を安全に行うことができる。
• AWS KMS マスターキーでサーバー側の暗号化を使用して、データストリームに保存されているデータを暗号化できる。
  • Kinesis Data Streams のサーバー側の暗号化は、ユーザーが指定した AWS KMS マスターキー (CMK) を使用して自動的にデータを暗号化してから、データストリームストレージレイヤーに書き出し、ストレージから取得した後でデータを復号化する。
• 独自の暗号化ライブラリを使用して、データを Kinesis に格納する前にクライアント側のデータを暗号化できる。
• VPC エンドポイントを作成すると、Amazon Virtual Private Cloud (VPC) から Kinesis Data Streams API にパブリックIPを使わずにプライベートでアクセスできる。

--- CloudFront ---

「S3の署名付きURL」とするか「S3+CloudFrontの署名付きURL」とするか

共通

• URLを共有すれば誰でも見られる状態にできる
• 有効期限を設定できる

S3の署名付きURL

• URLがS3のものになる
• ユースケース
• 期間限定で何かしらのファイルを配信したい場合

S3+CloudFrontの署名付きURL

• カスタムURLを設定できる
• キャッシュを効かすことができるので高速な配信が可能
• ユースケース
• S3に置いていることを隠したい（自分のドメインにしたい）場合
• 「大量のリクエスト」が見込まれるファイルの場合（CloudFrontの特性が活かせる）
• グローバルなアクセスが見込まれる場合（CloudFrontの特性が活かせる）

特定の国、地域、個人からのアクセスを制限する方法

• CloudFront の地理制限機能の使用
  • （地域制限の有効化にてホワイト/ブラックリストで指定できる）
• 「国」より詳細なレベルで制限をする場合は、サードパーティの位置情報サービスの使用するしかない

キャッシュについて

https://qiita.com/tmiki/items/be36303e514ce4d012f8

• キャッシュコントロールする手段、メリット＆デメリット
  • Min/Max/Defaultがあるが基本的にはその値のみで動作が決定するわけではない。
  • ヘッダーの値など踏まえてキャッシュ時間が計算される
    • https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
  • TTLを0にした場合、リクエストの都度Originに更新有無を確認し、更新されてなければ304が返ってくる。その場合は、キャッシュしたコンテンツを返すためある程度はOriginの負荷軽減にもなる。
    • https://qiita.com/tmiki/items/be36303e514ce4d012f8

S3 hostingにおけるアクセス制御（署名付きURL or 署名付きCookie）

http://developers.goalist.co.jp/entry/2017/05/11/191628

• 署名付きURL/Cookieとは、非公開のbucketに対して、任意のクライアントにはアクセス許可を与えるための手法
• URLにアクセスしただけでは403となるが、署名付きでアクセスした場合は、許可される。
• 署名は、クライアントが秘密鍵、サーバ側が公開鍵を保持することで、認証と改ざん検知を行う。
• 署名には、有効期限を設定することができ、任意の時間しか公開しないようにすることができる。
• CloudFront 署名付き URL または署名付き Cookie を作成して Amazon S3 バケット内のファイルへのアクセスを制限する
• オリジンアクセスアイデンティティ (OAI) という特別な CloudFront ユーザーを作成して配布に関連付ける
• CloudFront が OAI を使用してファイルにアクセスしてユーザーに提供できるようにS3にアクセス許可を構成します
• たとえば、ユーザーがコンテンツにアクセスできなくなる日時の制御や、コンテンツへのアクセスに使用できる IP アドレスの制御が可能です。

Originのプロトコル設定

• HTTPか、HTTPSか、Match viewer（両方）か、で設定できる

キャッシュの最適化

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html

• クエリ文字列（URLの/login?back_url=～みたいな）に対するキャッシュの動作を指定できる。
• 設定の例
  • クエリ文字列により、コンテンツが変わらない場合は、クエリ文字列をOriginに転送せず、クエリ文字列に関係なくコンテンツをキャッシュする
  • すべてのクエリ文字列のパラメータに応じてキャッシュする。
    • この場合、クエリ文字列が違うと別のリクエストと解釈されるため、ヒット率が下がる。
  • 指定したクエリ文字列のみ、キャッシュしそれ以外はオリジンに転送する。
    • 上記１つと２つめのハイブリッドのようなもの

Lambda@Edgeについて

• CloudFrontの拡張機能。エッジロケーションでコードを実行するlambda関数のこと。
• Client→CF、CF→Origin、CF←Origin、Client←CFの4つのイベントをトリガとし起動可能。

---

--- API Gateway ---

提供されるメトリクス

• 4XXError：指定された期間に取得されたクライアント側エラーの数。
• 5XXError：指定された期間に取得されたサーバー側エラーの数。
• CacheHitCount：指定された期間内に API キャッシュから配信されたリクエストの数。
• CacheMissCoun：API キャッシュが有効になっている特定の期間における、バックエンドから提供されたリクエストの数。
• Count：指定された期間内の API リクエストの合計数。
• IntegrationLatency：API Gateway がバックエンドにリクエストを中継してから、バックエンドからレスポンスを受け取るまでの時間
• Latency：API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。

lambda統合時の504の原因

• API Gatewayはバックエンドの処理含め29秒でタイムアウトし504を返す
• INTEGRATION_FAILURE（統合失敗）
  • 応答タイプが指定されていない場合、この応答はデフォルトでDEFAULT_5XXタイプになる
• INTEGRATION_TIMEOUT（統合タイムアウトエラー）
  • 応答タイプが指定されていない場合、この応答はデフォルトでDEFAULT_5XXタイプになる
  • Lambdaの処理に時間かかって29秒以上経過した場合など
  • いつもは正常でたまに発生する、などの場合はこちらの可能性を疑う

Lambdaオーソライザーでの認証

• Lambda関数を使用してAPIへのアクセスを制御する機能
• OAuth や SAML などのベアラートークン認可戦略を使用する、または発信者 ID を判断するためにリクエストパラメータを使用するカスタム認証スキームを実装する場合に利用する
• 以下の2種類がある
  • トークンベース の Lambda オーソライザー (TOKEN オーソライザー)
    • JSON ウェブトークン (JWT) や OAuth トークンなどのベアラートークンで発信者 IDを受け取る
  • リクエストパラメータベースの Lambda オーソライザー (REQUEST オーソライザー)
    • ヘッダー、クエリ文字列パラメータ、stageVariables、および $context 変数の組み合わせで、発信者 ID を受け取ります

---

--- EC2 ---

各インスタンスタイプの特徴

T3インスタンス

• ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプ
• いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備える
• バランスの取れたコンピューティング、メモリ、およびネットワークのリソースを提供し、使用中に一時的なスパイクが生じる中程度の CPU 使用率を持つアプリケーション向けに設計されている

G2インスタンス

• 低レイテンシネットワーキングを備えた高度なグラフィック処理サーバーについて言及する場合は、EC2インスタンスの中のG2インスタンスが最適

G4インスタンス

• 業界内で最も費用対効果の高いGPUインスタンス
• 機械学習モデルの本番環境やグラフィクスを多用するアプリ向け

EC2のネットワークについて

100Gbpsのネットワークのサポート

• 前提として拡張ネットワーキングの有効化が必要
• 対応するのは以下のインスタンスタイプ
  • C5, C5d, C5n
  • F1, H1
  • G3, G4, I3, I3en, Inf1, m4.16xlarge
  • M5, M5a, M5ad, M5d, M5dn, M5n
  • P2, P3, R4, R5, R5a, R5ad, R5d, R5dn, R5n
  • T3, T3a
  • u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, u-18tb1.metal, u-24tb1.metal
  • X1, X1e, z1d

拡張ネットワーキング

• 高い帯域幅、低レイテンシーを実現するための機能
• OSへのモジュールインストールとEC2へのAWS CLIでの有効化が必要になる。（一部OS/タイプでは最初から有効化されている）

IPv6対応

• T3は未対応、T4は対応

インスタンスストアの特徴など

• EBSより高IOPS、高スループット、低遅延
• I3, F1, 第5,6世代では、C5d, M6gdのようにdがつくタイプのみ利用可能
• スナップショットの取得はできない、再起動ではデータ維持される
• 利用する場合は起動後にマウントが必要

EC2 AutoScaling Policyのトリガーとして使えるメトリクス

• CPU/Memory
• SQSのキュー
• ネットワークのIN/OUTトラフィック

プレイスメントグループについて

• EC2が起動するAWSのデーターセンターの物理サーバ配置を指定できる設定
• クラスター、パーティション、分散の３つの戦略がある
• クラスターは、インスタンス間の通信を低レイテンシーにしたい場合
• パーティションは、hadoopやkafkaなど、いくつかのインスタンスは低レイテンシにしつつ、それらの複数のクラスターを分散させたい場合
• 分散は、物理サーバのラックを分散させ耐障害性を上げたい場合
• 既存のインスタンスをプレイスメントグループに追加する場合は、一度停止させaws cliで移動させる必要がある

  • インスタンスタイプを統一し、追加に伴うインスタンス総数を再設定して追加した上で、プレイスメントグループを再起動することが必要です。既存のプレイスメントグループに新規EC2インスタンスを追加する際は、インスタンスグループ全体を一旦停止してから、新規EC2インスタンスをグループに追加して、プレイスメントグループにあるEC2インスタンスを再起動することで解決することができます https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/placement-groups.html#change-instance-placement-group

---

--- 認証・認可（IAM,STS）---

STS

• ユーザIDをAWSの外で管理している場合、AWSアカウントにIAMユーザを作成する代わりにIdPを利用する
• IdPを使用するには、IAM IDプロバイダーエンティティを作成して、AWSアカウントとIdPの間に信頼関係を確立する
• IAMはOIDCまたはSAML2.0と互換性のあるIdPをサポートする
• https://qiita.com/fkooo/items/a6d71407b2bed42332cc
• https://dev.classmethod.jp/articles/getfederetiontoken-assumerole-getsessiontoken/#toc-1

一時的なセキュリティ認証情報セットを取得するAPIコール 5種類

GetSessionToken

• 信頼されてない環境にあるユーザー向けの一時的認証情報
  • 帰ってくる認証情報　：IAM User
  • 認証を要求するユーザ：IAM User

GetFederationToken

• カスタムIDブローカーを経由したフェデレーション
  • 帰ってくる認証情報　：IAM User
  • 認証を要求するユーザ：Federated User（外部サービスのユーザ）

AssumeRole

• クロスアカウントの委任、カスタムIDブローカーを経由したフェデレーション
  • 帰ってくる認証情報　：IAM Role
  • 認証を要求するユーザ：IAM User

AssumeRoleWithWebIdentity / AssumeRoleWithSAML

• WebIdentityは、OpenID Connect互換のIdPを経由したフェデレーション、SLAMはSAML2.0　
  • 帰ってくる認証情報　：IAM Role
  • 認証を要求するユーザ：Federated User（外部サービスのユーザ）

モバイルアプリの認証実装パターン

前提知識

https://blog.serverworks.co.jp/summary-of-getting-security-credentials-from-sts

STSがユーザからのリクエストに対して割り当てる一時的認証情報

• アクセスキー(アクセスキーID, シークレットアクセスキー)
• セキュリティトークン
• 有効期限

解答

• パターン１
  • cognitoでユーザプール、IDプールを実装し外部IdPでの認証もしくは、cognitoで認証＋認可を実装する。
• パターン２
  • AssumeRoleWithWebIdentity APIの呼び出しをSDKで実装し、外部IdPからの認証情報を呼びだし、それをもってAWSからIAM Roleを引き受ける。

--- AWS Shield（マネージド型のDDoS保護サービス）---

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/ddos-overview.html

スタンダード（無料）

• 追加料金なしですべてのAWSユーザーが自動的に利用可能
• L3および4を標的とするDDoS攻撃を保護
• AWSへの受信トラフィックを監視し、悪意のあるトラフィックがあれば検出する
• 攻撃を自動的に緩和
• DDoS攻撃の履歴の参照、レポート化、通知を送信といったことはできない
• ただし、AWS WAFを同時に利用すれば、L7層のDDoSを検知/通知が可能

アドバンスト（有料）

• アプリケーションレイヤー（L7層）におけるDDoS攻撃も検出
• 高度なルーティング技術を利用した、より大規模なDDoS攻撃に対する追加の緩和機能
• AWSの他サービスとの連携でより可視化された状態の提供と攻撃の通知が利用可能
• DDoS攻撃の影響で請求金額が大きく上がった場合の払い戻し
• 24時間365日の専門サポート

DDoS対策関連リンク

https://media.amazonwebservices.com/jp/DDoS%20White%20Paper_Revised.pdf

https://www.slideshare.net/AmazonWebServicesJapan/awswebinar-awsddos

--- DynamoDB ---

概要

• リージョン内の3つのazで同期的にreplicateされ、高可用性＆耐久性を提供する
• デフォルトでは結果整合性（最新の書き込みを反映してない可能性がある）
• 強一貫性読み込みも可能（読み取り前に成功した書き込みを反省する結果を返す）
• DynamoDBはスループットを指定できるため、それを超えると「スループット超過エラー」となる
  • →これを防ぐために書き込み処理をSQSにQueingしバッファとすることが可能

Cross region Replicationの利用シーン

• 災害対策
• リージョン移行

DynamoDB Stream

• DynamoDBに対する項目の追加、変更、削除をイベントとして検出できる機能
• 24時間以内の変更の時系列順序を保持し、テーブル単位で有効にできる

キーの種類

https://qiita.com/shibataka000/items/e3f3792201d6fcc397fd

• プライマリキー

  • データを一意に識別するためのキー
  • パーティションキー or パーティションキー＋ソートキーの複合キーで構成

• パーティションキーとは

  • データをカテゴライズするためのキー
  • DynamoDBのデータは、複数のパーティションに分散して保存される。
  • この時、このパーティションキーを基にどのパーティションに保存されるかが決定される。
  • 例：個人情報テーブル（苗字、名前、郵便番号、電話番号）で郵便番号をパーティションキーとした場合、郵便番号が同じデータは、同じパーティションに保存される。

• ソートキーとは

  • ソートキーが設定されている場合、パーティション内でソートキーを基に並べ替えられ、物理的に近い位置に配置される。
  • 例えば、上記のテーブルで名前をソートキーとした場合、パーティション内で名前順にソートされる。
  • パーティションキーでカテゴライズし、そのカテゴライズされたデータをソートキーでソートする

• GSIとは

  • あるテーブルに対して、新たなパーティションキー＋ソートキーのテーブルを再作成する仕組み

• LSIとは

  • あるテーブルに対してパーティションキーはそのままに、ソートキーを別にしてでーぶるを作成する仕組み

• FGAC（Fine Grained Access Control）とは

  • IAMではテーブル単位？でしかアクセス制御ができない
  • それに対してレコード単位、キー単位での細かいアクセス制御を実現する
  • これにより、モバイルAppなどが直接DynamoDBへアクセスする構成がやりやすくなった

読み込みキャパシティーユニット（RCU）の計算方法

• 1つの読み込みキャパシティーユニットは、最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを表します。
• 例えば、10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルを作成するとします。これにより、最大 4 KB の項目について、1 秒あたり 10 回の強い整合性のある読み込み、または20回の結果的に整合性のある読み込みを行えます。
• 4KB を超える項目の読み込みには、より多くの読み取りキャパシティーユニットを消費します。たとえば、8 KB (4 KB × 2) の項目の強い整合性のある読み込みは、2 ユニットの読み込みキャパシティーユニットを消費します。同じ項目の結果的に整合性のある読み込みは、読み込みキャパシティーを 1 ユニットしか消費しません。 したがって、RCUは10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルに対して、 20 回の結果的に整合性のある読み込みを行えるため、10RCUが正しい設定となります。

書き込みキャパシティーユニット（WCU）の計算方法

• 1つの書き込みキャパシティーユニットは、最大サイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表します。
• 例えば、10 ユニットのプロビジョニングされた書き込みキャパシティーでテーブルを作成するとします。これにより、1 秒あたり最大でサイズが 1 KB の項目について、1 秒あたり 10 回の書き込みを行えます。
• 書き込みの項目サイズは、次の 1 KB の倍数に切り上げられます。たとえば、500 バイトの項目の書き込みは、1 KB の項目の書き込みと同じスループットを消費します。 したがって、WCUは30 ユニットのプロビジョニングされた読み取りキャパシティーのテーブルに対して、 1 秒あたり最大でサイズ1 KB の項目について、1 秒あたり 30 回の書き込みを行えます。

DynamoDBトランザクション

• 複数テーブルへの同時読み取りと書き込みの一貫性を提供する
• グローバルテーブルは非同期のためサポートされない
• 同時に10件のテーブル操作を1つのトランザクションにまとめられる
• トランザクション内での同じアイテムに複数操作はできない

https://qiita.com/blackcat5016/items/c2af7d3d55093134bac3

キャパシティ

• 自分で設定してプロビジョニング（パーティション設計が必要）
• Auto Scalingによるプロビジョニング（パーティション設計が必要）
• On-demond（パーティション設計が不要）
• キャパシティを15%以上利用される設計にできるのであれば、プロビジョニングのほうが安く済む

--- Direct Connect ---

ホワイトペーパーのサマリ

https://dev.classmethod.jp/articles/whitepaper-translate-jpn-vpc-connectivity-o]ptions-01/

構築に必要な設定

• VGWの設定とルート伝搬の有効化
• オンプレ側と通信するサブネットのルートテーブルにオンプレ宛のルートの登録

--- Transit Gateway network manager ---

https://dev.classmethod.jp/articles/transit-gateway-network-manager-vpn/ - TGWやVPC、VPNのトポロジを可視化して管理しやすくするサービス - 可視化とモニタリングが今のところの機能か？

--- Amazon MQ ---

• ActiveMQに互換性のあるマネージドサービス
• Pub/Sub型のキューイングサービス
• EC2としてVPC内に起動し、ActiveMQのGUIが使える
• 機能的には、SQSやSNSと同じだが、ActiveMQを利用しているユーザへの移行用として提供されているサービス
• AWSとしては、新規に使う場合はSQSを推奨している

--- キューイングシステム比較（MQ/Kafka）---

https://qiita.com/mura16/items/0ea2914156b1614201aa

--- RD gateway server ---

https://blog.pfs.nifcloud.com/20191711_RD_Gateway_RemoteDesktopConnection - インターネットから企業内のシステムにRDS接続する際に、https/443でプロキシするための機能/それを提供するサーバ - 接続先となるPC/サーバと同じLAN（FW）内に配置し、RD Gatewayサーバの設定を実施し、証明書をインストールする。 - クライアント側では、RDSの接続において、RD Gateway経由の接続を選択しサーバ名を指定する。クライアント証明書をインストールした上で接続を行う。

--- AWSへのBYOIP（所有しているグローバルIPアドレスの持ち込み手続き）の手順 ---

• AWSに自組織の所有するグローバルIPのアドレス範囲を持ち込むことができる。
• 対象のアドレス範囲は、RIR（Reginal internet registry）に登録する必要がある。

登録手順

1.ROAオブジェクト（IPアドレスレンジとASNの対応を証明するもの）を作成する

• ROA (Route Origination Authorization)
• “IPアドレスとそれを広報するAS番号の正しい組み合わせ” に、RPKIで発行したリソース証明書で署名を施したデータ。
• リソース証明書とは、以下用途とする証明書
  • アドレス資源の利用権利を証明する
  • ルーティングセキュリティで使う

http://jpopf.net/opf-jp/opm16/jpopm16-08.pdf

2.RDAPレコード作成のためのX509証明書作成

• RDAP (Registration Data Access Protocol)とは、IPアドレス等のレジストリに登録したデータにアクセスするためのプロトコルで、WHOISプロトコルの後継として、 RFC7480～7485において標準化されたものです。
• RDAPの主な特徴としては、以下が挙げられ、TCP43番ポートを用いてテキストベースで通信されるWHOISとは異なっています。
  • HTTP(S)にて通信されること
  • 応答がJSON形式で構造化されていること

3.署名付き認可メッセージを作成する

• アドレスレンジは、AWS CLIでプロビジョニングする。
• その際に必要となる署名付き認可メッセージの作成が必要となる。
• 署名付き認可メッセージの形式は以下のとおりです。日付はメッセージの有効期限日になります。

  1|aws|account|cidr|YYYYMMDD|SHA256|RSAPSS

4.AWSで使用するためのアドレス範囲のプロビジョニング

• 以下のコマンドでAWSに登録する。

  aws ec2 provision-byoip-cidr --cidr address-range --cidr-authorization-context Message="$text_message",Signature="$signed_message"

--- RDS Proxy ---

• アプリケーションとAWS RDS の間に配置され、Proxyとしてデータベースへの接続を効率的に管理してくれるサービス
• データベースへのコネクションプールを管理し、アプリケーションからのデータベース接続を少なく抑えられる
• フェールオーバー時間の短縮（Aurora および RDS データベースのフェールオーバー時間が、最大 66％ 短縮可）
• LambdaからRDSへの接続がある際は、コネクションが乱立する可能性があるためこれを使う方がいい。

--- App Sync ---

前提知識／Graph QLとは

• RESTの課題を解決するためにFacebookが開発したオープンソースのAPI
• RESTがアーキテクチャスタイルであるのに対して、GraphQLは、標準化された言語、型付け、仕様を持つクエリ言語である。
• RESTが取得できるリソースの内容を変更したい場合には、クライアント側でリソース取得後に加工するか、バックエンド側の改修が必要だった。しかし、GraphQLは、クエリするリソースのデータ構造をスキーマとして最初から定義するため、クライアント側から取得したいデータだけを選択し実装することができる（という理解）

https://www.webprofessional.jp/rest-2-0-graphql/

https://eh-career.com/engineerhub/entry/2018/12/26/103000

App Syncの概要

• サーバレスの形（EC2等不要で）でGraphQLのバックエンド（DynamoDBなどのデータソース）を実装できるサービス をエンドポイントを提供するためのサービス GraphQL版のAPI Gatewayのようなサービス １．GraphQLのスキーマ（データの種類、属性、片などの定義）を作成する ２．フィールドごとのリゾルバーを作成（スキーマとデータソースのマッピング） ３．GraphQLのエンドポイントが生成される ※便利なのはリゾルバーをVTLというテンプレート言語で作成することです。

https://dev.classmethod.jp/articles/relay-re-introduction-2019-appsync/

--- AWSが提供するマネージドETL（Extract/Transform/Load）サービスまとめ ---

Glue

• S3, RDS, Redshift等のAWSサービスの連携を仲介する
• クローラ、データカタログ、スケジューラー、ジョブ等の機能で構成される
  • データカタログ
    • 永続的なメタデータストア
    • ELT処理を実行する際に必要なテーブル定義、ジョブ定義、その他制御情報を保持する
  • クローラ
    • データカタログにメタデータテーブルを作成するプログラム
    • S3、DynamoDB、RDS、Redshift等をクロールすることが可能
  • ジョブ
    • ETL処理の内容（ビジネスロジック）
    • Apache SparkとPython Shellの2つのタイプがある
  • ETL処理の流れ
    • データソース（CSVファイル）をクロールして、データカタログにメタデータを作成する
    • データカタログの情報より、コンソールにてジョブを定義する
    • スケジューラーを設定してジョブの実行タイミングを設定する
    • ジョブを実行し、集出・変換・書き込みを実施する

Datapipeline

• マネージドETL（Extract/Transform/Load）サービス
• AWS内のデータソースからデータをExtractし、それに任意の処理を行い、別のデータソースに保存することができる
  • 例
    • S3からRedshiftにデータをロードする
    • RDSからデータを抽出してS3にエクスポートする

--- CloudFormation ---

Syntax

• DeletionPolicy
  • 削除時の動作を指定できる
• Snapshot
  • スナップショットをサポートするリソース (AWS::EC2::Volume など) の場合はを指定可能。これにより AWS CloudFormation は、スナップショットを作成したうえで、リソースを削除する。
• Retain
  • スタックを削除する際にこのリソースやコンテンツを削除せず保持する。
  • この削除ポリシーは、あらゆるリソースタイプに追加可能
• Delete
  • スタックの削除時にリソースと (該当する場合) そのすべてのコンテンツを削除する
• CreationPolicy
  • EC2インスタンスをプロビジョニングする場合、ソフトウェアパッケージのインストールやbootstrap処理など、追加のアクションを指定してインスタンスを設定できるようにするもの
  • インスタンスが正常に作成された後、（たとえ内部でinitスクリプトが完了していなくても）スタックの作成を続行する
  • CreationPolicyを使用するとアクションが完了した後にのみ、CloudFormationがスタックの作成を続行できるように設定が可能

CFでのLambda関数のデプロイ方法

• AWS::Lambda::Functionを利用して、Lambda 関数のデプロイパッケージをCloudFormationで参照する
• すべてのランタイムに対して、Amazon S3 内のオブジェクトの場所を指定可能
• 例外的に依存関係が無い場合は、AWS::Lambda::FunctionにLambda関数コードを記載可能である

ヘルパースクリプト

• CroudFormationでのEC2作成時にEC2へのミドルウェアのインストール、その実行結果の有無をCF側に連携させるなどの事ができる拡張ツール。

cfn-init 　      : EC2へのパッケージのインストール、ファイル作成などをできる
cfn-signal       : EC2内の指定のインストールができたときに結果（OK/NG）を他のスタックに連携させる
cfn-get-metadata : メタデータの取得
cfn-hup          : メタデータへの更新を確認し、変更を検知し次の処理に連携させる

--- Amazon Inspector ---

• 対象AWSにおいてよくあるセキュリティリスクに対処できているかをテストする
• 運用中のEC2でもしもAのような攻撃を受けたとしても問題ないような設定や仕様になっているか？という観点
• 以下のルールパッケージがある
  • ネットワークの到達可能性
    • ネットワークを介してアクセス可能かどうかを評価されるセキュリティ評価項目のパッケージ
    • インターネット経由でポートベースやVPC ピアリング接続、VPNを通じて該当EC2にアクセスされる可能性があるかどうかを評価します。
  • ホスト評価
    • Amazon EC2インスタンスそのもの（ホスト）に関するセキュリティ評価項目のパッケージ。
    • EC2そのものの脆弱性や問題のある設定をチェックします。

--- AWS Organization ---

• 複数のAWSアカウントのセキュリティと請求をまとめて管理するためのサービス
• マスターアカウントとそこに属する子アカウントという構造をとる
• Organaizationを使用して子アカウントを新規に作成するとAdmin権限が付与されたOrganizationAccountAccessRoleというロールが子アカウントに自動的に作成される。

セキュリティの管理

• OUという単位でAWSアカウントをグループ化できる。またOUは階層的に定義することができる。
  • →例）開発事業部の第一開発部、第二開発部のような
• OUに対して、SCPというポリシーを割り当てることで、そのアカウントに許可/拒否するAWSサービスを制御できる
• OUには、継承という機能があり上位のOUで許可/拒否されているAWSサービスは、下位のOU/AWSアカウントでも許可/拒否される
• SCPは、IAMポリシーと同じ考え方/記載方法（暗黙のDeny＜明示Allow＜明示Deny）
• ただし、SCPは、サービスにアタッチされたIAMロールには影響しない。

請求の管理

• 子アカウントの請求をマスターアカウントにまとめることができる

https://dev.classmethod.jp/articles/organizations-scp-inheritance/

Organizationsからの子アカウントの削除

• 削除対象のアカウントがスタンドアロンとして動作するための設定がされている必要がある。
• そのためには、メンバーアカウントに支払い関連の権限を割り当てられたIAMユーザにて設定を変更する必要がある。

OrganizationでのCloudtrail

• マスターアカウントのCloudTrailを有効化することで全メンバーアカウントのログ取得が可能となる。
• その場合、ログ取得先をプライマリアカウントの単一S3バケットにすることも可能。
• Organization使わない場合も、別アカウントのS3バケットに送信することは可能。

利用可能な2つの機能セット

• Organizations自体が以下の2パターンで作成できる。

すべての機能

• 一括請求、SCP、組織全体でのAWSサービス管理、アカウントの作成招待が可能
• Organizationsを利用するにあたって有効化することが推奨されている

一括請求機能

• 請求機能とアカウントの作成及び招待の2つの機能のみ利用可能

リザーブドインスタンスの共有

• Organizationsの場合、リザーブドインスタンスを共有できる
• 逆に共有しないための設定は、マスターアカウントからのみ可能

---

CloudHSM

• 専用のハードウェアで暗号化キーを保管する（KMSはハードウェアは顧客間で共用）
• CloudHSMの方がより安心してキーを管理することが可能
• KMSに比べると高価
• FIPS 140-2のレベル3認証済みのHSMを使用して、暗号化キーを管理できる
• ログを保存するために、可用性が高く耐久性のあるS3サービスを使用して、SSE-3Sによる暗号化を実施できる
• SSE-S3は暗号化キーの管理はAWS側で実施される

CloudHSMを使ったHTTPS（SSL）のオフロード（暗号化処理をCloudHSMで実施できる）

1. クライアントはサーバーに Hello メッセージを送信する
2. サーバーは Hello メッセージで応答し、サーバーの証明書を送信する
3. クライアントは以下のアクションを実行する
   1. SSL/TLS サーバーの証明書がクライアントの信頼するルート証明書により署名されていることを確認する
   2. サーバーの証明書からパブリックキーを抽出する
   3. プリマスタシークレットを生成し、サーバーのパブリックキーで暗号化する
   4. 暗号化されたプリマスターシークレットをサーバーに送信する
4. クライアントのプリマスターシークレットを復号するため、サーバーはそれを HSM に送信する。HSM は、HSM のプライベートキーを使用してプリマスターシークレットを復号し、プリマスターシークレットをサーバーに送信します。クライアントとサーバーはそれぞれ独立してプリマスターシークレットおよび Hello メッセージからのいくつかの情報を使用して、マスターシークレットを計算する。
5. ハンドシェイクプロセスは終了する。残りのセッションでは、クライアントとサーバーの間で送信されたすべてのメッセージは、マスターシークレットのデリバティブで暗号化される

---

--- ELB ---

トラフィック急増時の原因確認に使えるメトリクス

メトリクス名	説明
SurgeQueueLength	サージQueの状況。ALBにて保留中のリクエストの数
SpilloverCount	サージQueがいっぱいであったため破棄されたリクエストの数

クライアント証明書使う場合の実装

• EC2でHTTPSを終端する必要があり、ALBで終端することができないため、NLBを使用しTCPリスナー（443）とする必要がある

Proxy Protocolについて

https://dev.classmethod.jp/articles/nlb-meets-proxy-protocol-v2/

S3暗号化

https://stay-ko.be/aws/solutionarchitect-pro-amazon-s3-data-protection/

スティッキーセッションについて

スティッキーセッション時のcookie名はAWSELBとなる（CLBでも同じ）

---

--- System Manager ---

https://d1.awsstatic.com/webinars/jp/pdf/services/20200212_AWSBlackBelt_SystemsManager_0214.pdf

https://blog.serverworks.co.jp/tech/2020/04/16/systems_manager_yattemiyou/

https://uh-inc.backlog.com/wiki/CLOUD/AWS+System+Manager+%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

運用管理

• エクスプローラー(Explorer)：運用アイテム情報のダッシュボード
• OpsCenter：運用アイテム（対応が必要なイベント）の管理
• CloudWatch ダッシュボード：CloudWatch用のダッシュボードをカスタマイズ
• Trusted Advisor と PHD：Trusted Advisor と Personal Health Dashboard のダッシュボード

アプリケーション管理

• リソースグループ(Resource Groups)：タグによるサーバー群のグループ管理
• AppConfig：アプリケーション設定（機能グラフ等）の管理
• パラメータストア：設定パラメータの集中管理用データストア
  • 各種設定値を安全に格納場所。アプリケーションやコンテナからSDKやAPIで取得できる。

変更管理

• 自動化(Automation)：AWS環境全体に対する自動化処理の実行
• カレンダーの変更(Change Calendar)：実行可否を制御するカレンダー
• メンテナンスウィンドウ：自動化処理のスケジュールと順序の管理
• ノード管理
• コンプライアンス(Configuration Compliance)：コンプライアンスの適合状態ダッシュボード
• インベントリ(Inventory Management)：サーバー構成情報のインベントリを閲覧する
• マネージドインスタンス：SSM管理対象のサーバー群
• ハイブリッドアクティベーション(Activations)：オンプレミスサーバーをSSM管理下に入れる
• セッションマネージャー：SSMを使ったサーバーへリモートアクセスする
• SSMドキュメントを利用したcronジョブ的機能
• Run Command：サーバー群の上でコマンドを実行するステートマネージャー(State Management)：サーバー群の構成を指定した状態に維持する
• パッチマネージャー(Patch Mangement)：サーバー群に指定ルールに基づきパッチを適用する
  • 指定したインスタンスに対し、メンテナンスウィンドウでの自動パッチ適用が可能。
  • パッチグループとパッチベースラインで設定する（link）
• ディストリビューター(Distributor)：サーバー群にパッケージをインストールする

共有リソース

• ドキュメント：
  • 管理対象インスタンスに対する操作を定義したもの。
  • インスタンス自体の起動/停止/作成/削除などの操作とOS内でのコマンドの実行などを事前に定義できる。
  • これをテンプレートとして自動化などに利用する。

有料な機能

• OpeCenter
• AWS AppConfig
• パラメータストア
• オンプレミスインスタンス管理
• ディストリビューター
• オートメーション

---

Amazon Managed Blockchain

• フルマネージド型のサービスで、一般的なオープンソースフレームワークである Hyperledger Fabric や Ethereum を使用して、スケーラブルなブロックチェーンネットワークを簡単に作成し管理できる
• ブロックチェーンネットワークへの参加するためには、ブロックチェーンネットワークに他の AWS アカウントを招待するという提案を作成し、そのネットワーク内の現在のメンバーがその提案に対して投票し、ネットワークの投票ルールに基づいてその提案が承認された場合、その AWS アカウントはネットワークに参加するための招待状を受け取れる
• Managed Blockchain ネットワークは分散型のリソースで、ネットワークの作成時に指定された投票ルールに応じて、等しい所有権の持ち分が複数の AWS アカウントに割り当てられる
• マネジメントコンソールにおいて、当該ネットワークへのアクセス権限を付与したIAMロールによってメンバー参加をさせることはできない
• 当該ネットワークへのアクセス権限を付与したSTSを設定することでメンバーを参加させることはできない
• メンバーアカウントの中からネットワークに参加するアカウントを指定して、登録許可を実施するといった対応はできない