AWS ソリューションアーキテクト（SAA）の勉強ノート

書き置き

• Udemyの「AWSソリューションアーキテクトアソシエイト短期突破講座」をもとに作成。

S3

• 利用コストはリージョンによって価格が異なる。
• ライフサイクル設定
  • バケット全体やPrefixに設定する。
  • 最大1000ルールが設定できる。
  • MFA Deleteが有効だと設定不可になる。
• アクセス管理
  • IAMユーザーポリシー
    • IAMユーザーに対して権限を設定する。
  • バケットポリシー
    • JSONで設定する。
    • 外部ユーザーも含めて管理ができる。
  • ACL
    • XMLで設定する。
    • オブジェクトに個別に設定可能。
  • 署名付きURL
    • アカウントAの所有するバケットに対して、アカウントBがアクセスする許可を与えられる。
    • SDKで生成した権限URLを一定期間付与する。
    • 第三者が閲覧することができる。
• クロスアカウントアクセス
• S3アクセスポイント
  • アクセス先に応じてアクセスポイントを作成して、ポリシーを適用しアクセス設定が可能になる。
• 静的WEBホスティング
  • メリット
    • サーバーなしにWEBサイトをホスティングできる。
    • マルチAZの冗長化を勝手にしてくれる。
    • Route53で独自ドメインを設定できる。
    • CloudFrontによって配信可能。
  • デメリット
    • サーバースクリプト言語を実行する動的サイトは利用不可。
    • 単独ではSSLを利用できないので、CloudFrontが必要。
  • WEBサイトエンドポイント
    • http://bucket-name.s3-website-region.amazonaws.com
    • http://bucket-name.s3-website.region.amazonaws.com
  • クロスオリジンリソースシェアリング（CORS）
    • 1つのWEBサイトを複数ドメインで共有して利用できる。
• 整合性モデル
  • 新規登録
    • 登録後即時にデータが反映される。
  • 更新
    • 2020/12より強い整合性モデルに変更された。
    • 齟齬は発生しない。
  • 削除
    • 2020/12より強い整合性モデルに変更された。
    • 齟齬は発生しない。
  • アップロード時のデータ整合性確認
    • オブジェクトのbase64でエンコードされたMDSチェックサム値を取得する。
    • アップロード中のオブジェクトの整合性を確認する。
    • 但し、アップロードがAWS署名Ver4でされている場合は、x-amz-content-sha256ヘッダを使用する必要がある。
  • マルチパートアップロード
    • 大容量オブジェクトをいくつかに分けてアップロードする。
• Glacier
  • 構成要素
    • ボールト
      • アーカイブ（S3のオブジェクトに相当し、各アーカイブには138バイトのランダムなIDが自動で割り当てられる）を保存するための領域。S3のバケットに相当する。
    • インベントリ
      • 各ボールトに保存されているアーカイブの情報を収集する。およそ1日1回の頻度で更新されるため最新情報の反映にはタイムラグが発生する。
      • リアタイで確認したい場合は、マネジメントコンソールから確認するか、ListVaults APIを実行する。
    • ジョブ
      • アーカイブやインベントリに対して検索をかけたり、データをダウンロードするといった要求に対して処理を実行し、処理状況を管理する。
  • 取り出しオプション
    • 高速、標準、バルクの三種類の取り出しオプションがあり、翌日に見られれば十分と言った場合はバルクオプションを利用すると良い。
  • Glacier Select
    • アーカイブデータに対してSQLを実行し、条件にあったデータを抽出できる。

EC2

• 利用コストはインスタンスを停止することで課金を抑えられる
  • 開始 / 再起動（Running）
    • 実行時間に応じて料金が発生する
    • 利用中のEBSボリュームの料金が発生する
  • 停止（Stop）
    • EC2の利用料金は停止する
    • 利用中のEBSボリュームの料金が発生する
  • 終了（Terminate）
    • EC2の利用料金は停止する
    • デフォルトではルートボリュームに設定されたEBSボリュームも削除され、料金発生は停止する
• AMI
  • EC2のバックアップとして構成内容を保存する（EBSボリュームのスナップショットも含まれる）
  • 最適なEC2インスタンスの構成を反映したAMI（＝ゴールデンイメージ）を複数利用できる
  • AMIの共有は、アカウント番号を指定するだけで、ほかアカウントに共有可能
  • AMIはリージョン内でのみ利用可能。別リージョンにコピーして別AMIとして利用可能。
• キーペア
  • ユーザーがPCにダウンロードした秘密鍵を使って、EC2インスタンスの公開鍵とマッチさせる
  • 1つのVPCにおいて最大5000個発行可能
• EC2フリート
  • オンデマンドインスタンスとスポットインスタンスで構成されるインスタンスグループとして設定を定義する仕組み
• スポットフリート
  • インスタンスタイプや入札価格を指定することで、自動で最安値のインスタンスを選択して起動する
• スポットブロック
  • メリット
    • 最大６時間まで中断することがない
    • 途中で中断する可能性があるスポットインスタンスの利用を安定させる
    • スポットフリートのオプションとして設定可能
  • デメリット
    • 通常のスポットインスタンスよりも値段が若干高くなるため最安値ではなくなる。
• プレイスメントグループ
  • 単一のAZ内のインスタンスのパフォーマンスを向上させるために論理的にグループ化する機能
    • クラスタープレイスメントグループ
      • 単一AZ内のインスタンスを論理的にグループ化した構成
      • 同じリージョン内の複数ピアVPCにまたがることができる
      • グループ内のインスタンスはTCP/IPトラフィックのフローあたりのスループット上限が高くなり、ネットワークの2分帯域幅の広い同じセグメントに配置されインスタンス間通信が向上する
      • 低いネットワークレイテンシー、高いネットワークスループットを実現するアプリケーション向けの構成
    • パーティションプレイスメントグループ
      • EC2は各グループをパーティションと呼ばれる論理的なセグメントに分割した構成
      • プレイスメントグループ内の各パーティションにそれぞれ一連のラックがあり、プレイスメントグループ内のパーティション同士が同じラックを共有しない
      • ラックを分離することで、アプリケーション内でのハードウェア障害による影響を隔離して軽減する
    • スプレッドプレイスメントグループ
      • それぞれ独自にネットワーク及び電源がある異なるラックに別々に配置できるインスタンスのグループ
      • 1つのAZ内のスプレッドプレイスメントグループに配置された7つのインスタンスは、7つの異なるラックに配置される
      • 少数の重要なインスタンスが互いに分離して保持できる。インスタンスが同じラックを共有する時に発生する可能性のある同時障害リスクを軽減する
• EC2のリカバリー
  • 定期的にバックアップ（IAM/スナップショット）を取得する
  • 定期的にリカバリプロセスを確認する
  • 複数のAZに重要なアプリケーションをデプロイする
  • CWによりインスタンスのステータスをモニタリングする
    • チェック結果が失敗の場合はCWアラームアクションを使用してインスタンスを自動的に復旧
    • 自動復旧後のステータスとIPアドレスは元のインスタンスと同じ
  • インスタンス起動じに動的IPアドレス処理の設定を行う
• ハイバネーションを利用し、再起動時に停止前の状態を維持する
  • シャットダウン前にメインメモリの内容をハードディスクなどに退避することで、次回起動時にまたメインメモリに読み込み、シャットダウンする前と同じ状態で起動する
  • インスタンスタイプに応じてハイバネーションの実施可否が決まる
    • 現在では、M3~M5, C3~C5, R3~R5に加えて、Amazon Linux2 や WIndowsなども対応している

VPC

• CIDR（Classless Inter-Domain Routing）と呼ばれる、サブネットマスクの値を設定し、同じネットワークとして扱うIPアドレスの個数を調整できるIPアドレスの設定方法で表現する

• /16を設定した際に設定可能なサブネット数とIPアドレス数の組み合わせ
  

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

  • パブリックサブネットからインターネットに接続するにはインターネットゲートウェイが必要
  • ルートテーブルによりインターネットゲートウェイへのルートを確立する

• NATゲートウェイ

  • プライベートサブネットからインタネットに接続するにはNATゲートウェイがパブリックサブネットに必要
  • ルートテーブルによりインターネットゲートウェイへのルートを確立する
  • AWSマネージドサービスのため冗長性が高く、管理が楽

• NATインスタンス

  • ユーザーが管理するサービス

• VPCエンドポイント

  • グローバルIPを持つAWSサービスに対し、VPC内から直接アクセスするための出口
    • ゲートウェイ型エンドポイント
      • AWSサービスをあて先とするトラフィックのルートテーブルのあて先として指定できるゲートウェイ
      • DynamoとS3にのみ適用可能
      • ゲートウェイ型はサブネットに特殊なルーティングを設定し、VPC内部から直接外のサービスと通信する
      • 無料で利用でき、AWS側で冗長性を確保するマネージドサービス
    • プライベートリンク型エンドポイント（インターフェイス型）
      • AWSサービスをあて先とするトラフィックのエントリポイントとして機能するサブネットのIPアドレス範囲のプライベートIPアドレスを持つElastic Network Interface
      • プライベートIPアドレスを使用してサービスにプライベートアクセスする
      • RDSやEC2などの多くのサービスに適用可能
      • 有料で利用できるマルチAZ設計により冗長性を担保する

• VPC Peering

  • 2つのVPC間でのトラフィックルーティングが可能
  • AWSアカウントを跨いで接続することが可能

• セキュリティグループ

  • サーバー単位で適用できる
  • ステートフルのため、インバウンドのみ設定すればアウトバウンドも許可される（＝状態を維持する）
  • 全てのルールを適用する
  • デフォルトでは同じSG内通信のみ許可する設定になっている
  • 許可のみをIN/OUTで指定するホワイトリスト形式

• ネットワークACL

  • VPC/サブネット単位で適用できる
  • ステートレスのため、インバウンド設定だけではアウトバウンドは許可されない
  • 番号順に適用していく
  • デフォルトでは全ての通信を許可する設定になっている
  • 許可と拒否をIN/OUTで指定するブラックリスト形式

• VPCフローログ

  • ネットワークトラフィックを取得し、CWでモニタリングできるようにする機能
  • VPC内の通信の解析に使用する
  • 追加料金は発生しない

• VPCにおけるDNSの使用

  • enableDnsHostname
    • パブリックIPアドレスを持つインスタンスが、対応するパブリックDBSホスト名を取得するかどうかを示す
    • この属性がtrueでenableDnsSupport属性もtrueである場合、VPC内のインスタンスはDNSホスト名を取得できる
  • enableDnsSupport
    • DNS解決がサポートされているかを示す
      • この属性がfalseの場合、パブリックDNSホスト名をIPアドレスに解決するRoute53 Resolverサーバーが機能しない
      • この属性がtrueの場合、DNSサーバー（169.254.169.253）へのクエリ、またはリザーブドIPアドレス（VPCIPv4ネットワークの範囲に+2したアドレス）へのクエリは成功する

• ENI（Elastic Network Interface）

  • 仮想ネットワークカードを表すVPC内の論理ネットワーキングコンポーネント。

• インスタンスへのIPアドレス割り当て時に利用する

AutoScaling

• スケーリングポリシーの設定
  • ターゲット追跡スケーリングポリシー（簡易スケーリングポリシー）
    • CWのモニタリングメトリクスを利用したスケーリングを実施できる
• ライフサイクルフック
  • AutoScalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行することができる
  • Lambdaと連携した処理も可能

RDS

• ストレージタイプ
  • 汎用タイプ
    • SSDタイプ
    • GBあたりの容量課金を実施
    • 通常のパフォーマンスに加えてバーストを実施し、100~30,000IOPSを実現可能
  • プロビジョンドIOPS
    • SSDタイプ
    • GBあたりの容量課金を実施＋プロビジョンド済みIOPS単位の課金
    • 通常のパフォーマンスに加えてバーストを実施し、1,000~30,000IOPSを実現可能
  • マグネティック（古いタイプ）
    • ハードディスク
    • GBあたりの容量課金を実施＋　IOリクエスト課金
    • 平均100~最大数百のIOPS
• 冗長化構成
  • パブリックアクセス構成
    • パブリックサブネットにRDSを設置し、直接SQLクライアントツールで接続して操作する（MySQLの場合はWorkbenchがよく使われる）
  • 一般的な構成
    • RDSをプライベートサブネットに設置して、EC2インスタンスを踏み台にしてアクセスする
    • ただし、AZ障害が発生した場合、対応できない
      • マルチAZ構成により、非常に簡単にフェールオーバーが利用可能となる。
        • ゲールオーバー時にCNAMEレコードがプライマリからセカンダリに移行する
  • リードレプリカ
    • 参照専用のレプリカを最大5台（AUuroraは15台）設置し、DBの読み取り処理をスケールアウトできる
• RDSのスケーリング
  • インスタンスサイズの変更
  • インスタンスタイプの変更
  • ストレージタイプの変更がある。
    • AutoScallingで容量が増加できるが、減少させることはできない。（RDSのAutoScallingはパフォーマンス性能向上ではなく、容量アップによって実行される）
• RDSの暗号化
  • インスタンス作成時のみ暗号化を設定可能（後からする場合はスナップショットを取得してから再構築する際に設定することで暗号化できる）
  • 通信の暗号化
    • SSL/TLSを使用して、DBインスタンスへの接続を暗号化する
  • 保管データの暗号化
    • 保管時のデータリソースを暗号化する

EBS

• EC2インスタンスとともに利用されるブロックストレージ
• 1つのEBSを複数のインスタンスで共有することはできない
• 同じAZ内のインスタンスのみ付け替え可能（他のインスタンスに付け替え可能）

ELB

• ALB
  • レイヤー7で実行される
  • 単一ロードバランサで異なるアプリケーションへリクエストをルーティングが可能
  • 1つのインスタンスに複数ポートを登録可能
  • 加重ロードバランシングが利用可能
• NLB
  • レイヤー4で実行される
  • 超低遅延で高スループットを維持しながら秒間何百万リクエストを捌くように設計された高性能ロードバランサ
  • 事前申請が不要
• ELBの主要機能
  • ヘルスチェック機能
  • 配下のEC2の負荷に応じて、複数AZにまたがるEC2インスタンスに均等に負荷分散を行うクロスゾーン負荷分散
  • 暗号化通信
  • セッション中に同じユーザーからきたリクエストを継続して同じEC2インスタンスに送信するスティッキーセッション
  • インスタンスが登録解除されるか、以上が発生した場合に、そのバックエンドインスタンスへの新規リクエスト送信を中止するConnection Draining
  • ログ取得

SQS

• ポーリング処理（一旦中継に通信内容をためておき受信側のタイミングが良い時に通信を行う）型のキューイングサービスでタスクの並列実施などに利用される
• 疎結合アーキテクチャを実現可能
• 主要機能
  • 標準キューでは通信順序は保証されないが、FIFOキューを採用すると順番を保証できる
  • 優先キューは他のキューよりも優先的に処理させることが可能
  • メッセージ保持期間中はメッセージを保持するが、超過するとメッセージを削除する
    • デフォルトでは４日間（最小60秒〜最大14日で設定可能）
    • アプリケーション上でメッセージを削除する処理を実施しないと期間を超過するまでキューが滞留してしまう
  • 発行したメッセージは取り消し不可
  • 配信ポリシーによるキューの再試行を実施することができる
  • 無制限にメッセージを利用することができるが、メッセージサイズは最大256KBとなっている
• 可視性タイムアウト
  • 処理担当のインスタンス以外からは一定時間（30秒〜12時間）キューが見えなくなる機能
  • 他のインスタンスが同じメッセージを再処理しないように可視性タイムアウトを設定することで、重複処理を防ぐことができる
• ポーリング方式
  • ロングポーリング
    • 問い合わせの結果が空であった場合に、指定したメッセージ受信待機時間の間、SQSが待機してから応答を返す
    • 空のレスポンス数を削減することができる
  • ショートポーリング
    • キューが空の場合に、すぐに空のメッセージが返される
• キューの詳細設定
  • 遅延キュー
    • キューへの新しいメッセージの配信を数秒遅延させることができる（0秒〜15分）
    • 可視性タイムアウトとの違いは、キューが発行された直後から見えなくなり、キュー全体に効果がある
  • 優先度付きキュー
    • キューの処理順序に優先度をつけ、優先対応があるタスクを最初に処理するようにワークフローを設定できる
  • デッドレターキュー
    • 正常に処理（消化）できないメッセージを別のキューへ移動させ、処理不能なキューの滞留を防げるほか、処理できなかった原因を後で解析できる

CloudFront

• CDN（Content Delivery Network）サービスとして、WEBコンテンツなどを配信する際に主にエッジサーバーとして使われる
• 210以上のエッジロケーションによる高性能な分散配信
• WAFやCertificate Managerとの連携やDDoS対策によるセキュリティ機能を持つ
• オリジンに対してHeader, Cookie, Query Stringによるフォワード指定で動的なページ配信が可能
• Gzip圧縮機能
  • エッジ側でコンテンツをGZIP圧縮してより高速に配信可能となる

DynamoDB

• キーバリュー型（ワイドカラム型）によりデータを簡易に操作できる
• できること
  • キーに対するバリューのCRUD操作
  • 簡易なクエリやオーダー
• できないこと・向いていないこと
  • JOIN, TRANSACTION, COMMIT, ROLLBACKは不可
  • 詳細なクエリやオーダー（データ検索や結合処理など）は向いていない
  • 大量のデータ読み書きにはコストがかかる
• 整合性モデル
  • 書き（Wriite）
    • 少なくとも2つのAZで書き込み完了が取れた時点で完了
  • 読み（Read）
    • デフォルトでは結果整合性モデルが採用され、最新の読み取り処理が反映されない場合がある
    • オプションで、強い整合性モデルが選択でき、GetItem, Query, Scan では強い整合性のある読み込みオプションが指定可能
• キャパシティモード
  • オンデマンドモード
  • プロビジョニングモード
• プライマリキー
  • ハッシュキー
    • データを特定するためのIDなどのこと
    • 単独での重複を許さない
  • レンジキー
  • ハッシュキーにレンジを加えたもの。複合キーとも呼ぶ。
  • 2つの値の組み合わせによって、1つの項目を特定する
  • 複合キーは単独であれば重複が許される
• DynamoDBストリーム
  • Dynamoテーブルに保存された項目の追加/変更/削除の発生時の履歴をキャプチャできる機能
    • データ保存
      • 過去24時間以内のデータ変更履歴を保存し、24時間経過すると消去される
      • データ容量はマネージド型で自動的に管理される
    • データ保存の順番
      • 捜査が実施された順番に応じてデータがシリアライズされる
• DAX（DynamoDB Accelerator）
  • DynamoDBにインメモリキャッシュ型の機能を付加する

Lambda

• リクエスト数とコードの実行期間で算出されて課金される
• Lambdaの制限
  • 関数のタイムアウトはデフォルトで3秒、許容最大数は900秒（15分）。タイムアウトに達すると関数が停止される
  • 最大同時実行数はデフォルトで100（最大は1000だが、申請によって数十万まで引き上げ可能）
  • 関数の実行時に使用できるメモリは128MB〜3008MBと制限されている
  • /tmpディレクトリのストレージは512MBまでとされている
  • Lambdaレイヤー（共通処理関数）は最大5妻で設定可能
• Lambdaエッジ（Lambda@Edge）
  • CloudFrontの配信コンテンツをLambda関数によってエッジロケーションで処理することが可能

Route53

• IPアドレスを人間が読みやすいURLに変換して住所として利用できるようにしてくれるDNSサーバーの役割を提供する
  • https://www.yahoo.co.jp/ → DNS → https://196.10.0.1 というように、IPアドレスに変換するのがDNS
• ポート53で動作するため、Route53と呼ばれる
• エイリアスレコードタイプ
  • A
    • ホスト名とIPv4アドレスの関連づけを定義するレコード
  • MX
    • メールの配送先（メールサーバー）のホスト名を定義するレコード
  • CNAME
    • 正規ホスト名に対する別名を定義するレコード
    • 特定のホスト名を別のドメイン名に転送する時などに利用する
• ルーティングポリシー
  • シンプルルーティング
    • レコードセットで事前に設定された値のみに基づいてDNSクエリに応答する
    • 特殊なルーティングポリシーを使わない標準的な1対1のルーティング
  • 加重ルーティング
    • 複数エンドポイントごとの重み設定によりDNSクエリに応答する
    • 指定した比率で複数リソースにトラフィックをルーティングする際に使用する
    • ABテスト（AパターンとBパターンを比べて修正後のBがどの程度の成果が出るかを検証するテスト）のために新サービスをリリースしたサーバーに一定割合のユーザーを誘導したい場合にも利用できる
  • フェイルオーバールーティング
    • ヘルスチェックの結果に基づいて、利用可能なリソースをDNSクエリに応答する
    • スタンバイ/アクティブ方式でアクティブ側のヘルスチェックが失敗したときにスタンバイ側のシステムへルーティングする
    • 本番システム稼働時にSorryサーバーのIPアドレスをセカンダリレコードに登録しておくと、自動的にSorryコンテンツを表示できる
  • 複数値回答ルーティング
    • ランダムに呼ばれた最大8つの別々のレコードを使用してIPアドレスを設定し複数値を返答する
    • 1つのレコードに異なる複数のIPアドレスを登録しておき、ランダムに返却されたIPアドレスに接続する
    • ヘルスチェックがNGとなったIPアドレスは返却されないため、正常に稼働しているサーバーに対してのみアクセスを分散させることができる
  • レイテンシールーティング
    • リージョンの遅延によりDNSクエリに応答する
    • 基本的にユーザー最寄りのリージョンに返答する
  • 位置情報ルーティング
    • ユーザーのIPアドレスにより位置情報を特定して、地位ごとに異なるレコードを返す
    • ネットワーク構成に依拠しない精度の高いレコードの区分けが可能
  • 地理的近接性ルーティング
    • ユーザーとリソースの場所に基づいて地理的近接性ルールを作成してトラフィックをリーティングする
    • 必要に応じてバイアスを設定し、特定のリソースにルーティングするトラフィック量を変更できる
    • トラフィックフローを利用する必要がある
• フェイルオーバー
  • リージョンを跨いで設定することができる
  • アクティブ/パッシブ方式
    • プライマリリソースをアクティブなリソースとしてルーティングする
    • 障害発生時、Route53はセカンダリリソースをルーティングする
    • フェイルオーバーポリシーを使用して設定する
  • アクティブ/アクティブ方式
    • 複数のリソースをアクティブとしてルーティングする
    • 障害発生時、正常なリソースにフェイルバックする
    • フェイルオーバー以外のルーティングポリシーを使用して設定する

Aurora

• RDBの一つだが、マルチクラスタ構成を採用している
• 従来のRDBは集中管理するものだが、クラウド時代の分散型のRDBとして誕生した
• 高い並列処理によるクエリを高速処理が実現できる
• 大量の書き込みや読み込みを同時に扱うことができる
• DBの集約やスループット向上が見込まれる
• MySQLとPostgreSQLと互換性があり、同じ操作方法で扱うことができる
• 耐障害性と自己回復性
  • 3つのAZに2つのコピーを設置可能で合計6つのコピーを保持する
  • 過去のデータがそのままS3に継続的にバックアップされる
  • リストアも差分適用がなく高速に処理できる
  • どのタイミングでも安定したリストアを実現できる
  • 99.99%の高可用性と高耐久性を持つ。
• スケーラビリティ
  • 10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張可能
  • 最大15のリードレプリカを利用した高速読み込みが可能

Elastic Beanstalk vs. OpsWorks

• Elastic Beanstalk
  • アプリケーションのデプロイ自動化
• OpsWorks
  • インフラの設定自動化

AWS Step Functions vs. SWF

• Step Functions（推奨）
  • ステートマシンをJSONで記述する
  • Lambdaと統合されたサーバレスアプリケーション
• SWF
  • JavaとRubyでコード記述できるが、複雑になりがちなため利用は推奨されていない
  • プロセスにおいて介入する外部信号が必要な場合、あるいは、結果を親に返す子プロセスを起動する場合はSWFを利用する

Snowball - Snowball Edge - Snowmobile

以上