はじめてのアマゾン ウェブ サービス

AWS の基礎 ~ 主要概念 ~

はじめに

クラウドネイティブパラダイムは大変だよね、

この記事で得られるもの

1. 全てのサービス当てはまる AWS の 5 本の柱
2. クラウドについて考えるときに使用するメンタルモデル
3. クラウドについて考えるときの重要な概念

5本の柱

AWS_Well-Architectedフレームワークに由来する、クラウドでのスケーラブルなアプリケーションの構築を可能にする主要素。

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

1. セキュリティ

クラウドでインフラストラクチャをセキュア化する方法に焦点を当てる

AWS側：物理的なセキュリティを担う

我々：クラウド内におけるセキュリティ

メンタルモデル

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

→　このモデルでは、アプリケーションのコンポーネントとサービスのすべてが、害を及ぼす可能性のある個別のエンティティと見なされます。

エンティティ：実体・ER図に出てくる箱

概念

ゼロトラストという考えから...

→　システムのあらゆるレベルにセキュリティ対策を適用する必要があるということ

以下は、クラウドにおけるゼロトラストでのシステムのセキュア化に関する 3 つの重要な概念です。

1.Identity and Access Management (IAM)
システム内でのアイデンティティとアクセスの追跡に対する責任を担うサービス

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

2.ネットワークセキュリティ　ex.) VPCやWAFなど
ネットワークとネットワークにアクセスできるリソースのアクセスと可用性を保護する、すべてのシステム、設定、またはプロセスが関与する。

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

3.データの暗号化　ex.) ALBやCMKなど
(データを解読するために必要なキーを持たない)サードパーティーにとって判別不能な方法で情報を暗号化するプロセス

転送時の暗号化・保管時の暗号化など

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

まとめ

このモジュールでは...
AWS のセキュリティの柱について学んだ

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

2. パフォーマンス効率

クラウドでサービスを効率的かつスケーラブルに実行する方法

メンタルモデル

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

• オンプレミスモデル：サーバーが高額, 手動でデプロイメントと設定, サーバーが実際に納品, データセンターに物理的に接続されるまで数週間かかる, など
  →　それぞれがユニークで多くのメンテナンスが必要となる
  =　ペットのように扱われていた

• クラウドでは、サーバーを家畜として考える
  クラウド：数秒で自動的にプロビジョニングできる

概念

「家畜モデル」ではプロビジョニングが安価かつ迅速であるため、ワークロードに最も近いサーバータイプを選択する自由が得られます。サービスのスケーリングも容易であり、サーバーが置き替え可能で、迅速にデプロイできる

1. 選択 使用の開始には適切なサービスの選択が重要 AWS の 4 つの主要サービスカテゴリ、つまりコンピューティング、ストレージ、データベース、およびネットワーク

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

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

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

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

1. スケーリング
   継続的なパフォーマンスにはスケーリング方法の選択が重要
   AWSにおける2 つの主なスケーリング手段

   1. 垂直スケーリング　大きくなるイメージ(基盤となるコンピューティングのより大きなインスタンスタイプへのアップグレード)
   2. 水平スケーリング　増えるイメージ(基盤となるインスタンスの数の増加)
      • 垂直スケーリングは運用面ではシンプルだが、可用性のリスクがあり、上限も低い
      • 水平スケーリングにはより多くのオーバーヘッドが必要だが、はるかに優れた信頼性と、大幅に高い上限がある

まとめ

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

3. 信頼性

サービスとインフラストラクチャ両方の中断に対する耐障害性を備えたサービスを構築する方法
クラウドは中断に耐え得る耐障害性を備えたサービスを構築する手段を提供する、そのために信頼性を念頭に

メンタルモデル

信頼性について考えるときは、障害影響範囲の観点から考えることが役に立つ
信頼性の高いシステムを構築する = 個々のコンポーネントの障害影響範囲を最小限化する

概念

障害の問題はもはや発生するかどうかの問題×ではなくなり、いつ発生するか○になります。

1. 障害の分離　ダメージを抑えるイメージ

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

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

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

2. 制限　サービスを囲う・守るイメージ、またそのライン

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

   AWSのそれぞれのサービスには、アカウントおよびリージョンごとにサービス固有の制限"サービスクォータ"が存在する

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

まとめ

AWS の信頼性の柱について学んだ
障害影響範囲の観点から考える
障害影響範囲を制限するための障害の分離ゾーンの使用について
サービスの制限、およびサービスの中断を避けるために制限を引き上げる

4. 運用上の優秀性

システムを実行し、より優れた手順を作成して、洞察を得る能力を継続的に向上させる方法

メンタルモデル

オートメーションの観点から考える

自動化できる操作が多ければ多いほど、人為的エラーの可能性が減る

内部プロセスの継続的な改善にも役立つ
= 組織全体に適用できる反復可能なベストプラクティスを促進

概念

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

1. Infrastructure as Code

   機械可読な設定ファイルを使ってインフラストラクチャを管理するプロセス

   インフラストラクチャのオートメーションを可能にする土台

   コードですでに行っているように、同じツール (例: git) とプロセス (例: コードレビュー) をインフラストラクチャに適用することを可能に

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

1. オブザーバビリティ

   システム内部の状態を測定するプロセス

   システムを望ましい最終状態に最適化する

   オートメーションの影響を追跡し、それを継続的に改善する能力を提供であり、以下の手順が伴う

   1. 収集 システムの状態を評価するときに必要なメトリクスのすべてを集約するプロセス
   2. 分析 収集されたメトリクスの分析には、AWS が提供する多数のデータベースおよび分析ソリューションのひとつを使用できます
   3. アクション それらを使って特定の成果またはプロセスを達成することが可能

- 望ましい最終状態を達成するために、システム内部の状態を測定するプロセス
- メトリクスの収集と分析、およびそれらに対するアクションの実行で構成

まとめ

運用上の優秀性の柱について学んだ

運用をオートメーションとして考える

IaC について、および現在コードに使用しているものと同じツールとプロセスを使ってサービスを自動的にプロビジョニングするための IaC の使用方法について学んだ

オブザーバビリティについて、および運用作業を継続的に改善するためにメトリクスを収集し、分析して、メトリクスに基づくアクションを実行する方法について学んだ

5. コスト最適化

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

メンタルモデル

CapEx ではなく OpEx の観点からクラウド支出を考える

OpEx は継続的な従量制料金モデルですが、CapEx はスポット購入モデルです。

オンプレミスデータセンターにおける従来の IT コストのほとんどが CapEx に当てはまる

すべてのキャパシティーに対する費用を前払い

AWS では、コストが OpEx になり、使用するキャパシティーに対して継続的な支払いを行う

エンジニアリング部門がリアルタイムで実行できる。なぜならOpEx コストがはるかに小額で、要件が変化した場合には撤回できるから

概念

高額な先行固定費用ではなく、少額の継続的な可変費用で考える

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

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

2. コスト最適化のライフサイクル

   長期間にわたってクラウド支出を改善させる継続的なプロセスです。

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

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

まとめ

コスト最適化の柱について学んだ

OpEx に焦点を合わせたモデルのクラウド支出への適用について

規模最適化、サーバーレス、予約、およびスポットインスタンスといったコスト最適化手法について

Cost Explorer、タグ、および Budgets といったサービスを使用して、予算のレビュー、追跡、および最適化を行う

こちらからは以上です！！