徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略シリーズ

AWS

2021-05-04 12:54:31

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略シリーズ

  • 第1章 AWSサービス全体の概要
  • 第2章 AWSにおける高可用アーキテクチャ
  • 第3章 AWSにおけるパフォーマンス
  • 第4章 AWSにおけるセキュリティ設計
  • 第5章 AWSにおけるコスト最適化
  • 第6章 AWSにおける運用管理

第1章 AWSサービス全体の概要

  • AWS Well-Architectedフレームワーク
    • 運用上の優秀性
    • セキュリティ
    • 信頼性
    • パフォーマンス効率
    • コスト最適化
  • リージョン
    • 地理的に離れた領域のこと
  • AZ
    • リージョン内にある複数のデータセンターの集合体
  • 高可用性の実現
    • マルチAZ推奨
  • 災害対策(DR)サイト構築
    • マルチリージョン推奨
  • AWSサービスの範囲
    • グローバルサービス
      • リージョンに依存しない共通サービス
      • DR構築時に考慮が不要
      • ex. IAM, CloudFront, Route53, etc.
    • リージョンサービス
      • 特定のリージョン内でのみ利用するサービス
      • ex. VPC, DynamoDB, Lamda, etc.
    • アベイラビリティゾーンサービス
      • 特定のAZ内で利用するサービス
      • DR構築時にマルチAZまたはマルチリージョンを検討する必要がある
      • ex. EC2, RDS, etc.
  • IAM
    • IAMユーザーおよびIAMグループは作成直後は権限が付与されていない
  • VPC
    • IPv4のVPC
      • プライベートIPアドレスの範囲内で、16ビット以上28ビット以内のCIDRを指定する必要がある
    • IPv6のVPC
      • 56ビットのCIDRに固定されている
  • サブネット
    • VPC内に構成するネットワークセグメント
    • 作成時にどのAZで構成するか指定する
    • 1つのVPCに対して複数作成することができるが、VPCのIPアドレス範囲内でのCIDRを設定する必要がある
    • パブリックサブネット
      • ルートテーブル内のデフォルトゲートウェイ(0.0.0.0/0)へのルーティングにインターネットゲートウェイを指定したサブネット
    • プライベートサブネット
      • ルートテーブル内のデフォルトゲートウェイ(0.0.0.0/0)へのルーティングにインターネットゲートウェイを指定していないサブネット
  • インターネットゲートウェイ
    • VPC内のリソースからインターネットへとアクセスするためのゲートウェイ
  • ルートテーブル
    • サブネット内のEC2インスタンスに対する静的ルーティングを定義するもの
    • 設定はサブネット単位で行う
    • VPC内の通信
      • デフォルトでルートテーブルにlocalが定義されている
      • 同じVPC内にあるサブネット間で相互通信が可能
        • 異なるVPC内のAZに作成されたサブネット間も含む
  • セキュリティグループ
    • EC2インスタンスなどに適用するファイアウォール機能
    • デフォルトでは、アウトバウンドはすべて許可、インバウンドはすべて拒否
    • ステートフル
  • ネットワークACL
    • サブネット単位で設定するファイアウォール機能
    • ステートレス
  • VPCエンドポイント
    • ゲートウェイ型
      • ルートテーブルに指定されたターゲットを追加することでAWSの各種サービスへプライベート接続することができる
    • インターフェース型
      • AWS PrivateLinkとも呼ばれる
      • AWSの各種サービスのAPIコールに対して、インターネットを経由せずにプライベート接続することができる
  • ELB
    • Auto Scaling
      • 事前に設定したAMIからEC2インスタンスを起動
        • AMIを常に最新化しておくことが重要
  • Route53
    • ホストゾーン設定
      • パブリックホストゾーン
        • 外部向けDNS
      • プライベートホストゾーン
        • VPC内DNS
  • Elastic IP
    • EC2インスタンスにアタッチされていない場合や、アタッチされているEC2インスタンスが停止中の場合は時間単位の料金が発生
  • AMI
    • EC2インスタンスを作成する際に使用する仮想マシンイメージで、EBSのスナップショットとEC2インスタンスの構成情報から成り立つ
    • EBS-Backedインスタンス
      • EBSをOSのルート領域として利用したインスタンス
      • 不揮発性
      • EC2インスタンス停止後もデータを永続化することができる
    • Instance Store-Backedインスタンス
      • インスタンスストアをOSのルート領域として利用するインスタンス
      • 揮発性
      • EC2インスタンス停止後はデータが削除される
  • インスタンスメタデータ
    • EC2インスタンス自身に関するデータ
    • 実行中のインスタンスを設定または管理するために利用される
    • ex. インスタンスID, プライベートIPv4アドレス, パブリックIPv4アドレス, ローカルホスト名, 公開鍵, etc.
  • S3
    • S3に保存したオブジェクト
      • デフォルトで同一リージョン内の3箇所のAZへ自動的に複製される
  • EBS
    • スナップショットによるバックアップ
      • 初回はフルバックアップ, 以後は増分
  • インスタンスストア(エフェメラルディスク)
    • 特定のEC2のインスタンスタイプで利用することができる無料のストレージサービス
    • ホストコンピューターのローカル領域を使用するため高パフォーマンス
    • 揮発性
  • AWS Storage Gatewary
    • S3へNFS、SMB、iSCSIなどの標準プロトコルでアクセスできるサービス
      • iSCSI(Internet Small Computer System Interface)
        • データ転送にTCP/IPを使用するしくみ
        • ネットワーク上のストレージに直接接続できるメリットがある
    • EC2インスタンスだけでなく、オンプレミスサーバーにS3をマウントして利用することもできる
    • キャッシュ型ボリュームゲートウェイ
      • データはS3に格納、アクセス頻度の高いデータはローカルにキャッシュ
      • インターフェースはiSCSI
    • 保管型ボリュームゲートウェイ
      • データをスナップショットとしてS3に格納する
      • インターフェースにはiSCSI
    • テープゲートウェイ
      • 物理テープ装置の代替としてS3(Gracier)に格納
      • インターフェースにはiSCSI
    • ファイルゲートウェイ
      • データをオブジェクトとして、直接S3に格納する
      • インターフェースにはNFS

第2章 AWSにおける高可用アーキテクチャ

  • 可用性
    • システムが正常に継続して動作し続ける能力
    • 指標として「稼働率」が使われる
    • 稼働率と年間停止時間
      • 99% 3日15時間36分
      • 99.90% 8時間46分
      • 99.95% 4時間23分
      • 99.99% 52分34秒
  • フェイルオーバー
    • 稼働中のサーバーで障害のため正常動作しなくなった時に、待機している別のサーバーに自動的に切り替える仕組み
  • SLA(Service Level Agreement)
    • サービス提供者と利用者の間で結ばれる品質基準のこと
  • Design for Failure
    • 障害発生を前提としたシステム構築
  • VPC
    • 複数のAZでサブネットを構成する
      • データセンターレベルの障害や特定地域の自然災害などに対応するため
    • サブネットはパブリックサブネットとプライベートサブネットを構成
      • ネットワーク・セキュリティの境界を明確にするため
      • パブリックサブネットが存在するためにはIGW(インターネットゲートウェイ)が必要
        • IGWはELBと同じくAWS内部で冗長化されているので複数作成する必要はない
    • IPアドレス設計
      • 将来利用予定のIPアドレスを見越しておく
  • Route53
    • ALIASレコード
      • Route53独自のDNS機能
      • ELBやCloudFrontのエンドポイントをCNAMEレコードではなくAレコードとして指定することができる
  • Direct Connect
    • 占有型
      • 物理接続に対して契約するため、ユーザー側で自由に論理接続を作成することができる
    • 共有型
      • 物理接続をキャリアが保有しており、論理接続単位での契約が必要になる
  • IGW(インターネットゲートウェイ)
    • AWS内部で透過的に冗長化されている
    • 1つのIGWを1箇所のVPCで利用する
    • ある一つのAZで障害が発生してももう一方のAZで利用する通信には影響がない
  • NATゲートウェイ
    • AZ内では冗長化されているが、AZ間の冗長化はされていない
  • DR(Disaster Recovery)サイトの構築
    • それぞれのリージョンでVPCを作成
    • 各リージョンのデータをコピーしたりする場合は、VPCピアリングを使ってVPC間の接続をプライベートに行う
  • EBS
    • 複数のEC2インスタンスからアクセスする共有ディスクとして使用できない
    • データベースをEC2で利用する場合は、2台のデータベース間を同期したり、EFSなどの共有ストレージサービスを利用するなどの工夫が必要
  • RDS
    • シングルAZのRDSに障害が発生した場合
      • 障害発生時に自動的に再起動する機能がある
        • 再起動中はダウンタイムが発生する
    • マルチAZのRDSに障害が発生した場合
      • マスターのRDSデータベースインスタンスに障害が発生した場合、自動的にスタンバイへフェイルオーバーを行う
        • スタンバイのRDSデータベースインスタンスがマスターに昇格
        • マスターで利用していたRDSレコードをスタンバイのDNSレコードへ切り替える
          • RDSのエンドポイント変更が不要
        • データはマスターとスタンバイで常に同期されているため、リカバリは不要
        • フェイルオーバー中はダウンタイムがわずかに発生する
  • EBS
    • 永続可能なブロックストレージサービス
    • AZ単位で作成される
    • 単一のAZ内で自動的に複製されているため、単一のディスク障害については考慮不要
    • AZ障害時のデータ消失リスクはある
      • スナップショットをバックアップとして取得
  • インスタンスストア(エフェメラルディスク)
    • 無料で利用できるストレージサービス
    • 揮発性のディスクであるため、EC2インスタンス停止時にはデータ消失
      • 再起動では消失しない
  • EFS
    • スケーラブルな共有ストレージサービス
    • 自動で複数のAZで冗長化される
    • スナップショット取得はできない
      • AWS Backupと連携する
  • FSx
    • マネージド型ののストレージサービス
    • マルチAZ、S3へのバックアップ
  • S3
    • オブジェクトストレージサービス
    • デフォルトの場合は3箇所のAZで自動的に複製されるため耐久性が高い
    • 可用性はSLAが99.99%
  • S3 Glacier
    • アーカイブ目的のストレージ
  • EBSとインスタンスストアの利用手段
    • OSのルート領域として使用可能
    • EBS-Backedインスタンス
      • EBSをOSのルート領域として利用したEC2インスタンス
    • Instance Store-Backedインスタンス
      • インスタンスストアをOSのルート領域として利用したEC2インスタンス
  • EBSとEFSの違い
    • EBSは1台のEC2インスタンスと接続してそのインスタンスでしたか利用できない
    • EFSは複数のEC2インスタンスと接続して利用可能
  • EFSとFSxの違い
    • どちらもEC2と接続可能、マルチAZ配置可能
    • EFSはNFS(Network File System)
    • FSx for WindowsはSMB(Server Messsage Block)
  • 各ストレージのバックアップ
    • EBS
      • スナップショット機能を利用
      • S3に保存される
      • リージョンごとに保管されている
      • 増分バックアップ
      • 取得開始位時点のものが保管される
        • 取得開始から取得完了までの間に変更があった場合はスナップショットに反映されない
      • システム無停止で取得可能
      • データ整合性が必要な場合はI/Oを停止して取得
    • EC2
      • EBSを使っている場合はEBSのスナッショットを使えるが大抵はAMI(Amazon Machine Image)を使ってバックアップされている
      • AMI=EBSスナップショットとEC2の構成情報
      • AMIはリージョンごとに保管されている
    • S3
      • データ整合性モデル
        • 新規追加(PUT)
          • 書き込み後の読み込み整合性
          • データの一貫性が保証される
        • 更新(PUT)
          • 結果整合性
          • 更新直後は古いデータが参照されることがある
        • 削除(DELETE)
          • 結果整合性
          • データ削除後は削除前のデータが参照されることがある

            第3章 AWSにおけるパフォーマンス

  • CloudFront
    • 接続ポイント
      • エッジロケーション
        • コンテンツをキャッシュしておくことができるキャッシュサーバー
      • リージョン別エッジキャッシュ
        • エッジロケーションよりも容量の大きいデータをキャッシュ可能なキャッシュサーバー
    • 配信するコンテンツの保護
      • HTTPS接続
      • 特定のユーザーや特定の地域のユーザーだけがコンテンツを閲覧できるようにするアクセス制限 
      • 通信中のデータを暗号化するためのフィールドレベルの暗号化
    • S3コンテンツへのアクセスを制限した配信
      • OAI(オリジンアクセスアイデンティティ)
        • CloudFrontのみにS3バケットへのアクセスを許可、コンテンツ取得を可能にすることで、ユーザーにはCloudFrontのみアクセスを許可することができる
    • Lamda@Edge
      • CloudFrontのエッジロケーション上でLamdaのプログラムを実行するサービス
        • Lamda関数はユーザーに近いロケーションで実行される
  • Route53
    • レイテンシーベースルーティング
      • 複数リージョンにコンピューティングサービスが配置されている前提
      • レイテンシーが低いリージョンからリクエストを処理する
  • プレイスメントグループ
    • EC2インスタンスを論理的にグループ化したもの
      • グループ化したEC2インスタンス間での通信は通常のインスタンス間通信よりも高速になる
      • 複数のコンピューティングリソースを一つとして機能させるクラスターコンピューティングを実装するような用途に最適
    • クラスタープレイスメントグループ
      • 単一のAZ内のEC2インスタンスを論理的にグループ化
        • すべて同じラックに格納される
        • 低レイテンシーかつ高スループットなネットワーク
    • パーティションプレイスメントグループ
      • EC2インスタンスの各グループをパーティションと呼ばれる論理的なセグメントに分けたもの
      • パーティションの単位でラックが分かれている
        • それぞれのラックは独自にネットワークと電源を備えている
          • 耐障害性(ハードウェア障害)に強い
      • 分散処理環境をデプロイできる
    • スプレッドプレイスメントグループ
      • EC2インスタンスがそれぞれ個別にネットワークと電源を備えたラックに配置される
      • 離れたAZにも配置することができる
      • システム全体が障害の影響を受けるリスクを軽減することができる
  • EBS最適化インスタンス
    • EC2とEBSの間の通信専用帯域を確保することで安定したパフォーマンスを発揮する
    • デフォルトで最適化が選択されている
  • Lamdaのレイテンシー対策
    • 「プロビジョニングされた同時実行の設定」を利用することで設定した数だけコンテナがウォームスタンバイの状態を維持する
  • 各EBSボリュームタイプのスループットとIOPS
    • スループット
      • 1秒間の最大データ転送量
      • スループット重視はHDD
    • IOPS
      • 1秒間のストレージI/O性能
      • IOPS重視はSSD
    • 汎用SSD(General Purpose SSD:gp2)
      • コストパフォーマンスのよいボリュームタイプ
    • プロビジョン度IOPS SSD(PIOPS SSD:io1およびio2)
      • 汎用SSDではカバーできない低レイテンシーかつ高スループットに適したボリュームタイプ
      • EBS最適化インスタンスでの起動を推奨
      • io1とio1はボリュームの耐久性が異なる
        • io2の方が年間の故障率(AFR:Annual Failure Rate)が低い
    • スループット最適化HDD(st1)
      • スループットが高く低コストなHDD
      • アクセス頻度が高い用途に適している
    • コールドHDD(sc1)
      • アクセス頻度が低い用途に適している
      • 大量データを保存するストレージに用いられる
    • マグネティック
      • 旧世代のボリュームタイプ
      • アクセス頻度が低い用途に適した旧世代のHDD
  • RAIDの設定
    • EBSでは標準的なRAIDが使用できる
    • RAID0
      • 2台以上のディスクに対してストライピングでデータを読み書きする
        • オンプレミスでは一般的にはディスク1台にしかデータが保存されないが、EBSではAZ内で冗長化されているため、耐障害性と高速なI/Oを実現できる。
        • ストライピング
          • あるデータを複数のハードディスクに分割して書き込むこと
          • データの転送速度は高速化するが、耐障害性は低い
    • RAID1
      • 2台以上のディスクに対してデータをコピー(ミラーリング)して保存
      • 高い耐障害性
    • RAID5
      • 3台以上のディスクに対してストライピングでデータを分散して書き込む
      • パリティデータも書き込んでおくことでディスク1台が故障してもデータ消失を防ぐことができる
    • RAID6
      • 4台以上のディスクに対してストライピングでデータを分散して書き込む
      • パリティデータも2台のハードディスクに対して書き込んでおくことでディスク2台が同時に故障してもデータ消失を防ぐことができる
    • RAID5、RAID6はパリティデータの書き込み処理にIOPSが消費されるため、AWSでは推奨されていない
  • Amazon DynamoDB
    • キーバリュー型のNoSQLデータベース
  • Amazon DynamoDB Accelerator(DAX)
    • DynamoDB用インメモリキャッシュ
  • Amazon ElastiCache
    • Memcached
      • 一時的なデータのキャッシュ用として使用
      • ノード間の複製は行われない
      • データベースを別途用意
      • シンプルなデータ構造が必要
      • 複数コアまたはスレッドをもつ大きなノードを実行する必要がある
      • スケールアウトおよびスケールイン機能が必要
      • データベースなどのオブジェクトをキャッシュする必要がある
    • Redis
      • プライマリ・レプリカ型の構成
      • データストアとしても利用可能
      • 複雑なデータ構造を用いる
      • プライマリノードに障害が発生した場合、自動的にフェイルオーバーが行われる可能性がある
      • 読み取るデータ量が多いため、プライマリノードから複数のリードレプリカに複製する
      • 永続性が必要

第4章 AWSにおけるセキュリティ設計

  • IAMユーザー
    • 1AWSアカウントで5000ユーザーまで作成可能
    • IAMポリシーでIAMユーザーに対して権限を直接付与することができる
  • IAMグループ
    • 1AWSアカウントで最大300グループ作成できる
    • IAMポリシーを割り当てることで権限管理が簡素化される
  • IAMポリシー
    • 最小権限の原則に則り、デフォルトではユーザーは何の権限も持たない
      • IAMポリシーで明示的に許可を設定しない限り、すべての操作が拒否される=明示的な拒否
      • IAMポリシーで明示的に許可や拒否の権限を付与する=明示的な許可、明示的な拒否
      • 権限の優先度
        • 明示的な拒否>明示的な許可>暗示的な拒否
          • 明示的な拒否は明示的な許可より優先される
  • IAMポリシーの種類
    • AWS管理ポリシー
      • AWSが管理する事前に定義されたポリシーのテンプレート
        • ex.
          • AdministratorAccess
            • すべてのアクセス権限を提供するポリシー
          • PowerUserAccess
            • IAMサービスを除くその他すべてのアクセス権限を提供するポリシー
  • カスタマー管理ポリシー
    • AWSのユーザーが自身で作成・カスタマイズすることが可能なポリシー
  • インラインポリシー
    • IAMユーザー、IAMグループ、IAMロールに埋め込まれているポリシーに対し、ポリシー設定を個別に反映できる
  • IAMロール
    • AWSサービスやアプリケーションに対してAWSの操作権限を付与する仕組み
    • IAMユーザーやIAMグループとは紐付けず、IAMロールに対してIAMポリシーを直接付与することで権限管理を行う
  • IAMによるIDフェデレーション
    • IDフェデレーション
      • 企業や組織などで既に導入されている認証の仕組み(LDAPなど)とAWSの認証の仕組みを紐付けし、シングルサインオンを実現する機能
        • LDAP(Lightweight Directory Access Protocol)
          • ユーザーの認証情報などを格納したディレクトリデータベースへアクセスするためのプロトコル
    • AWS Directory Service
      • AWSのクラウドで管理されるマネージド型のMicrosoft AD
        • サポートするディレクトリタイプ
          • Microsoft AD
            • AWS上でActive Directoryサービスを利用できる
          • Simple AD
            • AWS上でActive Directory互換のSambaサービスを利用できる
          • AD Connector
            • 既存のActive Directory環境へ接続する為のプロキシサービス
  • AWS Organizations
    • 複数のAWSアカウント作成の自動化やグループ化による集中管理、それらのグループにポリシーを適用したアクセス管理ができる
    • 複数のAWSアカウントで発生した使用料を一括請求することもできる
  • サービスコントロールポリシー(SCP)
    • AWS Organizationsが提供する機能で、Organizationsで管理されている複数のAWSアカウントに対して、IAMポリシーのような権限制御を統合的に管理・適用する機能
      • 特定のAWSサービスの操作を禁止したり、共通のポリシーを設定したりすることができる
  • セキュリティグループとネットワークACLによるアクセス制御
    • ネットワークACL
      • VPC内に構成されたサブネットに対するファイアウォール機能
        • VPC内に構成したサブネットごとに一つだけネットワークACLを設定可能
        • VPC作成時にデフォルトのネットワークACLが一つ準備されており、初期設定ではすべてのトラフィックを許可
          • ルール番号100で「すべてのトラフィックを許可」
          • ルール番号*(最後の行)で「この行より上に記載したルールに一致しないすべての通信を拒否」
            • ルールは番号順に適用される。明示的な拒否の場合は100より小さな数字を指定する。
        • 新規にネットワークACLを作成することもでき、その場合の初期設定はすべてのトラフィックを許可
        • インバウンドとアウトバウンドのそれぞれに対して、許可または拒否を明示した通信制御が可能
        • ステートレス
          • インバウンドとアウトバウンドに対する通信制御が必要
    • セキュリティグループ
      • ECSインスタンスなどに適用するファイアウォール機能
        • デフォルトでは、アウトバウンドはすべて許可、インバウンドは拒否
        • 設定追加・変更は即座に反映
        • ステートフルな制御が可能(ルールで許可された通信の戻りの通信も自動的に許可される)
    • セキュリティグループとネットワークACLを両方とも適用している場合
      • 双方のルールで許可されていないと拒否となる
  • Webアプリケーションの保護
    • AWS Web Application Firewall(WAF)
      • SQLインジェクションやクロスサイトスクリプティングのような一般的な攻撃から保護する機能
      • Amazon CloudFrontやApplication Load Balancer、Amazon API GatewayなどのAWSサービスにWAFをアタッチすることで各サービスへのアクセスを制限することができる
    • AWS Shield
      • DosやDDosなどの一斉攻撃に対する攻撃から保護する機能
  • 暗号化によるデータの保護
    • 通信の暗号化
      • SSL/TLSによる通信の暗号化をサポートしている代表的なサービス
        • ELB
        • RDS
        • Cloud Front
        • API Gateway
      • AWS Certificate Manager(ACM)
        • SSL/TLS証明書の購入や登録・更新などの一言管理ができる
  • データ暗号化の方式と場所
    • クライアントサイドでの暗号化(CSE:Client Side Encryption)
      • AWSにデータを送信・保存する前に、ユーザーの環境でデータを暗号化する
      • S3
        • ファイルに暗号化やパスワード処理を施してからアップロードする
        • AWS SDKを利用してプログラムからS3noアップロード時にファイル暗号化も可能
      • EBS
        • OSが提供するファイルシステムの暗号化機能を利用。ユーザーがファイルシステム全体を暗号化してからデータを保管する
    • サーバーサイドでの暗号化(SSE:Server Side Encryption)
      • S3
        • バケットにデフォルト暗号化オプションを設定
          • S3バケット内に保存されるファイルが自動的に暗号化される
      • EBS
        • ボリュームの作成時に暗号化設定が可能
          • 既存のEBSボリュームを暗号化ボリュームに変更する手順
            • 既存ボリュームのスナップショットを作成
            • 作成したスナップショットを複製する際に暗号化オプションを指定
            • 暗号化されたスナップショットからEBSボリュームを再作成
            • EC2インスタンスから既存のEBSボリュームをデタッチ
            • EC2インスタンスから暗号化されたEBSボリュームをアタッチ
  • セキュリティ監視
    • AWS CloudTrail
      • AWSアカウントで利用された操作(APIコール)をログとして記録するサービス
    • VPCフローログ
      • VPC内のネットワークインターフェイス間で行き来する通信の内容をキャプチャする機能
    • Amazon GuardDuty
      • 各種ログ(CloudTrailやVPCフローログ、Route53のクエリログなど) を監視し、攻撃や不正操作などのセキュリティ脅威を検知するサービス
    • CloudWatch Logs
      • 各種ログを統合的に収集するサービス
    • AWS Config
      • AWSのサービスで管理されているリソースの構成変更を追跡するサービス
    • AWS Trusted Advisor
      • AWSのベストプラクティスに基づいて、コスト最適化、セキュリティ、耐障害性、パフォーマンス、サービスの制限の5項目でユーザーのAWS利用状況をチェック、改善事項を推奨するサービス
    • Amazon Inspector
      • EC2インスタンスにInspectorのエージェントをインストールすることで、EC2インスタンス上のアプリケーションの脆弱性などを診断可能

第5章 AWSにおけるコスト最適化

  • オンデマンドインスタンス(デフォルト)
    • 決められた一定レートの料金で使用した時間に対して課金。使用期間の制約はなし。
  • リザーブドインスタンス
    • 24時間365日の継続・常時起動を前提とした割引が適用されるインスタンス
    • あらかじめ決められた使用期間分を購入することで最大75%オフの割引価格が適用される
      • 最低限の台数が必要なWebサーバーやアプリケーションサーバー、常時起動しておく必要があるデータベースサーバーなど向いている
    • Standardタイプ
      • リージョンやAZを指定してインスタンスを購入できる
        • 同じインスタンス構成であれば、購入時に指定したリージョンやAZ内でインスタンスの配置変更が可能だが、それ以外の場所に変更する場合は変更手続きが必要
    • Convertibleタイプ
      • 指定したインスタンス構成に依存せず、柔軟に構成変更(作成時の価格と同等以上)が可能。割引率はStandardタイプより低い。
    • スケジュールされたリザーブドインスタンス
      • 特定の時間や期間だけ稼働させたい用途向けの機能
      • 日時、週次、月次のような時間や期間でリザーブドインスタンスを購入することができる
  • スポットインスタンス
    • 最大で90%オフとなる最も割引率が高い購入オプション
    • スポット価格が上回っていればインスタンスが起動し利用可能
    • スポット価格が高騰して入札価格を上回るとインスタンスが強制終了
    • 処理が中断されても支障なく再実行可能なシステムに向いている
    • スポットブロック
      • インスタンス起動後、設定された時間に対して継続して動作することを保証するオプション(最大6時間まで)
    • スポットフリート
      • 指定した性能キャパシティを満たすようにスポットインスタンスを構成するオプション
      • スポットインスタンスが強制終了しても代替構成で全体の性能キャパシティを維持する
  • インスタンスタイプの構成
    • t3.xlarge
      • t
        • インスタンスファミリー
      • 3
        • インスタンス世代
      • xlarge
        • インスタンスサイズ
  • インスタンスファミリー
    • EC2などのコンピューティングリソースの利用用途や特性に合わせたサイジングの種類のこと
      • 汎用
        • T2,T3, M4, M5
      • コンピューティング最適化
        • C4, C5
      • メモリ最適化
        • X1e, X1, R5
      • 高速コンピューティング
        • P2, P3, G3, F1
      • ストレージ最適化
        • H1, I3, D2
  • インスタンス世代
    • 数字が大きいほど新しい世代、一般的には最新のアーキテクチャが使われているため、高性能かつ安価
  • インスタンスサイズ
    • インスタンスサイズ
    • 一般的にはvCPU数が、largeは2、xlargeは4、2xlargeは8、4xlargeは16と増加していく
  • 適切なストレージ選定
    • S3のストレージクラス
      • スタンダード
        • デフォルト
        • 複数箇所にデータを複製
        • 99.999999999%の耐久性
      • 標準低頻度アクセス
        • スタンダードと同等の耐久性
        • データの格納コストはスタンダートクラスより安価
        • データの読み出し容量に対しても課金される
        • データへのアクセス頻度が低い場合に向いている
      • Glacier
        • 主にS3のファイルのアーカイブに利用されるストレージ
        • 最も安価
        • データの取り出しは通常3~5時間かかる
      • Glacier Deep Archive
        • Glacierよりも更に安価な
        • データの取り出しには12時間以上かかる
      • 低冗長化ストレージ(Reduced Redundancy Storage)
        • 耐久性が99.99%
        • Glacierから取り出したデータの一時的な置き場、データを安価に一時的に格納するなどの目的に向いている
      • 1ゾーン低頻度アクセス(One Zone-Infrequent Access)
        • 1つのAZのみにデータを保存する
        • スタンダードクラスと比較すると20%程度コスト削減できる
      • Intelligent-Tiering
        • S3上に格納したオブジェクトへのアクセス頻度に応じて、コスト最適なストレージ層を自動的に使い分けるタイプ
        • コスト構造の異なる低頻度・高頻度の2階層のストレージ層がある。オブジェクト別にアクセス頻度に応じてS3が自動的にオブジェクトの階層を移動させることで、コスト最適化を自動的に行う
    • EBSのボリュームタイプ
      • 汎用SSD(General Purpose SSD: gp2)
        • デフォルト
        • I/O性能は最大100000IOPS程度まで利用可能
      • プロビジョンドIOPS SSD(PIOPS SSD: io1およびio2)
        • 最もパフォーマンスが高いタイプ
        • 最大64000IOPSまで指定可能
        • ストレージ性能だけでなく、指定したIOPS数に対しても課金される
      • スループット最適化HDD(st1)
        • 主にファイルへのシーケンシャルアクセスが多い場合に高いスループットを提供するタイプ
      • コールドHDD(sc1)
        • 高いスループットを求めない場合の低価格なHDDを提供するタイプ
      • マグネティック
        • 旧世代のEBS
  • SQS
    • 標準キュー
      • キューイングされたメッセージを取り出して処理を行う際の順番が保証されない
    • FIFOキュー
      • メッセージをキューイングした順番で処理することが保証される
    • ショートポーリング
      • SQSキューに対して、受信者がメッセージ取得要求を送るとキューが空でもEmptyメッセージが返送される
    • ロングポーリング
      • キューが空の場合にメッセージが取得できるまで待つ時間(1~20秒)を設定することでメッセージ取得要求の数を減らす
        • SQSはリクエスト単位で課金されるため、リクエストを減らすことでコスト削減となる
    • 可視性タイムアウト
      • ある受信者がメッセージを取得した場合に、他の受信者にはそのメッセージをある一定時間見せないようにすることで処理の重複を防ぎ、リクエスト数を減らすことが可能
      • スポットインスタンスと相性が良い
        • スポットインスタンスが強制終了されたとしても、可視性タイムアウト超過後に自動的に他の受信者がメッセージを取得できるようになるため、処理の再実行が可能になる
  • Amazon Kinesis
    • 主にストリーミングデータの収集・処理・リアルタイム分析に利用される
    • SQSとの違い
      • Kinesisでは複数のコンシューマ(メッセージを取得する側)が同時に同じメッセージを取得して処理できる点
    • Amazon Kinesis Data Streams
      • ストリーミングデータをほぼリアルタイムで収集することができ、EMRやLamdaなどと連携することでデータを処理することが可能
      • 流れてくる大容量のデータを効率的に処理するために「シャード」と呼ばれる単位でデータを分割して並行処理ができる
    • Amazon Kinesis Data Firehose
      • ストリームデータをS3やRedshift、ESに配信・保存できるサービス
    • Amazon Kinesis Data Analytics
      • ストリーミングデータに対してSQLクエリを実行し、リアルタイム分析を行うサービス
  • AWSにおけるコスト管理
    • Consolidated Blling(一括請求)
      • コストの請求・支払い
      • 複数のAWSアカウントに対する請求を1つに統合し、まとめて支払いできる機能
      • AWS Organizationsの1機能
    • AWS Cost and Usage Report(コストと使用状況レポート)
      • コスト状況の詳細把握
    • AWS Cost Explorer
      • コストの可視化・傾向分析
      • 可視化・分析・予測の3つの機能
    • AWS Budgets(予算設定)
      • 過剰利用の監視
      • 予算額設定・通知設定
    • AWS Trusted Advisor
      • コスト最適化の検討
      • コスト最適化・セキュリティ・耐障害性・パフォーマンス・サービスの制限の5項目でAWSの利用状況をチェックし、改善事項を推奨するサービス

About the author

Image

bmf san @bmf_san
A web developer in Japan.