はじめに

AWS の基礎コースは、AWS で効率的に作業を行う上で必要な主要概念を学ぶことができるように設計されています。

AWS の使用開始当初は、手に負えないように感じるかもしれません。インフラストラクチャ構築のクラウドネイティブパラダイムは、オンプレミスで作業を行う従来の方法とはかけ離れたものとなり得ます。そして、初めてインフラストラクチャを扱うのか、過去 10 年間 Linux カーネルのチューニングを行ってきたのかを問わず、175 を超える AWS のサービスでは、どこから手を付けたらよいのか分からないかもしれません。

AWS の基礎コースは、経験の有無にかかわらず、AWS の使用を開始する援助となるように設計されています。このコースでは、最終的に選択するサービスのすべてに当てはまる AWS の 5 本の柱、クラウドについて考えるときに使用するメンタルモデル、および重要な概念について学びます。

 

構造

AWS の基礎コースは、5 つのモジュールに分かれています。各モジュールは、以下の形式に従います。

  • はじめに: 注目する柱の簡単な説明
  • メンタルモデル: 各柱で紹介される概念を理解するために役立つ指針的なメンタルモデル
  • 概念: 各柱の広範囲におよぶ基礎的なトピックを対象とする重要な概念
  • まとめ: 学んだ事柄の概要
  • その他の資料: 追加のリンクとリソース
 

5 本の柱

AWS の基礎コースで取り上げる 5 本の柱は、AWS Well–Architected フレームワークに由来するものです。Well–Architected フレームワークには、クラウドでのスケーラブルなアプリケーションの構築における 10 年を超える経験が凝縮されています。

5 本の柱は、以下の分野で構成されています。

  1. セキュリティ
  2. パフォーマンス効率
  3. 信頼性
  4. 運用上の優秀性
  5. コスト最適化
 

セキュリティ

セキュリティの柱は、クラウドでインフラストラクチャをセキュア化する方法に焦点を当てています。セキュリティとコンプライアンスは AWS とお客様の間における責任共有です。この責任共有モデルでは、AWS がクラウドのセキュリティに対する責任を担います。これには、AWS クラウドサービスの物理的なインフラストラクチャ、ソフトウェア、およびネットワーキング機能が含まれます。お客様はクラウド内でのセキュリティに対する責任を担います。これには、特定のクラウドサービスの設定、アプリケーションソフトウェア、および機密データの管理が含まれます。

 

メンタルモデル

クラウドでのセキュリティについて考えるときは、ゼロトラストのモデルを取り入れることが役に立ちます。

このモデルでは、アプリケーションのコンポーネントとサービスのすべてが、害を及ぼす可能性のある個別のエンティティと見なされます。これには、基盤となるネットワークファブリック、リソースにアクセスできるすべてのエージェント、およびサービス内で実行されるソフトウェアも含まれます。

 

概念

ゼロトラストの観点からセキュリティを考えるということは、システムのあらゆるレベルにセキュリティ対策を適用する必要があるということです。以下は、クラウドにおけるゼロトラストでのシステムのセキュア化に関する 3 つの重要な概念です。

  1. Identity and Access Management (IAM)
  2. ネットワークセキュリティ
  3. データの暗号化

 

  • IAM は、システム内でのアイデンティティとアクセスの追跡に対する責任を担うサービスです。これは、IAM という、これにふさわしい名前が付けられたサービスを通じて AWS で管理されます。アクセスは、AWS 内のエージェントにアクセス境界を設定する IAM ポリシーを使用して管理されます。IAM ポリシーには 3 つの基本的な要素があります。

    • 誰に許可が付与されるかを指定するプリンシパル
    • 何が実行されるかを指定するアクション
    • どのプロパティがアクセスされるかを指定するリソース

    IAM へのゼロトラストモデルの適用は、最小権限の原則の導入を意味します。つまり、すべてのエージェントが持つのは、その機能を実行するために必要な最小権限のみにするべきだということです。

    IAM ポリシーは、AWS のプリンシパルまたは AWS のリソースに適用できます。プリンシパルに関連付けられたポリシーは、アイデンティティベースのポリシーと呼ばれ、リソースに関連付けられたポリシーは、リソースベースのポリシーと呼ばれています。リソースベースのポリシーがあるのは一部のサービスのみ (S3、KMS、SES など) であることに留意してください。

    プリンシパルが特定のリソースのためにアクションを実行するアクセス許可を持っているかどうかは、そのプリンシパルのアイデンティティベースのポリシーがそのアクションを許可しているか、およびリソースベースのポリシー (存在する場合) がそれを禁止していないかどうかに依存します。

    これは、IAM のアクセス許可モデルを大幅に簡素化したものであることに注意してください。この他にも、アクセス許可を付与できるかどうかに影響するポリシータイプが多数あります。これには、アクセス許可の境界組織のサービスコントロールポリシーアクセスコントロールリスト、およびセッションポリシーなどがあります。これらの追加のポリシータイプは、このコースの範囲外です。詳細については、本モジュールのその他の資料セクションをご覧ください。

    重要ポイント

    • IAM ポリシーは AWS 内のエンティティに対するアクセス境界を宣言する
    • IAM ポリシーはプリンシパル、アクション、およびリソースで構成される
    • IAM ポリシーは最小権限の原則を実施するために使用できる
    • IAM には多数のポリシータイプがある – その 2 つの例がアイデンティティベースとリソースベースのポリシー
    • IAM は、所定のリソースに適用されるすべてのポリシータイプの評価に基づいてアクセスを評価する
     

    その他の資料

  • ネットワークセキュリティには、ネットワークとネットワークにアクセスできるリソースのアクセスと可用性を保護する、すべてのシステム、設定、またはプロセスが関与します。AWS は、ネットワークレベルおよびリソースレベルの両方でネットワークをセキュア化するための幅広い機能を提供しています。

    ネットワークセキュリティに対するゼロトラストアプローチには、ネットワークの最外層だけではなく、すべての層でセキュリティコントロールを適用する多層防御アプローチが含まれます。

    ネットワークレベルのセキュリティ

    AWS における基本的なネットワークレベルのプリミティブは Amazon Virtual Private Cloud (VPC) です。これは、ユーザーが定義してリソースをプロビジョニングできる論理ネットワークです。

    以下は、VPC を構成するコンポーネントの一部です。

    • サブネット: VPC 内の IP アドレスの範囲
    • ルートテーブル: トラフィックの送信先を決定する規則のセット
    • インターネットゲートウェイ: VPC 内のリソースとインターネットの間における通信を許可するコンポーネント

    VPC 内のトラフィックを保護するには、リソースを外部向けリソースと内部リソースに分けることができます。攻撃対象領域を減らすには、インターネット向けトラフィックのすべてを処理するために、Application Load Balancer (ALB) などのプロキシサービスを使用できます。そうすることで、サーバーおよびデータベースといった内部サービスのすべてを、直接的なパブリックインターネットアクセスから切り離された内部サブネット内にプロビジョニングできます。

    VPC に加えて、AWS Web Application Firewall (WAF) を使ってネットワークへのトラフィックをさらに制限することもできます。

    リソースレベルのセキュリティ

    個々の AWS リソースにも、ユーザーが設定できるネットワークセキュリティコントロールがあります。最も一般的なコントロールは、セキュリティグループと呼ばれるものです。セキュリティグループは、リソースに出入りするトラフィックへの適用に使用できる仮想ファイアウォールです。セキュリティグループを使って、インスタンスに特定のポートおよび信頼されたソースからのトラフィックのみを許可します。セキュリティグループは、EC2 インスタンス、RDS インスタンス、および Lambda などのリソースにアタッチできます。

    重要ポイント

    • ネットワークセキュリティには、ネットワークとネットワークにアクセスできるリソースのアクセスと可用性を保護するために設計されたメカニズムが関与する
    • ネットワークセキュリティに対するゼロトラストアプローチには、ネットワークのすべての層での多層防御の実装が伴う
    • VPC と WAF は、ネットワークレベルでのセキュリティ対策の適用を可能にする
    • セキュリティグループは、リソースレベルでのセキュリティ対策の適用を可能にする

    その他の資料

  • データの暗号化とは、データを解読するために必要なキーを持たないサードパーティーにとって判別不能な方法で情報を暗号化するプロセスです。

    データへのゼロトラストモデルの適用は、あらゆる場所にある転送時および保管時両方のデータを暗号化することを意味します。

    転送時の暗号化

    転送時の暗号化には、システム間を行き来するデータの暗号化が伴います。AWS 内のストレージおよびデータベースサービスはすべて、転送時のデータの暗号化をサポートする HTTPS エンドポイントを提供します。また、AWS は、ユーザー独自のサービスへの転送時の暗号化の実施に役立つネットワークサービスも提供しています。たとえば、Application Load Balancer (ALB) を使って、エンドポイントへの HTTPS 経由の接続を実施できます。

    保管時の暗号化

    保管時の暗号化には、システム内のデータの暗号化が伴います。保管時の暗号化は、AWS のすべてのストレージおよびデータベースサービスでサポートされており、これらのサービスのほとんどで暗号化がデフォルトで有効化されています。暗号化に対する追加料金はなく、データの暗号化に対するパフォーマンスオーバーヘッドもごくわずかです。

    また、ほとんどのストレージおよびデータサービスは、Amazon Key Management Service (KMS) と直接的に統合されています。KMS は、データを暗号化するためのカスタマー管理のキー (CMK) を作成する機能を提供する、一元的なキー管理サービスです。

    CMK の使用により、暗号化以上の追加機能が提供されます。これには、独自のカスタムキーストアを使用する能力、AWS CloudTrail との統合によって暗号化されたリソースの監査証跡を作成する能力、および自動キーローテーションの実施が含まれます。

    重要ポイント

    • 暗号化は、適切なキーを持つ当事者のみが情報を解読できる方法で情報を暗号化するプロセス
    • 転送時および保管時における暗号化でデータをセキュア化する
    • AWS のすべてのストレージおよびデータベースサービスが保管時および転送時の暗号化を提供する
    • ALB といった AWS のネットワーキングサービスを使って、独自のサービスに転送時の暗号化を実施できる
    • CMK を使うと、監査証跡の作成、独自のカスタムキーの使用、および自動キーローテーションといった高度な機能を使用できるようになる

    その他の資料

    機能

     

    サービス

     

    参照ドキュメント

     

     

まとめ

このモジュールでは、AWS のセキュリティの柱について学びました。ゼロトラストのメンタルモデルについて学びました。IAM と最小権限の原則について学びました。AWS のネットワークセキュリティと多層防御の原則について学びました。データの暗号化と、それを転送時および保管時のデータに適用することについて学びました。

 

その他の資料

パフォーマンス効率

パフォーマンス効率の柱は、クラウドでサービスを効率的かつスケーラブルに実行する方法に焦点を当てています。クラウドはあらゆる量のトラフィックを処理する手段を提供しますが、規模を念頭にサービスを選択し、設定することが必要になります。

 

メンタルモデル

クラウドにおけるパフォーマンス効率について考えるときは、サービスを cattle、not pets (ペットではなく家畜) として考えることが役に立ちます。

オンプレミスモデルの方式では、サーバーが高額で、多くの場合、手動でデプロイメントと設定が行われていました。サーバーが実際に納品され、データセンターに物理的に接続されるまで、数週間かかることもありました。このため、サーバーは、それぞれがユニークで多くのメンテナンスが必要となるペットのように扱われ、名前が付いていたものさえありました。

クラウドでは、サーバーを家畜として考えます。サーバーは、数秒で自動的にプロビジョニングできる商品リソースです。サービスの運用に必要不可欠なサーバーがあってはなりません。

 

概念

サーバーを家畜として考えることは、多くのパフォーマンス関連のメリットをもたらします。サーバー管理の「ペットモデル」では、複数のワークロードに同じタイプのサーバー (あるいは同じサーバー) を使用することがごく当たり前でした。異なるマシンを注文してプロビジョニングするのはあまりにも面倒だったからです。「家畜モデル」ではプロビジョニングが安価かつ迅速であるため、ワークロードに最も近いサーバータイプを選択する自由が得られます。

「家畜モデル」は、サービスのスケーリングも容易にしてくれます。すべてのサーバーが置き替え可能で、迅速にデプロイできるため、より多くのサーバーを追加することでキャパシティを素早くスケールすることができます。

パフォーマンス効率では、次の 2 つの概念に注目します。

  1. 選択
  2. スケーリング
 
  • AWS での選択は、ワークロードに最も良く適合するサービスを選択する能力です。AWS には、24 を超えるカテゴリの全体にまたがる 175 のサービスを備えた、最も広範なサービスの選択肢があります。選択を通じたパフォーマンスの達成は、ジョブに適切なツールを選択できることを意味します。

    典型的なワークロードでは、通常、AWS の 4 つの主要サービスカテゴリ、つまりコンピューティング、ストレージ、データベース、およびネットワークのいくつかで選択を行うことが必要になります。

    • コンピューティングは、データを処理するサービスに対応します (例: 仮想マシン)
    • ストレージはデータの静的ストレージに対応します (例: オブジェクトストア)
    • データベースはデータの編成されたストレージに対応します (例: リレーショナルデータベース)
    • ネットワークデータの移動方法に対応します (例: コンテンツ配信ネットワーク)

    このモジュールでは、最初の 3 つのカテゴリでの適切な選択について説明します。異なるネットワーキングオプションでの選択に関するガイドについては、その他の資料セクションを参照してください。

    選択を行うサービスのカテゴリにかかわらず、検討する必要がある 3 つの事柄があります。

    1. サービスのタイプ
    2. 管理レベル
    3. 設定

    サービスのタイプ

    カテゴリで選択を行うとき、AWS は使用できるサービスのタイプに多数のオプションを提供します。タイプは各カテゴリ特有のものです。

    コンピューティングサービスを選択するときは、VM ベース、コンテナベース、またはサーバーレスベースのコンピューティングのどれがよいかを判断します。

    • VM ベースのコンピューティングには、ほとんどの人にとって最も身近なメンタルモデルがありますが、より高額で、より多くのメンテナンスが必要となる場合があります
    • コンテナベースのコンピューティングは、ワークロードのより詳細な部分を有効にし、素早くスケーリングできますが、設定とオーケストレーションがより複雑になります
    • サーバーレスベースのコンピューティングは、管理とスケーリングの複雑性のほとんどを取り除きますが、ハードシステム制限があり、新しいツールチェーンとプロセスの導入が必要です

    ストレージサービスを選択するときは、ファイルストア、ブロックストア、オブジェクトストア、またはアーカイブストアのどれが必要かを判断します。

    • EBS のようなブロックストレージサービスは、単一の EC2 インスタンスからのデータを永続化するために最適です
    • EFS のようなファイルシステムは、同じデータへのアクセスを複数のクライアントに提供するために最適です
    • S3 のようなオブジェクトストアは、多数のクライアントによるアクセスが必要となる、複数の大きなデータの塊に最適です
    • S3 Glacier のようなアーカイブストレージは、頻繁にアクセスする必要がない大量のデータに最適です

    データベースサービスを選択するときは、リレーショナルデータベース、非リレーショナルデータベース、データウェアハウスソリューション、またはデータのインデックス作成と検索ソリューションのどれが必要かを判断します。

    • リレーショナルデータベースは、Join および ACID プロパティを使用できますが、パフォーマンスとデータストレージに上限があります
    • 非リレーショナルデータベースにはより柔軟なスキーマがあり、リレーショナルデータベースよりも大幅に高い上限までスケールできますが、Join および完全な ACID 機能がないのが一般的です
    • データウェアハウスソリューションは、ペタバイト規模の構造化データへの迅速なアクセスによる大規模な分析を可能にします
    • データのインデックス作成と検索ソリューションでは、さまざまなソースからのデータをインデックス化し、検索することができます
     

    管理レベル

    サービスのタイプを決定したら、特定のサービスにさらに絞り込む必要があります。AWS では、特定のサービスタイプにまたがる複数の製品を提供することもあります。AWS の同じタイプの各種サービスにおける主な違いは、その管理レベルにあります。

    コンピューティングサービスの使用時に VM タイプを決めるときは、EC2Lightsail、および Elastic Beanstalk のいずれかを選択する必要があります。EC2 の直接的な使用は最大のコントロールを提供しますが、Lightsail を選択すると、カスタム化の一部が使用できない代わりに、はるかに優れたマネージドエクスペリエンスが得られます。Elastic Beanstalk はこの中間に位置し、サービスアーキテクチャに独断的なフレームワークを提供しますが、設定を通じてカスタマイズすることも可能です。

    ストレージサービスの使用時におけるサービスの選択は、所定のタイプにひとつのサービスしかない傾向があるため、より簡単です (オブジェクトストアには S3、ファイルストアには EFS など)。

    データベースサービスの使用時におけるリレーショナルタイプの判断には、RDSAurora のいずれかを選択する必要があります。RDS では、基盤となるデータベースをより良くコントロールでき、ほとんどのリレーショナルデータベースで利用できます。Aurora は特定バージョンの MySQL および PostgreSQL でしか機能しませんが、基盤となるストレージの管理を行い、クラスタリングサポートが組み込まれています。

    結局のところ、特定サービスの選択は主に、基盤となるテクノロジーに対する熟知度と、希望するマネージドエクスペリエンスによって決まります。

     

    設定

    サービスが決まったら、その設定方法をさらに決定していく必要があります。設定は、達成したい特定のパフォーマンス特性に依存し、これらはサービスカテゴリごとに異なります。

    コンピューティングサービスのパフォーマンス特性を評価するときは、メモリとコンピューティングの要件を検討することから始めるとよいでしょう。

    • VM ベースのコンピューティングを使用している場合、インスタンスのサイズ (例: t3.small 対 t3.xlarge) およびインスタンスファミリー (例: r3.small 対 c5.small) がメモリと CPU に影響します
    • コンテナベースのコンピューティングを使用している場合は、メモリと CPU を個別に設定できます
    • サーバーレスベースのコンピューティングを使用している場合、直接設定できるのはメモリだけです。コンピューティング (およびその他システムリソース) の値は、利用可能なメモリ量に対して線形に増加します

    ワークロードによっては、ネットワークキャパシティー、およびインスタンスストレージといった特定のリソースの可用性など、配慮しなければならない追加のリソース制限があることに留意してください。

    ストレージサービスのパフォーマンス特性を評価するときは、レイテンシー、スループット、および IOPS の要件を検討します。

    • ブロックストレージサービスを使用している場合
      • レイテンシーは選択したボリュームタイプによって変動 (例: ソリッドステートドライブ対ハードディスクドライブ)
      • スループットは、ほとんどのボリュームタイプのボリュームサイズに比例
      • IOPS キャパシティーは、ほとんどのボリュームタイプのボリュームサイズに比例
    • ファイルシステムサービスを使用している場合
      • レイテンシーと IOPS は選択したパフォーマンスモードによって変動
      • スループットは、プロビジョニングされたスループットを使用する選択によって変動
    • オブジェクトストアを使用している場合
      • レイテンシーは、バケットのエンドポイントまでの地理的な距離によって変動
      • スループットは、マルチパートアップロードなどのスループットが最適化された API の使用によって変動
      • IOPS は設定不可
    • アーカイブストアを使用している場合
      • レイテンシーは、バケットのエンドポイントまでの地理的な距離、および取得メソッドの選択によって変動
      • スループットは、マルチパートアップロードなどのスループットが最適化された API の使用によって変動
      • IOPS は設定不可

    データベースサービスのパフォーマンス特性を評価するときは、リソース要件 (CPU、メモリ、ストレージなど) を検討します。

    • リレーショナルデータベースを使用している場合
      • リソースの機能性は、選択する EC2 インスタンスによって決まる
    • DynamoDB などの非リレーショナルデータベースを使用している場合
    • Redshift などのデータウェアハウスソリューションを使用している場合
      • リソースの機能性は、基盤となる EC2 インスタンスの選択によって決まる
    • Elasticsearch Service などのインデックス作成ソリューションを使用している場合
      • リソースの機能性は、選択する EC2 インスタンスによって決まる

     

    重要ポイント

    • AWS には成果を達成するための多数のサービスと方法がある
    • AWS でのワークロードの実装には、コンピューティング、ストレージ、データベース、およびネットワークカテゴリ全体でのサービスの選択が関与する
    • 各カテゴリでは、ユースケースに基づいて適切なサービスタイプを選択できる
    • 各タイプでは、希望する管理レベルに基づいて特定のサービスを選択できる
    • 各サービスでは、達成したい特定のパフォーマンス特性に基づいて特定の設定を選択できる
     

    その他の資料

  • 使用の開始には適切なサービスの選択が重要ですが、継続的なパフォーマンスにはスケーリング方法の選択が重要です。

    AWS には 2 つの主なスケーリング手段があります。

    1. 垂直スケーリング
    2. 水平スケーリング


    垂直スケーリング

    垂直スケーリングには、基盤となるコンピューティングのより大きなインスタンスタイプへのアップグレードが伴います。たとえば、t3.small インスタンスを実行しているとしましょう。このインスタンスの垂直スケーリングは、インスタンスの t3.large へのアップグレードになり得ます。

    垂直スケーリングは通常、サービスをクラスター化することなく実装できるので、より簡単に実行できます。欠点は、水平スケーリングと比べて上限が大幅に低くなることです (コンピューティングインスタンスの最大サイズと同等)。また、インスタンスの中断がサービスの完全な利用不能化を引き起こす可能性があるため、単一障害点にもなります。

     

    水平スケーリング

    水平スケーリングには、基盤となるインスタンスの数の増加が伴います。たとえば、t3.small インスタンスを実行しているとしましょう。このインスタンスの水平スケーリングには、2 つの t3.small インスタンスを追加でプロビジョニングすることが含まれます。

    水平スケーリングには、実装面でより多くのオーバーヘッドが生じます。これは、サービスのフリートにトラフィックをルーティングするプロキシサービスが必要となるためです。また、不良インスタンスをルーティングプールから排除するためにヘルスチェックを実行する、およびワークロードに最適な特定のルーティングアルゴリズムを選択する必要もあります。その代わりに、垂直にスケーリングされたサービスよりも耐障害性がはるかに優れており、大幅に高い上限までスケールできるサービスが実現されます。


    重要ポイント

    • 垂直スケーリングは運用面ではシンプルだが、可用性のリスクがあり、上限も低い
    • 水平スケーリングにはより多くのオーバーヘッドが必要だが、はるかに優れた信頼性と、大幅に高い上限がある
     

    その他の資料

まとめ

このモジュールでは、AWS のパフォーマンス効率の柱について学びました。サーバーをペットではなく家畜として扱うメンタルモデルについて学びました。適切なサービスサービスの選択方法と、パフォーマンス目標に基づくそれらの設定について学びました。サービスのスケーリングと、垂直および水平スケーリングのトレードオフについて学びました。

 

その他の資料

信頼性

信頼性の柱は、サービスとインフラストラクチャ両方の中断に対する耐障害性を備えたサービスを構築する方法に焦点を当てています。パフォーマンス効率と同様に、クラウドは中断に耐え得る耐障害性を備えたサービスを構築する手段を提供しますが、信頼性を念頭にサービスを設計することが必要になります。


メンタルモデル

クラウドにおける信頼性について考えるときは、障害影響範囲の観点から考えることが役に立ちます。障害影響範囲は、システム障害発生時に受ける可能性がある最大の影響として考えることができます。信頼性の高いシステムを構築するには、個々のコンポーネントの障害影響範囲を最小限化します。

 

概念

障害影響範囲の観点から考えると、障害の問題はもはや発生するかどうかの問題ではなくなり、いつ発生するかになります。障害が発生した時に対応するには、以下の手法を使用して障害影響範囲を制限することができます。

  1. 障害の分離
  2. 制限


  • 障害の分離は、障害の分離ゾーンによって分離されている独立した冗長コンポーネントを使用することで、インシデントの障害影響範囲を制限します。障害の分離ゾーンは、ゾーン内のエリアに対する障害の影響を封じ込めます。

    AWS には 3 つのレベルの障害の分離ゾーンがあります。

    1. リソースとリクエスト
    2. アベイラビリティーゾーン
    3. リージョン

     

    リソースとリクエスト

    AWS のサービスは、リソース ID などの所定の次元でのすべてのリソースとリクエストをパーティション化します。これらのパーティションはセルと呼ばれます。セルは、独立しており、単一のセル内の障害を封じ込めるように設計されています。AWS は、舞台裏でシャッフルシャーディングなどの手法を用いて障害影響範囲を制限しています。これらはすべて、リクエストが行われる、またはリソースが作成されるたびに透過的に行われ、ユーザー側が追加のアクションを行う必要ありません。


    アベイラビリティーゾーン

    AWS のアベイラビリティーゾーン (AZ) は、専用の電力、サービス、およびネットワーク機能を持つ完全に独立した施設です。これらは、火災や洪水などの環境災害による相関障害を避けるために、他の AZ から地理的に離れています。

    AZ レベルでの障害の分離は、複数の AZ を使ってサービスの冗長インスタンスをデプロイすることによって実現されます。これは、ひとつの AZ で停電が発生しても、別の AZ のトラフィックには影響しないことを意味します。

    レイテンシーについて言うと、AZ は地理的に離れてはいても、AZ 間のネットワークレイテンシーを最小限に抑えるには十分な近さの距離に位置しています。これによって、AZ 間で同期データレプリケーションといった特定の機能を実行することが可能になります。


    リージョン

    AWS リージョンは、究極の独立性を提供します。各リージョンは、2 つ以上の AZ で構成される完全な自律データセンターです。リージョンレベルでの障害の分離は、異なる AWS リージョンにまたがってサービスの冗長コピーをデプロイすることによって実現されます (AWS 独自のサービスにも、この通りのことが行われています)。

    極めて高いレベルの可用性が必要な場合は、複数リージョンへのデプロイメントを検討してください。複数のリージョンにまたがったサービスの運用は、リージョン間に共有のインフラストラクチャがないことから、大幅なオーバーヘッドがあることに留意してください。しかし、マルチリージョン構築に役立つサービスと機能が存在します。たとえば、異なるリージョン間におけるトラフィックのルーティングには、AWS のスケーラブルな DNS サービスである Route53 を使用できます。また、DynamoDB Global Tables および S3 のクロスリージョンレプリケーションなどの機能を使って、リージョン間でデータをレプリケートすることも可能です。


    重要ポイント

    • サービスの障害影響範囲、およびインフラストラクチャの中断を制限するには、障害の分離ゾーンを使用する
    • リソースおよびリクエストレベルでの障害の分離は、AWS の全サービスの設計に組み込まれている – ユーザーが追加のアクションを行う必要はない
    • AZ レベルでの障害の分離は、複数の AZ にまたがってサービスをデプロイすることで実現される – これは最小限のレイテンシー影響で実行できる
    • リージョンレベルでの障害の分離は、複数のリージョンにまたがってサービスをデプロイすることで実現される – これには大幅な運用オーバーヘッドが必要になる


    その他の資料

  • 制限は、サービスを過剰な負荷から保護するために適用できる制約です。これらは、外部インシデント (例: DDoS 攻撃) と内部インシデント (例: ソフトウェアの誤設定) の両方による障害影響範囲を制限するための効果的な手段です。

    AWS のサービスには、アカウントおよびリージョンごとにサービス固有の制限があります。これらの制限は、サービスクォータとも呼ばれます。これらは、AWS アカウント内の特定のリソース、アクション、および項目に対する最大値です。

    制限には 2 つのタイプがあります。

    • AWS による制限緩和をリクエストすることで緩和が可能になるソフト制限
    • 緩和不可能なハード制限

    サービスにはそれぞれ異なる制限があります。制限を追跡し、緩和をリクエストするには、サービスクォータサービスを使用できます。

    サービスの中断を避けるためにも、サービス制限をモニタリングして、制限に近づく時期を把握することが大切です。Lambda 関数の同時実行などの一部のリソースでは、CloudWatch を使った追跡が可能です。EC2 インスタンスの数といったその他のリソースは、手動で、またはスクリプトを使って追跡する必要があります。ビジネスサポートプラン、またはエンタープライズサポートプランをご利用の場合は、AWS Trusted Advisor サービスを使って制限を追跡できます。awslimitchecker などのオープンソースツールも、プロセスの自動化に使用できます。


    重要ポイント

    • 制限は、サービスを過剰な負荷から保護するために適用できる制約
    • AWS のサービス制限は、サービスクォータサービスを使って追跡/管理することができる
    • 緩和可能なソフト制限と、緩和不可能なハード制限がある
    • サービスの中断を避けるため、使用しているサービスの制限をモニタリングし、状況に応じて制限の緩和を計画する


    その他の資料

まとめ

このモジュールでは、AWS の信頼性の柱について学びました。障害影響範囲の観点から考えるメンタルモデルについて学びました。障害影響範囲を制限するための障害の分離ゾーンの使用について学びました。サービスの制限、およびサービスの中断を避けるために制限を引き上げる方法について学びました。

 

その他の資料

運用上の優秀性

運用上の優秀性の柱は、システムを実行し、より優れた手順を作成して、洞察を得る能力を継続的に向上させる方法に焦点を当てています。


メンタルモデル

クラウドにおける運用上の優秀性について考えるときは、オートメーションの観点から考えることが役に立ちます。

欠陥および運用上のインシデントの主な原因は人為的エラーです。自動化できる操作が多ければ多いほど、人為的エラーの可能性が減ります。

エラーの防止に加えて、オートメーションは内部プロセスの継続的な改善にも役立ちます。これらは、組織全体に適用できる反復可能なベストプラクティスを促進します。


概念

運用をオートメーションとして考えるときは、現在最も多くの手作業を必要とする分野、およびエラーが最も大きな問題を引き起こす分野における取り組みに焦点を当てます。また、運用作業を追跡、分析、および改善するためのプロセスも設定します。

ここでは、以下にある 2 つの運用上の優秀性の概念に注目します。

  1. Infrastructure as Code
  2. オブザーバビリティ


  • Infrastructure as Code (IaC) とは、機械可読な設定ファイルを使ってインフラストラクチャを管理するプロセスです。IaC は、インフラストラクチャのオートメーションを可能にする土台で、

    サービスを手動でプロビジョニングするのではなく、必要なリソースを記述するテンプレートを作成します。作成後、IaC プラットフォームがユーザーに代わってリソースのプロビジョニングと設定を処理します。

    IaC は、インフラストラクチャをプロビジョニングする宣言的で自動化された方法を提供します。これは、コードですでに行っているように、同じツール (例: git) とプロセス (例: コードレビュー) をインフラストラクチャに適用することを可能にします。

    AWS の IaC は、以前から CloudFormation サービスを使って実装されてきました。CloudFormation では、JSON または YAML を使ったリソースの宣言が必要ですが、これらの構成言語を使用したくない場合のために、AWS では JavaScript、Python、および Java などのネイティブプログラミング言語を使って CloudFormation テンプレートを作成できる Cloud Development Kit (CDK) も提供しています。

     

    重要ポイント

    • IaC は、機械可読な設定ファイルを使ってインフラストラクチャを管理するプロセス
    • IaC はインフラストラクチャをプロビジョニングする宣言的で自動化された方法
    • コードと同様に、インフラストラクチャに同じツールとプロセスを適用できる
    • AWS での IaC の実装には、CloudFormation および CDK などのサービスを使用する
     

    その他の資料

  • オブザーバビリティとは、システム内部の状態を測定するプロセスです。これは通常、システムを望ましい最終状態に最適化するために行われます。

    運用上の優秀性では、測定しないものを改善することはできません。オブザーバビリティの堅固な土台を構築することは、オートメーションの影響を追跡し、それを継続的に改善する能力を提供します。

    オブザーバビリティの実装には、以下の手順が伴います。

    1. 収集
    2. 分析
    3. アクション


    収集

    収集とは、システムの状態を評価するときに必要なメトリクスのすべてを集約するプロセスです。

    これらのメトリクスは、以下のカテゴリに当てはまります。

    • インフラストラクチャレベルのメトリクス
      • これらのメトリクスは、AWS のサービスによって自動的に生成され、CloudWatch サービスによって収集されます
      • サービスには、CloudWatch Logs を使って有効化し、収集できる構造化ログを生成するものもあります
    • アプリケーションレベルのメトリクス
      • これらのメトリクスは、ソフトウェアによって生成され、CloudWatch のカスタムメトリクスを使って収集できます
      • ソフトウェアログは、CloudWatch Logs を使って保存、または S3 にアップロードすることができます
    • アカウントレベルのメトリクス
      • これらのメトリクスは、AWS アカウントによってログに記録され、CloudTrail サービスを使って収集できます


    分析

    収集されたメトリクスの分析には、AWS が提供する多数のデータベースおよび分析ソリューションのひとつを使用できます。

    適切なソリューションの選択は、ユースケースに応じて異なります。

    • CloudWatch Logs に保存されたログの分析には、Cloudwatch のログデータをインタラクティブに検索して分析できるサービスである CloudWatch Logs Insight の使用を検討します
    • S3 に保存されたログの分析には、サーバーレスクエリサービスである Athena の使用を検討します
    • 構造化データの分析には、マネージド型リレーショナルデータベースサービスである RDS の使用を検討します
    • 大量の構造化データの分析には、ペタバイト規模のマネージド型データウェアハウスサービスである RedShift の使用を検討します
    • ログベースのデータの分析には、人気のオープンソース分析エンジン、Elasticsearch のマネージドバージョンである Elasticsearch Service の使用を検討します

     

    アクション

    メトリクスを収集して分析したら、それらを使って特定の成果またはプロセスを達成することができます。

    以下は、成果とプロセスの例です。

    • モニタリングとアラーム発行
      • CloudWatch Alarms を使って、システムが特定のメトリクスの安全メトリクスを超えた場合に通知を行います
      • このアラームは、手動または自動化された緩和対策を始動させることができます。
    • ダッシュボード
      • メトリクスのダッシュボードは、Cloudwatch ダッシュボードを使って作成することができます
      • これらのダッシュボードを使って、サービスのパフォーマンスを長期的に追跡し、改善することができます
    • データドリブンな意思決定
      • パフォーマンスとビジネス KPI を追跡して、製品のデータドリブンな意思決定を行うことができます

     

    重要ポイント

    • オブザーバビリティとは、望ましい最終状態を達成するためにシステム内部の状態を測定するプロセス
    • オブザーバビリティは、メトリクスの収集と分析、およびそれらに対するアクションの実行で構成される
    • メトリクスは、サービス、アプリケーション、およびアカウントレベルで収集できる
    • メトリクスは、CloudWatch Log Insight、Athena、Elasticsearch Service、RDS、および Redshift などのサービスを使用して分析できる
    • パフォーマンスとビジネス KPI をモニタリングし、アラームとダッシュボードを作成して追跡することで、メトリクス基づいたアクションを実行することができる

     

    その他の資料

まとめ

このモジュールでは、運用上の優秀性の柱について学びました。運用をオートメーションとして考えるメンタルモデルについて学びました。IaC について、および現在コードに使用しているものと同じツールとプロセスを使ってサービスを自動的にプロビジョニングするための IaC の使用方法について学びました。オブザーバビリティについて、および運用作業を継続的に改善するためにメトリクスを収集し、分析して、メトリクスに基づくアクションを実行する方法について学びました。

 

その他の資料

コスト最適化

コスト最適化の柱は、コストを最小限に抑えながらビジネス成果を実現するために役立ちます。


メンタルモデル

クラウドでのコスト最適化について考えるときは、CapEx ではなく OpEx の観点からクラウド支出を考えることが役に立ちます。OpEx は継続的な従量制料金モデルですが、CapEx はスポット購入モデルです。

オンプレミスデータセンターにおける従来の IT コストのほとんどが CapEx に当てはまり、最終的に使用することになるかどうかに関わらず、すべてのキャパシティーに対する費用を前払いします。新しいサーバーの購入は、複数の当事者からの承認を得なくてはならない長期間のプロセスになる恐れがありました。これは、CapEx コストが往々にして高額で、誤った判断が多大な損失をもたらすことに起因するものです。サーバー購入後も、実際に納品されるまで数週間かかる可能性がありました。

AWS では、コストが OpEx になり、使用するキャパシティーに対して継続的な支払いを行います。新しいサーバーのプロビジョニングは、長い承認プロセスを必要とすることなく、エンジニアリング部門がリアルタイムで実行できます。これは、OpEx コストがはるかに小額で、要件が変化した場合には撤回できるからです。使用分の料金のみを支払うので、余分なキャパシティーは停止して終了するだけですみます。サービスを使用することにした場合のプロビジョニングは、数秒および数分で完了できます。


概念

CapEx モデルから OpEx モデルへの移行は、インフラストラクチャの原価計算に対するアプローチを根底から変え、高額な先行固定費用ではなく、少額の継続的な可変費用で考えます。

この従量制料金モデルは、コスト最適化プロセスに以下の変化をもたらします。

  1. 従量制料金
  2. コスト最適化のライフサイクル


  • AWS のサービスは、使用するキャパシティーの料金のみを支払う従量制料金モデルを採用しています。以下は、従量制料金の場合にクラウド支出を最適化する 4 つの一般的な方法です。

    1. 規模最適化
    2. サーバーレス
    3. 予約
    4. スポットインスタンス


    規模最適化

    規模最適化とは、サービスのプロビジョニングと設定を、ワークロードに適合させることを指します。EC2 ベースのサービスでは、適切なインスタンスサイズとファミリーを選択するという意味になります。コンピューティングリソースのほとんどがアイドル状態である場合は、小規模の EC2 インスタンスの使用を検討します。ワークロードに特定のシステムリソースが大量に必要となる場合は、そのリソース向けに最適化されたインスタンスファミリーへの変更を検討します。

    このプロセスには、過去のシステムメトリクスに基づいて最適な EC2 サイズを提案する AWS Compute Optimizer を役立てることができます。


    サーバーレス

    Lambda のようなサーバーレステクノロジーの使用時には、使用分の料金のみを支払います。Lambda が実行されていない場合に料金はかかりません。サーバーレスは、従量制料金の究極的な例です。サーバーレスがユースケースで許容される場合は、サーバーレスの選択が最もコスト効率性の良いサービス構築手段となり得ます。


    予約

    予約のリクエストとは、大幅な割引と引き換えに、特定量のキャパシティーへの支払いを確約することを意味します。EC2 では、これがコンピューティングにおける最大 72% の割引につながる可能性があります。

    コンピューティングに対する予約を行うには、Savings Plans を使用できます。EC2、Fargate、および Lambda 全体でのコスト削減には、1 年または 3 年期間で特定の量のコンピューティングを使用する契約に申し込むことができます。

    予約は EC2 限定ではないことに留意してください。RDS、DynamoDB、および CloudFront といった他のサービスでもリクエストできます。


    スポットインスタンス

    EC2 スポットインスタンスでは、使用されていない EC2 キャパシティーを利用することで、オンデマンド料金よりも最大 90% 低い料金でインスタンスを実行できます。これは、耐障害性を備えたワークロードにおける大幅な節約につながる可能性があります。

    スポットインスタンスを使用する場合のトレードオフは、EC2 がそのキャパシティーをいつでも回収できることです。アプリケーションは、回収が行われる前に 2 分間の終了通知を受け取ります。


    重要ポイント

    • AWS のサービスは従量制料金 – 使用するキャパシティーの料金が課金される
    • インスタンスの規模を最適化して、ワークロードに適さないサービスの料金を節約することができる
    • サーバーレステクノロジーを使用して、お客様がサービスを使用するときの料金のみを支払うようにすることができる
    • 予約を使用して、前払いの義務と引き換えに割引を受けることができる
    • スポットインスタンスを使用して、耐障害性を備えたワークロードの実行で割引を受けることができる


    その他の資料

  • コスト最適化のライフサイクルは、長期間にわたってクラウド支出を改善させる継続的なプロセスです。

    これには、以下の 3 ステップのワークフローがあります。

    1. レビュー
    2. 追跡
    3. 最適化


    レビュー

    クラウド支出を最適化する前に、まず支出の出所を理解する必要があります。

    AWS Cost Explorer は、経時的なクラウド支出を視覚化してレビューするために役立ち、支出をサービスおよびカテゴリといった異なる側面で分類することができます。Cost Explorer は、請求の大まかな概要と、詳細レポートの両方を取得するために使用します。

    より詳細なデータが必要な場合は、AWS のコストと使用状況レポートを使用して、時間単位の明細項目を取得できます。


    追跡

    全体的なクラウド支出の概要を把握したら、関心がある側面に応じた分類を開始できます。これは、コスト配分タグを使って行います。これらは、追跡したい各タグで有効にする必要があります。

    以下は、タグカテゴリの一般的な例です。

    • アプリケーション ID – 支出変化の追跡を容易にするために、特定のアプリケーションに関連するリソースを識別し、プロジェクト終了時に無効化します。
    • オートメーションのオプトイン/オプトアウト – インスタンスの起動、停止、またはサイズ変更などの自動化されたアクティビティにリソースを含めるかどうかを示します。
    • コストセンター/事業単位 – リソースに関連付けられたコストセンターまたは事業単位を識別するもので、通常はコストの配分と追跡に使用されます。
    • オーナー – リソースの責任者を識別します。これは通常テクニカルオーナーです。必要な場合には、個別のビジネスオーナータグを追加できます。オーナーは E メールアドレスとして指定できます。E メールアドレスの使用は、必要に応じたテクニカルオーナーとビジネスオーナー両方への自動通知をサポートします (リソースが伸縮性または規模最適化の候補であるかどうかなど)。

    タグに加えて、AWS Budgets を使って予算目標を策定することもできます。Budgets を使用することにより、関心がある側面全体での支出をモニタリングできます。Budgets は、ユーザー設定のフィルタに従って、現在の AWS 支出の追跡と予測作成の両方を実行します。


    最適化

    支出をレビューして追跡した後は、最適化することができます。支出の最適化には、従量制料金で説明されている手法の導入が伴います。この最適化は通常、包括的な予算目標の一環として行われます。

    以下は、最適化目標の例です。

    • Cost Savings Plan の対象となる EC2 インスタンスの割合 – 組織では 80~90% を目標とするようにしてください
    • アイドル状態のリソースの割合 – アイドル状態の定義と正確な割合は、ビジネスに応じて異なります


    重要ポイント

    • コスト最適化までライフサイクルは、長期間にわたってクラウド支出を改善させる継続的なプロセス
    • コスト最適化のライフサイクルは、支出のレビュー、追跡、および最適化で構成される
    • 支出のレビューには、支出を理解するための Cost Explorer といったツール、およびコストと使用状況レポートの使用が伴う
    • 支出の追跡には、ビジネスに関連する側面に応じてデータをフィルタリングするためのコスト配分タグの使用と予算が伴う
    • 支出の最適化には、包括的な予算目標の一環として、前セクションからの手法を使用することが伴う


    その他の資料

まとめ

このモジュールでは、コスト最適化の柱について学びました。OpEx に焦点を合わせたモデルのクラウド支出への適用について学びました。規模最適化、サーバーレス、予約、およびスポットインスタンスといったコスト最適化手法について学びました。Cost Explorer、タグ、および Budgets といったサービスを使用して、予算のレビュー、追跡、および最適化を行うことについて学びました。

 

その他の資料

おめでとうございます!

これで AWS の基礎コースは終了です。このコースでは、以下について学習しました。

  • AWS Well-Architected フレームワークの 5 本の柱
  • 5 本の柱についてのクラウドネイティブな考え方を説明する重要なメンタルモデル
  • 5 本の柱それぞれにおける重要な概念

本コース修了時点で、パフォーマンス効率性、信頼性、および運用上の優秀性が高く、セキュアでコスト最適化されたサービスをクラウドで構築するための基礎を習得したことになります。知っておくべき事柄はまだまだ沢山ありますが、AWS ジャーニーの残りの行程のための確かな出発点を築きました。AWS の基礎コースを修了した今、AWS で次の素晴らしいサービスを構築するために、学んだ事柄をぜひ活用してください。