下記サイトの理解を深めるため、自分なりに整理しないがらすすめたメモです。
5本の柱
セキュリティ
- セキュリティの柱は、クラウドでインフラストラクチャをセキュア化する方法に焦点を当てている。セキュリティとコンプライアンスは AWS とお客様の間における責任共有。
- この責任共有モデルでは、AWS がクラウドのセキュリティに対する責任を担う。これには、AWS クラウドサービスの物理的なインフラストラクチャ、ソフトウェア、およびネットワーキング機能が含まれる。
- ユーザーはクラウド内でのセキュリティに対する責任を担う。これには、特定のクラウドサービスの設定、アプリケーションソフトウェア、および機密データの管理が含まれる。
考え方
クラウドのセキュリティについて考えるときは、ゼロトラストのモデルを取り入れることが役立つ
概念
ゼロトラストの観点からセキュリティを考えるということは、システムのあらゆるレベルにセキュリティ対策を適用する必要があるということ
Identity and Access Management(IAM)
- IAM は、システム内でのアイデンティティとアクセスの追跡に対する責任を担うサービス。
- AWS内のエンティティに対するアクセス境界を宣言する
IAMポリシーの3要素
- プリンシパル：誰に許可が付与されるかを指定
- アクション：何が実行されるかを指定
- リソース：どのプロパティがアクセスされるかを指定
ポリシータイプ
- アイデンティティベースのポリシー：そのアクションを許可しているか
- リソースベースのポリシー：そのアクションを禁止していないか
- 他多数
ネットワークセキュリティ
ゼロトラストアプローチは多層防御
ネットワークレベルのセキュリティ
AWSにおける基本的なネットワークレベルの基本はAmazon Virtual Private Cloud (VPC) 、これはユーザーが定義してリソースをプロビジョニングできる論理ネットワーク
| Amazon Virtual Private Cloud (VPC) |
|---|
| リソースの配置、接続性、セキュリティなど、仮想ネットワーク環境を完全に制御することができるクラウド |
| プロビジョニング |
|---|
| 必要に応じてネットワークやコンピュータの設備などのリソースを提供できるよう予測し、準備しておくこと |
VPCを構成するコンポーネント
- サブネット：VPC内のIPアドレスの範囲
- ルートテーブル：トラフィックの送信先を決定する規則のセット
- インターネットゲートウェイ：VPC内のリソースとインターネットの間における通信を許可するコンポーネント
- 他多数
サーバーおよびデータベースといった内部サービスのすべてを、直接的なパブリックインターネットアクセスから切り離された内部サブネット内にプロビジョニングするために、
- トラフィックを保護するために、リソースを外部向けリソースと内部リソースに分けることができる
- 攻撃対象領域を減らすには、インターネット向けトラフィックの全てを処理するために、Application Load Balancer (ALB) などのプロキシサービスを使用できる
- VPC に加えて、AWS Web Application Firewall (WAF) を使ってネットワークへのトラフィックをさらに制限することもできる。
| Application Load Balancer |
|---|
| 受信したトラフィックを複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させる |
| AWS Web Application Firewall (WAF) |
|---|
| 可用性、セキュリティ侵害、リソースの過剰消費に影響を与えるような、ウェブの脆弱性を利用した一般的な攻撃やボットから、ウェブアプリケーションまたは API を保護する |
リソースレベルのセキュリティ
個々の AWS リソースにも、ユーザーが設定できるネットワークセキュリティコントロール、セキュリティグループなど
- リソースに出入りするトラフィックへ適用できる仮想ファイアウォール
- インスタンスに特定のポートおよび信頼されたソースからのトラフィックのみを許可する
- EC2 インスタンス、RDS インスタンス、および Lambda などのリソースでつかえる
データ暗号化
データを解読するために必要なキーを持たないサードパーティーにとって判別不能な方法で情報を暗号化するプロセス
転送時の暗号化
- システム間を行き来するデータの暗号化
保管時の暗号化
- システム内のデータの暗号化
- データを暗号化するためのカスタマー管理のキー (CMK) を作成する機能を提供するAmazon Key Management Service (KMS) と直接的に統合されている
- 独自のカスタムキーストアを使用する能力、AWS CloudTrail との統合によって暗号化されたリソースの監査証跡を作成する能力、および自動キーローテーションの実施が含まれる
| AWS CloudTrail |
|---|
| AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービス |
パフォーマンス効率
考え方
- クラウドにおけるパフォーマンス効率について考えるときは、サービスを cattle、not pets （ペットではなく家畜） として考えることが役に立つ
- サーバーは、数秒で自動的にプロビジョニングできる商品リソース
概念
- 「ペットモデル」では、異なるマシンを注文してプロビジョニングするのはあまりにも面倒だったので、複数のワークロードに同じタイプのサーバー (あるいは同じサーバー) を使用していた
- 「家畜モデル」ではプロビジョニングが安価かつ迅速であるため、ワークロードに最も近いサーバータイプを選択する自由が得られる
選択
選択を通じたパフォーマンスの達成は、ジョブに適切なツールを選択すること
通常、AWS の 4 つの主要サービスカテゴリ、つまりコンピューティング、ストレージ、データベース、およびネットワークのいくつかで選択を行うことが必要になる
- コンピューティング：データを処理するサービスに対応する (例: 仮想マシン)
- ストレージ：データの静的ストレージに対応する (例: オブジェクトストア)
- データベース：データの編成されたストレージに対応する (例: リレーショナルデータベース)
- ネットワーク：データの移動方法に対応する (例: コンテンツ配信ネットワーク)
選択を行うサービスのカテゴリにかかわらず、検討する必要がある 3 つの事柄
サービスのタイプ
コンピューティングサービスの選択
- VM ベース
ほとんどの人にとって最も身近なメンタルモデルがありますが、より高額で、より多くのメンテナンスが必要となる場合がある - コンテナベース
ワークロードのより詳細な部分を有効にし、素早くスケーリングできますが、設定とオーケストレーションがより複雑になる - サーバーレスベース
管理とスケーリングの複雑性のほとんどを取り除きますが、ハードシステム制限があり、新しいツールチェーンとプロセスの導入が必要になる
| オーケストレーション |
|---|
| コンピュータシステム、アプリケーション、およびサービスにおける、設定、管理、調整の自動化 |
ストレージサービスの選択
- ブロックストア
単一のEC2インスタンスからのデータを永続化するために最適、EBSなど - ファイルストア
同じデータへのアクセスを複数のクライアントに提供するために最適、EFS - オブジェクトストア
多数のクライアントによるアクセスが必要となる、複数の大きなデータの塊に最適、S3 - アーカイブストア
頻繁にアクセスする必要がない大量のデータに最適、S3 Glacier
データベースサービスの選択
- リレーショナルデータベース
JoinおよびACIDプロパティを使用できますが、パフォーマンスとデータストレージ上限がある - 非リレーショナルデータベース
柔軟なスキーマがあり、リレーショナルデータベースよりも大幅に高い上限までスケールできますが、Join および完全な ACID特性がないのが一般的 - データハウスソリューション
ペタバイト規模の構造化データへの迅速なアクセスによる大規模な分析を可能にする - データのインデックス作成と検索ソリューション
さまざまなソースからのデータをインデックス化し、検索することができる
| ACID特性 |
|---|
| 関連する複数の処理を一つの単位として管理するトランザクション処理に求められる4つの特性 “Atomicity”（原子性）、“Consistency” （一貫性）、“Isolation”（独立性）、“Durability”（耐久性） |
管理レベル
コンピューティングサービス
- VMタイプはEC2、Lightsail、Elastic Beanstalkから選択する
- EC2は最大のコントロールを提供する
- Lightsailはカスタム化の一部が使用できない代わりに、はるかに優れたマネージドエクスペリエンスが得られる
- Elastic BeanstalkはEC2とLightsailの中間に位置し、サービスアーキテクチャに独断的なフレームワークを提供するとともに、設定でカスタマイズすることも可能
ストレージサービス
- 所定のタイプにひとつしかサービスしかない傾向があるので、比較的簡単
- オブジェクトストアにはS3、ファイルストアにはEFSなど
データベースサービス
- RDS と Aurora のいずれかを選択する
- Aurora は特定バージョンの MySQL および PostgreSQL でしか機能しないが、基盤となるストレージの管理を行い、クラスタリングサポートが組み込まれている
- 基盤となるテクノロジーに対する熟知度と、希望するマネージドエクスペリエンスによって決まる
設定
コンピューティングサービスのパフォーマンス特性の評価
達成したい特定のパフォーマンス特性に依存するので、パフォーマンス特性を評価するときは、メモリとコンピューティングの要件を検討することから始めるといい
- VMベース
インスタンスのサイズ(t3.small／t3.xlarge)およびインスタンスファミリー(r3.small／c5.small)がメモリとCPUに影響する - コンテナベース
メモリとCPUを個別に設定できる - サーバーレスベース
メモリだけ直接設定できる、他のシステムリソースは利用可能なメモリ量に対して線形に増加する
ストレージサービスのパフォーマンス特性の評価
- ブロックストレージサービス
レイテンシー：選択したボリュームタイムによって変動
スループットは：プロビジョニングされたスループットを使用する選択によって変動
IOPS：キャパシティーは、ほとんどのボリュームタイプのボリュームサイズに比例 - ファイルシステムサービス
レイテンシー／IOPS：選択したパフォーマンスモードによって変動
スループット：プロビジョニングされたスループットを使用する選択によって変動 - オブジェクトストア
レイテンシー：バケットのエンドポイントまでの地理的な距離によって変動
スループット：マルチパートアップロードなどのスループットが最適化されたAPIの使用によって変動
IOPS：設定不可 - アーカイブストア
レイテンシー：パケットのエンドポイントまでの地理的な距離、および取得メソッドの選択によって変動
スループット：マルチパートアップロードなどのスループットが最適化されたAPIの使用によって変動
IOPS：設定不可
データベースサービスのパフォーマンス特性の評価
- リレーショナルデータベース
リソースの機能性は、選択する EC2 インスタンスによって決まる - 非リレーショナルデータベース（DynamoDB など）
リソースの機能性は、プロビジョニングされたキャパシティーなどの設定オプションによって決まる - データウェアハウスソリューション（Redshift など）
リソースの機能性は、基盤となる EC2 インスタンスの選択によって決まる - インデックス作成ソリューション（Elasticsearch Service など）
リソースの機能性は、選択する EC2 インスタンスによって決まる
重要ポイント
- ワークロードの実装はコンピューティング、ストレージ、データベース、およびネットワーク（カテゴリ）ごとに行う
- 各カテゴリでは、ユースケースに基づいて適切なサービスタイプを選択する
- 各サービスタイプでは、希望する管理レベルに基づいて特定のサービスを選択する
- 各サービスでは、達成したい特定のパフォーマンス特性に基づいて特定の設定を選択する
スケーリング
AWSでの主なスケーリング手段
- 垂直スケーリング
- 水平スケーリング
垂直スケーリング
基盤となるコンピューティングのインスタンスサイズにより規模の増減を調整する（t3.small⇒t3.largeなど）
- メリット
サービスをクラスター化することなく実装できるので、より簡単に実行できる - デメリット
水平スケーリングと比べ上限が大幅に低くなる
インスタンスの中断がサービスの完全な利用不能化を引き起こす可能性があるため、単一障害点になる
水平スケーリング
基盤となる コンピューティングの インスタンスの数により規模の増減を調整する
- メリット
障害性が優れている
大幅に高い上限までスケールできる - デメリット
サービスのフリートにトラフィックをルーティングするプロキシサービスが必要になる、ワークロードに最適な特定のルーティングアルゴリズムを選択する必要もあるので、実装面で多くのオーバーヘッドが生じる
| フリート |
|---|
| もののあつまり |
信頼性
中断に対する耐障害性を備えたサービスを構築する方法
クラウドが中断に耐え得る耐障害性を備えたサービスを構築する手段を提供するが、信頼性を念頭にサービスを設計することが必要になる
考え方
- クラウドの信頼性を考えるときは、障害影響範囲の観点から考えるといい
- 信頼性の高いシステムを構築するには、個々のコンポーネントの障害影響範囲を最小化する
| 障害影響範囲 |
|---|
| システム障害発生時に受ける可能性がある最大の影響 |
概念
発生するかどうかではなく、いつ発生するかが障害の問題
障害の分離
障害の分離ゾーンによってインシデントの障害影響範囲を制限し、ゾーン内のエリアに対する障害の影響を封じ込める
リソースとリクエスト
- 全てのリソースとリクエストをパーティション（セル）化し、各セル内に障害を封じ込めるように設計されている
- シャッフルシャーディングなどの手法によって障害影響範囲を制限する
アベイラビリティゾーン(AZ)
- 専用の電力、サービス、およびネットワーク機能を持つ完全に独立した施設
- 火災や洪水などの環境災害による相関障害を避けるため、他のAZとは地理的に離れている
リージョン
- ２つ以上のAZで構成される完全な自律データセンター
制限
- サービスを過剰な負荷から保護するために適用できる制約
- 外部インシデント（DDos攻撃など）と内部インシデント（ソフトウェアの誤設定など）の両方による障害影響範囲を制限するための効果的な手段
- サービスクォータ
AWSサービスのアカウントおよびリージョンごとのサービス固有の制限
AWSアカウント内の特定のリソース、アクション、および項目に対する最大値
制限の２つのタイプ
- ソフト制限：AWSによる制限緩和をリクエストすることで緩和が可能になる制限
- ハード制限：緩和不可能なハード制限
サービスクォータサービス
- サービスの制限を追跡し、緩和をリクエストするためのサービス
サービスの中断を避けるために、制限に近づく時期を把握することが大切
- Lambda関数の同時実行などの一部リソースでは、CloudWatchを使った追跡が可能
- EC2インスタンスの数といったその他のリソースは、手動またはスクリプトで追跡する必要がある
- ビジネスサポートプランまたはエンタープライズサポートプランでは、AWS Trusted Advisorサービスを使って制限を追跡できる
- オープンソースツールのawslimitcheckerも、プロセスの自動化で利用可能
運用上の優秀性
より優れた手順を作成し、洞察を得る能力を継続的に向上させる方法など
考え方
- オートメーションの観点から考えることが役に立つ
- 欠陥および運用上のインシデントの主な原因は人為的エラー、操作を自動化することで人為的エラーの可能性が減る
- 自動化はエラーの防止に加え、内部プロセスの継続的な改善につながる
概念
自動化で焦点を当てるポイント
- 最も多くの手作業を必要とする分野
- エラーが最も大きな問題を引き起こす分野
Infrastructure as Code(IaC)
- 機械可読な設定ファイルを使ってインフラストラクチャを管理するプロセス
- インフラストラクチャのオートメーション化の土台
- サービスを手動でプロビジョニングせず、必要なリソースを記述するだけで、Iacプラットフォームがリソースのプロビジョニングと設定を自動で行う
- インフラクトラクチャをプロビジョニングする宣言的で自動化された方法を提供する
CloudFormation
- AWSのIaC
- JSONまたはYAMLを使ったリソースを宣言して利用
Cloud Development Kit(CDK)
- JavaScript、Python、javaなどのネイティブプログラミング言語を使ってCloudFormationテンプレートを作成できる
オブザーバビリティ
- システム内部の状態を測定するプロセス
- システムを望ましい最終状態に最適化する
- オートメーションの影響を追跡し、計測的に改善する能力を提供する
収集
システムの状態を評価するときに必要なメトリクスの全てを集約するプロセス
インフラストラクチャレベルのメトリクス
- AWSのサービスによって自動的に生成され、CloudWatchサービスによって収集される
- サービスにはCloudWatch Logsを使って有効化し、収集できる構造化ログを生成するものもある
アプリケーションレベルのメトリクス
- ソフトウェアにより生成され、CloudWatchのカスタムメトリクスを使って収集する
- ソフトウェアログは、CloudWatch Logsを使って保存、またはS3にアップロードすることができる
アカウントレベルのメトリクス
- AWSアカウントによってログ記録され、CloudTailサービスを使って収集する
分析
収集したメトリクスはAWSのデータベースおよび分析ソリューションを使用して分析できる
CloudWatch Logsに保存されたログの分析
Cloudwatch のログデータをインタラクティブに検索して分析できるサービスである CloudWatch Logs Insightを使用を検討
構造化データの分析
マネージド型リレーショナルデータベースサービスである RDS の使用を検討
大量な構造化データの分析
ペタバイト規模のマネージド型データウェアハウスサービスである RedShift の使用を検討
ログベースのデータの分析
人気のオープンソース分析エンジン、Elasticsearch のマネージドバージョンである Elasticsearch Service の使用を検討
アクション
メトリクスを収集して分析した結果を使って特定の成果、またはプロセスを達成する
システムが特定のメトリクスの安全メトリクスを超えた場合に通知を行える
このアラームは、手動または自動化された緩和対策を始動させることができる
サービスのパフォーマンスを長期的に追跡し、改善することができる
データドリブンな意思決定
パフォーマンスとビジネス KPI を追跡して、製品のデータドリブンな意思決定を行うことができる
コスト最適化
コストを最小限に抑えながらビジネス成果を実現する
考え方
クラウドのコスト最適化について考えるときは、CapEx(スポット購入モデル)ではなくOpEx(継続的な従量制料金モデル)の観点からクラウド支出を考えるといい
CapEx(スポット購入モデル)
- キャパシティーに対する費用を一括で支払うため、高額になりがち
- 要件が変化したり誤った判断によって、多大な損失をもたらす可能性がある
- 購入後から納品、サービス開始まで数週間かからう可能性がある
- 支払いが高額であったり、多大な損失の可能性があるので、承認プロセスが長期間になる可能性がある
OpEx(継続的な従量制料金モデル)
- 承認プロセスはエンジニアリング部門がリアルタイムで実行できる
- 継続的な支払になるがCapExと比較してはるかに小額
- 要件が変化した場合、余分なキャパシティーは増減可能なため、損失を最小限に抑えられる
- サービス開始まで数秒または数分で完了できる
概念
CapExモデルからOpExモデルへの移行は、インフラストラクチャの原価計算に対するを高額な先行固定費用ではなく、少額の継続的な可変費用で考えること
従量制料金
AWSでクラウド支出を最適化する４つの一般的な方法
規模最適化
- サービスのプロビジョニングと設定を、ワークロードに適合させること
- EC2ベースのサービスでは、適切なインスタンスサイズとファミリーを選択すること
- コンピューティングリソースのほとんどがアイドル状態である場合は、小規模のEC2インスタンスの使用を検討
- ワークロードに特定のシステムリソースが大量に必要となる場合は、最適なインスタンスファミリーへの変更を検討すること
| AWS Compute Optimizer |
|---|
| ワークロードのコストを削減してパフォーマンスを改善する最適な AWS Compute リソースのレコメンデーション |
サーバーレス
- 使用分の料金のみを支払う
- 従量制料金の究極的な例
- サーバーレスが許容される場合は、サーバーレスが最もコスト効率性の良いサービス構築手段となる
予約
- 予約のリクエストとは、大幅な割引と引き換えに、特定量のキャパシティーへの支払いを確約すること
- EC2限定ではなく、RDS、DynamoDB、およびCloudFrontでも予約のリクエストができ、
- EC2では、これがコンピューティングにおける最大72％の割引につながる
- 予約のリクエストはSavings Plansで使用できる
| Saving Plans |
|---|
| 1 年または 3 年の期間で特定の使用量 (USD/時間で測定) を契約するかわりに、オンデマンド料金と比較して低料金を実現する柔軟な料金モデル |
スポットインスタンス
- 使用されていないEC2キャパシティーを利用することで、オンデマンド料金よりも最大90%低い料金でインスタンスを実行できる
- 耐障害性を備えたワークロードにおける大幅な節約につながる可能性がある
- トレードオフは、EC2が使用していなかったキャパシティーをいつでも回収できる。回収前に2分間の終了通知が発行される
コスト最適化のライフサイクル
長期間にわたってクラウド支出を改善させる継続的なプロセスで、以下の2ステップのワークフローがある
レビュー
クラウド支出を最適化するために、支出の出所を理解する必要がある
| AWS Cost Explorer |
|---|
| AWS Cost Explorer ではクラウド支出を視覚化して、支出をサービスおよびカテゴリといった異なる側面で分類することができるので、レビューするために役立つ。請求の大まかな概要と、詳細なレポートが取得できる。 より詳細なデータはAWS のコストと使用状況レポートで確認できる。 |
追跡
レビュー結果をもとに、関心がある側面の支出をモニタリングして追跡する
追跡するためにはコスト配分タグが活用できる
以下がタグの例
- アプリケーションID
プロジェクトに関係する特定のアプリケーションに関連するリソースを識別する - オートメーションのオプトイン／オプトアウト
リソースに関連付けられたインスタンスの起動、停止、またはサイズ変更などの自動化されたアクティビティを識別する - コストセンター／事業単位
リソースに関連付けられたコストセンターまたは事業単位を識別する - オーナー
リソースの責任者を識別する
AWS Budgets を使って予算目標を策定して支出をモニタリングすることもできる
最適化
支出のレビューや追跡した結果をもとに最適化をする
最適化には、従量制料金で説明された手法で行う
最適化目標の例
- EC2インスタンスの割合
Cost Saving Planの対象なので、組織では80%～90%を目標とする - アイドル状態のリソースの割合
アイドル状態の定義と正確な割合は、ビジネスに応じて異なる
