Amazon AWSソリューションアーキテクト・アソシエイト試験(SAA-C02)の受験を検討している。最短で取得したいので、「試験の概要」「効率的な学習方法」「学習時間」を知りたい。前回の記事で「試験の概要」「効率的な学習方法・学習時間」については分かったので、「試験内容について、具体的な概念や用語についても把握したい」
上記について、筆者自身が近々AWSソリューションアーキテクト・アソシエイト(以下、試験と記載します)を受験する予定なので、学習内容をまとめる意味も込めて、記事を作成します。
この試験については、2回シリーズでご紹介しており、前回の記事で「試験の概要」「効率的な学習方法・学習時間」について、今回の記事で、「試験内容について、具体的な概念や用語について」をご紹介します。ご興味があれば、前回の記事もご覧いただけますと幸いです。
【参考記事】
>> 【第1回】AWSソリューションアーキテクトアソシエイト勉強法/初心者が最短合格するための学習方法
>> 【第2回】AWSソリューションアーキテクトアソシエイト勉強法/主な学習トピックとポイント(本記事)
この記事で分かること
主な学習トピックと学習ポイント
以下に主な学習トピックとポイントをまとめました。内容としては、学習を進めるなかで、筆者がAmazonの公式ページやその他教材、動画、などで学んだ事項を自分なりにまとめたものとなります。
【参考にさせていただいたページ】
>> 【公式】AWS ドキュメント
>> AWSチャンネル
>> Acrovision > 技術記事 >AWS
>> これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)
もし記載誤り、お気づきの点などございましたら、以下の問い合わせページよりご指摘いただけますと幸いです。
>> 筆者へのお問い合わせ
主な学習トピック
- IAM (Identity and Access Management)_
- EC2 (Amazon Elastic Compute Cloud)_
- VPC (Amazon Virtual Private Cloud)
- S3 (Amazon Simple Storage Service)
- Well Architected Framework
- 信頼性の設計
- Route53
- データベース
- キャッシュの活用
- サーバレス
- 環境の自動化_
- セキュリティと運用_
IAM (Identity and Access Management)
-
IAMとは
- ・AWS Identity and Access Management
- ・安全にAWS操作を実施するための認証・許可の仕組み
- 【IAMでできること】
- ・AWS利用者認証の実施
- ・アクセスポリシーの設定
- ・ユーザー個人またはグループ毎に設定
-
責任共有モデル
- セキュリティに対して、AWSとユーザーとで責任分解して対応する責任共有モデルとなっている
ユーザー側の責任範囲 |
・AWSインフラストラクチャ -ユーザーアクセス -ロールベースのアクセス -ユーザーが利用するAWSサービス |
AWS側の責任範囲 |
・AWSインフラストラクチャ (ハードウェア、ソフトウェア、ネットワーク) ・AWSデータセンター |
-
ユーザーが利用するAWSサービス
- IAMによるアカウント管理
- セキュリティグループの設定
- アプリケーションのロールベースのアクセス設定
- ネットワーク/インスタンスオペレーションシステム(バッチ)などの設定
- OS/ホストベースのファイアウォール設置
—
・主要トピック
- ユーザー
- グループ
- ポリシー
- ロール
—
本記事の文字数が増えてしまったため、IAMについての詳細は以下の記事に移動しました。
>> 【AWS】IAM概要まとめ/ユーザー・グループ・ポリシー・ロールとは?
EC2 (Amazon Elastic Compute Cloud)
【参考】
>> 【公式】AWS ドキュメント EC2
>> 【公式】AWS ドキュメント EBS
-
主要トピック
- EC2の概要
- EBSの概要
EC2の概要
-
EC2とは
- 数分で利用可能となる従量課金(時間~秒単位)で利用可能な仮想サーバー
- 利用する単位をインスタンスと呼ぶ/仮想領域
- 任意のAZにインスタンスを立ち上げ、サーバーとして利用する
- 起動・ノード追加・削除・マシンスペック変更が数分で可能
- 汎用的なIntelアーキテクチャを採用
- 管理者権限で利用可能
- WindowsやLinuxなどのほとんどのOSをサポート
- OSまでは提供されているタイプを選択することで自動設定され、OSより上のレイヤーを自由に利用可能
- 独自のAmazon Machine ImageにOS設定を作成し、保存して再利用が可能
本記事の文字数が増えてしまったため、EC2についての詳細は以下の記事に移動しました。
>> 【AWS】EC2概要まとめ/EC2とは?概要、EC2のセッティング方法、EBSの概要について
VPC (Amazon Virtual Private Cloud)
【参考】
>>【公式】Amazon ドキュメント VPC
>> Amazon VPC とは?
-
Virtual Private Cloud (VPC)
- 任意のIPアドレス範囲を選択し、ネットワークを構築
- サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など仮想ネットワーキング環境を完全に制御可能
- 必要に応じてクラウド内外のネットワーク同士を接続することも可能
- 複数の接続オプションが利用可能
-インターネット経由
-VPN/専用線(Direct Connect)
VPCはAWSクラウド内に論理的に分離されたセクションを作り、ユーザーが定義した仮想ネットワークを構築するサービス
—
-
Virtual Private Cloud (VPC)
- 単一のVPCを構築すると、単一AZの範囲に設定される
—
-
Virtual Private Cloud (VPC)
- 同一リージョン内では、VPCは複数のAZにリソースを含めることが可能
—
-
サブネットとVPC
- VPCとサブネットの組み合わせでネットワーク空間を構築する。VPCはサブネットとのセットが必須
—
-
VPC設定手順
- CIDR方式でアドレスレンジを選択
- AZのサブネットを選択
- インターネット経路を選択
- VPCへのトラフィック許可を設定
—
本記事の文字数が増えてしまったため、VPCについての詳細は以下の記事に移動しました。
>> 【AWS】VPCとは?CIDRとは?VPCとの接続、VPCの設計ポイントについて
S3(Amazon Simple Storage Service)
【参考】
>> 【公式】AWS ドキュメント S3
Amazon Simple Storage Service(Amazon S3)の概要
- インターネット用のストレージ
- Amazon S3 を使用すると、データの大きさにかかわらず、ウェブ上のどんな場所からでもいつでも保存、取得することが可能
- シンプルかつ直感的なウェブインターフェイスの AWS マネジメントコンソール を用いて、これらのタスクを実行することが可能
- データをオブジェクトとしてバケットに保存
- オブジェクトは、ファイルと、そのファイルを記述する任意のメタデータ
- Amazon S3 にファイルをに保存するには、バケットにファイルをアップロード
- ファイルをオブジェクトとしてアップロードする際に、オブジェクトと任意のメタデータにアクセス権限を設定することが可能
- バケットは、オブジェクトのコンテナ
- 1 つまたは複数のバケットを持つことが可能
- バケットごとにアクセスを制御し、バケット内のオブジェクトを作成、削除、リスト化できるユーザーを決定することが可能
- Amazon S3 がバケットとそのコンテンツを保存する地理的リージョンを選択し、バケットとそのオブジェクトのアクセスログを表示することも可
なお、本記事の文字数が増えてしまったため、S3についての詳細は以下の記事に移動しました。
>> 【AWS】S3とは?概要、主な機能、料金体系、バケットなどについて
Well Architected Framework
信頼性の設計
ELBについて
ELBについては文字数が多くなったため、以下の記事にまとめましたのでよろしければ、ご覧ください。
>> 【AWS】ELBまとめ/ELBとは?概要、ELBのセッティング方法についてのまとめ
Auto-Scaling
【参考】
>> 【公式】AWS ドキュメント Auto Scaling
・AWS Auto Scalingの概要
概要 | ・需要に応じてインスタンスを自動的に増減させることができるサービス ・また、異常なインスタンスやアベイラビリティーゾーンを 自動で切り離すことを可能とし、 コスト最適化と高可用性を実現することができる |
AWS Auto Scalingの対象リソース | ・EC2 ・EC2スポットフリート ・ECS ・DynamoDB ・Aurora ※AWS Auto Scalingを使用することで、 自動でEC2インスタンスを増減したり(Amazon EC2 Auto Scaling) ECSサービスの増減、 DBのテーブルもしくは読み取り/書き込み容量を増減、 Auroraリードレプリカの数を増減する ※spot fleet スポットフリートリクエストで 指定した容量ターゲットを満たすように、 スポットインスタンスと オンデマンドインスタンスの数を調整して起動する機能 |
起動設定 | ・AMI ・インスタンスタイプ ・キーペア ・セキュリティグループ ・IAMロール ・Auto Scalingグループ ・EC2インスタンスの自動スケーリングとインスタンス数の維持を可能にする ・起動したインスタンスは複数のアベイラビリティーゾーン間で 均等にバランシングされる |
スケーリングプラン | 〇手動スケーリング ・高負荷バッチ処理が予定されているなどの場合に、 手動でスケーリングする ・インスタンス数の最小最大を設定し、 最小値と最大値の間でスケーリングを実施 〇動的スケーリング ・アクセス予測が困難な場合に、 CloudWatchを利用し閾値に基づいて インスタンス数を変動させる場合に利用 〇スケジュールスケーリング 例えば18時にアクセスが増大する傾向のあるアプリケーションなど、 予測可能なサービスの負荷に対応する場合に利用 〇ELB/ヘルスチェックの設定 ELB配下のインスタンスをAuto Scalingの対象とする場合、 使用するELBを選択し、さらにヘルスチェックの対象を EC2もしくはELBに設定 異常と判断された場合は、 該当のインスタンスを削除したうえで 新しいインスタンスを起動することで インスタンス数を維持 これはAuto Healingと呼ぶ ※ Elastic Load Balancing: アプリケーションへのトラフィックを複数のターゲット (Amazon EC2 インスタンス、コンテナ、 IP アドレス、Lambda 関数など) に 自動的に分散する機能 |
・AWS Auto Scalingのメリット
スケーリングを迅速に設定する | ・AWS Auto Scaling では、単一の直感的なインターフェイスで 複数のリソースに対するターゲット使用率レベルを設定できる ・他のコンソールに移動することなく、 すべてのスケーラブルリソースの平均使用率をすばやく確認できる ・例えば、アプリケーションが Amazon EC2 と Amazon DynamoDB を使用している場合、 AWS Auto Scaling を使用して、 アプリケーション内のすべての EC2 Auto Scaling グループと データベーステーブルのためのリソースプロビジョニングを管理できる |
スマートなスケーリング判断を行う | ・AWS Auto Scaling では、 異なるリソースのグループが需要の変化に対応する方法を 自動化するスケーリングプランを構築できる ・可用性、コスト、または両方のバランスを最適化することが可能 ・AWS Auto Scaling は、ユーザーの設定に基づいて、 すべてのスケーリングポリシーの作成とターゲットの設定を 自動的に行う ・AWS Auto Scaling はアプリケーションを監視し、 需要の変化に応じてリアルタイムで リソースグループの容量を自動的に追加または削除する |
パフォーマンスを自動的に維持する | ・ワークロードが断続的、予測不可能、または 継続的に変化している場合でも、 AWS Auto Scaling を使用すれば、 最適なアプリケーションのパフォーマンスと可用性を維持できる ・AWS Auto Scaling ではアプリケーションを継続的に監視して、 アプリケーションが望ましいパフォーマンスレベルで 確実に動作する ・需要が急増するときは、 優れたサービスの品質を維持できるように、 AWS Auto Scaling が制約されたリソースの容量を 自動的に増加させる。 |
必要分のみの支払い | ・AWS のサービスの消費時における使用率と コスト効率性の最適化に役立ち、 実際に必要なリソースの料金のみを支払うことができるようにする ・需要が減少すると、AWS Auto Scaling が 過剰なリソース容量を自動的に削除するので、 過度の支出を避けることができる ・AWS Auto Scaling の使用は無料で、 AWS 環境のコストの最適化を可能にする |
Amazon EC2 Auto Scaling
- アプリケーションの負荷を処理するために適切な数の Amazon EC2 インスタンスを利用できるように準備することが可能
- Auto Scaling グループと呼ばれる EC2 インスタンスの集合を作成
- Auto Scaling グループ内のインスタンスの最小数を指定することができ、Amazon EC2 Auto Scaling のグループはこのサイズよりも小さくなることはない
- 各 Auto Scaling グループ内のインスタンスの最大数を指定することができ、Amazon EC2 Auto Scaling のグループはこのサイズよりも大きくなることはない
- グループの作成時、またはそれ以降の任意の時点で、希望する容量を指定した場合、Amazon EC2 Auto Scaling によって、グループのインスタンス数はこの数に設定される
- スケーリングポリシーを指定する場合、Amazon EC2 Auto Scaling でアプリケーションに対する需要の増減に応じて、インスタンスを起動または終了できる
・スケールダウン
- メモリやCPUを削減すること
NewestInstance
- AutoScalingによって新しく設置されたインスタンスから削除される設定
・Auto-Scalingグループで設定する内容
- 起動インスタンスの最小数と最大数を設定する
- -起動台数をAZ館でバランシングする
- -AZ障害時には障害が発生していないAZにおいて、その分のインスタンスを起動するように構成
・起動設定で実施する内容
- インスタンスタイプを選択
・Auto-Scalingの設定
- ELBのターゲットグループを設定すれば、ELB構成を利用してELBのヘルスチェックによりAutoScalingを実行することが可能
・Auto-Scalingのターミネーションポリシーのデフォルト設定の動作
- 最も古い起動設定のインスタンスから削除する
Amazon RDS
【参考】
>> 【公式】AWS ドキュメント Amazon Relational Database Service
・Amazon Relational Database Service (Amazon RDS) とは
- Amazon Relational Database Service (Amazon RDS) は、AWS クラウドでリレーショナルデータベースを簡単にセットアップ、運用、スケーリングできるウェブサービス
- 業界標準のリレーショナルデータベース向けに、費用対効果に優れた拡張機能を備え、一般的なデータベース管理タスクを管理する
・Amazon RDS
-
- メモリ、パフォーマンス、または I/O に最適化されたいくつかのデータベースインスタンスタイプで利用可能
- 6 つの使い慣れたデータベースエンジンから選択可能
-Amazon Aurora
-PostgreSQL
-MySQL
-MariaDB
-Oracle データベース
-SQL Server
・RDSのリードレプリカの構築
- マスタースレーブ構成のスレーブに対するリードレプリカも構築することができる
- リードレプリカは非同期レプリケーションを実施している
- リードレプリカを利用することで、読み込み処理の負荷を下げることができる
・RDSのスナップショット
- RDSのスナップショットはリージョン内のS3に保存される
- スナップショットによる復元では別のDBを構築することになる
- スナップショットは自動/手動で取得することができる
・RDSを利用したスケーリング
- 途中でインスタンスタイプを縮小することができる
・RDSの暗号化対象
- RDSはそもそもオブジェクトは利用していないため、暗号化対象として不適切
- Amazon RDS リソースの暗号化オプションを有効化すると、AES-256 暗号化アルゴリズムにより DB インスタンス、 自動バックアップ、 リードレプリカ 、スナップショット、 ログを暗号化します
・RDSの暗号化方式
- AES-256
- SSE
- AWS KMS
・RDSのフェイルオーバー
- 手動で実施可能
・RDSを利用すべき判断ポイント
- マネージド型サービスを利用し、コストを削減したい
- DBソフトウェアのバージョンは必ずしも最新でなくてよい
- 冗長性の高いDB
ユースケース
EC2インスタンスを構築し、Webサイトを運営している。サービスの可用性をたかめるために使用される手法は?
EC2の障害から自動でリカバリするオートスケーリンググループ
Elastic Load Balancer
複数のAZ
Route53
【参考】
>> 【公式】AWS ドキュメント Route 53 ドキュメント
Amazon Route 53
- 可用性と拡張性に優れたドメインネームシステム(DNS)ウェブサービス
- Route 53 を使用すると、ドメイン登録、DNS ルーティング、ヘルスチェックの 3 つの主要な機能を任意の組み合わせで実行可能
- 3 つのすべての機能で Route 53 を使用するように選択した場合は、次の順序でステップを実行
-1. ドメイン名の登録
-2. ドメインのリソースへのインターネットトラフィックのルーティング
-3. リソースの正常性のチェック
プライベートホストゾーン
- 1つのプライベートホストゾーンで複数VPCに対応可能
- プライベートホストゾーン:Amazon VPC サービスで作成する 1 つ以上の VPC 内のドメインとそのサブドメインに対する DNS クエリに Amazon Route 53 が応答する方法に関する情報を保持するコンテ
- プライベートサブネット内のドメインをルーティングすることが可能
パブリックホストゾーン
- インターネット上に公開されたDNSドメインを管理する
- インターネットのDNSドメインに対するルーティング方法を定義する
レイテンシールーティングポリシー
- 複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用
- ユースケース
-A社はグローバルにサービス展開されるアプリケーションをAWSで構築しようとしている
-ユーザーにとって最も応答速度が速いサーバーからアクセスできるようにルーティングを実行する非機能要件を満たすために使用
エイリアスレコード
- Route 53 独自の DNS 拡張機能が提供
- エイリアスレコードを使用すると、選択した AWS リソース (CloudFront ディストリビューションや Amazon S3 バケットなど) にトラフィックをルーティング可能
- エイリアスレコードにより、ホストゾーン内のあるレコードから別のレコードにトラフィックをルーティング可能
トラフィックフロー
- 順序を設定することでルーティングポリシーを設定
- ユースケース
-Route53を利用して複雑なルーティングポリシーを設定する際などに使用
データベース
【参考】
>> 【公式】AWS ドキュメント Amazon DynamoDB
>> 【公式】AWS ドキュメント Amazon ElastiCache
>> 【公式】AWS ドキュメント Aurora
>> 【公式】AWS ドキュメント Amazon Elastic File System
DynamoDB
Amazon DynamoDBの概要
- Amazon DynamoDBは、どのような規模でも信頼性が高いパフォーマンスを維持できる、非リレーショナルデータベース(NoSQL)
- 完全マネージド型マルチリージョン、マルチマスターで耐久性があるデータベースで、セキュリティ、バックアップ及び復元と、インターネット規模のアプリケーション用のメモリ内キャッシュが組み込まれている
スケールに応じたパフォーマンス | ・規模に関係なく一貫した数ミリ秒台の応答時間を実現することで、 世界最大規模のアプリケーションの一部をサポートしている ・事実上無限のスループットとストレージでアプリケーションを構築可能 |
サーバー管理が不要 | ・DynamoDBはサーバーレスであり、プロビジョニング、パッチ適用、 管理するサーバーはなく、インストール、保守、運用する ソフトウェアもない。 ・DynamoDBは、テーブルを自動的にスケールアップ/ダウンして容量を調整し、 パフォーマンスを維持する。 ・可用性とフォールトトレランス機能が組み込まれているため、 こうした機能のためにアプリケーションを構築する必要はない |
エンタープライズ対応 | ・ビジネスクリティカルなアプリケーションを 大規模に構築できるようにACIDトランザクションをサポート ・デフォルトですべてのデータを暗号化 ・すべてのテーブルに対してきめ細かいIDと アクセスコントロールを提供 |
DynamoDBの特徴
- 半構造化データをドキュメントとして保存する「ドキュメントデータベース」でもある
- 1桁ミリ秒単位のレイテンシーを要求するアプリケーションにも対応
- 期限切れになった項目を自動的にテーブルから削除することも可能
- 格納と取得に特化されている(高度な最適化)
- 表結合など柔軟なクエリを発行するのは不得意
- 「値」とそれを取得するための「キー」だけを格納するというシンプルな機能を持った「Key Valueストア」
- 完全マネージド型の NoSQL データベースサービス
- 高速で予測可能なパフォーマンスとシームレスな拡張性が特長
- Amazon DynamoDB を使用して作成したデータベーステーブルによって、任意の量のデータの格納および取り出しができ、どのような量のリクエストトラフィックも処理可能
- Amazon DynamoDB によって自動的に、そのテーブルのデータとトラフィックが多数のサーバーに分散る
- サーバーの数は、お客様指定のリクエストキャパシティーと格納されているデータを処理するのに十分であるように選択される
- このような分散処理の間も、パフォーマンスは一定で、高速
DynamoDBのデータ整合性モデル
- デフォルトは結果整合性モデルですが、オプション機能で強い整合性モデルも利用
DynamoDBの設定
- 利用負荷があらかじめ予測できる場合はプロビジョンドスループットを選択することが最適
DynamoDBを利用すべきではないユースケース
- DynamoDBはJOIN/TRANSACTION/COMMIT/ROLLBACKが必要な複雑な処理には向いていない
DynamoDBによるクロスリージョンレプリケーション
- クロスリージョンレプリケーションを利用するためにはDynamoDB Streamsを有効化する必要がある
DynamoDB Streams
- 過去24時間以内のデータ変更履歴を保存、24時間を経過すると削除
- 操作が実施された順番に応じて、データはシリアライズされる
- データ容量はマネージド型で自動的に管理する
DynamoDBにおいてデータにインデックスを付けたいケース
- GSIはハッシュキーテーブル及び複合キーテーブルのどちらにでも設定可能
DynamoDBの設定手順
- テーブル作成 → 項目 → 属性
DynamoDB Accelerator(DAX)
- DAXクラスターは1秒間に数百万件のリクエストを処理することができる、インメモリ型のキャッシュ高速化を実現します。
ElastiCache
【参考】
>> 【公式】AWS ドキュメント Amazon ElastiCache
Amazon ElastiCache
- クラウドでのメモリ内分散キャッシュ環境のセットアップ、管理、およびスケーリングを AWS クラウドで簡単に行うことが可能
- このサービスは、高パフォーマンスでコスト効率に優れるだけでなく、サイズ変更も可能なメモリ内キャッシュを提供しながら、分散キャッシュ環境のデプロイと管理に伴う複雑性を排除
- ElastiCache は、Redis と Memcached エンジンのどちらでも使用可能
Amazon Aurora
Amazon Aurora とは
- Amazon Aurora (Aurora) は完全マネージド型のリレーショナルデータベースエンジン
- AWSが提供している分散型のリレーショナルデータベース
- AuroraはプライマリDBインスタンス1個、Auroraレプリカ最大15個、クラスタボリューム1個から構成され、これをAurora DB クラスタと呼ぶ
- プライマリインスタンスは読み書き可能なインスタンス/Auroraレプリカは読み込み専用のインスタンスでプライマリインスタンスが停止した際にフェイルオーバーされるインスタンス
- クラスタボリュームはインスタンスのデータを3つのAZに跨って6個レプリケーションして、S3にバックアップしている記憶領域
- 上記のような冗長構成により、可用性が99.99%を越えるよう設計されている
- 従来の商用データベースと比較して1/10程度の価格で利用可能、MySQL と比べて最大 5 倍のスループット、PostgreSQL と比べて最大 3 倍のスループットと低価格で高性能になる
- MySQL および PostgreSQL と互換性がある
- 既存の MySQL および PostgreSQL データベースで現在使用しているコード、ツール、アプリケーションを Aurora でも使用可能
- 既存のアプリケーションのほとんどを変更することなく、ほんの少しのワークロードで MySQL のスループットの 5 倍、PostgreSQL のスループットの 3 倍を実現
【参考】
>> 【公式】AWS ドキュメント Amazon Relational Database Service
Auroraの主な機能
MySQL・PostgreSQL互換 | 既存のMySQL、PostgreSQLのアプリケーションやツールと互換性があります。 |
Amazon Aurora Global Database | データベースを複数のAWSリージョンで運用できる機能。災害時に迅速な復旧対応ができる。 |
Amazon Aurora Parallel Query | クエリ処理を並列実行する機能。クエリ処理を高速化できる。 |
Amazon RDS Performance Insights | データベースを監視する機能。問題を検出しパフォーマンスを最適化できる。 |
Amazon Aurora Serverless | データベースの自動スケーリング機能。コスト効率を最適化できる。 |
Amazon Aurora Machine Learning | Amazon SageMakerとAmazon Comprehendとの統合により、機械学習を用いた予測が可能。 |
Aurora
- 標準的な構成でマルチAZに跨って仮想ボリュームを構成
Auroraの特性
- MySQL5.7と互換性
- PostgreAQL11.7と互換性
- 最大15台のリードレプリカを利用した高速読み込みが可能
- 可用性 99.99%
- 耐久性 99.99%
Auroraのレプリカ利用
- 最大15台のリードレプリカを利用した高速読み込みが可能
- リードレプリカはマルチAZで作成可能
- マルチマスター機能によって別AZにWriterのレプリカを生成可能
EFS
- EC2インスタンスからマウントターゲットを通ってアクセスする
- アクセス制御はセキュリティグループによって設定
- マルチAZにファイルを分散保持している
- アカウントあたりのファイルシステムを1000まで構築可能
【参考】
>> 【公式】AWS ドキュメント Amazon Elastic File System
Amazon EFSの概要
- Amazon EFSはシンプルでスケーラブル、かつ伸縮自在な完全マネージド型の NFS ファイルシステムを提供しているサービス
- ファイルが追加されたり削除されるのに合わせて自動で拡大および縮小されるため、拡張に合わせて容量をプロビジョニングおよび管理する必要がなくなる
- Amazon EFS では、標準ストレージクラスと低頻度アクセスストレージクラス(EFS IA)という2つのストレージクラスが提供されている
- EFS IA は、毎日アクセスしないファイルに対して最適化されたコスト効率の料金/パフォーマンスを提供しているので、より効率的に低価格で利用したい場合に適したサービス
- Linuxワークロードに共有のファイルシステムストレージを提供するフルマネージドサービスなので、複雑なデプロイ、パッチやファイルシステムの基盤メンテナンスをなくすことができる
Kinesisの概要
Kinesis:動画とデータストリームをリアルタイムで容易に収集、処理、分析
- キネシス
- Amazon Kinesis Data Firehoseはデータ蓄積に向けてS3などに対してデータ変換や配信を行います
- Amazon Kinesis Streamによりストリーム処理アプリケーションを構築可能
- Amazon Kinesis Data Analyticsを利用することで、リアルタイム解析が可能
- Kinesis AgentはKinesisサービスへのデータ収集を支援する
- Amazon Kinesis Data Analytics
-東京リージョンで利用可能
-Kinesisストリーム後に利用可能
-Amazon Kinesis Data Firehoseをワークフローの前後に利用する
-Kinesisストリームデータがないと利用できない
【参考】
>> 【公式】AWS ドキュメント Amazon Kinesis
キャッシュの活用
【参考】
>> 【公式】AWS ドキュメント ElastiCache
>> 【公式】AWS ドキュメント CloudFront
ElastiCache for Memcacheの特徴
- スナップショット機能がない
- フェイルオーバーと復元機能がない
ElastiCacheとは
- Amazon ElastiCacheとはAWS上で動作するインメモリデータストアを操作、運用できるサービス
- インメモリデータストアとは、メモリ上で動作するDBのようなもの
- 通常データを取得する際、データの保存されているHDDやSSDなどのディスクを読み込みますが、ディスクの読み取りはメモリなどの記憶装置に比べると低速になる
- ElastiCacheではそうしてディスクの読み取りを行わず、メモリ上にDBを作成しておくことで、レスポンスを飛躍的に短縮させることができるようになる
- Amazon ElastiCacheではRedisとMemcachedの2つのエンジンを利用
・RedisとMemcachedの違い
可用性 | 【Redis】 ・ノードをクラスター化し可用性を保つことが可能 ・クラスター化するとは、ノードを複数接続し運用することで、 仮に一つのノードで障害が発生した場合でも、 システムを止めることなく稼働させることが可能 ・Redisでは自動フェールオーバー(障害復旧)機能があり、 プライマリノード(メインのノード)が 自分の複製(レプリカ)を作成し、 障害が発生した場合や多大な負荷がかかった場合に レプリカをプライマリに昇格させ、処理させる 昇格したプライマリノードは新たにレプリカを作成し、 次の障害発生時に備える ・Redisではこうした”レプリケーション機能”を備えているため、 可用性が高い 【Memcached】 ・クラスター化はできるが、 レプリケーション機能はない |
柔軟性 | 【Redis】 ・RedisではList、Set、Sorted Set、Hash、Bit Arrayなど 様々なデータ型を扱え、コマンドも豊富にある 【Memcached】 ・Memcachedでは、シンプルなデータ(String)のみ格納可能 ・String型以外のデータを扱う場合は、 アプリケーション側で格納できる形に変換する必要がある ・getやsetなどのキャッシュを操作するための 簡単なコマンドしか用意されていない |
復元性 | 【Redis】 ・Redisの場合だと”スナップショット”を取得することが可能 ・このスナップショットからバックアップを取得することが可能 【Memcached】 ・Memcachedの場合は、バックアップ機能なし |
機能性 | 【Redis】 ・Redisではシングルスレッドを採用 【Memcached】 ・Memcachedではマルチスレッドを採用 ・MemcachedではCPUの性能をスケールアップすれば、 処理速度を上げることが可能となる |
拡張性 | 【Redis】 ・Redisでは最大 170.6 TB のインメモリデータを持つ クラスターまで簡単にスケールすることが可能 ・Redis Cluster 環境を 最大 250 のノードと 250 のシャードにまで スケール可能 【Memcached】 ・Memcachedでは、クラスターあたり最大20個のノードと 12.7TiBの容量を持つインメモリキャッシュにスケール可能 |
まとめ | 【Redis】 ・可用性の高い柔軟なアプリケーションを作成する場合 【Memcached】 ・シンプルさとマルチスレッドを活かした 高速なキャッシュとして利用する場合に向く |
Redisの特徴
- シングルスレッドで動作するインメモリキャッシュDBであり、すべてのデータ操作は排他的
ユースケース
-
- A社は一部データ処理のキャッシュによる高速化を検討
- 単純なデータトランザクション処理を行っており、需要の増減に応じてノード追加と削除が必要となる
- Redisとmemcachedのどちらにを選択するべきか
→ memcachedを選択
memcachedを選択するユースケース
- シンプルなデータ型でオーケストレーションを利用したい場合はmemcached
cf Redis用 Amazon ElastiCacheが適しているユースケース
- キャッシング
- チャット/メッセージング
- ゲーミングリーダーボード
- 地理空間
- 機械学習
- メディアストリーミング
- キュー
- リアルタイム分析
- セッションストアなどのリアルタイムのトランザクション
- 分析処理
CloudFront
- 世界中のエッジロケーションを利用してCDNを構築可能
- GZIPによる圧縮化により、高速な処理が可能
- 独自ドメインをCloudFrontに設定可能
CloudFrontの導入方法
- AWS上でWebシステムを構成していれば、そのまま利用可能
CloudFrontの配信設定
- Web DistributionとRTMP Distributionを選択可能
- Web DistributionではMediaPackageをオリジン設定できる
- RTMP DestributionではS3パケットをオリジン設定できる
サーバレス
【参考】
>> 【公式】AWS ドキュメント Amazon Simple Queue Service (SQS)
>> 【公式】AWS ドキュメント Amazon Simple Email Service (SES)
>> 【公式】AWS ドキュメント Lambda
>> 【公式】AWS ドキュメント Amazon Simple Notification Service (SNS)
SQS
- ショートポーリングはキューが空の場合でも、即時にリターンする
- ロングポーリングはキューが~の場合はタイムアウトまで待つ
- 可視性タイムアウト(Visiblity Timeout)は指定した処理サーバーに対してはメッセージ内容を指定期間見えなくする
- メッセージ保持期限:最大で14日(保持期間は60秒から14日間の間で変更可能)
- コンポーネント間の通信を非同期でコンシューマー側の状況に応じて通信を実現したい場合に選択するべき
SNSの概要
- 送信側がトピックを作成し、受信側をポリシー指定することで、制御された非同期通信を実現
SESの特徴
- フルマネージド型のコスト効率に優れたEメールサービス
- 受信したメールをトリガーにS3やLambdaなどを起動可能
- ドメインやメール登録を事前申請する必要あり
API Gateway
- 最大数十万個のAPI同時呼び出し・受付が可能
- EC2/Lambda/ににのウェブアプリケーションのワークロード処理を実行する
- APIを生成・管理することができる
- WEBSocketを利用した相互通信が可能
Lamdbaの特徴
- SDKを利用してAPPに組み込むことが可能
- スケジュール機能を利用して特定時刻をトリガーにして、Lambdaファンクションを実行する
- バージョニング機能でファンクションの一時点を記録管理することが可能
- ENIを通してVPC内のリソースにアクセスできる
- LambdaのPushモデルとPullモデルについて正しい組合せを選択してください。
- Pushモデルは3回リトライを実行する
Lamdbaの特徴:イベントドリブン型のプログラミング
- イベントドリブン型のプログラミング
- Lambdaはイベントの発生によって、実行が開始される
- イベントとなりうるのは、AWSの様々なサービス
【例】
-アラームによって一定時間が経過した
-S3にファイルがアップロードされた - 「API Gateway」というサービスと組み合わせると、HTMLフォームやAjax通信などによるリクエストをLambdaで処理することが可能
- つまり、WebシステムやWebサービスの構築もLambdaの用途の1つです。
AWS Lambdaのメリット
Lambdaは、サーバレスのプログラム実行環境です。従来のEC2インスタンスでプログラムを実行するのに比べて次のメリットがあります。
保守・運用に手間がかからない | ・Lambdaはマネージドサービス ・実行環境がAWSによって用意されるため、OSやフレームワークなどの保守は必要としない |
高負荷に耐えられる | ・Lambdaによるプログラムの実行は、必要に応じてスケーリングする ・そのため、高負荷に耐えられる |
コスト削減ができる | ・Lambdaは、実行時間に対する課金 ・稼働中はずっとコストが生じるEC2インスタンスでの運用に比べて、コストを削減が可能 |
AWS Lambdaの制限
ステートレスである | ・アップロードしたLambda関数は、都度、実行され、 実行が終わると破棄されるステートレスな構成 ・前回実行したときの状態などを保持することができない |
最大稼働時間は5分 | ・Lambda関数には、最大稼働時間がある ・設定できる最大時間は5分 |
Lambdaのパーミッション
- Extention Roleにより、Lambdaがその他リソースで実行できる内容を設定する
環境の自動化
【参考】
>> 【公式】AWS ドキュメント AWS CodeBuild
>> 【公式】AWS ドキュメント AWS CodeCommit
>> 【公式】AWS ドキュメント AWS CodeDeploy
>> 【公式】AWS ドキュメント AWS CodePipeline
>> 【公式】AWS ドキュメント Elastic Beanstalk
>> 【公式】AWS OpsWorks
>> 【公式】AWS ドキュメント AWS CloudFormation
>> 【公式】AWS ドキュメント Amazon Elastic Container Service
>> 【公式】AWS ドキュメント Amazon CloudWatch
環境自動化サービス
Codeシリーズ |
・開発コードのGit上のコミット・実行・デプロイを自動化する一連のサービス ・PipelineはCloudFormationとECSのデプロイ自動化にも利用可能 |
Elasic Beanstalk |
・ウェブアプリケーションやサービスを 使い慣れたサーバーでデプロイ・スケーリングするためのサービス |
OpsWorks |
・ChefやPuppetといった、 マネージド型インスタンスのサーバー設定、デプロイ、管理を 自動化できるようになる設定管理サービス |
CloudFormation |
・クラウド環境内のすべてのインフラストラクチャリソースを記述して、 プロビジョニングするためテンプレート化された プロビジョニングサービス |
Amazon ECS |
・AWS上でDockerコンテナによる環境構築のテンプレート化を 実現するサービス。 DockerFileに環境イメージを設定し、インフラ設定をコード化する |
CloudWatch |
・EC2インスタンスやEBSボリューム、DBインスタンス、 または、カスタムメトリクスなどのリソースを簡単にモニタリングできる |
以下は各環境自動化サービスの詳細
Codeシリーズ
CodeCommit |
Gitベースのリポジトリを セキュアにホスト |
|
CodeBuild |
コンパイル・テスト実行・デプロイ可能な SWパッケージを作成可能 |
CodeDeply | デプロイの自動化 |
- 上記をつなげてCodePipeline上で自動化することが可能
—
Elastic Beanstalk
-
Elastic Beanstalk
- 早く簡単にアプリケーションをデプロイ
- Java, PHP, Ruby, Python, Node.js, .NET, Docker, Goに対応してWEBアプリケーションを展開できる
- Apache, Ngnix, Pssenger, IISなど使い慣れたサーバーでデプロイ・スケーリングが可能
- コードをアップロードすれば、キャパシティのプロビジョニング、ロードバランシング、AutoScalingからアプリケーションのモニタリングまでデプロイを自動化できる。
Webアプリケーションの定番構成の構築・デプロイの自動化サービス
Elastic Beanstalkの構成要素
アプリケーションという単位にバージョン・環境設定がコードとして保持され、
環境にバージョンが展開される
アプリケーション |
・トップレベルの論理単位で バージョンや環境や環境設定が含まれている入れ物 |
バージョン |
・デプロイ可能なコードでS3で管理する ・異なる環境、異なるバージョンを展開可能 ・バージョンリポジトリに保持する |
環境 |
・各環境(ウェブサーバ/ワーカー)に応じて構築されるインフラ環境 ・バージョン(ソースコード)をデプロイ |
環境設定 |
・その環境に関連するリソースの動作を定義する設定パラメータ ・永続データの格納場所はS3やRDSなどの外部サービスを利用 |
-
Elastic Beanstalkのユースケース
- WEBアプリケーションのデプロイを容易にすることや、タスク時間の長いワークロードの展開に利用
—
OpsWorks
-
OpsWorks
- OpsWorksスタック
- OpsWorks for Chef Automation
- OpsWorks for Puppet Enterprise
Chef(しぇふ)またはPuppet(ぱぺっと)というツールを使用してアプリケーションを設定および運用するための設定管理サービス
-
Elastic BeanstalkとOpsWorksの違い
- Elastic Beanstalk : アプリケーションのデプロイ自動化
- OpsWorks : インフラの設定自動化
—
CloudFormation
-
CloudFormation
- プロビジョニングされたリソースの変更・削除が可能
- 追加リソースの通常課金のみで追加料金なし
- JSON/YAML(やむる)で記述
- クロスリージョンとクロスアカウントで管理
- 直接サポートされていないリソースや機能を利用する場合は、カスタムリソースでスタック作成の一部に独自ロジックを組み込むことが可能
AWSクラウド環境内の全インフラリソースを記述してテンプレート化して展開する環境自動設定サービス
-
CloudFormationのユースケース
- AWSリソースの構築を効率化したい
- 開発・テスト・本番環境で利用するインフラを標準化したい
- 毎回同じリソースやプロビジョニング設定を正確に利用したい
- ソフトウェアと同じように環境構成を管理したい
-
CloudFormationの構成
- テンプレート
- CloudFormation
- スタック : AWSリソースの集合
—
Amazon ECS
-
コンテナ
- ホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離する仮想化方式
-
Docker
- コンテナ型の仮想環境を作成、配布、実行するためのプラットフォーム
Amazonのコンテナサービス
- レジストリ
- コントロールプレーン
- データプレーン
レジストリ |
・コンテナエンジンに実行される イメージが保管される場所 ・Amazon ECR(Elastic Container Registry) ・フルマネージド型のレジストリサービス ・Dockerコンテナイメージを簡単に保存・管理・デプロイが可能 |
コントロールプレーン |
・コンテナを管理するサービス ・Amazon ECS(Elastic Container Service) ・Dockerコンテナをサポートする拡張性と パフォーマンスにすぐれたコンテナオーケストレーションサービス ・Amazon EKS(Elastic Kubernetes Service) ・コンテナ化されたアプリケーションの デプロイ・管理・スケールを オープンソースのKubernetesを使って実行するサービス |
データプレーン |
・コンテナが実行される環境 ・AWS Fargate ・サーバーやクラスターの管理なしに、 コンテナを実行するECSに対応したコンピューティングエンジン |
-
各サービスの連携
- CodePipeline x CloudFormation
CloudFormationで設定したAWS環境に対して、CodePipelineを使うことでテンプレートの変更・実行・展開を自動化する - CodePipeline x ECS
ECSで設定したDocker環境に対して、CodePipelineを使うことで、テンプレートの変更・実行・展開を自動化する
セキュリティと運用
【参考】
>> 【公式】AWS ドキュメント AWS Key Management Service (KMS)
>> 【公式】AWS ドキュメント AWS Directory Service
>> 【公式】AWS ドキュメント AWS Pricing Calculator
>> 【公式】AWS ドキュメント AWS Systems Manager
>> 【公式】AWS ドキュメント Amazon GuardDuty
>> 【公式】AWS ドキュメント AWS Config
このトピックのポイント
- セキュリティの確保 : AWS Well Archtected Frameworkの一つ
- AWS KMSの活用 : 暗号キーを利用するサービス
- コスト最適化 : AWS Well Archtected Frameworkの一つ
- 運用上の優秀性 : AWS Well Archtected Frameworkの一つ
- CloudWatchの設定 : 設定や操作
セキュリティの確保
-
セキュリティの設計事項
- 全てのレイヤーでのセキュリティを適用
- アクセス追跡・モニタリングの確実な実施
- 条件ドリブンのアラートをトリガーとしてセキュリティイベントへの応答を自動化
- AWS責任共有モデルに基づく対象範囲の保護に集中する
- セキュリティのベストプラクティスの自動化
-ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率のよいスケーリングを安全に実行する
-仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用自動化
-インフラストラクチャ全体のテンプレ化による管理
AWS内のデータ/システム/アセットを保護して、モニタリングによりセキュリティを高める
—
セキュリティの主要サービス
データ保護 | ELB, EBS, S3, RDS, RDS, KMS |
権限管理 | IAM, MFA |
インフラ保護 | VPC |
検出制御 | CloudTrail, CloudWatch, AWS GuardDuty, Amazon Inspector |
—
データ保護
-
データの保護:暗号化
- 多くのDBサービスはKMSと統合されており、暗号化を容易に実施できる
- KMSと統合されているDBサービスの例
-EBS, Redshift, RDS, Elatic Transcorder, S3, WorkMail, EMR
-
Cloud HSM
- 不正使用防止策がとられている専用HWモジュール(HSM)により、暗号キーを保護するサービス
- 厳しい暗号化要件に対応するために利用
—
S3はデータ保護のためにAWS認証情報によるアクセス制御と暗号化を実施
- 暗号化方式 : サーバーサイド暗号化
- 特徴 : AWSサーバーリソースを利用して、格納データの暗号化を実施
- 暗号化タイプ SSE-S3/SSE-KMS/SSE-C
- 暗号化方式 : クライアントサイド暗号化
- 特徴 : 暗号化プロセスをユーザー側で管理する
- 暗号化タイプ :
-AWS KMSで管理されたカスタマーキーで暗号化
-クライアントが管理するマスターキーで暗号化
RDSはセキュリティグループによる制御とデータ接続の暗号化とリソースの暗号化を実施
セキュリティグループ |
・DBのSGでDBインスタンスへのアクセス制御 ・VPCのSGでVPC内のインスタンスへのアクセス制御 ・EC2のSGでEC2インスタンスへのアクセス制御 |
データ接続の暗号化 |
・SSL/TLSを用いてアプリケーションと DBインスタンス間のデータ接続を暗号化 |
リソースの暗号化 | ・暗号化オプションにより保管データを暗号化 |
—
-
責任共有モデル
- セキュリティに対して、AWSとユーザーとで責任分解して対応する責任共有モデルとなっている
ユーザー側の責任範囲 |
・AWSインフラストラクチャ -ユーザーアクセス -ロールベースのアクセス -ユーザーが利用するAWSサービス |
AWS側の責任範囲 |
・AWSインフラストラクチャ (ハードウェア、ソフトウェア、ネットワーク) ・AWSデータセンター |
-
ユーザーが利用するAWSサービス
- IAMによるアカウント管理
- セキュリティグループの設定
- アプリケーションのロールベースのアクセス設定
- ネットワーク/インスタンスオペレーションシステム(バッチ)などの設定
- OS/ホストベースのファイアウォール設置
—
権限管理
-
権限管理
- AWS DirectryService
- ディレクトリサービスとは、ユーザに関わる各種情報を保管して、ユーザー認証を実現する仕組み
管理するユーザー情報 |
・ID ・ユーザー名 ・姓名氏名 ・部署 ・グループ ・担当 ・電話番号 ・メールアドレス ・パスワード |
実現する機能 |
【IDとアクセス管理】 ・運用効率の向上 ・コンプライアンス向上 ・セキュリティの強化 【アプリのアクセス制御】 ・ファイル共有 ・バッチ管理 |
—
-
権限管理
- AWS DirectryService
- AWSに新しいディレクトリを作成するか、既存のActiveDirectory機能を利用した制御を実現
Simple AD | ・AWSに新規ディレクトリを作成 |
AD Connector | ・既存のディレクトリをAWSに接続 |
—
-
権限管理 Security Token Service (STS)
- STSは限定的で一時的なセキュリティ認証情報を提供するサービス
-
IAMユーザー
認証済ユーザー
↓
STSの発行
↓
一時的な利用者
—
-
権限管理 Amazon Cognito(こぐにと)
- シンプルでセキュアなユーザーのサインアップ、サインイン、アクセスコントロールをアプリケーションに実装
—
インフラの保護
-
サブネットの分割
- サブネットはインターネットアクセス範囲を定義するために利用する
パブリックサブネット |
・インターネットと接続が必要なリソースをそろえる ・インターネットとのアクセス制御に利用する |
プライベートサブネット | ・インターネットから隔離することで、セキュリティを高める |
—
-
VPCアクセス制御
- VPCはセキュリティグループとネットワークACLで制御する
セキュリティグループ |
・インスタンス単位で制御 ・ステートフル (インバウンドのみ設定) |
ネットワークACL |
・サブネット単位で制御 ・ステートレス (インバウンド・アウトバウンドどちらも設定) |
検出制御
-
検出制御
- 検出やモニタリングを継続的に実施してセキュリティを高める
CloudTrail |
・AWSユーザーの行動ログを取得 ・ガバナンス、コンプライアンス、 運用とリスクの監査を行えるように支援する |
CluodWatch |
・AWSリソースとAWSで実行するアプリケーションに対して、 様々なメトリクスやログを収集・追跡するモニタリングサービス |
AWS GurdDuty |
・AWS上での悪意ある操作や不正な動作を 継続的にモニタリングする脅威検出サービス |
Amazon Inspector |
・自動的にアプリケーションを検証し、その露出、脆弱性、 ベストプラクティスからの逸脱状況を確認し、 セキュリティを実施するサービス |
AWS WAF |
・可用性、セキュリティ侵害、リソースの過剰消費といった 一般的な脆弱性からウェブアプリケーションまたは APIを保護するウェブアプリケーションファイアウォール |
AWS Shield |
・マネージド型の分散サービス妨害(DDoS)にたいする保護サービス。 AWS Shieldにはスタンダードとアドバンストの2つの階層があり、 サポート範囲が異なる。 |
IAM Access Analyzer |
・外部エンティティと共有されているAmazonS3バケットやIAMロールなど、 組織とあかんとのリソースを識別し、 ・セキュリティ上のリスクであるリソースと データへの意図しないアクセスを特定 |
AWS Security Hub |
・セキュリティアラートを一元的に表示して管理し、 コンプライアンスチェックを自動化。 ・監査結果から修正すべき設定の数と現在のセキュリティ状態が把握できる |
AWS KMSの活用
-
AWS KMS
- 簡単にデータを暗号化するためのマネージド型暗号化サービス
-
AWS KMS
- IAMと連携して鍵のアクセス管理を実施
- カスタマーマスターキー(CMK)の無効か・有効化・削除を実施し、1年ごとの自動キーローテーションをすることが可能
- CMKを外部から持ち込んで管理することも可能
- キーを保護するために、FIPS140-2の検証済または、検証段階のハードウェアセキュリティモジュールを使用
- AWS CludTrailと統合されており、すべてのキーの使用ログを表示
- RDSやS3などの多数のAWSサービスに適用可能
- KMS SDKを利用することで、アプリケーションにおける暗号化も可能
暗号鍵の作成・管理・運用を実施するマネージドサービスでAWSマネジメントコンソール、AWS SDK またはCLIを使用して、キーを作成、インポート、ローテーション、削除、管理する
ーーー
-
AWS KMS
- RDSでは保存されるデータ・リソースの暗号化と接続の暗号化を実施可能
カスタマーマスターキー |
・暗号化を実施する上で、最初に作成されるマスターキー ・暗号化キーを暗号化する ・ローテーションされる |
カスタマーデータキー |
(暗号キー) ・実際のデータの暗号化に利用するキー ・KMSで生成されてCMKで暗号化される |
エンベロープ暗号化 |
・マスターキーで暗号化をせずに、 暗号化したデータキーを利用して暗号化する暗号化方式 |
—
コスト最適化
5つの設計原則と11のベストプラクティス
信頼性 |
パフォーマンス 効率 |
安全性 | コスト最適化 | 運用の優秀性 |
スケーラビリティの確保 | セキュリティの確保 | コスト最適化 | 環境の自動化 | |
単一障害点の排除 | キャッシュの利用 | |||
コンポーネントの疎結合 | 増大するデータ量対応 | |||
環境の自動化 | 最適なデータベース選択 | |||
サーバーではなくサービス | ||||
使い捨てリソースの使用 |
-
Cost Optimization : コスト最適化
- 【設計事項】
- 不必要なリソース削減
- 透明性のある費用管理
- マネージド型サービスの利用によるコスト削減
- 固定の償却コストを変動コストへと転換
- スケールによるコストメリット
- データセンターへの投資不要
不必要なリソースを削減し、最適な料金選択によりコスト最適化すること
—
-
コスト最適化の主要サービス
- 需要と供給の一致:Auto Scaling
- コスト効率の高いリソース:EC2購入方式、Trusted Advisor
- 支出の認識:CloudWatch、見積もりツール
- 継続した最適化:AWS最新情報、TrustedAdvisor
—
-
AWSを安く使う
- 最もシンプルで一番最初にやるべきコスト最適化は無料利用枠の最大利用と最適な料金オプションの選択
—
-
AWSの課金方式
- 従量制料金 : 従量課金による利用料に応じた価格設定
- 予約による節約 : EC2などの特定のサービスにはリザーブド価格(予約による低価格販売)が実施されている
- 使うほど安い : AWSではボリュームディスカウントを受けることができ、使用量が増えるほど節約できる
AWSは利用料に応じた柔軟な料金設定となっている
—
-
AWSの料金改定
- >> 【公式】AWS 料金
他クラウドサービスとの競争優位性を保つ観点から、日々価格改定がなされるため、利用毎に料金表を確認することが必要
—
-
EC2の購入オプション
- オンデマンドインスタンス
- スポットインスタンス
- リザーブドインスタンス
- ハードウェア占有インスタンス
- Dedicated Host
- ベアメタル
EC2の購入オプションは、利用形態や利用期間などに応じて多岐にわたるため、コスト最適な選択をすることが重要
ーーー
-
AWS Organizationによる一括請求
- AWS Organizationの一括請求で、メンバーアカウント間でリザーブドインスタンスを共有化したり、S3などの利用量に応じた課金がお得になる
ボリュームアカウント適用 | リザーブドインスタンスの共有 |
・S3などのボリューム料金階層がある場合、 多く利用するほど価格が低くなる ・一括請求で複数アカウントを まとめてボリューム料金に統合することで、 コスト削減が可能 |
※一定の条件を満たせば、 メンバーアカウント間で購入した リザーブドインスタンスが共有される ・AWS Organizationで有効化 ・同じAZ内に購入する ・同じインスタンスタイプである |
—
-
価格算定ツールを利用する
- 簡易見積もりツール : 利用するAWSサービスに対する月額料金を見積もることができる
- TCO(総所要コスト)計算ツール : AWS利用した場合とオンプレミス環境やコロケーション環境との価格比較が可能
- Pricing Caluculator : ビジネスや個人のニーズに沿った個別の予測コスト見積もりを実施することができる
AWS公式ツールを利用して、見積もりや価格比較を実施する
—
-
コストの可視化
- CloudWatch
- Trusted Advisor
-コスト最適化
-セキュリティ
-対障害性
-パフォーマンス向上
CloudWatchのbilling機能により、請求額通知を可能とし、Trusted Advisorからアドバイスをもらう
—
-
AWS Budgets
- カスタム予算を設定して、コストまたは使用量が予算額や予算量を超えた場合に、細かくアラームを設定することができる
—
-
AWSのコストと使用状況レポート
- AWSのコストと使用状況に関する最も包括的データを提供
—
-
AWS Cost Categories
- 自身の組織やプロジェクト構造にわけてコストをカテゴライズすることが可能な機能
—
運用上の優秀性
5つの設計原則と11のベストプラクティス
信頼性 |
パフォーマンス 効率 |
安全性 | コスト最適化 | 運用の優秀性 |
スケーラビリティの確保 | セキュリティの確保 | コスト最適化 | 環境の自動化 | |
単一障害点の排除 | キャッシュの利用 | |||
コンポーネントの疎結合 | 増大するデータ量対応 | |||
環境の自動化 | 最適なデータベース選択 | |||
サーバーではなくサービス | ||||
使い捨てリソースの使用 |
—
-
Operational Excellence 運用上の優秀性
- コード化された運用実行(環境自動化)
- ビジネス目的に沿った運用手順
- 期的かつ小規模で増加的な変更管理
- 予期せぬイベントへの対応テストの実施
- モニタリングにより障害を予測する
- 運用上の失敗やイベントから学習する
- 運用手順を繰り返しアップデートする
計画変更が起こった場合や、予期せぬイベントの発生時において、自動化された運用実務および、文書化され、テキストされ、レビューされた手順書があること
運用上の優秀性の主要サービス
準備 |
・Cloud Formation ・Codeシリーズ ・Runbook Playbook |
|
運用 |
・System Manager ・AWS Service Catalog ・AWS Cloud Trail ・AWS Artifact ・AWS GurdDuty ・Cloud Watch ・AWS Config ・API Gateway |
|
進化 |
継続的かつ段階的な改善のために、 時間とリソースを割り当て、 運用の有効性と効率性を向上させる |
—
-
AWS Config
- 定期的に構成情報のスナップショットをS3に保存
- 構成情報に基づきシステム構成があるべき状態になているかを評価
- 評価基準にはAWSルールまたは独自ルールを適用
AWSリソースのレポジトリ情報からリソース変更履歴や構成変更を管理するサービス
—
-
AWS Configの機能3つ
- 構成変更を管理するストリーム
- 履歴管理するヒストリー
- 構成要素を保存するスナップショット
—
-
AWS Service Catalog
AWSで承認されたITサービスのカタログを作成および管理する支援サービス
—
-
AWS Artifact
重要なコンプライアンス関連情報を一元管理
—
-
AWS Gurd Duty
VPCフローログ、CloudTrailログ、DNSログや悪意のあるIPやドメインリストなどを分析して処理する継続的なセキュリティモニタリングサービス
—
-
AWS System Manager
利用中のAWSサービスやリソースをモニタリングして、運用リスクを自動化するサービス
—
CloudWatchの設定
-
CloudWatchでできること
- モニタリング
- 監視の集約化
- トラブルシューティング
- ログ解析
- 自動アクション
- 運用状況の確認
AWSリソースとAWSで実行するアプリケーションのモニタリングサービスで、様々なログやメトリクスを監視できる
-
CloudWatchの機能
- CloudWatch(メトリクス監視)
- CloudWatch Logs
- CloudWatch Events
—
-
CloudWatchのメトリクス
- 標準メトリクス
- カスタムメトリクス(拡張モニタリング実行時)
—
-
CloudWatchダッシュボード
必要なRDSのメトリクスを選択してダッシュボードで可視化することが可能
—
-
拡張モニタリングの実施
DBインスタンスが実行されているオペレーティングシステム(OS)のリアルタイムメトリクスを取得できる
—
-
CloudWatchアラーム
- メトリクス
- 名前空間
- ディメンション
- 正常値OK
- 異常値アラーム
- 判定不能(INSUFFICENT_DATA)
CloudWatchアラームにより、特定のメトリクスのしきい値に応じたアラーム通知や自動アクションを実行可能
—
-
CloudWatch logs
CloudWatch logsはログを管理しつつ、可視化・分析を実施できるサービスで、RDSのログに対応している
—
-
CloudWatch logs
- ロググループ
- ログストリーム
- ログイベント
CloudWatch logsは以下の3つのレイヤーで構成されている
—
-
CloudWatch logs Insights
CloudWatch logs Insightsはログデータをインタラクティブに検索して分析
—
-
CloudWatch logsとの連携
AWS上のリソースの変更を示すシステムイベントをトリガーとして、ターゲットがイベントを処理する
学習コストと得られる結果を考慮すると、スクールに行くのがコスパが高い件
本記事では、独学を前提にAWSソリューションアーキテクト試験の学習方法をご紹介しました。しかし、IT自体のご経験が薄く、独学ではちょっと厳しそう。。。という方向けに、初学者にとってプログラミングを独学する際の挫折しやすいポイントと回避策について、以下の記事にまとめましたのでご紹介しておきます。
>> 無料あり:エンジニア歴20年の筆者がおすすめするプログラミングスクール
まとめ
本記事では、以下についてご紹介しました。
- 試験の概要
- 学習方法・学習時間
- 主な学習トピックとポイント ← 本記事でご紹介
また、独学では心もとない方向けに、プログラミングスクールに関してもご紹介しました。
>> 無料あり:エンジニア歴20年の筆者がおすすめするプログラミングスクール
これから、Amazon AWSソリューションアーキテクト・アソシエイト試験(SAA-C02)の受験を検討している方のご参考になれば幸いです。
【関連記事】
>> 【第1回】AWSソリューションアーキテクトアソシエイト勉強法/初心者が最短合格するための学習方法
>> 【第2回】AWSソリューションアーキテクトアソシエイト勉強法/主な学習トピックとポイント(本記事)
【参考にさせていただいたページ】
>> 【公式】AWS ドキュメント
>> AWSチャンネル
>> Acrovision > 技術記事 >AWS
>> これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)
>> TOPにもどる