Assume Roleに必要なもの

• 移譲先のAWSアカウントID (例 3rd Partyベンダー側のAWSアカウント)
  信頼ポリシー作成時にプリンシパルとして必要
• ロールに紐づける外部ID
  移譲元と移譲先だけが知っている識別子。移譲元が設定し、移譲先が引き受ける際に指定する。
  https://dev.classmethod.jp/articles/iam-role-externalid/
• 移譲先が操作するためのアクセス許可
  許可ポリシー。

サービスリンクのIAMロール

「AWSサービス」にリンクされたロール。後述の「リソースベースのポリシー」とは概念的にも別物。
あくまで、「AWSサービス」がユーザーの代わりに振る舞う権限が定義されたもの。

なお、OrganizationのSCPは、サービスリンクされたロールには影響しない。
サービスにリンクされたロールは、他のAWSサービス・AWS組織と統合でき、この権限についてはSCPによって制限することはできない。

ポリシー分類

ユーザーベースのポリシー

IAMユーザー、グループ、ロールにつけるポリシー。
操作主体となる「Principal」は記述せず、これがアタッチされたものが操作主体となる(ユーザーベース)。

リソースベースのポリシー

関連づける先が「ユーザー等」ではなく「AWSサービス」であるポリシー。わかりやすいのが、S3バケットポリシー。
操作される側(リソースベース)につけるポリシーというイメージになる。

これが用いられるサービスは特定のものしかなく、S3, EMR, API GW, Lambda, Glue, EFS, ECR, Backup, CodeBuild, Cloud9, KMS, ACM, CloudWatchLogs, OpenSearch Service (旧ElasticSearch)等が該当
※こちら参照：http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

タグ付けの強制

タグ付を強制するIAMポリシーの設定としては、ForAllValues修飾子を使用してポリシーで定義されているすべてのタグを適用する場合にのみ、ユーザーがリソースを作成できるようにする形になる。これにより、ユーザーがポリシーに含まれていないタグを適用すると、アクションは拒否される。
この制御にくわえて、Organizationなどでタグポリシー等制御を組み合わせて管理する。

インスタンスプロファイル

名前(と存在)忘れがち。
IAMロールをEC2へ渡すコネクターの役割。
https://dev.classmethod.jp/articles/do_you_know_iaminstanceprofile/

オンプレの認証情報によるAWSへのシングルサインオンの実現には、オンプレミスにあるSAML2.0 IDプロバーダーとAWS SSOエンドポイントを使用する。
また、もしオンプレの認証情報がADにある場合、オンプレミスのIDプロバイダー(IdP)としてAD Federation Service (ADFS)などが利用できる。 この場合、オンプレミスのIDストアをSAMLベースのIdPと連携するように設定する。

こちらでパターンを整理
https://d1.awsstatic.com/webinars/jp/pdf/services/20200722_AWSBlackbelt_シングルサインオンの設計と運用.pdf

SAMLは、Security Assertion Markup Languageの略。
異なるインターネットドメイン間でユーザー認証を行うための認証情報の規格で、ユーザーの認証情報をやり取りするルール・プロトコルのことを指している。

登録流れ

1. オンプレIdPでSAMLのメタデータドキュメントを作成する。
2. AWSのIAMで新しいSAMLプロバイダーを作る。これに前の手順で作成したメタデータドキュメントをアップロードする。
3. IAMロール(AssumeRoleWithSAML用)を作成する。このロールにて、フェデレーション時にIdPをプリンシパルとして識別させるようにし、信頼ポリシーとしてはIAMで作成したSAMLプロバイダーを指定する。さらに、AWSで実行するアクションも定義する。
4. AWSのsaml-metadata.xmlファイルをオンプレミスのIdPにインストールし、AWSを信頼された証明書利用者として登録する。

利用者の認証流れ

1. オンプレのIdPで認証、SAMLアサーションを取得。
2. IdPからAWSのAWS SSOエンドポイントへSAMLアサーションをPOST。
3. AWS SSOが、STSからAWSへの一時トークンを取得し、SSOのエンドポイントからコンソールのログインURLを利用者へ返す。
4. そのURLを使い、AWSへログイン

Web Identity Federation

FBやGoogleなどのパブリックIdPで利用されるフェデレーション。この場合はこれを許可するAssumeRoleWithWebIdentity用のIAMロールを準備する。

OAuth 2.0

FBやGoogleなどのパブリックIdPとのWeb Identity Federationで利用される機能。クライアント側へのアクセストークンの要求・応答を標準化したもの。

AssumeRoleWithWebIdentity

Web Identity Federation専用のSTS。この場合の、一時的な認証セット要求APIコールとしてこれが使われる。

IAMの一時認証リクエスト

一時的な認証のリクエストでは、AWS API で AWS Security Token Service (AWS STS) が使用される。
この一時認証情報を引き受けるために、アプリケーションはAWS STS AssumeRole APIオペレーションを呼び出し、使用するロールのARNを渡す。 この認証操作により、一時的な資格情報で新しいセッションが作成される。 このセッションには、そのロールのIDベースのポリシーと同じ権限がある。

リモートアクセスのVPNについて

IPSec VPN

ネットワーク層で張られるVPN
特定の拠点間など、接続元同士がわかっているような場合に向いている。
そのため、セキュリティ的にも安全となる。
あくまでネットワーク層の通信なので、SSLでの暗号化(SSLはセッション層)ではなく、別の暗号化アルゴリズム(AH、ESP、IKE等)で暗号化通信が行われている。

SSL VPN

セッション層で張られるVPN
SSL証明書を使って認証することで接続先を担保している。
以下のパターンがある

• リバースプロキシ
  Webブラウザを用いてリモート端末とVPN装置間でSSL通信を行う。Webブラウザ上アプリケーションで使える。
• ポートフォワーディング
  Webブラウザから特定のモジュールが自動的にSSLを確立する方式。ポート番号が変わらなければ使えるが、FTPなどのファイル転送がある場合には不向き
• L2フォワーディング
  SSL-VPNクライアントソフトウェアをインストールして行う方式。アプリケーションデータをHTTPSのパケットでカプセル化してSSL暗号化するので、全アプリケーションで使用できる。

AWSの場合

SSL VPNとして、AWS Client VPNが提供されている。これを用いることで、ユーザーがAWSリソースにプライベート接続できるようになる。

一方、IPSec VPNとしては、サイト間VPN (AWS Site-to-Site VPN)がある。これは、オンプレミスとVPC間のプライベート接続で使われる。
カスタマーGW, 仮想プライベートGW, TransitGWなどがこれの構成コンポーネントとなる。

流れ

1. AWSでVPCの作成
2. AWSで仮想プライベートGW(VGW)の作成
3. AWSでカスタマーGW(CGW)の作成
4. ルーティング設定(AWS側)
5. AWSでSite-to-Site VPN接続の作成
6. ローカルネットワーク側の設定

カスタマーゲートウェイの存在意義

拠点がわかっている状態で接続申請するDXと違い、VPNの場合はAWSから見たら接続先がわからないので、その情報をもつリソースを作成する必要がある。それがカスタマーゲートウェイの役割。
カスタマーゲートウェイ作成時に、IPとルーティング(静的・動的)を登録しておき、VPN接続時は、仮想プライベートデートウェイとそのカスタマーゲートウェイを接続するように設定する形になる。

CloudTrail連携

AWS Organizationsを利用し、マスターアカウントのCloudTrailで組織の証跡を有効化することで、全てのメンバーアカウントでのログ取得を可能にすることができる。それにより、各AWSアカウントに関連するログをプライマリアカウントの単一のS3バケットに配信する設定が可能になる。

メンバーアカウントの削除

この場合は、

• メンバーアカウントでの請求を、メンバーアカウントのIAM ユーザーアクセスで有効にする
• アカウントがスタンドアロンアカウントとして動作するために必要な情報を登録(AWSカスタマーアグリーメント同意、サポートプラン、連絡先情報、支払い方法)する

がまず必要になる。
その上でスタンドアロン化したアカウントを削除する流れになる。

SCPの制限事項

SCPは、OU化のアカウントの各種権限範囲を指定できるだけで、具体的な許可条件などは指定することができない。リソースごとなどの制御をかけたい場合は、IAM側での実施になる。

一括請求とリザーブドインスタンス

一括請求 (コンソリデーティッドビリング)が有効になっていれば、デフォルトでリザーブドインスタンスの購入条件は同一組織内で共有される。これを避ける場合は、リザーブドインスタンスの共有をオフにする必要がある。

なお、リザーブドインスタンスの購入条件 (リージョン・AZ指定・タイプ等)は当然他のアカウントでも同一視される。

AWS Budgetsとの組み合わせ

請求のマスターアカウントでは、AWS Budgetsで組織全体の予算管理になるが、リンクされた子アカウントの予算管理もできる。それをもとにSCP適用をするアクションを取ることも可能。
ただし、リソース個別の細かな管理については、マスターアカウントだと見えきれない場合がある。
そのため、子アカウントに対して個々に細かく管理する場合は、子アカウント側で有効化・設定し、それを持ったアクションをSNS経由で実施したり、Budgets Actionsで実施する方法もある。

https://fu3ak1.hatenablog.com/entry/2020/12/29/144304
https://blog.serverworks.co.jp/aws-budgets-actions

Organizationの機能セット

2パターンの機能セットの有効化ができる。

• すべての機能
  Organizationの使用はこちらが推奨。SCPなどの機能を用いるにはこちらが必要。
• 一括請求 (コンソリデーティッドビリング) 機能
  全ての組織でサポートされ、請求とのアカウント管理を一元化するために使用できる基本的な管理ツールが提供される。
  なお、後から「すべての機能」有効化もできる。

請求タグ

コスト配分タグについては、Billing and Cost Managementページから設定することが可能。
複数アカウントのOrganization環境の請求レポートで活用する場合は、masterアカウントでタグを有効化することが必要となる。

地理的制限

CloudFrontのエッジロケーションでは地理的制限を有効化ができ、特定の国・地域からのアクセスを制限できる。ただしこれはディストリビューションのすべてのファイルに当てはまる。ただ、もしファイルのサブセットレベルでアクセス制限が必要な場合や、「国・地域」レベルより詳細なレベルでアクセスを制限する場合は、サードパーティー性の位置情報サービスを用いる必要がある。

WebディストリビューションのOrigin Protocol Policy

ディストリビューションがWebの際は、オブジェクトのリクエスト時にビューワーがHTTPやHTTPSを使用するように、Origin Protocol Policyで設定することができる。
ただし、これはあくまでオリジンへの通信のオプションになる。
Origin Protocol Policyの値として選択できる3つのオプションは以下。

• HTTP Only：HTTPのみでオリジンにアクセス
• HTTPS Only：HTTPSのみでオリジンにアクセス
• Match Viewer：リクエストのプロトコルに応じてHTTP/HTTPSでオリジンへアクセス

ビューワープロトコルポリシー

これはビューワー(閲覧者)からCloudFrontへの通信部分の制御。以下のオプションがある。

• HTTP and HTTPS：HTTP/HTTPSでもどちらでもアクセスできる。
• HTTPS Only：アクセスがHTTPSの時のみコンテンツにアクセスできる。HTTPの場合は403を返す。
• Redirect HTTP to HTTPS
  GET/HEADリクエストは自動的に HTTPSにリダイレクトしビューワーに一旦戻す(コード301を返す)。
  戻った後HTTPSリクエストとして再度アクセスが来るが、この場合CloudFrontでは両方のリクエストに対する課金が発生する。

キャッシュヒット率の向上

キャッシュ期間を長くする

Cache-Control max-age ディレクティブをオブジェクトに追加し、max-ageを適切な範囲で長くする。これにより、オブジェクトの変更確認の感覚が長くなる。

Origin Shield の使用

Origin Shieldは、オリジンの負荷を最小限に抑え、可用性を向上させ、運用コストを削減するために役立つ、CloudFront キャッシュインフラストラクチャ内の追加レイヤー。
CloudFront のすべてのキャッシュレイヤーからオリジンへのすべてのリクエストが Origin Shield を通過するようになり、キャッシュがヒットする可能性が高くなる。
Origin Shield により、オリジンへのリクエストと、CloudFront キャッシュのその他のレイヤー (エッジロケーションとリージョン別エッジキャッシュ)へのアウトバウンドトラフィックが集約できる。

クエリ文字列パラメータに基づくキャッシュ

オリジンが一意のオブジェクトを返すクエリ文字列パラメータのみを転送するように CloudFront を設定する。主なものとしては、クエリ文字列の大文字小文字を統一したり、パラメータ順番を統一する。

Cookie 値に基づくキャッシュ

• すべての Cookie を転送する代わりに特定の Cookie のみを転送するように CloudFront を設定
• 静的コンテンツと動的コンテンツに対してそれぞれ異なるキャッシュ動作を作成し、動的コンテンツの場合にのみ Cookie をオリジンに転送するように CloudFront を設定
• Cookie 値がユーザーごとに一意である (ユーザー ID など) 動的コンテンツと、より少ない数の一意の値に基づいて変化する動的コンテンツに対してそれぞれ異なるキャッシュ動作を作成

リクエストヘッダーに基づくキャッシュ

• すべてのヘッダーに基づいて転送およびキャッシュする代わりに特定のヘッダーのみに基づいて転送およびキャッシュするように設定
• 多数の一意の値を持つリクエストヘッダーに基づいてキャッシュすることを可能な限り回避する

圧縮が不要な場合に Accept-Encoding ヘッダーを削除する

キャッシュキーから Accept-Encoding ヘッダーを削除し、オリジンリクエストにヘッダーを含めないため、オリジンリクエストにヘッダー情報が含まれず、そのオリジンからは同一のコンテンツが変えるようになる。

HTTP を使用したメディアコンテンツの提供

ビデオオンデマンド (VOD) およびビデオコンテンツのストリーミングで用いられる
※参考
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html

Origin Access Identity (OAI)

オリジン設定項目で、S3へのアクセスをCloudFront経由に限定する際に使う機能。

以下の流れで実施する

• オリジンアクセスアイデンティティ (OAI) と呼ばれる特別な CloudFront ユーザーを作成し、ディストリビューションに関連付ける。
• CloudFront が OAI を使用してバケット内のファイルにアクセスしてユーザーに提供できるように、S3 バケットのアクセス許可を設定する(バケットポリシー等)。
• また、ユーザーが S3 バケットへのダイレクト URL を使用して、そこにあるファイルにアクセスできないようにS3側で設定する(バケットポリシー等)。

DDoS対策

CloudFrontには、AWS WAFを当てられるほか、そのものがエッジロケーションで利用者からのアクセスを世界中に分散してくれるため、DDoSのような多数のIPからの攻撃対策にもなる。
その意味では、ALBの前段に置くというのも十分効果的。

オリジンフェイルオーバー

オリジングループにプライマリオリジンとセカンダリオリジンを設定することで、CloudFrontのみのフェイルオーバーが実装できる。
https://dev.classmethod.jp/articles/cloudfront-origin-failover/
※ブログにある通り、オリジンリクエスにおいてLambda@Edgeを活用している環境で、プライマリオリジンのリクエストでエラーが起きた場合、セカンダリ側で再発火される。

CloudFrontのログ

CloudFrontログは定期的にAmazon S3に保存される。つまり、即時保存ではなく、場合によっては最長 24 時間後に発生することとなる。

ディストリビューションの標準ログを 1 時間に最大で数回配信します。一般的に、ログファイルには、一定期間内に CloudFront が受信したリクエストに関する情報が含まれています。CloudFront は通常、その期間のログファイルを、ログに書き込まれたイベントの発生から 1 時間以内に Amazon S3 バケットに配信します。ただし、ある期間のログファイルエントリの一部またはすべてが、最大で 24 時間遅れることもあります。

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#access-logs-timing

バージョニング

既存のS3のバージョン管理を有効にする場合、既存のファイルはすべてバージョンIDがNULLになる。
有効化後に追加・更新されるファイルは、英数字のバージョンIDが振られる。

顧客が用意した暗号化キー(SSE-C)を使用したサーバー側の暗号化

バケットにオブジェクトがアップロードされると、その鍵を使って暗号化を行う。この場合、HTTPでのリクエストは使えなくなる。

この場合、Amazon S3 REST APIで呼び出す際には、以下のHTTPリクエストヘッダーを全て含める必要がある。

• x-amz-server-side-encryption-customer-algorithm
• x-amz-server-side-encryption-customer-key
• x-amz-server-side-encryption-customer-key-MD5

S3で管理された暗号化キー(SSE-S3)によるサーバーサイド暗号化

• バケットに格納されたオブジェクトは、強力な多要素暗号化を使用する一意のデータキーで暗号化される。
• このデータキーも、定期的にローテートされるカスタマーマスタキーを使用して暗号化される。
• サーバーサイド暗号化はAWS マネジメントコンソールまたは HTTP リクエストヘッダーを使用しているため、事前に署名された URL を使ってアップロードする場合には適用できない。

KMSで管理された暗号化キー(SSE-S3)によるサーバーサイド暗号化

SSE-S3 に似ているが、AWS キーマネージメントサービス (KMS) を使用してサーバーサイドで暗号化する方式

通信の暗号化

S3への接続をHTTPSに限定する際は、"aws:SecureTransport": "false" を満たすようにバケットポリシーを設定することで実現できる。
なお、この設定の有無をConfigルール「s3-bucket-ssl-requests-only」を用いて検知することもできる。
バケットポリシー例

{
  "Id": "ExamplePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSSLRequestsOnly",
      "Action": "s3:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

※参考
https://aws.amazon.com/jp/premiumsupport/knowledge-center/s3-bucket-policy-for-config-rule/

S3 RSS

Amazon S3 低冗長化ストレージ(RSS)
一応あるが、推奨されていないので忘れる。
S3 One Zone-IA (S3 OneZone 低頻度アクセス)に似ているが、別物。

S3内データの分析

検索機能：ElaticSearchまたはAmazon CloudSearch
簡易的なデータ抽出：Amazon S3 Select
データ分析：Amazon EMR またはAthena

※ElaticSearchとAmazon CloudSearchの比較についてはこちら
https://dev.classmethod.jp/articles/elasticsearch-service-vs-cloudsearch/

S3選択フローチャート

神。いつもどこか忘れる部分が全部まとまっている。
https://cdn-ssl-devio-img.classmethod.jp/wp-content/uploads/2021/03/Untitled-1.png
https://dev.classmethod.jp/articles/should_i_choice_s3_storage_class/

Amazon S3 Transfer Acceleration

クライアントと Amazon S3 バケットの長距離間でファイルを高速、簡単、安全に転送する設定。世界中に散らばる Amazon CloudFront の AWS エッジロケーションが活用され、データが AWS エッジロケーションに到着すると、最適化されたネットワークパスで Amazon S3 バケットに向かうようルーティングされる機能。S3 Transfer Acceleration を有効にし、Amazon S3 の PUT および GET リクエストで、s3-accelerate エンドポイントのドメイン名を指定することで通信できる。
この機能とマルチパートアップロードといった各種S3標準機能も併用できる。

Amazon S3 クロスリージョンレプリケーション (CRR)

CRR とは、さまざまな AWS リージョンのバケット間でデータを自動的にレプリケートする Amazon S3 の機能。CRR を使用すると、バケットレベル、共有プレフィックスレベル、オブジェクトレベルで S3 のオブジェクトタグによってレプリケーションを設定できる。
また、さまざまな地理的地域で低レイテンシーのデータアクセス(GETアクセス)を実現できたり、離れた場所にデータのコピーを保存する(バックアップなど)というコンプライアンス要件がある場合にも役立つ。

オブジェクト名の工夫 (ハッシュの付与)

旧ドキュメントに記載されていた"The sequence pattern in the key names introduces a performance problem.(キー名を連続するパターンにすると、パフォーマンス上の問題が発生します)"という問題が解決しています。
従来は、キー名がシーケンシャルだとI/Oが分散せず性能が向上しませんでした。その為、
・16 進のハッシュプレフィックスをキー名に追加する
・キー名の文字列を左右反転する(逆キーを生成する)
のように、設計時にキー名を考慮してあげなければいけない。

PUT/POST/DELETEリクエストでの技の一つ。

※参考
https://dev.classmethod.jp/articles/amazon-s3-announces-increased-request-rate-performance/

リクエスタ払い

通常、S3の料金は、データ格納や転送量はバケット所有者が負担するが、リクエスタ払いを設定すると、オブジェクトのDLやリクエストに関してはそれを実施した側が支払うようにすることができる。
リクエスタ払いの場合、バケット所有者とアクセス許可されたアカウント側のみオブジェクトにアクセスできるようになり、匿名アクセスは不可になる。
また、アクセス許可については、

• アクセスするアカウントでIAMポリシーの設定を行う
• HTTPアクセスの場合、リクエストヘッダに"x-amz-request-payer"を含める

などを実施することで実現できる。

マルチパートアップロード

S3に対し、アップロードでファイルを分割して行う方式。
大きなデータなどを分割して送るので、

• 並列送信ができるため、高速転送ができる
• 一部が転送に失敗してもその部分のみやり直しができる
• 上記に関連し、オブジェクトのアップロードの一時停止・再開ができる

S3 Standard-IAとS3 One Zone-IAの注意点

これらのオブジェクトクラスは、30日以上の利用を想定しており、それ未満の利用でも1ヶ月分の料金が取られてしまう。

注記
S3 Standard-IA と S3 One Zone-IA ストレージクラスは、サイズが 128 KB 以上あり、少なくとも 30 日間保存する予定のオブジェクトに最適です。オブジェクトが 128 KB 以下の場合、Amazon S3 は 128 KB に相当する料金を請求します。最小ストレージ期間の 30 日が過ぎる前にオブジェクトを削除した場合は、30 日分の料金が発生します。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/storage-class-intro.html#sc-infreq-data-access

画像分析機能をアプリケーションに簡単に追加できるサービス。
現在はRekognition Imageが画像認識サービスになり、分析対象が動画の場合はAmazon Rekognition Videoを用いる。

Rekognition API

画像・動画問わず両方とも。

• DetectLabels：物体やシーンとの画像比較
• DetectFaces：顔との画像比較 (表情分析)
• CompareFaces：二つの画像の顔の比較 (同一人物可能性)
• IndexFaces/SearchFacesByImage：顔のインデックス付けと、大量の画像からの同一の顔を検索する

他にも、LambdaにあるRekognition用ブループリントを用いることで、S3やDynamoDBに対しても画像分析を実行できたり、有名人検索等随時追加されている。

Rekognitionでは、画像をバイトコードに変換する方式(base64エンコードなど)は使わない。

Rekognition Video

動画認識サービス。認識対象の動画データとして、S3上のmp4/movファイルと、Kinesis Video Streamのストリームに対応している。

分類

Amazon Kinesis Video Streams

分析、機械学習 (ML)などの処理のために、接続されたデバイスから AWS へ動画を簡単かつ安全にストリーミングできるようにするサービス

Amazon Kinesis Data Streams

数十万規模のソースから秒あたり数ギガバイトものデータを継続的にキャプチャできる、スケーラブルで耐久性に優れたリアルタイムデータストリーミングサービス

Amazon Kinesis Data Firehose

データストリームを AWS データストアにキャプチャ、変換、ロードし、既存のビジネスインテリジェンスツールを使って準リアルタイムで分析できるようにするサービス

Amazon Kinesis Data Analytics

新しいプログラミング言語や処理フレームワークを習得することなく、SQL や Apache Flink でデータストリームをリアルタイムで処理できるようにするサービス

Amazon Kinesis Video Streams

ストリーミング種類

ストリーミングには2種類存在する。

• メディア形式
  デバイスからのストリーミングデータをクラウドへ取り込んで保存する。ライブ再生には数秒のレイテンシーが発生
• WebRTC
  超低遅延の双方向ストリーミング。双方向へ送受信可能ではあるが、クラウドへの保存覇されない

メディア形式収集のアーキテクチャ概要

• プロデューサー：メディアをアップロードするデバイス側 (IoT機器など)
• ストリーム：データを受け付ける単位。デバイスと1対1
• コンシューマー：データを取り込んで分析等を行うアプリ側 (EC2, Rekognitionなど)。ストリームに対して複数作れる。
• インデックス：ストリーム内のデータに付与する時間ベースのインデックス。これが付けられて内部S3に保存される。

Amazon Kinesis Data Streams

アーキテクチャ概要

• プロデューサー：Video Streamsと同じく、データの送信元
• コンシューマー：これも同じく、データの取り込み・処理側。EC2(Kinesis Client Library(KCL))やS3、Redshift、Kinesis Data Analytics/Firehoseなど。
• シャード：ストリーマとして動くData Streamsの中で作られる、データレコードのシーケンス単位。複数のシャードでストリームが構成され、各シャードが1単位となる。

Kinesis エージェント

EC2などにインストールする、スタンドアロンの Java ソフトウェアアプリケーションで、データを収集して Kinesis Data Streams に送信する働きを持つ。
動作としては、一連のファイルを継続的に監視して、新しいデータをストリームに送信したり、ファイルのローテーション、チェックポイント、失敗時の再試行などの処理を行う。また、ストリーミング処理のモニタリングとトラブルシューティングに役立つ Amazon CloudWatch メトリクスも出力可能。
単なるAgentなので、オンプレのサーバー等にもインストール可能。

Amazon Kinesis Data Firehose

アーキテクチャ概要

• プロデューサー：Video Streams等と同じく、データの送信元
• 配信ストリーム：データ配信単位。Data Streamsのシャードに似ている。Firehoseエンドポイントから配信先に応じたストリームに流される。
• コンシューマー：データ送り先としては、S3, Elasticsearch Service, Redshiftが定番。

データ加工

送信元のデータを変換してから配信したい場合は、オプションからLambda関数を呼び出すことが可能。
これにより、送信先での処理がしやすくなる。

Kinesisコネクタライブラリ

このライブラリを用いることで、KinesisからS3やDynamoDB, Redshift, Elasticsearchなどにデータを永続化することができる。これを利用するためには、Kinesis クライアントライブラリ(KCL)が必要になる。

Kinesis クライアントライブラリ(KCL)

KCLは、Kinesis DataStreamsからデータを読み取って処理するアプリケーションを作るライブラリ。
ストリームボリュームの変化への適応、ストリーミングデータの負荷分散、分散サービスの調整、データ処理の耐障害性などの複雑な問題に対応できる。

リシャーディング

シャードの分割・統合のこと。

分割

分割により、ストリーム内のシャードの数が増え、ストリームのデータ容量が増える。
ただし、シャード単位で請求されるため、分割によりストリームのコストが増える。

統合 (マージ)

マージによってストリーム内のシャードの数が減り、したがってストリームのデータ容量とコストが削減される。

Kinesis Video Stream のHTTP Live Streaming (HLS)再生

HLSは、業界標準の HTTP ベースのメディアストリーミング通信プロトコルで、ライブ再生又は、オンデマンドの再生が可能になる。エディアタイプや保持期間等の要件を満たせば、Kinesis Video Streamでは湯甥に使用が可能。

Kinesis Video Streamの形式

以下の3つ。

• GetMedia
  GetMedia API を使用して、Kinesis ビデオ ストリームを処理する独自のアプリケーションを構築する方式。GetMedia は低レイテンシーのリアルタイム API。
  GetMedia を使用するプレーヤーを作成する場合は 、自分で構築する必要がある。

• HLS
  上述。HLS を使用することで、ライブ再生またはアーカイブ済み動画の再生用に Amazon Kinesis Video Streamが活用できる。

• MPEG-DASH
  Dynamic Adaptive Streaming over HTTP (DASH) (MPEG-DASH とも呼ばれる) は、従来の HTTP ウェブサーバーから配信されたインターネット経由で高品質のストリーミングを可能にする適応ビットレートストリーミングプロトコル。

流れとしては大きく以下

1. レプリケーション先の準備
   • Replication Subnet Group
   • Replication Instance (サイズ、エンジンバージョン、VPC関連情報、その他アドバンスド情報)
   • NW (NAT-GW, VPN, DX等)
2. レプリケーションのターゲット・ソース側準備
   • エンドポイント作成 (ソースエンジン、エンドポイントのサーバーIP/FQDN、ポート、認証情報)
3. 移行タスクの作成
   • タスク作成 (レプリケーションインスタンス、ソース・ターゲットエンドポイント、移行タイプ(初期移行、データ変更レプリケーション、新しいテーブル作成)、テーブル作成モード、ロギングなど)
4. 移行を実施し、移行完了の確認・不足部分の別途移行を行う
   ※エラーがあった場合はCloudWatchLogsからログを確認し、エラー部分を除いて実施していく。

S3をソースとしたDB移行

データソースのサポートや旧式といった問題で、DMSが使えない場合がある。
その場合、CSV形式でデータをエクスポートできれば、そのデータをS3にアップロードすることで移行が可能になる。
この場合、ソースとしてCSVが格納されたS3を選択してエンドポイントを作成する。

移行タイプ

• FULL Load
  既存データの連携で使う。ソースデータベースからターゲットデータベースへ、指定したテーブルデータがそのまま移行されるイメージ。
  ※フルロード中に発生した更新差分データは受信バッファで保持されたまま

• 変更データキャプチャ (CDC : Change Data Capture)
  更新差分データの連携。メインのデータ移行は、dumpなどのネイティブツールでの移行を行い、その後のデータ差分同期で用いる方式。
  CDCで、ソースからターゲットへキャプチャされたデータ変更を仲介し、このデータ変更をターゲットへ適用してくれる。

• FULL Load + CDC
  上記二つの組み合わせ。
  ソースで変更をキャプチャしながら、全ロードが実行される。
  全ロードが完了すると、キャプチャされた変更がターゲットにレプリケーションされ、移行が完了した状態になる。

https://d1.awsstatic.com/webinars/jp/pdf/services/20210216_Blackbelt_DatabaseMigrationService.pdf

専用のハードウェアで暗号化キーを保管するサービス。ハードウェアセキュリティモジュールで「HSM」。
FIPS 140-2 Level3という高いレベルに準拠したHSMを提供している。
KMSはLevel2で、マルチテナント形式なので、少々セキュリティ面では下だが、運用手間がなくシンプルで安いという違いがある。

CloudHSMは、VPC外からアクセスする場合、CloudHSMがあるVPCにルーティングが必要。また、リージョンを跨ぐことはできない。

Aurora Serverless

「ワークロードが予測不能」「新規のアプリケーション(開発)」「使用頻度の少ないアプリケーション」などで向いている
リクエストが頻繁に来ず、スケーリングできるようなシチュエーションであれば、サーバー管理不要・節約の面でも優秀。

ただし、スケールするまでの感度とタイムラグがあまり良くないので注意。特にスケールはクエリ処理中にスケールアップできないという制約がある。そのため、高パフォーマンスや停止不可のサービスなどには向いていない。

Oracle Recovery Manager (Oracle ​RMAN)

様々なOracleデータ形式での高度なパフォーマンス要求や、管理性の高いバックアップおよびリカバリへの要望に応える製品。そのために、サーバーとの密な連携が必要な設計になっており、リストア中のブロック・レベルの破損を検出する。また、シェルアクセスによる権限設定が必要となってくる。そのため、この場合だとRDS等は使用することができない。

Oracle Real Application Cluster (RAC)

1つのデータベースを1台、もしくは複数のサーバインスタンスで構成し、複数クライアントから同時にアクセス可能にするOracle社によるシェアードエブリシング型のデータベースクラスターテクノロジー。これにより、Oracleデータベースをクラスター化できる。現状AWS (RDS) だとこの機能はサポートされていないが、AMIのOracle DBは提供されており、EC2での使用は可である。

RDSリードレプリカの昇格

昇格プロセスの完了までには数分かかります。リードレプリカを昇格させると、レプリケーションが停止され、リードレプリカが再起動されます。再起動が完了すると、リードレプリカは新しい DB インスタンスとして使用可能になります。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Promote

RDSのIO強化

以下のイメージで実施

• I/O 処理能力の高い別の DB インスタンスクラスに移行
  古いものから変更するのは基本。デフォルトでEBS最適化されているものが多く、t3, m4, r4以降くらいはそれに該当するので、これらを用いる方向をまず検討。c1, m1, r3以降でデフォルト標準化されていないものはとりあえず最適化するだけでも効果はありそう。
• マグネティックストレージ → 汎用 → プロビジョンド IOPS ストレージの順で変更を検討
  特にプロビジョンド IOPS ストレージが選べるなら、コスト面で問題ないなら選択肢に入れる。プロビジョンド IOPSは、現在はio1のみ。(EBSとしてはio2はGA済)
• すでにio1を使っている場合は、追加のプロビジョニングを行う。
  プロビジョンド IOPS の値やディスク使用範囲は、以下の通り。
  https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_Storage.html#USER_PIOPS

RDS on VMware

VMが1つのAZと認識され、RDS同様のコンソールから操作できる感じ。
リードレプリカが使え、各種バックアップとその管理、ポイントタイムリカバリー、自動パッチ、オートリカバリーなどが対応している。
一方で、マルチAZ構成はサービスの特徴がらサポートされておらず、ElasticIPなどの付与も不可となる。

Memcachedはシンプル、Redisは複雑でも対応可という前提はあり。
Redisでは、シンプルなデータ(String)以外にも、List, Set, Hashなどの様々なデータを扱うことができる。

https://www.wantanblog.com/entry/2019/12/21/210857#:~:text=周辺連携サービス-,Amazon Redshift,-概要

Amazon Redshift のワークロード管理 (WLM)

Redshift はクライアントからクエリを受信すると、ユーザーに割り当てられたクエリキュー追加、順に取り出してクエリを実行する。
このとき、実行時間が短いクエリは、実行時間が長いクエリが完了するまでキューで待機しなければならない場合があり、クラスタ全体のボトルネックになることがある。
Workload Management(WLM)では、用途ごとにクエリーの並列度やメモリ（％）の上限を設けた複数のキューを設定・管理する。

なお、現在はAutomatic Workload Management (Auto WLM) が出ており、これは機械学習アルゴリズムを用いてクエリを実行するために必要なリソースを動的に管理する機能になっている。
※旧形態のものを「Manual WLM」と呼ぶようになった

データ分析系サービスのユースケース分類

Amazon Redshift では、特に複数の結合やサブクエリを伴うきわめて複雑な SQL を使用する場合に、エンタープライズレポートやビジネスインテリジェンスワークロードで高速なクエリパフォーマンスが利用できます。Amazon EMR を使用すると、オンプレミスのデプロイと比較して、Hadoop、Spark、Presto などの高度に分散された処理フレームワークをシンプルでコスト効率の高い方法で実行できます。Amazon EMR は柔軟性を備えています。カスタムアプリケーションやコードを実行し、詳細なコンピューティング、メモリ、ストレージ、およびアプリケーションパラメータを定義して、分析要件を最適化できます。Amazon Athena を使用すると、サーバーのセットアップや管理をしなくても、S3 内のデータに対してアドホッククエリを簡単に実行できます。

※参照
https://aws.amazon.com/jp/athena/faqs/#When_to_use_Athena_vs_other_big_data_services

• Amazon Redshift
  複雑なSQLを使用し、高速なクエリパフォーマンスを求める場合
• Amazon EMR
  Hadoop、Spark、Presto などの処理フレームワークをシンプルでコスト効率よく実現する場合
• Amazon Athena
  サーバーのセットアップや管理なしに、S3 内のデータに対してクエリを簡単に実行する場合

RedshiftのDR対策

ローカルリージョンだけでなく、クロスリージョンスナップショット機能により別のリージョンへもスナップショットを作成できる。
これにより、DynamoDBのグローバルテーブルや、RDSのクロスリージョンリードレプリカのように、リージョン障害時の可用性を担保できる。

Concurrency Scaling

Redshiftのスケーリングで、同時実行クエリの数に応じてクラスタをオートスケールする機能。
この機能では、メインクラスタに加えて、スケーリングできるクラスタ(スケーリングクラスタ)を組み合わせ、高い同時実行性と一貫した高速なパフォーマンスを提供することができる。

仮想インターフェース(VIF)の種類

DXのAWS側のインターフェース(VIF)には以下の種類がある。

プライベートVIF

プライベートIPを使ってVPCへアクセスする際に使う
DXGWタイプと、仮想プライベートゲートウェイ(VGW)タイプがある。
DXGWタイプが推奨だが、オンプレ間通信が必要なCloudHub構成の場合はVGW構成を使う。
ただ、VGWタイプであれば、冗長構成の際にVPNを用いてDX併用接続(VGWの共有)できる。

パブリックVIF

パブリックIPを使ってアクセスする際のVIFで、全リージョンのAWSパブリックサービスにアクセスする際に使う。
オンプレミスのプライベートアドレスをパブリックIPにNATしてくれて、S3やDynamoDBなどにもアクセスできる。
※なお、現在S3はPrivateLink経由でのプライベートアクセスもできるようになっている。

Transit VIF

TransitGWを使う場合に接続するVIF。プライベートVIFと同じような要件で使える。
VIFとDXGWを繋ぎ、DXGWとTGWを繋ぐ形になる。

DX Link Aggregation Group（LAG）

Link Aggregation Control Protocol (LACP)を用いることで複数のコネクションを集約し、一つの論理インターフェースとして提供する機能。
等速度なコネクションを最大で4つ集約し、例えば、1Gbpsのコネクションを4Gbpsに、もしくは10Gbpsのコネクションを40Gbpsとして、論理的に束ねて利用することができる。また、各コネクションにトラフィックが分散される。

DirectConnect

繋ぎ方のパターン一覧
https://dev.classmethod.jp/articles/whitepaper-translate-jpn-vpc-connectivity-options-01/

「AWS Direct Connect + VPN」というパターンがあり、冗長化の意味ではなく、Direct Connectの専用ネットワーク接続をAmazon VPC VPNと組み合わせて使う方式(DX接続上にIPsec形式の Amazon VPC VPNを張る感じ)。
DirectConnect上の通信の暗号化にも役立つ。
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/encryption-in-transit.html

DX Gateway

複数リージョンで共有できるリソース。なので、1リージョンでDXを貼れば、AWS側はこのDX GWで複数リージョンに接続できる。
ただし、DX GWは料金は時間当たりの料金になる。
もし、DX複数リージョン利用時に費用対効果を求める場合は、1リージョンの1VPCとDXを張り、リージョン間VPCピアリングで接続すると、データ転送量次第では安くできる可能性がある。
(VPCピアリングはデータ転送量での課金のため)

プロパゲーション

アタッチメントにて関連づけたAmazon VPCなどをからルートテーブルに経路を伝播すること。DXの場合、VGWに対してルートテーブルの設定でルートプロパゲーションを有効化する必要がある。

Egress-Only インターネットゲートウェイ

Egress-Only インターネットゲートウェイは、IPv6のNAT-GWの役割。
名前が似ているがインターネットゲートウェイではない。インターネットゲートウェイはそのものがIPv6に対応している。
名前の通り、Egress(送信)のみで、Ingress(受信)は対応していない。

ゲートウェイ型VPCエンドポイント

昔からあるタイプ。S3でよく使うが、グローバルサービスであるDynamoDBも対応している。
逆に言えば、他のものは全てインターフェース型のエンドポイントで提供されていると覚えていい。

リージョン間VPCピアリング

リージョン間VPCピアリングは、別名?「インターリージョンVPCピアリング」

PrivateLink

インターフェース型VPCエンドポイントを活用して接続する。VPCピアリングでは一時的にパブリックインターネットに出る経路にを使うが、Privatelinkの場合、完全にAWSクラウド内のプライベート通信となっている。
AWS PrivateLinkはクライアントVPC内のENIを利用するため、サービスプロバイダーとのIP競合が発生せず、2つのVPC内のクライアントとサーバーのIPアドレスが重複している場合にも対応可能になる。
PrivateLink エンドポイントに対しては、VPC ピアリング、VPN、および AWS Direct Connect 接続を介して アクセスすることができる。

クラウドのメディア変換サービス。複数のプラットフォームデバイスで、メディアがMP4形式でグローバルにストリーミングを処理できる。

デプロイポリシー

AWS Elastic Beanstalkでアプリケーションの新しいバージョンをデプロイするときの挙動を設定するもの。以下4つがある。

All at Once

同時に全ての既存インスタンスにデプロイするポリシー。一気に行われるので、各インスタンスがサービス停止状態になり、ダウンタイムが発生するが、一番簡単で迅速に行われるポリシー。
これは単一インスタンス環境でも選択可能。

Rolling

バッチサイズを設定し、それを元に新しいバージョンがローリングデプロイされるポリシー。バッチサイズを50%とすると、まず半分でデプロイが行われ(半分でサービス断が起きる)、それらが終わったら残りでデプロイが行われる。全体的にキャパシティが減る時間があるが、ダウンタイムはない。一時的に新旧が混在する点に注意。
単一インスタンス環境では選べない。

Rolling with additional batch

「Rolling」の、キャパシティが減らないバージョン。バッチサイズを指定すると、その分のデプロイが行われるが、その前に不足分のデプロイが行われる(ただし、不足分の追加は旧バージョン)。例えば、50%を指定すると、半分がデプロイされている間、追加で同量のインスタンスが起動してくれる。そのため、デプロイが行われている間も、全体キャパシティが減らないという点で大きい。ただ、「Rolling」同様一時的に新旧が混在する点に注意。
単一インスタンス環境では選べない。

Immutable

既存のインスタンスは変更しないでデプロイをするポリシー。ELB配下に、新バージョンのインスタンス群(Auto Scaling Group)が作成され、動作確認後にまとめて切り替わる方式。動作確認時は1台のみ起動され、問題なければ既存と同量のインスタンス群でデプロイが実施される。この方式でも、新旧バージョンの混在は起きてしまう。
単一インスタンス環境でも使用可能。

Blue/Greenデプロイのやり方

デプロイポリシーのImmutableに似ているが、ELBごと入れ替わる方式のデプロイ方法。完全に新しい環境を作るデプロイを行い、DNS名の入れ替えで完了する。DNS名がそれぞれ別なので、確認時は新しい方(仮の方)のDNS名で確認を行う。この方式では、上記のものと違い、新旧が混ざることがない。
確認後の入れ替えは、[Environment actions (環境アクション)]、[Swap environment URLs (環境 URL のスワップ)]の操作により、古い環境と新しい環境の CNAME レコードを交換して、古いバージョンから新しいバージョンに、新しいバージョンから古いバージョンにトラフィックをリダイレクトする形で行われる。

ヘルパースクリプト

スタック内のEC2インスタンスの構築・変更等を便利にする機能で、4種類がある。

cfn-init: リソースメタデータの取得と解釈、パッケージのインストール、ファイルの作成、およびサービスの開始で使用します。
cfn-signal: CreationPolicy または WaitCondition でシグナルを送信するために使用し、前提となるリソースやアプリケーションの準備ができたときに、スタックの他のリソースを同期できるようにします。
cfn-get-metadata: 特定のキーへのリソースまたはパスのメタデータを取得するために使用します。
cfn-hup: メタデータへの更新を確認し、変更が検出されたときにカスタムフックを実行するために使用します。

https://dev.classmethod.jp/articles/cfn-helper-scripts/

共通パラメータ値のクロススタック参照

値を渡すテンプレートではOutputsにExport属性付きで値を出力し、受け取るテンプレートでは!ImportValue関数でパラメータを取得する。
共通するものはテンプレートでExportさせることが必要。
https://qiita.com/tiibun/items/67aa74cdc17bc0b9812c#2-importvalueを使うcross-reference

複数アカウントやNWで参照する方法

AZ

Fn::GetAZを用いて「有効AZのリスト」を返すようにする。
そこから選ぶようにする。

AMI

あらかじめMappingを用意して、そこに有効なAMIをリスト化しておくことで参照できる。
参照する際は、Fn::FindInMapを用いる。

順番制御関数

• WaitCondition
• CreationPolicy

がある。
元々前者のみだったが、現在は後から増えた後者が推奨になる。

組み込み関数の利用

条件付きでスタックリソースをデプロイする場合などの活用する。組み込み関数は、テンプレートの特定の部分 (Resourceプロパティ、Output、Metadata、Update)で使用することができる。

EBS等の削除保護

スタックが削除される際、ボリュームなどは保持しておきたいという場合に、DeletionPolicy属性を該当リソースに付与することで、スタックごと削除されることがなくなる。

SurgeQueueLengthメトリクス

正常なインスタンスへのルーティングを保留中の、リクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数を表示する。保留中の総数がわかるため、着信トラフィックトラフィックがわかる。

SpilloverCountメトリクス

サージキューがいっぱいになり拒否されたリクエストの総数。これは着信トラフィックが急増した際に拒否数を把握する際に利用できる。

マルチリージョン、マルチアカウントでのダッシュボード共有

https://dev.classmethod.jp/articles/cross-account-cross-region-dashboards-with-amazon-cloudwatch/

API Gatewayのメトリクス

Amazon API Gateway はCloudWatch にメトリクスデータを毎分送信する。
AWS/ApiGateway 名前空間には、以下のメトリクスが含まれる。

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

API Gatewayのログ

API Gateway側で有効化することで、レスポンスレイテンシー、HTTPレスポンスなどの情報のカスタムログが取得可能

CloudWatchの請求アラーム

請求概算額に対するパーセンテージや金額でアラートを設定可能
Budgetsの予算アラート機能との違いは以下。
https://zenn.dev/sakojun/articles/20210618-aws-cost-alart

Budgetsは、全体予算という意味でOrganization連携できるのも有用
https://zenn.dev/link/comments/5af563c5999e2e

DAX (DynamoDB Accelerator)

概要

キャッシュを利用したテーブル内のデータ処理を高パフォーマンス化する機能。
ミリ秒からマイクロ秒のパフォーマンス向上が見込める。

起動している間定常的に高パフォーマンスを提供するが、比較的高コストの機能となる。

ユースケース

レスポンス時間を最短にする必要や、読み込みが多く大規模なデータから何度も読み取りが起きるような場合に有効。
一方、キャッシュなので一貫性を保つ必要があったり、書き込みが多い様な場合には向いていない場合があり。

アーキテクチャ

DAXクラスターがVPC内リソースとして動作する。
接続元のEC2のアプリケーションなどはそのクラスターへ接続を行う。

DynamoDBテーブルのFGAC (Fine Grained Access Control）

DynamoDBがセキュリティ、アクセス制限を実現する仕組み。
FGAC（Fine Grained Access Control）とは、DynamoDB テーブルの所有者がテーブル内のデータに対して詳細なコントロールを行うための機能。
具体的には、テーブル所有者は「誰（呼び出し元）がテーブルのどの項目や属性にアクセスでき、どのようなアクション（読み込み/書き込み）を実行できるか」を指定できる。FGAC はIAMと組み合わせて使用され、セキュリティ認証情報および対応するアクセス権限の管理は、IAM で行う。
STSで払い出されたユーザー認証情報などはDynamoDBに格納するが、その際のセキュリティ強化として用いる。

キャパシティユニット

DynamoDBでは、キャパシティーユニットを事前に設定し、読み込み/書き込み容量の上限を決める。
この設定によって、料金も変わる。
書き込みと読み込みにそれぞれ設定がある。

書き込みキャパシティユニット(WCU)

1WCU = 1秒間に1回の書き込み。
最大サイズは1KBの項目で、項目単位は1KBの倍数に切り上げられる。
なお、テーブル1つにつき、40000がデフォルト上限となる。

読み込みキャパシティユニット(RCU)

1RCU = 1秒間に、2回の結果整合性のある読み込み、もしくは非常に強い結果整合性のある1回の読み込み
最大サイズは4KBで、超える場合はより多くのRCUを使う。
なお、テーブル1つにつき、40000がデフォルト上限となる。

グローバルテーブル・マルチマスター

マルチマスターのため、各リージョンのエンドポイントから書き込みが行うことができる。
ただ、グローバルテーブルを作成する場合、ストリームを有効にする。
ストリームは、「テーブルデータに変更があった際、その変更情報を暗号化してログとして保存しておく」機能

現在は既存のテーブルもグローバルテーブルに切り替えることが可能。

キー周り

難しい。。。

https://www.ragate.co.jp/blog/articles/2436

DynamoDB ストリーム

Dynamo DBに対する追加、変更、削除の変更履歴を保持する機能。DynamoDBの変更をトリガーに非同期にLambdaをキックすることができ、処理の集計、分析、通知に使える。

DynamoDB トランザクション

DynamoDBテーブル内およびテーブル間の複数の項目を、同時でしか調整、変更しないといったことができる。トランザクションのオールオアナッシング処理等で用いられる。

条件付き書き込み

PutItem オペレーションはキーが同じ項目を上書きします (存在する場合)。これを回避するには、条件式を使用します。これにより、問題の項目が同じキーを持っていない場合にのみ書き込みが続行されます。

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html#Expressions.ConditionExpressions.PreventingOverwrites

アトミックカウンターなどで上書く際にキーが増加してずれてしまうような場合に有効？

※アトミックカウンター参考
https://blog.serverworks.co.jp/tech/2019/04/03/atomic-counter/

キャパシティモード

読み取り/書き込みキャパシティーモードとは、読み取りおよび書き込みスループットの課金方法と容量の管理方法の設定。
テーブルを作成するときに設定でき、後で変更も可能(24時間に1度)。
以下の2種類が存在する。

プロビジョニング済み (デフォルト)

プロビジョニングモードでは、アプリケーションに必要な 1 秒あたりの読み込み(RCU)と書き込み(WCU)ユニットを設定し、スループットキャパシティを指定することができる。
また、AutoScalingが利用でき、CloudWatchのメトリクスからスケーリング設定も活用できる。
この場合、以下が主なユースケース。

• アプリケーションのトラフィックが予測可能な場合
• トラフィックが一定、または徐々に増加するアプリケーションな場合
• キャパシティーの要件を予測することでコスト管理が必要な場合

オンデマンドモード

容量計画なしで 1 秒あたりに数千ものリクエストを処理できる柔軟な請求オプション。
読み取りおよび書き込みのリクエストごとに支払い料金が用意されているため、使用した分だけ課金される形式になる。
こちらにAutoScaling機能はなく、プロビジョニング済みから変更した場合、その設定は外れる。
こちらは以下が主なユースケース

• 不明なワークロードを含む新しいテーブルを作成する場合
• アプリケーションのトラフィックが予測不可能な場合
• わかりやすい従量課金制の支払いを希望する場合

https://zenn.dev/mn87/articles/2da37b46713796

OpsWorksの自動ヒーリング

インスタンスが Amazon EC2 ヘルスチェックに合格した場合でも、スタック内にある異常なインスタンスまたは失敗したインスタンスを再起動する仕組み。
この自動ヒーリングが有効になっている場合、ダウンタイムを回避するために、失敗したEC2インスタンスは自動的に置き換えられる。
スタックのレイヤー設定では、自動ヒーリングがデフォルトで有効化されている。

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

以下5つがある。

• Setup : 新しいインスタンスが正常にブートした後に発生する
• Configure : インスタンスがオンライン状態に移行したときとオンライン状態から移行した時にスタックのすべてのインスタンスで発生する
• Deploy : ユーザーがアプリケーションをデプロイする時に発生する
• Undeploy : アプリケーションを削除する時に発生する
• Shutdown : インスタンスの終了

https://qiita.com/tada_infra/items/74e773f00129965dcf0b#ライフサイクル

OpsWorksの担当範囲

環境前提を表す「Stack」、その中の役割を分ける「Layer」、そしてLayer内には「Instance」が存在し、その上に「App」が乗っている形で管理される。
そのため、EC2やELBリソースまでは管理することができる。
また、Chefなどのレシピは、アプリケーションの展開で有効になるので、それも含めてStackを展開する形になる。

一方、VPCなどのNW周りは対象外なので、それについてはCFnで展開し、そのテンプレートに対してOpsWorks::Stackリソースを設定してネストするようにして紐づけることができる。

また、各「Layer」では、ライフサイクルイベント(前述の5種類)ごとにレシピを割り当てるができ、それらのイベントが発生されるときに実行するレシピを準備する必要がある。

DLM (Data Lifecycle Manager)の略。

AWS Backupとの違い

EBSスナップショットの世代管理方法が違う

Amazon DLM はスナップショットを何個残すか(retain)指定し、AWS Backupは各スナップショットをどれだけの期間残すか(expire)指定します。

https://dev.classmethod.jp/articles/how-aws-backup-and-amazon-dlm-manages-backup-lifecycle/

AWS Application Discovery Service (ADS)とも。
エージェントタイプとエージェントレスタイプがある。
レスタイプは、VMware (vCenterにアクセス可能な)環境で用いられる。

ADSでは、サーバーの設定データ、使用状況データ、動作データ等が収集されて、ユーザーに提供される。

収集されたデータは、ADS のデータストアに暗号化形式で保存される。
このデータを CSV ファイルとしてエクスポートし、AWS で稼働した場合の総所有コスト (TCO) の見積もりや、AWS への移行計画で使用できる。
また、このデータは AWS Migration Hub でも利用できる。

※AWS Migration Hub
AWS およびパートナーの複数のソリューション間におけるアプリケーション移行の進行状況を 1 つの場所で追跡できるサービス。
Migration Hub を使用すると、ニーズに最も適する AWS およびパートナーの移行ツールを選択でき、アプリケーションのポートフォリオ全体で移行状態の可視性が得られる。
Migration Hub では、移行にどのようなツールが使われていても、個々のアプリケーションの主要なメトリクスと進行状況を取得することもできる。

承認済みAMIの確認ルール

AWS Configマネージドルール「approved-amis-by-id」で検知可能

パラメーターの amiids に有効な AMI の一覧をカンマ区切りで指定する。
実行中のインスタンスで使用されている AMI が、このリストにない場合は NON_COMPLIANT になる。

レイテンシベースルーティングと加重ルーティング

レイテンシベースで振り分けたのち、その下は加重ルーティングとEvaluate Target Health (ターゲットの正常性の評価)を組み合わせることで実現できる。
なお、レイテンシベースではターゲットの正常性チェックにて分散を行い、加重ルーティングでは重み付けの設定で分散を行う。

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/dns-failover-complex-configs.html

プライベートホストゾーンのクロスアカウント参照

1. それぞれのVPCで、DNSHostnameとDNSSupportを有効化し、VPCピアリング等で繋いでおく。
2. プライベートホストゾーンを持っているアカウントから、aws route53 create-vpc-association-authorizationコマンドを実行し、連携先のアカウントへVPC連携のリクエストを送る (CLI限定操作)。
3. 連携先アカウントにて、aws route53 associate-vpc-with-hosted-zoneコマンドにて、リクエストを承認する。

なお、同一アカウントの場合、この関連付けはコンソールからでも可能となる。

プレイスメントグループ

インスタンスをグループ化する機能。これにより、

• ネットワークパフォーマンスの向上 (クラスター)
• 物理サーバ障害時の影響範囲を限定 (分散など)

などのメリット得られる。

クラスターでは、近距離のラックにサーバーが置かれるようになり、専用の帯域が確保されるようになるため、HPCのような場面で有効。
もし既存EC2をプレイスメントグループに足す場合、一度停止してから所属させることができる。

Elastic Network Adapter(ENA; 拡張ネットワークアダプター)利用

クラスタープレイスメントグループでEC2を起動することで、インスタンス間の低レイテンシー・高ネットワークを実現できる。
これらのインスタンスをENA互換インスタンスにし、有効化することで最大のパフォーマンスを実現できる。(最大 25 Gbps)

専有(Dedicated)ホストと専有(Dedicated)インスタンス

どちらも、マシンを他のアカウントのEC2と共有しない設定ではあるが、それぞれに特徴がある。

専有(Dedicated)インスタンス

同一物理サーバー上に、他のインスタンスマシンを起動しないことを確約する設定。
業界規制やライセンス規約等で、物理マシンを専有しないといけない場合に使うが、起動マシンの固定まではできない。
「ハードウェア専有インスタンス」とも

専有(Dedicated)ホスト

専有インスタンスと同様、起動する物理サーバーを専有でき、その上さらに起動するホストマシン(CPUソケット、コア、ホストID)まで指定が可能になる。
そのため、アフィニティ設定を「host」にしておけば、再起動時等もそのマシン上で動くことが確約できる。
また、同一アカウントであれば、共通の専有ホスト上にマシンを動かすことも可能になる。
BYOL(Bring Your Own License)で保有するソフトウェアライセンスをインスタンスへ持ち込む場合に用いる。
「占有ホスト」とも

https://awsjp.com/AWS/hikaku/DedicatedInstance-DedicatedHost-chigai.html

EBSバースト

インスタンスのCPUバーストとは別に、EBSにもIOPSバーストがある。
EBSのクレジットを貯まっている間は十分な能力を出せるが、これが枯渇すると最低限の性能になる。
EBSのクレジットは、EBSのサイズが大きければ貯まるクレジットも多くなる。
もしサイズアップでもI/O不足が解決しない場合は、クレジットの仕組みを利用しない「プロビジョニンドIOPS」タイプのEBSを用いることでIOPS低下を回避できる。

インスタンスストアボリュームのAMI取得

通常のAMIはEBSボリュームのイメージになるが、インスタンスストアでのイメージの場合、ec2-bundle-volやec2-upload-bundleAMIツールを用いることで取得が可能になる。。

ジャンボフレームサポート

ネットワーク接続の最大送信単位 (MTU) とは、接続を介して渡すことができる最大許容パケットサイズ (バイト単位) です。接続の MTU が大きいほど、より多くのデータを単一のパケットで渡すことができます。

イーサネットフレームの形式はさまざまで、最も一般的な形式は、標準イーサネット v2 フレーム形式です。これはインターネットのほとんどでサポートされている最大のイーサネットパケットサイズである 1500 MTU をサポートします。インスタンスでサポートされている最大 MTU は、インスタンスタイプによって異なります。すべての Amazon EC2 インスタンスタイプで 1500 MTU がサポートされており、現在の多くのインスタンスサイズで 9001 MTU またはジャンボフレームがサポートされています。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/network_mtu.html

使い分け一覧

https://aws.amazon.com/jp/snow/#Feature_comparison

移行ツールの基準

移行設計でよく問われるデータ転送時間も頻出。AWS Snow Familyなのか？AWS Direct Connectなのか？インターネットVPNなのか。
　データ転送時間：10TB/1Gbps=約1日(0.92日)、1TB/50Mbps=約2日(1.85日)
くらいの感覚を持っておくと、都度計算しなくてよく便利。

1TB/100Mbps=約1日(0.93日)
1TB/1Gbps=約2時間

※参照
https://qiita.com/fkooo/items/17fa401f4e46ecd00675#おまけ

Amazon Elastic MapReduceの略
Hadoop、Apache Spark、Hive、Presto等々のフレームワークのビッグデータ処理で使う

https://dev.classmethod.jp/articles/beginner-what-is-emr-overview/

EMRが動くインスタンスの購入オプション

EC2の購入オプションのように、オンデマンド、RI、スポットインスタンス、専有インスタンスが選べる。
https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-instance-purchasing-options.html

また、オートスケーリング時の設定で、オンデマンド・スポットインスタンスの割合なども選ぶことができる。
https://dev.classmethod.jp/articles/amazon-emr-now-supports-managed-scaling/#toc-5

分散バッチ処理

EMRでは、データをまとめて処理を行うが、この際、データ単位を「少数」かつ「大きいデータ」でまとめることでバッチ性能を向上できる。

S3などから、Redshift・Athena・EMRなどのツールにデータを送る際、事前に加工するサービスのイメージ。
Glueは「糊(のり)」なので、それぞれをつなぎ合わせる感じになる。

オンプレミスのVMware vSphereまたはMicrosoft Hyper-V / SCVMM仮想マシンの移行をサポートするサービス。
VMImportという類似サービスもあるが、SMSの方が高機能。

VM以外のサーバー移行でも使われるCloudEndure MigrationをAWSが買収した結果出たサービス。
新しく、非常に楽に移行ができるとうたっている。
AWS Application Discovery Serviceと混ざらないように注意。

EFSのデータ暗号化

EFSのマウントヘルパーユーティリティを利用する際に暗号化オプション「-o tls」等で行う。

AWS Systems Manager ステートマネージャー

安全でスケーラブルな設定管理サービスであり、Amazon EC2 およびハイブリッドインフラストラクチャを、定義された状態に保つプロセスを自動化してくれるサービス。

この定義は関連付け(Association) と言い、以下のような設定パラメータがある。

• 対象: どのインスタンスの状態を定義するか
• 実行ドキュメント: どのドキュメントを実行するか
• スケジュール: どの頻度で実行するか(or 1回のみの実施か)

SSM Parameter Store のSecure String (安全な文字列)

パラメータストアに機密性の高い情報(APIキー、連携URLなど)を格納する際に使うパラメータ形式。
デフォルトだとKMSでの暗号化が行われて格納される。ここで、暗号化権限を持つカスタマーマスターキー(KMS CMK)を用いることもできる。
このSecure Stringを参照するには、SSM のパラメータ取得(ssm:GetParameters)権限を持つリソースであれば大丈夫。もしロールで渡す場合は、sts:AssumeRole権限も忘れないように。

※参考
https://dev.classmethod.jp/articles/sugano-039-ssm-paramstore-lambda/

Step Functions類似で、ワークフローを作成するサービスだが、現在はStepFunctiondをを選択することを推奨。

https://dev.classmethod.jp/articles/re-introduction-2020-amazon-sqs/

可視性タイムアウト

可視性タイムアウトは ReceiveMessage でメッセージを取得してから指定した時間の間、同じメッセージを取得出来なくなる機能。
これにより、コンシューマーが同じメッセージを処理することはなくなり、重複排除機能として活用できる。

デッドレターキュー

長時間実行されなかったキューをデッドレターキューとして隔離して、キューがたまらないようにする仕組み。

なお、SNSにもデッドレターキュー機能があり、こちらはトピックからサブスクリプションに到達不能になった場合に一時的に失敗メッセージキューを保持する働きをする。

※参考
https://www.ragate.co.jp/blog/articles/4564

遅延キュー

キューへの新しいメッセージの配信を指定時間延期する機能。
キューに登録されてからn分後にコンシューマーで処理させたい場合に使う。

Lambda オーソライザー

Lambda 関数を使用して API へのアクセスを制御する API Gateway の機能。
OAuthやSAMLベース認可等で活用される。

• トークンベース の Lambda オーソライザー (TOKEN オーソライザーとも呼ばれる)
  JSON ウェブトークン (JWT) や OAuth トークンなどのベアラートークンで発信者 ID を受け取ります。
• リクエストパラメータベースの Lambda オーソライザー (REQUEST オーソライザーとも呼ばれる)
  ヘッダー、クエリ文字列パラメータ、stageVariables、および $context 変数の組み合わせで、発信者 ID を受け取ります。

Lambda プロキシ統合 / Lambda 非プロキシ (カスタム) 統合

Lambda プロキシ統合

クライアントとバックエンド Lambda 関数間に介入しないため、クライアントと統合された Lambda 関数は、そのままやり取りができる。
HTTPSを介して、クライアントからの着信要求をバックエンドLambda関数への入力値として渡すシンプルな統合方式を実装する際はこちら。

Lambda 非プロキシ統合

プロキシ統合のセットアップ手順に加えて、受信リクエストデータがどのように統合リクエストにマッピングされるか、統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかを指定する統合方式。
そのため、より複雑なマッピングを定義したい場合にはこちら。

REST API時のエンドポイント

クライアントからのリクエストを受けるエンドポイントとして、以下3つが提供されている。

エッジ最適化

APIリクエストが、クライアント最寄りのエッジロケーション(CloudFrontディストリビューション)にルーティングされるようになる。リージョンを跨ぐような、地理的に分散されたクライアントに最適

リージョン

リージョンに直接ルーティングする。クライアントが同一リージョンなら、エッジ最適化よりも低レイテンシでリクエストが送れる。

プライベート

パブリックなエンドポイントをもたずに、VPC 内からのアクセス・Private Link(VPCエンドポイント)を経由したアクセスのみ可能になる。

コンテナ化したバッチ処理を実行するサービス。忘れがちだが、ECSで動いている感じでイメージできる。
https://dev.classmethod.jp/articles/relay_looking_back_aws-batch/

マネージドのブロックチェーン構成サービス

https://www.skyarch.net/column/amazon-managed-block-chain/

AWS Blockchain Templates

これを用いることで、一般的なオープンソースフレームワークを使用するセキュアなブロックチェーンネットワークを、すばやく簡単に作成してデプロイできる。
そのため、ユーザーはブロックチェーンネットワークを手作業でセットアップすることに時間と労力を浪費することなく、ブロックチェーンアプリケーションの構築に集中できるようになる。
AWS Blockchain Templates を使ってブロックチェーンフレームワークをデプロイする際には、Amazon Elastic Container Service (ECS) クラスター上にコンテナとしてデプロイするか、Docker を実行する EC2 インスタンスに直接デプロイするか選択できる。

AWS Step Functions Expressワークフロー

新しいワークフロータイプで、AWS のコンピューティング、データベース、メッセージングサービスを毎秒 100,000 件を超えるイベントレートでコスト効率よく調整できる。
このExpress Workflow は、Amazon API Gateway を介した HTTP リクエスト、AWS Lambda リクエスト、AWS IoT ルールエンジンのアクション、および Amazon EventBridge の 100 件以上の AWS および SaaS イベントソースなどのイベントに応じて、自動的に開始される。
IoT データの取り込み、ストリーミングデータの処理と変換、大量のマイクロサービスオーケストレーションなどの大量のイベント処理ワークロードに適している。

トピックの種類とさまざまなユースケース

https://docs.aws.amazon.com/ja_jp/sns/latest/dg/welcome.html

以下の種類がある

ファイルゲートウェイ

オンプレ等の環境とS3を、NFSやSMBプロトコルによって接続できるようにするインターフェースタイプ。
直接S3上のファイルを操作できるが、レイテンシーが大きくなる。
S3へのファイル格納などで使用できる。

ボリュームゲートウェイ

以下2種類ある。

Gateway-Stored Volumes (保管型ボリューム)

オンプレミスにデータがあり、そのデータボリュームのスナップショットを非同期にS3へバックアップする形式。
そのスナップショットをもとに、オンプレミスのボリュームとしてリストアしたり、AWSでEC2のEBSボリュームとしてリストアすることで活用できる。
データセット全体への低レイテンシーアクセスが必要な場合にはこちらを使う。

Gateway-Cached Volumes (キャッシュ型ボリューム)

プライマリのマスターデータはS3側に置き、オンプレ側のボリュームゲートウェイが、よく使うファイル等のデータサブセットのコピーをキャッシュしておく形式。
オンプレミスのストレージが拡大してしまうことを防げる。

テープゲートウェイ

物理テープライブラリの代替えで、Storage Gatewayを仮想テープライブラリとして利用する形式。
Strage Gatewyを経由し、S3及びS3 Glacierにデータをアーカイブとして保管することができる。
堅牢性が高く、安価な外部保管バックアップストレージとして用いる場合に有効。

SSL対応

ACMに対応している。
LBがある場合、Elastic BeanstalkのLoad balancerカテゴリから、HTTPSリスナーを追加し、SSL証明書を紐付ける。その後、インスタンス側の設定ファイル(.ebextensions/https-reencrypt-alb.config など)を変更して、インスタンス側を終端とする設定を入れる。
LBがなく、インスタンス単体の場合は、設定ファイルで443トラフィックを許可し、SSLターミネーションの設定をすることで有効化できる(いくつかのパターンあり)
https://aws.amazon.com/jp/premiumsupport/knowledge-center/elastic-beanstalk-https-configuration/

特定の文字列に対する防御

悪意あるスクリプトなどの対策として、「特定の文字列」に対する防御のルールが作成可能。
ルールで監視する対象として、URI以外にも、HTTP ヘッダ、クエリ文字列(URLの「?」以降に続く文字列)、クエリパラメータ、本文などのリクエストボディが対象になる。
※参考
https://blog.pepese.com/entry/aws-waf-basics/

CodeCommitのリージョン移動

CodeCommitにもリージョンあり。
リージョン引越しは以下のようなやり方 (シンプルにリポジトリ移動のイメージ)
https://qiita.com/centipede/items/0d62dc0f9a3af9c4592d