AWS Certified Solutions Architect – Professional 合格までの道のりと出題範囲のポイントまとめ

8月末にAWS Certified Solutions Architect – Professional資格を取得しました。
せっかくなので合格までの道のり（勉強法）と、出題範囲で個人的にまとめたAWS各サービスのポイントを整理してみました。
これから受験する方の一助になりましたら幸いです。

AWS SAP 合格までの道のり

前提知識、経験は次のような感じでした。

• Solutions Architect Associate資格は取得済み
• 普段の業務でAWSに触れることはない
• 別のクラウドサービス（Oracle Cloud Infrastructure）の経験あり

上記を前提に、以下の流れで勉強しました。

1. ｢AWS認定ソリューションアーキテクト－プロフェッショナル～試験特性から導き出した演習問題と詳細解説」を通読＆模擬試験も実施し、間違えたポイントや不明点をノートに整理
2. 公式が提供するサンプル問題に回答＆間違えたポイントや不明点を調べてノートに整理
3. Udemyで提供されている「AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集」を演習4まで実施＆間違えたポイントや不明点をノートに整理
4. 1.～3.の過程で作成したノートを何度か見直し
5. 1.の模擬試験や2.のサンプル問題に再度チャレンジ

AWS SAP出題範囲のポイントまとめ

ここからは勉強の過程でまとめたAWS各サービスのポイントを記載します。
模擬問題で間違えたポイントを中心に整理しています。
サービスによっては概要を端折ってたりしますので、その場合は別途AWSのドキュメントをご確認ください。

Elastic Compute Cloud (EC2)

• Dedicated Hostsのアフィニティ設定
  • hostに設定することで再起動後も同じ物理マシンが再利用される
• Dedicated Instance
  • Dedicated Hostsと同様に物理マシンを専有できる
  • ただし同じ物理マシンを再利用できない
• バッチ処理については安価なスポットインスタンスを複数購入して処理を短時間で終わらせ、料金を節約する方式が推奨
• Auto Scalingの希望する容量を指定すると通常時そのインスタンス数に保たれる
• ジャンボフレーム
  • ジャンボフレームとは、イーサネット（Ethernet）規格のネットワークインターフェース（NIC）や通信機器が持つ機能の一つで、一度に送受信するデータ単位（フレーム）のサイズを大きくして、通信効率を引き上げるもの
  • 規格上は伝送するデータ（ペイロード）を1,500バイトごとに区切って18バイトの制御データと共に送信するよう定めている
  • ジャンボフレームでは8,000～16,000バイト程度に設定されることが多い
• 拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現
• Elastic Network Adapter (ENA) は拡張ネットワーキングが利用できる、より高速なインターフェイス
• プレイスメント
  • スプレッドプレイスメント
  • クラスタープレイスメント
  • パーティションプレイスメント（アプリケーションごとに冗長性を確保、スプレッドと似ている）
• インスタンスタイプ（ネットワーク最適化はない）
  • 汎用
  • コンピューティング最適化
  • メモリ最適化
  • 高速コンピューティング
  • ストレージ最適化
• スポットフリート
  • スポットフリート リクエストで指定した容量ターゲットを満たすような スポットインスタンス と オンデマンドインスタンスを起動しようと試みる
  • スポットインスタンス へのリクエストは、利用可能な容量があり、リクエストで指定した上限料金がスポット料金を超えている場合に実施
  • スポットインスタンス が中断した場合、スポットフリート はターゲット容量フリートを維持しようとする
• プレイスメントグループへのインスタンス追加
  • インスタンスタイプを統一
  • 追加するEC2インスタンス起動時にインスタンスグループを指定
• AutoScalingグループから任意のインスタンスを終了したい場合、以下コマンドを実行
  • 最後のオプションは以下いずれかの指定が必須
    • –should-decrement-desired-capacity
    • –no-should-decrement-desired-capacity

aws autoscaling terminate-instance-in-auto-scaling-group --instance-id YOUR-INSTANCE-ID --no-should-decrement-desired-capacity

• AMIによってコピーしたOSイメージの認証情報に関する仕様
  • OSなどのライセンス認証情報はコピーされる
  • PEMキーはコピーされない
    • 別途明示的にインポートする必要あり
    • インポートにはAWSコンソールとAWS CLIを利用可能
• EC2内部における一時的なセキュリティ認証情報の取得
  • ロールに添付された資格情報の取得には「インスタンスのメタデータ」を利用
  • 資格情報にはロールに添付されたポリシーで指定された権限が付与
• 一つのEC2インスタンスに複数のSSL証明書を設定する方法
  • 単一のEC2インスタンスにElastic Network Interface（ENI）を使用して複数のIPアドレスを付与することで可能
• インスタンスタイプによってはIPv6をサポートしていない
  • ex) m3.largeなど旧世代のインスタンスタイプはサポートしていない
• 永続的に必要なEC2のみリザーブドインスタンスでコストメリットを享受可能
• EC2Rescue for Windows Server
  • Amazon EC2 Windows Server インスタンス上で動作
  • 潜在的な問題の診断とトラブルシューティングを行うことができるツール
  • 他のインスタンスから Amazon EBS ルートボリュームを調べて、そのボリュームを使用する Windows Server インスタンスをトラブルシューティングするために必要なログを収集
• 承認済みAMIの監視
  • AWS Configのマネージドルールで対応可能
• インスタンスストアのバックアップ方法
  • ec2-bundle-volやec2-upload-bundleなどのAMIツールが必要
  • AWS EC2 CLIはEBSボリュームのAMI作成にのみ使用可能
  • コンソール画面から実行不可
• プレイスメントのクラスター配置グループはAZを跨いでの利用は不可
• HVM AMI
  • ホストシステム上の基盤となるハードウェアへの高速なアクセスを可能にするハードウェア拡張を利用可能
• EC2ではSR-IOVを利用可能
• 拡張ネットワーキングやプレイスメントグループはインスタンス間の通信改善に使える機能
  • VMとストレージ間の帯域改善には使えない
• ストレージに対するレイテンシの改善策
  • RAID0構成にする
  • EBSに対するIOレート改善できるインスタンスタイプへの変更
• t2インスタンスタイプを使ったコスト削減
  • t2インスタンス：ベースラインレベルの CPU パフォーマンスを維持しながら突発的な高パフォーマンス需要にも必要に応じて対応する融通性を備えた汎用インスタンスタイプ
  • 普段CPUリソースに余剰がありつつも、突発的にリソースが必要になる場合に有効

Elastic Block Store (EBS)

• 汎用SSDストレージは容量を増やすことでIOPSを増やせる
  • 5.34 TiB から 64 TiBであればIOPSは不変 (16,000 IOPS)
• Amazon DLM（Data Lifecycle Manager）
  • EBSのスナップショットのスケジューリングや世代管理をすることが可能
• EBSスナップショットのライフサイクルポリシーの仕様
  • ポリシーによって作成されたスナップショットをコピーする場合、新しいコピーはデータ保存期間設定の影響を受けない
  • ex) スナップショットの保存期間を10日に設定してコピーした場合、コピーされたスナップショットは10日間の保存期間を維持することはない

Virtual Private Cloud (VPC)

• VPCに追加できるセカンダリCIDRブロックの制限
  • /16～/28の範囲で追加可能
  • プライマリCIDRブロックと同じクラスから追加
• ゲートウェイエンドポイント
  • 対応サービス
    • S3
    • DynamoDB
  • 通信料：無料
• インターフェイスエンドポイント
  • 対応サービス
    • 50種類以上（S3、DynamoDB以外）
  • 通信料：有料
• IPv6対応でプライベートサブネットからインターネット接続を設定する場合
  • Egress-Only インターネットゲートウェイを作成する
  • IPv6はグローバルで一意なIPがアサインされるのでNAT変換という概念がない
• Amazon VPC Traffic Mirroring
  • EC2インスタンスのENIからネットワークトラフィックを他のENIやNLBにミラーリングする機能
  • Nitro世代のEC2で利用可能
  • VPCフローログと異なりパケット内容を取得可能
  • ユースケース
    • 脅威検出
    • コンテンツモニタリング
    • 問題判別
• VPCフローログはAmazon CloudWatch Logs または Amazon S3 に発行可能
• ルートテーブル
  • サブネットに設定されるリソース
  • VPCに対しては設定できない
• AWSへのBYOIP手順
  • アドレス範囲を、地域インターネットレジストリ (RIR、Regional internet registry) に登録
  • Route Origin Authorization (ROA) を作成
    • アドレス範囲、そのアドレス範囲を公開することを許可された自律システム番号 (ASN)、および有効期限が含まれる
    • ROA は Amazon が特定の AS 番号のアドレス範囲を公開することを承認
  • アドレス範囲について Registry Data Access Protocol (RDAP) の注釈で自己署名付きの X509 証明書を発行
  • RIR の RDAP レコードを更新
• VPCのDHCPで配布するDNS情報の設定
  • AWS提供DNSの情報を配布する場合は「domain-name-servers=AmazonProvidedDNS」を指定
  • 解決するドメイン名は「domain-name=domain-name-for-your-region」で指定
    • domain-name-for-your-regionだと利用しているリージョンにマッチするドメイン名が利用される
• NATゲートウェイ
  • NATゲートウェイの配置にはパブリックサブネットが必要
    • 高可用性のためにはパブリックサブネットを複数作成し、さらにNATゲートウェイを複数構成する
  • NATゲートウェイの利用はルートの設定で対応
    • 障害発生時のNATゲートウェイの切り替えはルートの設定変更で対応
• VPC拡張の制限
  • CIDRブロックはVPC ルートテーブルのいずれかのルートのCIDR範囲と同じ､またはそれ以上に大きくすることは不可

Elastic Load Balancing (ELB)

• ELBにはAuto Scaleによってインスタンス数を増減させる機能はない（Auto Scalingグループが持つ機能）
• プラットフォームタイプごとにSSL証明書を使わけつつ、ELBで負荷分散する構成
  • プラットフォームタイプごとに個別にELBを作成
  • これによりプラットフォームタイプに基づいて負荷を均等に分散可能
  • 独自のスティッキーセッションとSSL終了ロジックを処理するように各ELBを構成可能 → 管理の容易化
• 負荷テストにおいてスティッキーセッションを有効化したままアクセス先を分散させる方法
  • グローバルに分散化したクライアントやサーバーからのリクエスト送信ができるサードパーティーの負荷分散テストを利用
• SSL認証情報の設定に必要な権限
  • IAMポリシーによるアクセス権限設定はACMとELBのどちらにも設定することが必要
• スティッキーセッション
  • 特定のインスタンスに負荷が偏る（AZ全体の負荷が高まるわけではない）
• クロスゾーン負荷分散
  • 有効にすると複数AZにまたがって登録されたEC2インスタンスに均等に負荷が分散される
  • ロードバランサーごとの設定
    • ALB：選択不可、常にクロスゾーン負荷分散がELBでは有効
    • NLB：属性の編集から選択可能
    • CLB：作成時に選択可能
• ELBの使用するプロトコル
  • HTTP
  • HTTPS（セキュア HTTP）
  • TCP
  • TLS (セキュア TCP)
• TCP、TLSはCLBとNLBのみで利用可能
• ALBはHTTPとHTTPSがプロトコルとして利用可能
• ELB利用中にEC2でSSL終端処理をする場合、ELBではリスナーとしてHTTPSではなくTCPを使う
• ELBのバックエンドサーバがクライアントのIP情報を読み取るための構成
  • ELBでProxy Protocolを利用する
  • Proxy Protocol は、接続をリクエストする送信元から、接続がリクエストされる送信先に接続情報を伝達するために使用されるインターネットプロトコル
• ALB利用時にクライアントIPをバックエンドに渡すには X-Forwarded-For リクエストヘッダー を利用する
• 通信の暗号化
  • ALBはHTTPSプロトコルを利用
  • NLBはTLSプロトコルを利用

Elastic Container Service (ECS)

• ECSのオートスケーリング設定
  • Amazon ECS Cluster Auto Scalingを利用
  • 実装方法
    • あるAuto ScalingグループにECS Capacity Providerを関連付け
    • ECSクラスターにCapacity Providerを追加
    • Capacity Provider Reservationという新しいメトリックに対応するスケーリングポリシーが自動的に生成され、Auto Scalingグループにアタッチ
  • EC2起動タイプとFargate起動タイプは互換性なし
• ECSの権限設定
  • Amazon ECS タスク用の IAM ロールを使用すると、タスクのコンテナで使用できる IAM ロールを指定して、タスクごとに必要な権限を設定することが可能
  • タスクへのアクセス権限をタスク定義内のポリシーで実施するといった機能はない

Elastic Container Registry (ECR)

• Amazon ECRはDockerイメージを管理するサービス
• オープンソースで実行されているKubernetes環境をEKSへと移行するといった機能はない

Site-to-Site VPN

• Customer Gateway（CGW）
  • VPC と オンプレミス 環境間で VPN 接続を確立する際に必要
  • 顧客側のネットワーク情報をもつリソース
• AWS Site-to-Site VPNの仕様
  • Site-to-Site VPN 接続は、AWS Classic VPN または AWS VPN のいずれか
  • IPSecトンネル経由で送信されるデータの整合性を保持する
  • IPSecトンネルを経由して送信されるデータは暗号化される
  • IPSecはインターネット経由で送信中のデータを保護する
  • IPSecトンネルのセットアップ中にIDが認証される
  • VPNゲートウェイ（VPG）とカスタマーゲートウェイ（CGW）の間にIPSecトンネルが確立される → IPSec VPNであり、SSL-VPNではない（SSLは使わない）

Direct Connect

• Direct Connectの確立
  • 802.1QVLANタグに対してVLANトランキングを有効化する必要あり
• パブリック仮想インターフェイスはDirect Connect経由でパブリックリソース（S3など）にアクセスするために利用する
• Direct Connect経由でVPCエンドポイントにアクセスは出来ない ※2021年2月のアップデートでインターフェイスエンドポイント（PrivateLink）経由で接続可能になった
  • VPCエンドポイントには「ゲートウェイエンドポイント」「インターフェイスエンドポイント」がある
• Direct Connect経由のアクセスはSite-to-Site VPNを構成することで暗号化できる
  • これにより暗号化に加えて冗長構成もとれる（冗長化のために別途VPNを張る必要はない）
• Direct Connectを利用したリージョン間の接続
  • パブリック仮想インターフェイスを作成し、異なるリージョン間とのVPN接続を実現することで構成可能

Route 53

• Route 53 Private Hosted Zoneを異なるAWSアカウントのVPCに紐付ける方法
  • CreateVPCAssociationAuthorization APIによりPrivate Hosted Zoneを持つアカウントでVPCの紐付け許可を実施
  • AssociateVPCWithHostedZone APIによりVPCを持つAWSアカウントでPrivate Hosted ZoneとVPCを紐付け
    • 対象VPCにおけるenableDnsHostname、enableDnsSupportの有効化が必須
• Route 53 Private Hosted Zoneを同一AWSアカウントのVPCに紐付け
  • Private DNS Associateで紐付け
• Route 53のセキュリティ機能
  • シャッフルシャーディング
    • 数多くのエンドポイントに DNS リクエストを分散させ、アプリケーションの複数のパスとルートを提供
  • Anycastルーティング
    • 複数の PoP から同じ IP アドレスをアドバタイズすることで冗長性を高める
    • DDoS 攻撃が 1 つのエンドポイントを攻略した場合、シャッフルシャーディン グによって障害が分離され、インフラストラクチャに追加のルートが提供される
• Route 53で分散ルーティングする設定
  • 複数値回答ルーティングを使用
  • 複数値の回答ルーティングでは各リソースの正常性も確認可能（正常なリソースの値のみを返す）
  • 複数値回答ルーティングを設定する際はALIASレコードに「NO」と設定することが必要
• Route 53のフェイルオーバー設定
  • アクティブ/パッシブ：スタンバイを構成
  • アクティブ/アクティブ：両系プライマリ（ダウンタイムゼロ）

Simple Storage Service (S3)

• S3のETag：データの整合性チェックに利用
• S3 Transfer Accelaration
  • データ転送先としてCloudFrontのエッジロケーションを選択し、最短距離で転送する機能
• S3の低冗長化ストレージの利用は非推奨（スタンダードの方がコストメリット高い）
• S3へアップロードする際にランダムなプレフィックスを付与する必要は今はない
• 処理の並列化におけるストレージの選択
  • 単一のEBSボリュームを複数のインスタンスに接続することはできない → 複数サーバからの並列読み取りには不向き
  • S3をストレージとして利用し、入力データに対して並行して動作する複数のEC2インスタンスを利用
• S3へのアクセスをCloudFrontからのみ許可する設定
  • S3バケット上のオブジェクトを非公開に設定
  • CloudFront用のorigin access identityを作成
  • origin access identityからS3バケット上のオブジェクトに対するアクセスを許可するポリシーをS3に設定
• CloudFrontの署名付き URL と署名付き Cookie
  • 署名付き URL
    • 個別のファイル (アプリケーションのインストールダウンロード) へのアクセスを制限する場合。
    • ユーザーが Cookie をサポートしていないクライアント (カスタム HTTP クライアントなど) を使用している場合。
  • 署名付き Cookie
    • 複数の制限されたファイル (HLS 形式の動画のすべてのファイルやウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合。
    • 現在の URL を変更したくない場合。
• Glacierのモード
  • 迅速取り出し：1～5分
  • 標準取り出し：3～5時間
  • 大容量取り出し：5～12時間
• Glacier Deep Archiveのモード
  • 標準取り出し：12時間以内
  • 大容量取り出し：48時間以内
• S3上のオブジェクトの検索方法
  • S3のネイティブ検索機能
  • S3 Select
    • Amazon S3バケット上のCSVやJSON形式のオブジェクトから、必要なデータをSQLライクな構文で効率的に抽出できる機能
  • ElaticSearch *高速検索可能
  • CloudSearch *高速検索可能
• SSE-S3暗号化（サーバーサイド暗号化）
  • S3の暗号化を利用
  • 特徴
    • データキーでデータを暗号化する。
    • SSE-S3 は、定期的に回転するマスタキーを使用してデータキーを暗号化します。
    • S3 のサーバーサイド暗号化は、256ビット高度な暗号化標準 (AES-256)、データを暗号化するために利用可能な最強のブロック暗号のいずれかを使用しています。
    • サーバーサイド暗号化はAWS マネジメントコンソールまたは HTTP リクエストヘッダーを使用しているため、事前に署名された URL を使ってアップロードする場合には適用できません。

Storage Gateway

• Storage Gatewayの種類
  • ゲートウェイ保管型ボリューム
    • 新規にアップロードされたデータをローカルのディスクに保存した上で、非同期的にAWSへとバックアップを行う
  • ゲートウェイキャッシュ型ボリューム
    • データは仮想アプライアンス経由でAmazon S3へと保存されますが、その際に仮想アプライアンスにマウントされているCache Volumeに一時的に保存される
• テープゲートウェイ
  • 既存のテープベースのバックアップインフラストラクチャからAmazon Gracierにデータを保存することが可能
  • 仮想テープライブラリ (VTL) のインターフェイスを使用することで、既存のテープベースのバックアップインフラストラクチャを利用して、テープゲートウェイ 上に作成する仮想テープカートリッジにデータを保存
  • 各 テープゲートウェイ にはメディアチェンジャーとテープドライブがあらかじめ組み込まれている
  • これらは、既存のクライアントバックアップアプリケーションから iSCSI デバイスとして利用可能
• AWS Storage Gatewayにより取得されたデータの復元方法
  • ゲートウェイボリュームのポイントインタイムスナップショットを利用して、既存のEC2インスタンスにマウントできるスナップショットから新しいEBSボリュームを作成
  • ボリュームゲートウェイを使用し、オンプレミスマシンにマウントできるiSCSIデバイスをマウント
• AWS Storage Gatewayにより取得されたデータの仕様
  • ゲートウェイにキャッシュされたすべてのボリュームデータとスナップショットデータはSSEを使用して暗号化されたAmazon S3に保存
  • 上記からS3 APIからはアクセス不可

Athena

• Athenaは完全マネージド（ノード数指定などがない）

Elastic File System (EFS)

• インターネットからアクセスできない高可用性の共有ストレージ → EFS
  • S3はインターネットからアクセス可能のため要件にマッチしない
• Amazon EFS マウントヘルパー
  • EFS ファイルシステムのマウント処理を簡素化
  • トラブルシューティングのためのログ記録が組み込まれている
  • マウントヘルパーは efs という新しいネットワークファイルシステムタイプを定義
  • mountコマンドでマウント対応可能
• EFSファイルシステムIDの取得
  • コンソールまたは実行コードによって、EFSファイルシステムIDをEFS APIから連携

Snowファミリー

• Snowball Edgeの種類
  • Snowball Edge Storage Optimized：80TB
  • Snowball Edge Compute Optimized：42TB
• Snowballについて
  • 現在はSnowball edgeのみが利用可能であり、Snowballは利用不可
  • Snowball一台で80TBのデータを保存可能
  • Snowballへのデータ転送には中継機が必要（転送速度は中継機のスペックに依存）

RDS

• RDSリードレプリカはスタンドアロンDBインスタンスに昇格可能
• RDSのMulti-AZ配置リードレプリカはスタンバイDBとしても機能する
• RDSに対するDB インスタンスへのシェルアクセス
  • RDSはDB インスタンスへのシェルアクセスは禁止されているため、RMANなどシェルアクセスが必要なツールを使いたい場合は、EC2インスタンスにOracleデータベースソフトウェアをインストールして構成することが必要
• AWSにおけるOracle RAC
  • RDSの利用は不可
  • バックアップの仕組みは提供されていない
  • マーケットプレイスからEC2を利用して構築可能
• MySQLのログ
  • 一般ログ
    • mysqld の実行内容の一般的な記録
    • サーバーは、クライアントが接続または接続解除したときに情報をこのログに書き込み、クライアントから受け取った各 SQL ステートメントをログに記録する
  • エラーログ
    • mysqld が開始および停止された時期を示す情報と、サーバーが実行中に発生したあらゆるクリティカルエラーが格納される
  • スロークエリログ
    • 実行に要した時間が long_query_time 秒を超え、少なくとも min_examined_row_limit 行を検査する必要があった SQL ステートメントで構成される
• リードレプリカの最大数
  • RDS MySQL：5個
  • Aurora MySQL：15個

Aurora

• RDS MySQLからAuroraへの移行のベストプラクティス
  • スナップショットからの復元時にデータベースエンジンをAuroraに指定して起動
• Auroraエンドポイントの種類
  • クラスターエンドポイント: ロールがWriterのインスタンスへアクセスするエンドポイント
  • 読み込みエンドポイント: ロールがReaderのインスタンスへアクセスするエンドポイント
  • インスタンスエンドポイント: 特定のインスタンスへアクセスするエンドポイント
  • カスタムエンドポイント：インスタンスの組み合わせを自由に行えるエンドポイント

Database Migration Service (DMS)

• DMSの構成
  • レプリケーションインスタンスはEC2インスタンスではなくDMSコンソールで作成
• DMSを使ったデータ移行の方法
  • フルロード
  • フルロード + CDC
  • CDC
• ソースDBからAWS上のDBへ直接データ移行できない場合の代替策
  • 手順
    • レガシーデータベースから抽出したCSVファイルをS3にアップロード
    • AWS DMSコンソールを利用してS3をソースエンドポイントに、AWS上のDBをターゲットエンドポイントに指定して、テーブルマッピングを追加
  • S3がソースエンドポイントである場合、外部テーブル定義が必要
    • 外部テーブル定義は、AWS DMSがAmazon S3からのデータをどのように解釈するかを説明するJSONドキュメント

DynamoDB

• DynamoDBはキーバリュー型のデータベースであり、集計処理には不向き
• DynamoDBには「結界整合性のある読み込み」と「強力な整合性のある読み込み」がある
• DynamoDBのデータを更新する際は「条件付き書き込み」を利用することでダブって更新するのを防いだりできる
• インデックスの種類
  • グローバルセカンダリインデックス
    • パーティションキーおよびソートキーを持つインデックス
    • このインデックスに関するクエリが、すべてのパーティションにまたがり、ベーステーブル内のすべてのデータを対象とする可能性がある
    • サイズの制限はなし
  • ローカルセカンダリインデックス
    • パーティションキーはベーステーブルと同じですが、ソートキーが異なるインデックス
    • ローカルセカンダリインデックスのすべてのパーティションの範囲が、同じパーティションキー値を持つベーステーブルのパーティションに限定される
    • 任意の 1 つのパーティションキー値に対してインデックスが作成された項目の合計サイズが、10 GB を超えることは不可
    • 読み込みアクティビティおよび書き込みアクティビティのプロビジョニングされたスループット設定が、インデックス作成中のテーブルと共有
    • ローカルセカンダリーインデックスはテーブル作成時に設定する必要があり、既存のテーブルには追加不可
• DynamoDB Streams
  • DynamoDB テーブル内の項目レベルの変更に関するシーケンスを時間順にキャプチャし、その情報を最大 24 時間ログに保存
  • グローバルテーブルを利用する際に必要な設定
• DynamoDB DAX
  • キャッシュとしての利用は想定されていない
  • あくまでDynamoDBに対して高速処理を実現するために利用
• DynamoDBの高負荷対策
  • SQSを使用し、プロビジョニングされた容量を超えないように突然の高負荷を吸収するバッファーとして機能
  • DynamoDBテーブルのAutoScalingを有効化して、一時的なスループットキャパシティを増加
• FGAC（Fine Grained Access Control）
  • DynamoDB テーブルの所有者がテーブル内のデータに対して詳細なコントロールを行うための機能
  • テーブル所有者は誰（呼び出し元）がテーブルのどの項目や属性にアクセスでき、どのようなアクション（読み込み/書き込み）を実行できるかを指定できる
• DynamoDB 読み込みキャパシティーユニット（RCU）の計算方法
  • 1 つの読み込みキャパシティーユニットは、最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを表す
• 書き込みキャパシティーユニット（WCU）の計算方法
  • 1 つの書き込みキャパシティーユニットは、最大サイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表す
• DynamoDBのAutoScalingはプロビジョンドモードに備わっている機能
• DynamoDBに継続的にデータが保存される場合のライフサイクル管理
  • テーブルを一週間おきに逐次新規作成してライフサイクル管理するのは不可
  • この場合は同じテーブルを使い続けるしかない

Redshift

• Redshiftのノード数は手動でスケーリング
• RedshiftのDR構成
  • 自動スナップショット利用
    • プライマリ側で自動スナップショットを有効化
    • 自動スナップショットコピーを実施し、別リージョンにコピー
      • 増分も自動的にコピーされる
  • 2インスタンス構成
    • Amazon Redshift はシングル AZ 配置のみをサポート
    • そのため2 つの Amazon Redshift データウェアハウスクラスターをそれぞれ別のアベイラビリティーゾーンに配置
• Redshiftにマルチクラスターといった機能はない（あるとすれば個別にクラスター作成するくらい） – 同じ Amazon S3 入力ファイルセットからデータをロード
• Amazon Redshift はシングル AZ 配置のみをサポート
• Amazon Redshiftクラスターの暗号化
  • AWS KMSのマスターキーで暗号化可能
  • DR対応ではDR元リージョンにおいてAWS KMSで暗号化されたクラスターのクロスリージョンスナップショットコピーを有効化
  • その際、Amazon Redshiftが宛先リージョンで暗号化操作を実行できるように、宛先リージョンのマスターキーのスナップショットコピーを許可する設定が必要
    • KMSで共有された暗号化キーを宛先のIAMユーザから使用するには、IAMポリシーにて権限付与が必要
• Amazon Redshift のワークロード管理 (WLM)
  • ユーザーは、ワークロード内の優先順位を柔軟に管理して、短くて実行速度の速いクエリが実行時間の長いクエリの後に溜まらないようにできる
  • ２つの異なるワークロード管理グループを作成して、2つのデータ分析プロセスを設定可能
• Redshiftのクエリハング対応
  • 最大送信単位 (MTU) のサイズを小さくする（ネットワーク帯域使用の削減）
  • カーソルを使用して、結果セットをクライアントアプリケーションに渡す（Redshift側メモリ使用量の削減）

ElastiCache

• Memcached
  • シンプルに利用可能
  • AZにまたがってノードのスケールアウト／インが可能
  • データにアクセスする際はアプリ側でノード指定が必要
  • 高可用性の機能（レプリケーション設定）はMemcachedにはない
• Redis
  • 柔軟なデータ構造に対応（ゲーム業界でよく使われるらしい）
  • 高可用性の機能を提供
• ElastiCacheはキーバリュー型のデータベースであり、集計処理には不向き
• ElastiCache Redisの耐障害機能
  • 自動バックアップ
  • Redis AOF (Append-Only File) を使用した手動バックアップ
  • 自動フェイルオーバーを備えたマルチAZのセットアップ
• Redis AOF
  • AOF はデフォルトでは無効
  • キャッシュデータを変更するすべてのコマンドを Append-Only File に書き込み
  • ノードが再起動され、キャッシュエンジンが起動すると、AOF が「再生」
  • その結果、すべてのデータがそのままのウォーム Redis キャッシュを作成
  • 有効化方法
    • appendonly パラメータを yes に設定してパラメータグループを作成
    • 次に、そのパラメータグループをクラスターに割り当て
• Redis リードレプリカノード
  • 手動ステップやアプリケーション変更なしに、簡単に読み取りをスケールすることや、Redis クラスター環境の可用性を向上させることが可能
• Redisの性能向上
  • ノードタイプを変更（インスタンスタイプではない）

CloudFormation

• Service Catalogの作成順序
  • CloudFormationテンプレートを作成
  • ポートフォリオを作成
  • 製品を作成
  • 製品にCloudFrontテンプレートを紐付け
  • ポートフォリオに製品を追加
• CloudFormationの複数スタックで共通利用されるパラメータの設定
  • エクスポートされたリソースをクロススタック参照する
• 複数のスタックで共通利用されるインフラの構築
  • スタックのネストを利用することでテンプレートを使いまわし
• 作成するリソースに自動タグ付けする方法
  • CloudFormationのResource Tags プロパティを使用（決められたタグが静的に付与されるっぽい）
  • AWS Service Catalogを利用
    • デプロイされたAWSリソースにポートフォリオ、製品、ユーザーを識別するためのタグが自動的に付与
• CloudFormationを使ったLambdaのデプロイ
  • AWS SAM（Serverless Application Model）を利用
  • AWS SAMはLambdaをCloudFormationからデプロイできるようにするための拡張機能
  • AWS SAMを利用する際はCloudFormationに以下を設定
    • AWS SAM バージョンの指定（AWS::ServerlessオプションのTransformの設定）
• CloudFormationにおけるLambda関数のインライン実装
  • Node.js および Python 関数の場合で依存関係がない限りテンプレートにインラインで関数コードを指定可能
  • コードレポジトリーに保存して参照する機能はない
• CloudFormationのCreationPolicy
  • スタックの作成に進む前にリソース設定アクションを待機する場合は、CreationPolicy 属性を使用
  • AWS CloudFormation が指定数の成功シグナルを受信するかまたはタイムアウト期間が超過するまでは、ステータスが作成完了にならない
  • たとえば、EC2 インスタンスにソフトウェアアプリケーションをインストールして設定する際に、先に進む前にこのアプリケーションを起動して実行する場合に利用
• CloudFormationでAWS Serverless Application Model（SAM）を使う場合の構文
  • AWS :: Serverless-2016-10-31
    • SAMを使うために必要なテンプレート指定
  • AWS :: Serverless :: Api
    • SAMフレームワークでAPIゲートウェイを使う場合に指定
  • AWS :: Serverless :: Function
    • Lambda関数、IAM実行ロール、イベントソースマッピングを指定

Identity and Access Management (IAM)

• IAMのSecurityAuditポリシー
  • ほとんどのAWSリソースに対する閲覧権限が付与される（細かくサービスを選別できない）
• タグ付与の強制（自動タグ付けではない点に注意）
  • IAMポリシーにForAllValues修飾子を使用
  • 上記により指定したキー名のタグ付けを強制
• 監査対応など一時的な利用ではIAMユーザよりIAMロールの方が適している
• IAMでのSSL証明書管理
  • IAMで証明書を管理可能
  • ACMが利用できないリージョンでの利用を想定
• 各サービスに適用されるIAMロールは一つのみ（重複しない）
• IAMロールの更新対象
  • インスタンスプロファイルとAWS CLIを利用している場合、両方のIAMロールを更新する必要がある
  • でなければ古いIAMロールが一方で有効になる可能性がある

Organizations

• Organizationではすべての機能を有効にすることでSCPや一括請求機能が使える
• AWS Organizationsを使った権限管理
  • 使える機能はSCPのみ
  • 開発向けインスタンス以外へのアクセスを拒否するといった細かい設定は不可
• EC2などにIAMロールで付与された権限はSCPでは制限できない
• AWS Organizations内でリザーブドインスタンスを共有させない設定
  • マスターアカウントによってリザーブドインスタンス共有設定を非有効化

Security Token Service (STS)

• STSによる一時認証情報はIAMロールを利用して設定される
• アクセス権の即時取り消しは「IAMダッシュボードにおいて、ユーザーに提供した特定のロールを選択し、取り消し設定を利用」
• カスタム ID ブローカーを使った既存ID認証システムの転用
  • SAML2.0と互換性がないID認証システムに対して利用
  • STSの仕組みと連携
  • STSの認証方式
    • AssumeRole：クロスアカウント認証を利用
    • GetFederationToken：フェデレーションを利用
• 既存のLDAP認証を使ってAWSリソースにアクセスする仕組み
  • カスタムIDブローカーを利用
  • カスタムIDブローカーとSTSのAsumeRoleやGetFederationTokenによりアクセス許可
  • IAMロールには上記のような機能はない
• AWS Organizationsのメンバーアカウント削除
  • マスターアカウントでなくても削除可能 ※マスターアカウントの呼称はマネジメントアカウントに変更されている
  • メンバーアカウント削除が出来ない場合の理由は以下二つ
    • メンバーアカウントでの請求を IAM ユーザーアクセスで有効にした後でのみ、メンバーアカウントを削除できます。
    • アカウントがスタンドアロンアカウントとして動作するために必要な情報を持っている場合にのみ、組織からアカウントを削除できます。

AWS Managed Microsoft AD

• 既存ADを利用したSSOの実現方法
  • AWS管理のADドメインサービス
  • AD処理をAWS側に移行
  • 既存ADに接続し、認証情報を再利用可能

AD Connector

• 既存ADを利用したSSOの実現方法
  • 既存AD側の認証によりAWSリソースを利用可能とする

Cognito

• IDフェデレーションの実装はCognitoが担う（IAMではない）

SSO

• AWS SSOを利用した既存認証との連携
  • AWS Organizations サービスを設定し、[すべての機能] を有効化する必要あり

Certificate Management

• IAM内でデジタル証明書（SSL証明書）を管理できる
• AWSのWeb系サービスをHTTPS化する際にマネージドに利用することが可能
• 持ち込んだ証明書も管理可能
  • 正規の認証局で作成したりオレオレ認証局で作ったりした、外で作った自前ルートキー（CMK）を持ち込み可能
• AWS Certificate Managerが証明書を提供可能なサービス
  • ELB
  • CloudFront
  • Amazon API Gateway
• SSL認証情報の設定に必要な権限
  • IAMポリシーによるアクセス権限設定はACMとELBのどちらにも設定することが必要
• ACMから生成されたパブリック証明書は、EC2インスタンスで直接使用することはできない
  • プライベート証明書はEC2インスタンスでも利用可
• ACMのパブリック証明書とプライベート証明書の違い
  • パブリック証明書：パブリックインターネットでリソースを特定
    • アプリケーションとブラウザはデフォルトで自動的にパブリック証明書を信頼
  • プライベート証明書：プライベートネットワークでリソースを特定
    • プライベート証明書を信頼するには管理者がアプリケーションを明示的に設定する必要あり

Key Management Service (KMS)

• AWSマネージドな鍵管理サービス
• ACMのルートキーを暗号化したり、S3やEBS、ログ暗号化、など、いろいろなサービスをマネージドに暗号化
• 外で作った自前鍵（CMK）を持ち込み可能

CloudHSM

• VPC上に鍵管理専用のサーバをプロビジョン
• KMSより暗号化レベルが強く、管理が利用者になるため、エンタープライズな用途に向いている
• 外で作った自前鍵（CMK）を持ち込み可能
• ハードウェアセキュリティモジュール (HSM)
  • 不正使用防止策の施されたハードウェアデバイス内での、安全なキー保管と暗号化操作を提供
  • データ暗号化に利用される仕組み
  • KMSより安全に暗号化キーを保管可能（ただしKMSより高い）

Systems Manager

• 構成とシークレット用の単一のストアを提供
• 無料
• AWS Systems Manager Patch Managerの利用条件
  • SSM AgentをEC2インスタンスにインストールすることが必要
• Systems Manager Patch Managerでパッチ適用する際は「パッチベースライン」を作成する
  • パッチベースラインはインスタンスをグルーピングした「パッチグループ」に対して紐付けることが可能
  • パッチグループはEC2に「Patch Group」というキータグを付与することで設定可能
  • 参考資料
    • https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-patch-patchgroups.html

Secrets Manager

• ライフサイクル管理を備えた専用のシークレットストア
• 有料

Lambda

• Lambdaの実行時間は最大で15分
• Lambda@Edgeの構成
  • ビューワーリクエスト
  • オリジンリクエスト
  • オリジンレスポンス
  • ビューワーレスポンス
• Labmda関数のネットワークアクセス条件
  • Lambda関数はWEB上でサーバレスアプリケーションを実行
  • AWSのプライベートサブネット内での処理についてはNATゲートウェイ経由での返信処理が必要
  • VPC内でNATインスタンスかNATゲートウェイを使用することが必要
• LambdaからDynamoDBへのアクセス許可
  • Lambda向けのサービスロールを作成
  • DynamoDBに対する任意の操作を許可するIAMポリシーを作成し、サービスロールにアタッチ
• API GatewayからLambda関数へのアクセス許可
  • 以下のようなawsコマンドで設定（IAMの管理操作ではない）

aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id sns \
--principal sns.amazonaws.com

• Lambdaのプロキシ統合／非プロキシ統合
  • プロキシ統合
    • クライアントの API リクエストをLambda 関数に raw リクエストをそのまま渡す
  • 非プロキシ統合
    • プロキシ統合のセットアップステップに加えて、受信リクエストデータがどのように統合リクエストにマッピングされるか、統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかをAPI Gatewayにて指定

API Gateway

• API Gatewayに対してX-Rayを有効化することでLambdaやS3バケットなど各コンポーネント間の処理時間を可視化できる
• Lambdaオーソライザ
  • Lambdaで実装できるAPI Gatewayの認証機能
  • Labmda関数は以下の方法で認証を実施
    • OAuth アクセストークンを取得するために OAuth プロバイダーを呼び出します。
    • SAML アサーションを取得するために SAML プロバイダーを呼び出します。
    • リクエストパラメータ値に基づいて IAM ポリシーを生成します。
    • データベースで認証情報を取得します。
• Amazon API Gateway のCloudWatch メトリクスデータ
  • 4XXError：指定された期間に取得されたクライアント側エラーの数。
  • 5XXError：指定された期間に取得されたサーバー側エラーの数。
  • CacheHitCount：指定された期間内に API キャッシュから配信されたリクエストの数。
  • CacheMissCoun：API キャッシュが有効になっている特定の期間における、バックエンドから提供されたリクエストの数。
  • Count：指定された期間内の API リクエストの合計数。
  • IntegrationLatency：API Gateway がバックエンドにリクエストを中継してから、バックエンドからレスポンスを受け取るまでの時間。
  • Latency：API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。
• API Gateway ステージ変数
  • ステージ変数を使用することで、異なるバックエンドのエンドポイントとやり取りするよう API デプロイステージを設定可能
  • ステージごとにAPI Gatewayを作成する必要がなくなる
• Lambdaから29秒より多く応答がないとAPI Gatewayはタイムアウトする
• API Gateway 応答タイプ
  • INTEGRATION_FAILURE：そもそもLambdaとの連携が出来ていない
  • INTEGRATION_TIMEOUT：Lambdaから29秒より多く応答がない

Elastic Beanstalk

• Elastic Beanstalk
  • ロードバランシング、Auto Scalingも可能
• Elastic BeanstalkにおけるRDSの扱い
  • パフォーマンスが最適ではないため、RDSを個別に作成して利用することが求められる
  • データベースインスタンスのライフサイクルをアプリケーション環境のライフサイクルに結び付けるため、実稼働環境に理想的なものではない
• AWS Elastic Beanstalkのデプロイポリシー
  • All at once
    • 新しいバージョンをすべてのインスタンスに同時に展開
    • デメリット
      • 短時間ではありますが、サービスが停止する時間がある
  • Rolling
    • バッチサイズ分のインスタンスがLBからデタッチされ、デプロイ
    • 全てのインスタンスにデプロイがされるまで LBからデタッチ⇒デプロイ⇒ヘルスチェックOKならLBに再アタッチ を繰り返す
    • デメリット
      • デタッチされている分、ELBで捌けるインスタンス数が減るので、パフォーマンスに影響が出る可能性がある
  • Rolling with additional batch
    1. バッチサイズ 分のインスタンスを追加作成し、そのインスタンスにデプロイ実行
    2. ヘルスチェックをし、問題なければ、ELBにアタッチします。
    3. 2でアタッチした分、ELBからデタッチし、デプロイを実行
    4. デプロイ済みのインスタンスをELBにアタッチします。
    • 上記を繰り返すことで、全てのインスタンスを更新
    • デメリット
      • すごく短時間だが、EC2インスタンスの数が増え、料金がかかってしまう
  • Immutable
    1. EC2インスタンス実際に稼働している分とを同じ数、用意し、そちらにデプロイします。
    2. ヘルスチェックに通るかどうかを確認します。
    3. 問題なければ、EC2インスタンスを実際に稼働しているELBにアタッチします。
    4. 古いEC2インスタンスをデタッチし、終了させます。
    • デメリット
      • 一時的に、EC2インスタンスの数が倍増し、費用がかかる
  • SWAPはElasti Beanstalkを利用してブルーグリーンデプロイメントを実行する際に利用しますが、デプロイポリシーのオプションで実行するものではない（詳細はこちら）

CloudFront

• CloudFront オリジンフェイルオーバー機能
  • プライマリオリジンがHTTPステータス500、504などのエラーが返された際に、セカンダリオリジンにリクエストをルーティングする
  • ALBやRoute 53の場合、たまにしか発生しない50xエラーに対する解決策とはならない（unhealthyとみなさないため）
• エッジ最適化APIエンドポイント
  • クライアントからのAPIリクエストが、クライアントから最寄りのCloudFront接続ポイントにルーティングされる
  • 結果としてアップロード速度の改善につながる
• CloudFrontに対するアクセスログはS3に保存可能
• CloudFrontのビューアリクエストの割合を増やす施策 → なるべく最新の情報をCloudFrontにキャッシュする
  • オブジェクトにCache-Control max-ageディレクティブを追加
  • キャッシュ期間が短いほど最新バージョンを取得する頻度を増やせる
• CloudFrontのコスト削減策
  • エッジロケーションでのZIP圧縮によって配信ボリュームを低下
  • ビューワーがリクエストヘッダーに Accept-Encoding: gzip を含めたリクエストをした場合、CloudFront が自動的に特定のタイプのファイルを圧縮し、圧縮ファイルを提供
• 地域制限 (地理的ブロッキング)
  • CloudFront
    • エッジロケーションによる地理的制限を有効化
    • ディストリビューションに関連するすべてのファイルへのアクセスを制限
    • 国レベルでアクセスを制限する場合に利用
  • サードパーティの位置情報サービス
    • ディストリビューションに関連するファイルのサブセットへのアクセスを制限する場合に利用
    • 国レベルより詳細なレベルでアクセスを制限する場合は、この方法を使用
• CloudFrontの署名付き URL と署名付き Cookie
  • 署名付き URL
    • 個別のファイル (アプリケーションのインストールダウンロード) へのアクセスを制限する場合。
    • ユーザーが Cookie をサポートしていないクライアント (カスタム HTTP クライアントなど) を使用している場合。
  • 署名付き Cookie
    • 複数の制限されたファイル (HLS 形式の動画のすべてのファイルやウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合。
    • 現在の URL を変更したくない場合。
• CloudFrontで署名付きURLを利用する手順
  • キーペアを作成
  • パブリックキーをCloudFrontにアップロード
  • キー情報などをURLのクエリに追加し、CloudFrontへアクセス
• CloudFrontで署名付きCookieを利用する手順
  • ヘッダーに必要な情報を記載してアクセス
• CloudFrontのOrigin Protocol Policy
  • HTTP Only
    • HTTPのみを使用してオリジンにアクセス
  • HTTPS Only
    • HTTPSのみを使用してオリジンにアクセス
  • Match Viewer
    • ビューアーリクエストのプロトコルに応じてHTTPまたはHTTPSを使用してオリジンと通信
• CloudFrontのキャッシュヒット率の向上方法
  • CloudFront がオブジェクトをキャッシュする期間の指定
    • Cache-Control max-age ディレクティブをオブジェクトに追加し、max-age に対して最も長い実用的な値を指定するようにオリジンを設定
  • Origin Shield の使用
    • オリジンの前に追加のキャッシュレイヤーを提供するため、CloudFront ディストリビューションのキャッシュヒット率を向上させるために役立ちます
  • クエリ文字列パラメータに基づくキャッシュ
    • クエリ文字列パラメータに基づいてキャッシュするように CloudFront を設定
  • Cookie 値に基づくキャッシュ
  • リクエストヘッダーに基づくキャッシュ
  • 圧縮が不要な場合に Accept-Encoding ヘッダーを削除する
  • HTTP を使用したメディアコンテンツの提供
    • ビデオオンデマンド (VOD) およびビデオコンテンツのストリーミング
• CloudFrontのプロトコル制御
  • Origin Protocol Policy
    • cloudfrontからオリジンへのアクセスプロトコルを規定
  • Viewer Protocol Policy
    • クライアントからのプロトコルをどう変換するかを設定
    • 種類
      • HTTP and HTTPS
      • Redirect HTTP to HTTPS
      • HTTPS Only
• CloudFrontへのアクセス設定
  • CloudFront ディストリビューションを代替ドメイン名 (CNAME)に関連付ける
• CloudFrontで独自のドメイン名を使用する際のSSL証明書
  • ACMまたはIAMに保存されたカスタムSSL証明書を利用
  • ACMに保存されているデフォルトの証明書では独自のドメインによる配信設定が不可

Web Application Firewall (WAF)

• WAFはALB、CloudFront、Amazon API Gateway保護可能
• WAFの配置場所
  • サンドウィッチ方式が推奨
  • WAFレイヤーを2つのELBの間に配置して、すべてのトラフィックを処理できるよう構成
• SQLインジェクションやクロスサイトスクリプティング防止はAWS WAFで行う
• AWS WAFのルール変更履歴はAWS Configで取得可能（Cloud Trailではない）

Shield

• AWS ShieldはCloudFront、Route53、CLB、ALB、EIP、AWS Global Acceleratorに適用可能
• 詳細なリアルタイム通知や可視化機能はAWS Shield Advancedのみ利用可

Simple Queue Service (SQS)

• SQSで順序性を担保する機能
  • FIFOキュー
  • メッセージグループID
    • 同じメッセージグループに属するメッセージは、常にメッセージグループに対して厳密な順序で1つずつ処理される
• SQSの重複排除機能
  • 可視性タイムアウト
    • 設定時間内に他のコンシューマーが同じメッセージを受信したり処理したりすることを出来なくする機能
  • メッセージ重複排除ID
• SQS 可視性タイムアウトとスポットインスタンス
  • スポットインスタンスが途中で停止されてしまった場合、可視性タイムアウトを設定しているため、その処理は完全にストップする可能性あり → 処理のハングに繋がることも？

Kinesis

• Kinesisの機能
  • Kinesis Data Streams：ストリームデータをKinesis Client Libraryなどで独自に実装したリアルタイムアプリケーションに配信
  • Kinesis Data Firehose：ストリームデータをS3、Redshift、Elasticsearch Serviceへロード
  • Kinesis Data Analytics：Kinesis Data StreamsやKinesis Data Firehoseから配信されるデータを使い、標準的なSQLクエリでリアルタイム分析（完全マネージド）
  • Kinesis Video Streams：接続されたデバイスの動画を、Recognition Videoなどのリアルタイム動画分析機能へ配信
• Kinesis Agent
  • OSSのスタンドアロンJavaアプリケーション
  • プロヂューサーとして利用
• Kinesis Client Library
  • アプリケーション開発に利用
  • コンシューマを実装可能
• Amazon Kinesis Data Firehose
  • Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、Splunk にロード可能
  • Kinesis Data Firehoseから直接Lambda関数へデータを渡し、変換を行える
• Amazon Kinesis コネクタライブラリ
  • AWS サービスやサードパーティー製ツールと簡単に統合可能
  • Amazon Kinesis クライアントライブラリ (KCL) が必要
  • Amazon DynamoDB、Amazon Redshift、Amazon S3、Amazon Elasticsearch Service に対するコネクタを提供
• HTTP Live Streaming (HLS) 機能の利用
  • Kinesis Video StreamsにはHTTP Live Streaming (HLS) 機能が付随
  • Kinesis Video StreamsのGetHLSStreamingSessionURL APIによりHLSストリーミングセッションURLを取得可能
• Kinesis Video Streamsの対応形式
  • GetMedia
    • GetMedia API を使用して、Kinesis ビデオ ストリームを処理する独自のアプリケーションを構築します。GetMedia は低レイテンシーのリアルタイム API です。GetMedia を使用するプレーヤーを作成する場合は 、自分で構築する必要があります。
  • HLS
    • HTTP Live Streaming (HLS) は、業界標準の HTTP ベースのメディアストリーミング通信プロトコルです。HLS を使用して、ライブ再生またはアーカイブ済み動画の再生用に Amazon Kinesis ビデオストリーム を表示できます。
  • MPEG-DASH
    • Dynamic Adaptive Streaming over HTTP (DASH) (MPEG-DASH とも呼ばれる) は、従来の HTTP ウェブサーバーから配信されたインターネット経由で高品質のストリーミングを可能にする適応ビットレートストリーミングプロトコルです。

Batch

• 構成要素
  • ジョブ：ジョブはAWS Batch で実行する作業の単位です。ジョブは、ECS クラスターの Amazon ECS コンテナインスタンスで動作するコンテナ化されたアプリケーションとして実行できます。
  • ジョブキュー：ジョブはジョブキューに送信され、コンピューティング環境で実行するようにスケジュールされるまで、ジョブキューに留まります。ジョブキューでFIFOに対応しています。キューには優先順位をつけることができ、優先順位1より、優先順位10が先に実行されます。
  • ジョブ定義：ジョブ定義はジョブの実行方法を指定します。各ジョブはジョブ定義を参照する必要がありますが、ジョブ定義に指定されているパラメータの多くはランタイムに上書きできます。
  • コンピューティング環境：特定のタスクの実行リソースとしてバッチを処理するEC2環境を定義します。インスタンスタイプから、key pair、ロールなどを指定します。コンピューティング環境には、コンテナ化されたバッチジョブを実行するための Amazon ECS コンテナインスタンスが含まれています。特定のコンピューティング環境を 1 つ以上のジョブキューにマッピングすることもできます。ジョブキュー内では、関連付けられたコンピューティング環境ごとに順番があります。
• 特徴
  • AWS Batch では、コンピューティングリソース (CPU やメモリ最適化インスタンスなど) の最適な数量とタイプを、送信されたバッチジョブの量と具体的なリソース要件に基づいて動的にプロビジョニング
  • ジョブを実行するためのバッチコンピューティングソフトウェアやサーバークラスターをインストールしたり、管理したりする必要がなくなる
  • CloudWatch イベント を使用して、cron 式や rate 式により特定の時間に自己トリガーする自動アクションをスケジュール可能

OpsWorks

• OpsWorksの構成
  • Stack：1つのシステムの環境定義
  • Layer：はロードバランサー層、アプリケーション層、データベース層といった形で分離
  • Recipe：ライフサイクルイベント（Setup、Configure、Deploy、Undeploy、Shutdown）ごとに作成
• OpsWorksにおけるブルーグリーンデプロイメント
  • OpsWorksの設定のみで対応可能
  • CloudFormationとの連携は必須ではない
• OpsWorksの自動ヒーリング
  • インスタンスが Amazon EC2 ヘルスチェックに合格した場合でも、スタック内にある異常なインスタンスまたは失敗したインスタンスを再起動する

CodeCommit

• CodeCommitにはリージョン間レプリケーション機能はない（実現したければLambda関数などで対応）

CodePipeline

• AWS CodePipelineで指定できるソース
  • CodeCommit、S3、GitHub など

CodeDeploy

• AWS CodeDeploy デプロイ構成
  • Canary：Interval後に残りを新環境へ移行
  • Linear ：Intervalごとに徐々に新環境へ移行

Simple Workflow (SWF)

• ワークフロー作成にはSWFではなくAWS Step Functions の利用が推奨
• 以下のケースではAmazon SWFの使用が適切（参考リンク）
  • プロセスにおいて介入する外部信号が必要な場合
  • 結果を親に返す子プロセスを起動する場合

Step Functions

• AWS Lambda、AWS Fargate および Amazon SageMaker などのサービスをつなげて機能豊富なアプリケーションにまとめるワークフローを設計して実行可能
• 新しいアプリケーションには AWS Step Functions を使用することを推奨
• モニタリングではアクティビティに関してはCloudTrailが必要となり、システム状況はCloudWatchが必要となる
• AWS Step Functions 標準／Expressの選択
  • 標準：長時間実行され、耐久性が高く、監査可能なワークフローが必要な場合
  • Express：大量のイベント処理ワークロードの場合

Rekognition

• APIで提供されるサービス
• Amazon Rekognition（画像分析機能サービス）の利用方法
  • AWS CLI
  • Rekognition API
• インスタンスを必要としない

Macie

• Amazon Macie
  • 機械学習によって AWS 内の機密データを自動的に検出、分類、保護するセキュリティサービス

Server Migration Service

• 以下の機能を提供
  • ライブサーバーボリュームの増分レプリケーションの自動化
  • スケジュール設定、および追跡
• 利用手順
  1. AWS Connector for vCenterと呼ばれるコネクターを移行対象となるオンプレミス環境のサーバーにインストール
  2. VMware vCenter から Amazon EC2 に移行する仮想マシンから EC2 インスタンスを起動
  3. GUIを使用してAWS Connector for vCenter を使用して仮想マシンを Amazon EC2 に移行
• AWS Server Migration Serviceの移行対象ソース
  • VMware vSphere
  • Microsoft Hyper-V / SCVMM仮想マシン

Application Discovery Service

• サーバーの設定データ、使用状況データ、動作データが収集されて、ユーザーに提供される
• 情報はAWSへの移行計画に使用

CloudWatch

• CloudWatch エージェントによって収集されたログは、処理されて Amazon CloudWatch Logs に格納
• CloudWatch Logs Insights
  • フルマネージドのサービス
  • 大量のログを数秒で走査し、インタラクティブなクエリの実行と可視化を提供
• CloudWatch Logs エージェント
  • CloudWatch エージェントの古いバージョン
  • CloudWatchエージェントを利用することが推奨
• CloudWatchから複数リージョンのメトリクス情報を確認する方法
  • 1 つの CloudWatch ダッシュボードを使用して複数のリージョンにある AWS リソースをモニタリング可能
  • CloudWatchの設定手順
    1. https://console.aws.amazon.com/cloudwatch/にある CloudWatch コンソールを開きます。
    2. ナビゲーションペインで メトリクスを選択します。
    3. ナビゲーションバーで、リージョンを選択します。
    4. ダッシュボードに追加するメトリクスを選択します。
    5. [アクション] で、[ダッシュボードに追加] を選択します。
    6. [追加] で、新しいダッシュボードの名前を入力し、[ダッシュボードに追加] を選択します。
    7. または、既存のダッシュボードに追加するには、[既存のダッシュボード] を選択し、ダッシュボードを選択して、[ダッシュボードに追加] を選択します。
    8. 別のリージョンからメトリクスを追加するには、次のリージョンを選択し、以下のステップを繰り返します。
    9. [ダッシュボードを保存] を選択します。
• CloudWatchメトリクス
  • SurgeQueueLength
    • 正常なインスタンスへのルーティングを保留中のリクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数
  • SpilloverCount
    • サージキューがいっぱいなため、拒否されたリクエストの総数
  • HealthyHostCount
    • ロードバランサーに登録された正常なインスタンスの数
  • UnHealthyHostCount
    • ロードバランサーに登録された異常なインスタンスの数
  • RequestCount
    • 指定された間隔 (1 分または 5 分) の間に完了したリクエストの数、または接続の数
• CloudWatch Metrics – PutMetricData API
  • 一度に複数のメトリクスデータポイントを挿入可能

CloudTrail

• CloudTrailの有効化
  • AWS Organizationsを利用してマスターアカウントのCloudTrailにおいて組織の証跡を有効化することで、全てのメンバーアカウントでのログ取得が可能になる
• CloudTrailのログ保存先
  • 複数の AWS アカウントのログファイルを 1 つの Amazon S3 バケットに配信するように CloudTrail を設定可能
• 複数人に対するアクセス許可の設定
  • IAMロールはそれを必要とする任意の人が引き受け可能
  • IAMユーザーは 1 人の特定の人に一意に関連付け
• CloudTrailのログからある操作を行ったユーザを特定する方法
  • userIdentityを確認
  • クロスアカウントロールを作成している場合はsharedEventIdも確認
• CloudTrail自体はログ出力のみであり、ログをトレースするような機能はない
  • トレースする場合はCloudWatch logsにログ転送してCloudWatch logs insightsの機能を使う

Config

• AWS Config カスタムルール
  • カスタムルール作成時はLambda関数との紐付けが必要

Managed Blockchain

• 招待方法
  • ブロックチェーンネットワークに他の AWS アカウントを招待するという提案を作成
  • そのネットワーク内の現在のメンバーがその提案に対して投票
  • ネットワークの投票ルールに基づいてその提案が承認された場合、その AWS アカウントはネットワークに参加するための招待状を受け取る
• 特徴
  • ネットワークの作成時に指定された投票ルールに応じて、等しい所有権の持ち分が複数の AWS アカウントに割り当て

その他

• 処理の並列化で使える機能
  • ELBとAuto Scalingグループ
  • SQS
  • Auroraマルチマスター構成
• AWSのサービスを活用した運用自動化の実装方法
  • Systems Manager Automationを利用 ※AWS SWFやStepFunctionsはアプリケーション構築で利用するサービス
  • AWS Systems Manager コンソールを使用して、自動化の進捗状況および実行の詳細を監視
  • インスタンスのメトリクスとログを収集するには、SSM エージェント を使用する代わりに、Amazon CloudWatch エージェント を設定して使用可能（CloudWatchエージェントの方がAmazon EC2 インスタンスのメトリクスを多く収集可能）
  • エージェントから取得した情報はCloudWatchイベントを使用して通知を受け取る
• AWSのメッセージングサービス
  • Amazon MQ：OnPでActiveMQを使っていてAWSへ移行する場合に利用
  • Amazon SQS：キューを使うことでサービス間のメッセージングを非同期に行う
  • Amazon SNS：プッシュ通知など（キューイングしない？）
• SAML メタデータドキュメントのやり取りはSAML2.0 フェデレーションの初期設定で必要
  • 設定後の認証フローでは実行されない
  • 認証フローではIDプロバイダー（IdP）とアプリケーションの間でIDおよびセキュリティ情報を交換（参考）
• 外部のユーザへメール通知する場合はSESを利用
  • SNSはIAMユーザーなどの内部ユーザーやリソース間の通知に利用する機能
• 暗号化の実行場所
  • SSE：S3などサーバーサイドで暗号化
  • CSE：クライアントサイドで暗号化
  • ハイフンの後ろは鍵の管理場所を示す
    • ex) SSE-S3：S3側で鍵を管理
• AWSの各種ブロックチェーンサービス
  • Amazon QLDB
  • Amazon Managed Blockchain
  • AWS Blockchain Templates
  • AWS ブロックチェーンパートナー
• タスクに優先度を作ることのできるサービス
  • Step Functions
  • SWF
  • AWS Batch
  • SQSはキューに優先度をつけられるが、あくまでもキュー処理のみでその後のタスクに対する優先度付けは不可

Oracle Cloud InfrastructureとAWS / Azureとのサービスマッピング資料

AWS / Azureにある各種サービスとOracle Cloud Infrastructure（以下OCI）の各種サービスとの対応付けを整理したサイトが出来てます。
もしAWS / AzureからOCIへの移行やマルチクラウドをご検討の際はご参照ください。

OCI vs AWS

日本語版
Amazon Web Servicesのプロフェッショナル向けのOracle Cloud Infrastructure

英語版
Oracle Cloud Infrastructure for Amazon Web Services professionals

OCI vs Azure

日本語版
Oracle Cloud Infrastructure for Microsoft Azureのプロフェッショナル

英語版
Oracle Cloud Infrastructure for Microsoft Azure professionals

AWS Solutions Architect Associate 合格体験記

先日AWS Solutions Architect Associate (AWS SAA) を受験して合格しました。
合格を目指している方の参考までに、自分は以下の流れで勉強しました。

• ｢最短突破　AWS認定ソリューションアーキテクト　アソシエイト　合格教本」を通読
• ｢最短突破　AWS認定ソリューションアーキテクト　アソシエイト　合格教本」の巻末にある模擬問題を実施
• 日を置いて模擬問題で間違えた個所を復習
• AWS公式の模擬試験 (2,000円) を実施
• 一問ずつ調べながら公式模擬試験の正誤を確認
• 日を置いて公式模擬試験の間違えた個所を復習
• 参考書の模擬問題と公式模擬試験の間違えた個所を再度復習

これで820点を取って合格しました (720/1000がボーダーライン)。
今後はAWS Solutions Architect Professionalの取得を目指したいです。
そのためにも実際にAWSの各サービスに触りつつ、
ブログ等で最新情報をチェックして勉強に励みたいと思っています！

パブリックサブネットとプライベートサブネットについてAWSとOCIを比較してみた

OCI (Oracle Cloud Infrastructure) の勉強をしてから
AWSの勉強をしてるのですが、サブネットの扱い、
とりわけパブリック/プライベートの扱いが違っていて混乱。。
ということで簡単に整理してみました。

OCI

• Virtual Cloud Network (VCN) 内にサブネットを作成
• サブネットは以下の通りパブリック/プライベートが存在
  • パブリックサブネット：デフォルト設定でサブネット作成
  • プライベートサブネット：プライベートサブネットの設定を入れることで作成
• プライベートサブネットに所属するインスタンスはパブリックIPを持つことが出来ない

AWS

• Virtual Private Cloud (VPC) 内にサブネットを作成
• サブネットは以下の通りパブリック/プライベートが存在
  • パブリックサブネット：ルートテーブルにインターネットGW (0.0.0.0/0) に対するルートがある
  • プライベートサブネット：ルートテーブルにインターネットGW (0.0.0.0/0) に対するルートがない
• プライベートサブネットに所属するインスタンスであってもパブリックIPを持つことが出来る

これからはマルチクラウド前提のシステムが多くなりそうなので
複数のクラウドサービスについて知っておかないといけませんが、
こうしたささいな違いがあると混乱してきますね。。。

EC2+DockerでJupyter Notebookを動かす part2

前回はEC2インスタンスを作成し、Dockerをインストールしました。
今回はJupyter NotebookをDocker上で動かし、
EC2インスタンスのネットワーク設定をいじることで
外部からJupyter Notebookへアクセスできるようにします。

Jupyter NotebookのDockerイメージ取得・起動

まずはJupyter NotebookのDockerイメージを取得します。

docker pull jupyter/datascience-notebook

Jupyter Notebookのイメージ取得ができたことを確認します。

docker images jupyter/datascience-notebook

REPOSITORY                     TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
jupyter/datascience-notebook   latest              91f5bc10a994        36 hours ago        6.828 GB

イメージの取得ができたら、あとはDockerイメージを起動します。

docker run -it --name notebook -p 80:8888 jupyter/datascience-notebook

上記コマンドを実行するとJupyter Notebookにアクセスするための
トークンが標準出力されますので、それを使ってアクセスします。
その後は”Ctrl-p -> Ctrl-q”でイメージ内からログアウトし、
ターミナル等を閉じても稼働し続けるようにします。

EC2インスタンスのNW設定

次にEC2インスタンスのネットワーク設定を下記の手順で行います。

1. サイドメニューの「セキュリティグループ」を押下
2. Jupyter Notebookが稼働しているEC2インスタンスの
   セキュリティグループを選択
3. 下ウィンドウの「インバウンド」タブを選択
4. 編集ボタンを押下
5. ｢インバウンドルールの編集」画面で「ルールの追加」を押下
6. 以下の入力内容でルールを追加
   • タイプ｜HTTP
   • プロトコル｜TCP
   • ポート範囲｜80
   • 送信元｜カスタム、0.0.0.0/0
7. ｢保存」ボタンを押下

以上の設定をすると、EC2インスタンスのグローバルIPを指定すれば
任意のIPからJupyter Notebookにアクセスできます。

これで家からはもちろん、出先や会社からでも
手軽にデータ分析ができますね！

EC2+DockerでJupyter Notebookを動かす

はじめに

先週は更新が滞ってしまいましたが、今週は頑張ります。
以前の記事でJupyter Notebookの導入と使用感について触れました。

今回はAWS上のEC2インスタンスにDockerをインストールし、
Dockerイメージを使ってJupyter Notebookをたてようと思います。
またEC2のNW設定をいじり、
どこからでもJupyter Notebookにアクセスできるようにします。

EC2インスタンスの作成

AWSを触ったことのある方ならよくご存知とは思いますが、
一応EC2インスタンス作成から辿っていきます。

AWSにログインし、ダッシュボードからEC2を選択します。

インスタンス作成ボタンを押下します。

今回はAmazon Linuxをマシンイメージとして選択します。

あとはスペック等の設定をしていきますが、
今回は無料枠内での利用となるので
以下の設定意外はデフォルトで作成しました。

• インスタンスタイプ｜t2.micro
• ストレージ｜30GB

だいたい2、3分ほどでインスタンスができ、
SSH接続も可能となります。
サイドメニューのインスタンスをクリックすると、
作成したEC2インスタンスの一覧を確認できます。

EC2インスタンスへDockerをインストール

さて、EC2インスタンスができましたので、
Dockerをインストールしていきます。

インスタンス作成時に登録した公開鍵のペアとなる秘密鍵を用い、
“ec2-user”というユーザでインスタンスにSSH接続します。

まずはアップデートをかけます。

[root]# yum -y update

Dockerをインストールするために
EPELリポジトリを追加します。

[root]# wget http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root]# rpm -ivh epel-release-6-8.noarch.rpm

Dockerをインストールします。

[root]# yum -y --enablerepo=epel install docker-io

Dockerのサービスを起動します。

[root]# service docker start

以上でEC2インスタンスの作成とDockerのインストールが出来ました。
次回はJupyter NotebookのDockerイメージをEC2上で動かし、
EC2のNW設定をすることで
ブラウザからJupyter Notebookへアクセスできるようにします。