SAA学習-IAM-IAMロールへのポリシー適用
今回のテーマ：IAMロールへのポリシー適用
IAMロールの使用目的
IAMロールを設定する場面は、バッチ連携やAPI連携時などで付与します。
今回はサンプル事例となりますので、ケースとして以下の条件になります。
| 要件 | 必要な対処概要 |
|---|---|
| EC2インスタンスがバッチ処理でS3にデータ保存 | EC2インスタンスにS3へのアクセス権限を設定 |
また、今回の構成図は以下のようにないｒます。
実際の操作
- EC2を作成は本編と違うため割愛します。
IAMロールの作成
- IAMのダッシュボード-アクセス管理-ポリシーの順に選択し、ポリシーの作成をクリック
- 以下の設定を選択したら、次のステップ：タグを選択
| 設定項目 | 設定値 |
|---|---|
| サービス | S3 |
| アクション | 手動のアクション、*(すべてのアクション) |
| リソース | すべてのリソース |
| リクエスト条件 | なし |
該当するポリシーのJSONは以下のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
- タグは追加せず、次のステップ：確認をクリック
- 名称と説明に「S3Allow」と記載したら、ポリシーの作成をクリック
cf)以前作成していたものがの残っている場合、画面のようにエンティティが存在してますと表示されます。
その場合は名称を変更するか削除して作り直すとよいです。
- ポリシー作成後、アクセス管理-ロール-ロールの作成をクリック
補足：
ロールの適用範囲はAWSサービスへ適用する制限だけではなくGoogleなどのウェブIDや ADと連携するための統合認証のSAML2.0フェデレーションの許可を有効にする
- 先程作ったS3Allowというポリシーにチェックを入れ、次のステップ：タグをクリック
- タグの指定は不要なのでそのまま、次のステップ：確認をクリック
- ロール名を指定したら、ロールの作成をクリック
ここまでがロール作成なので作成したロールをEC2へ付与します。
IAMロールのEC2への適用
- IAMロールを適用したいインスタンスを選択したら、アクション-セキュリティ-IAMロールを変更の順に変更します。
- 先程作ったIAMロールを選択し保存をクリックします。
- ここからが適用後の確認
- インスタンスへログイン出来たら以下コマンドでS3にアクセスできるか確認
実行コマンド：
aws s3 ls
実際の結果：
今回のテーマは以上です。
SAA学習-IAM-IAMグループ/ユーザーへのポリシー適用：ハンズオン過程操作学習
今回のテーマ：IAMグループ/ユーザーへのポリシー適用
ハンズオン時で手を動かす際の流れやポイントになります。
ケーススタディ：自社組織に必要な権限設計
- IT管理者：ルート権限ユーザーも保持し、権限設定などの責任者
- 運用管理者：運用管理全般を担っているスタッフ。様々なモニタリング/障害対応などで直接アプリに触れる
- アプリ開発者：主だったAWSサービスを利用しサービス開発を実施
どのようなアクセス権限が必要か？
- IT管理者：フルアクセス権限。
権限：Administrator - 運用管理者：運用ツール全般と開発環境へのアクセスも付与し、DevOpsに参加。
権限：ELB/EC2/RDS/S3/Auto-Scaling/VPC/Config/Trail/CloudWatch - アプリ開発者：アプリ開発範囲でのみアクセス権限を付与。
権限：ELB/EC2/RDS/S3/Auto-Scaling/VPC
実際の画面操作
アクセス管理
以下のリソースを管理・実装することがベースとなります。
- グループ：作成したグループの一覧
- ユーザー：作成したユーザーの一覧
- ロール：規定されたロールの一覧
- ポリシー：AWS内で既存にあるポリシの一覧
サンプル：
cf) 境界に使用→権限に設定できる範囲を指定する
- IDプロバイダー：Active Directory などの認証基盤と連携(フェデレーション)し、アカウント管理を統合化する際に使用
- アカウント設定：パスワードポリシー、一時的なSTS
アクセスアナライザー
以下のアクセス情報を分析・認証するための使用がベース
- Access Analyer：認証情報の分析するためのツール
- 認証情報レポート：認証情報レポートをダウンロードできる
- 組織アクティビティ：AWS Organizationを使用する場合
- サービスコントロールポリシー：AWS Organizationを使用する場合
IAMグループの作成
作成するポリシーはアプリ開発者用のものを事例に作成します。
なお、以下の権限と別のポリシーを作成し2つを統合すれば、
運用管理者用のポリシーとなります。
権限：ELB/EC2/RDS/S3/Auto-Scaling/VPC
- 実際の作り方
①定義するポリシーを作成しておいてからグループへ適用するためポリシーの作成を行います。
1.アクセス管理-ポリシー-ポリシーの作成の順位クリック
2.サービスの選択から必要な権限を検索する。
3.該当サービスを選択すると操作レベルに関しての制限をするためアクション(操作範囲)の制限を規定します。
4.リソースの範囲を制限する場合がありますが、あまり厳しく制限すると必要なサービスが使用できなくなるためその際は解除するようにしておきます。
今回はすべてのリソースとしてます。
5.リクエスト条件でMFAが必要や送信元IPアドレスを指定などができます。
アクセス制限時の条件付けになります。
という流れで、必要なAWSリソースに対し追加していきます。
※VPCはEC2の中に含まれているためポリシー定義する場合はEC2から検索
文字数についてはタグのjsonファイルの文字数になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"rds:*",
"s3:*",
"ec2:*",
"elasticloadbalancing:*",
"autoscaling-plans:*"
],
"Resource": "*"
}
]
}
続いてタグ付けでこれは名称が分かればよいので以下のようにつけてみます。つけたら次のステップ：確認をクリック。 ※正直タグをつけなくてもよいですがサンプルです。
- キー：Name
- 値：Application-policy
名称と説明を付与してポリシーの作成を行います。
参考：「Config/Trail/CloudWatch」の場合のポリシーでアクションすべてリソースすべてと付与した場合のjsonファイルになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"cloudtrail:*",
"config:*"
],
"Resource": "*"
}
]
}
②グループの作成
アプリ開発者用のグループと作成します。
1.アクセス管理-グループ-新しいグループをクリック
※やることはグループ名の定義、ポリシーのアタッチ、設定の確認となります。
2.グループ名を設定して次のステップをクリック
3.ポリシーを指定して次のステップをクリック ※ここで先程作ったポリシーを適用します。
4.実際の値を確認しグループの作成をクリック
作った一覧がこちら
これに必要なユーザーを作ってグループに所属させていきます。
③ユーザの作成
1.アクセス管理-ユーザーーユーザーを追加をクリック
2.ユーザ名、アクセス制御、初期パスワードなどを設定し次のステップ：アクセス権限をクリック
3.アクセス制御するために先程グループを作ったのでそちらを活用する。今回はグループApplicationを使用し次のステップ：タグをクリック
4.タグは指定しなくても問題ないため、次のステップ：確認をクリック
5.設定内容を確認しユーザーの作成をクリック
実務だとユーザーの作成完了後にアカウント作成したユーザーに対して、
作成が終わりましたと連絡し、アクセスキーなどのcsvファイルを送付する場合があります。
今回のテーマは以上です。
SAA学習-IAM-IAM設計
今回のテーマ：IAM設計
IAM設計
IAMの設計する際、AWSを利用するユーザーの役割やアクセス権限を自社の組織構造と合わせて行います。
IAM設計のベストプラクティス
IAMの設計のベストプラクティスとして以下のものが挙げられます。
- アカウント設定などの必要な場合を除いて、rootユーザーを利用しない
- ルートユーザーなどの特権ユーザーに対して、MFAを有効化
- 利用者ごとにIAMユーザーを作成
- 組織利用の場合、役割ごとのIAMグループを作成してグループで単位で管理
- 最低限の権限設定と不要な認証情報の削除を行う
- ユーザーのために強度の高いパスワードポリシーを設定
- EC2インスタンスで作動するアプリケーションなどプログラムから利用する場合、ロールを使用
- モバイルやアプリケーションを含め、一時利用にはSTSなどで最低限の利用許可
- AWSアカウントのアクティビティは常に利用状況を監視
cf) AWS STS：AWS Security Token Serviceの略称で一時利用するための認証情報を発行するサービス
IAM の一時的な認証情報 - AWS Identity and Access Management
IAMの設計観点
IAM設計観点で以下の2つに対し留意しておくことが大切になります。
① IAMユーザ or IAMグループ
② グループ設計
①IAMユーザ or IAMグループ
個人のみで利用する場合を除いて、複数人で同じAWSアカウントを利用します。
そのため、小数利用でも最初からIAMグループを設計・設定することが望ましいです。
例：アプリ開発と運用管理など
② グループ設計
同じAWSアカウントを組織または個人利用者とその役割別の利用範囲を整理してグループ設計を行います。
フェーズとして以下のようなSTEPでの仕分けを行います。
STEP1：AWS利用者と役割の洗い出し
STEP2：利用グループへと集約
今回のテーマは以上です。
SAA学習-IAM-IAMの概要
本日のテーマ：IAMの概要
主要サービスの公式資料
IAM： docs.aws.amazon.com
IAMとは
AWS Identity and Access Managementの略称で、
安全にAWSの操作を実施するための認証・許可の仕組みとなります。
具体的には、AWSの操作を実施するため、ユーザ管理を行う仕組みとなります。
IAMの構成要素
IAMの構成要素としては以下のものが挙げられます。
- ユーザー
- グループ
- ポリシー
- ロール
IAMポリシー
ユーザーなどへアクセス権限を付与するための設定ドキュメント(JSON形式の文章)になります。
JSONファイルの構成要素
JSONファイルの構成要素と設定は以下のようになります。
- Effect：Allow→許可、Deny→拒否
- Action：対象のAWSサービス 例：s3:Get
- Resource：対象のAWSリソース ARNで記述
- Condition：アクセス制限が有効となる条件 例：IPアドレスなど
IAMユーザー
AWS上の利用者はIAMユーザーという権限を付与されたエンティティ(要素)として設定されます。
各種アカウントに対する概要は以下のようになります。
| 要素 | 概要 |
|---|---|
| ルートアカウント | ・AWSアカウント作成時に作られるIDアカウント ・すべてのAWSサービスとリソースを使用可能 ・日常的には使用しないことが推奨 |
| 管理者権限 | ・管理者権限の許可が付与されたIAMユーザー ・IAMの操作権限まで ルートアカウントしかできない権限は付与されない |
| パワーユーザー | ・IAM以外のすべてのAWSサービスにフルアクセス権限を有するIAMユーザー ・IAMの操作権限なし |
cf)自社所有のAWSアカウントに対し、外部ベンダーにIAMユーザーを払い出す際、活用することがあります。
以下は例となります。
- 自社：ルートアカウント、管理者権限
- 外部ベンダー：パワーユーザー
ルートアカウントでしかできない操作のリスト
以下の内容がルートアカウントでサインインしないと操作できない作業となります。
- AWSルートアカウントのメールアドレス/パスワードの変更
- IAMユーザーの課金情報へのアクセスに関するactivate(許可)/deactivate(拒否)の設定
- 他のAWSアカウントへのRoute53のドメイン登録の以降
- AWSサービス(サポート等)のキャンセル
- AWSアカウントの停止
- コンソリデイテッドビリングの設定(複数アカウント利用時の一括請求)
- 脆弱性診断フォームの提出
- 逆引きDNS申請
IAMグループ
IAMグループは、グループ権限をまとめて設定された単位となります。
また、一括で設定するアクセス権限の管理を行うことができ基本的には組織単位で設定します。
IAMロール
IAMロールは、AWSリソースに対し、アクセス権限をロールとして付与が可能です。
IAMの認証方式
IAMの認証方式は、AWSリソースを使用する手段によって異なります。
認証方式と使用する手段に関して以下のようなものがあります。
| 認証方式 | 使用する手段 |
|---|---|
| アクセスキーID/シークレットアクセスキー | ・EC2インスタンス接続などのREST/Query形式 ・AWS CLIやAPI利用時 |
| X.509 Certificate | ・SOAP形式のAPI陸セスト用の認証方式 ・あまり利用されるシーンがない |
| AWS マネジメントコンソールへログインパスワード | ・AWSアカウントごとにパスワードを設定してログイン ・デフォルトは未設定 |
| MFA(多要素認証) | ・物理デバイスなどを利用。 ・ルートアカウントなどは付与することを推奨 |
ユーザーのアクティビティ(利用)の記録
ユーザーのアクティビティ(利用)の記録を残す方法として、AWSのマネージドサービスを活用します。
AWSサービスを活用した記録は、以下のようなものが挙げられます。
| AWSサービス | 利用用途 |
|---|---|
| IAMアクセスアナライザー | 外部要素と共有されているS3バケットやIAMロールなどを分析し、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスを特定 |
| Access AdvisorのService Last Accessd Data | IAMエンティティ(ユーザー、グループ、ロール)が最後にAWSサービスにアクセスした日付と時刻を表示する機能 |
| Credential Report | 利用日時などが記録されたIAM認証情報のレポートファイル |
| AWS Config | IAMエンティティの変更履歴、構成変更を管理・確認する機能 |
| ACS CloudTrail | AWSインストラクチャ全体でアカウントアクティビティをログに記録と継続的に関しし保持することができる機能 |
IAM権限のベストプラクティス
IAM権限のベストプラクティスとして、以下の内容について網羅できいるかという観点が必要になります。
- AWSアカウントのルートユーザのアクセスキーをロックして通常は未使用
- 個々のIAMユーザーを作成して、IAMユーザーで管理
- IAMユーザーへのアクセス許可を割りあえてにIAMグループを利用
- IAMユーザー/グループには最小権限のみ設定
- 新しいポリシーを作るではなく、AWS管理ポリシーを使用
- インラインポリシーではなくカスタマー管理ポリシーを使用
- アクセスレベルをしゆ押してIAMアクセス許可を確認
- ユーザーのために強度の高いパスワードポリシーを設定
- MFA(多要素認証)を有効化
- EC2インスタンスで実行するアプリケーションにはIAMロールを使用
- 第三者に一時的に認証を付与する場合、IAMロールを使用してアクセス許可を移譲
- アクセスキーを共有しない
- 認証情報を定期的にローテーション
- 不要な認証情報の削除する(IAMエンティティの棚卸を行う)
- AWSアカウントのアクティビティを監視する
今回のテーマは以上です。
SAA学習-仮想化・クラウドの基本概要
本日のテーマ：仮想化・クラウドの基本概要
仮想化の仕組み
物理的なインフラに仮想化ソフトウェアを導入・設定し、実質的な機能をユーザーに切り分けて提供します。
仮想化の対象
| 項目 | 概要 |
|---|---|
| サーバの仮想化 | ・1台の物理サーバ上に複数のOSを動作させる方法 ・ハイパーバイザー型/ホストオンリー型/コンテナ型 |
| ストレージの仮想化 | ・複数のストレージを仮想的に統合し、1つの大きなストレージプールを構成 ・ブロックレベルの仮想化/ファイルレベルの仮想化 |
| ネットワークの仮想化 | ・新たな仮想ネットワークの構築/制御をソフトウェアにより動的に実施する ・SDN/VLAN |
| デスクトップの仮想化 | ・サーバ上においたPC環境のデスクトップ画面を遠隔地にある接続端末に転送する ・仮想PC方式/ブレードPC方式 |
仮想化のメリット
仮想化を利用することでインフラ利用の効率化や柔軟性が向上します。
以下は例になります。
- サーバースペースの削除
- 効率的なサーバー利用によるコスト削減
- 調達の迅速化
- 構成変更やメンテナンス対応の柔軟性
- セキュリティの向上
コンテナ
コンテナはホストマシンのカーネルを利用し、プロセスやユーザを隔離する仮想化方式となります。
Docker
Dockerはコンテナ型の仮想環境を作成、配布、実行するためのプラットフォームとなります。
以下は例になります。
- コード化されたファイル教諭するため誰でも同じ環境構築が可能
- 作成した環境の配布共有が容易
- 環境の即時構築・削除が可能なためCi/CDによる開発が実行できる。
クラウドとは
他社所有のハードウェア・ソフトウェアなどをネットワークを介して利用するシステムとなります。
また、インフラを仮想化しソフトウェアかされたサービスとして提供されるのがクラウド型のインフラサービスとなります。
クラウドの構成要素
クラウドで提供されるシステム構成はインフラ、ミドルウェア、アプリケーションの3層に分かれます。
以下は階層ごとの表になります。
| 階層 | 概要 | 例 |
|---|---|---|
| アプリケーション | ・プログラミング開発したアプリケーション ・業務機能が実装されたパッケージ |
・アプリケーション ・業務パッケージソフト ・フレームワーク |
| ミドルウェア/OS | ・共通利用される機能をまとめたソフトウェア ・Windowsなどの基本ソフト |
・システム連携 ・セキュリティ ・運用管理 ・Web/APサーバ ・データベース ・OS |
| インフラ | ・物理的な機器 ・ネットワーク回線 |
・サーバー機器 ・クライアント端末 ・ネットワーク機器 |
クラウドの5つの基本特性
クラウドは「5つの基本特性」、「3つのサービス」、「3つの利用形態」を兼ね備えている特性があります。
- 5つの基本特性
| 5つの基本特性 | 概要 |
|---|---|
| オンデマンド・セルフサービス | ・利用者は人を介さず、必要に応じてサーバー、ネットワーク、ストレージを設置/拡張/設定が可能 |
| 幅広いネットワークアクセス | ネットワークを介してPC、スマホ、タブレットなど各種デバイスから利用可能 |
| リソースの共有 | ハードウェアの使用容量などのリソースは複数利用者により共有し、利用者は必要に応じて動的に割り当てる。 |
| 迅速な拡張性 | ハードウェア等の資源は必要に応じて自動または手動で増やしたり、減らしたりできる |
| サービスは計測可能 | 稼働状態が常に測定されており、利用状況をコントロール・最適化できる 計測結果に応じて従量課金が可能 |
- 3つのサービス形態
| サービス形態 | 概要 | 特徴 |
|---|---|---|
| SaaS | ・クラウド事業者がアプリケーションまで提供 ・自社はすぐにアプリケーション利用可能 |
開発自由度：低い |
| PaaS | ・クラウド事業者がミドルウェアまで提供 ・自社はアプリケーション開発に専念 |
開発自由度：中 |
| IaaS | ・クラウド事業者がハードウェアまで提供 ・自社は別途ミドルウェア/OSを購入しアプリケーション開発 |
開発自由度：高い |
- クラウドの3つの提供形態
クラウド提供形態はプライベートとパブリックが主流。加えて両方を併用するハイブリット型の提供形態があります。
| 提供形態 | 概要 | メリット | デメリット |
|---|---|---|---|
| オンプレミス | ・ハードウェア/ソフトウェアを購入し、自社にシステムを構築 | 自社でハードウェアを自由にコントロール可能 | 調達・構築・運用管理に時間コストを要す。 |
| プライベートクラウド | ・自社内にクラウド基盤を構築し、ハードウェア/ソフトウェアを事業部や子会社で共同利用 | 自社資産の効率化。パブリックと比較しコントロールが自由 | クラウド運用管理が難しい。 |
| パブリッククラウド | ・ハードウェア/ソフトウェアを他社と共同利用し柔軟に構築や解除が可能 | 運用管理を他社に委任可能。 システム調達・構築の自由度が高い |
自社コントロール範囲が制限 |
今回のテーマは以上となります。
SAA学習-AWSの仕組みや概要など
今日のテーマ：AWSの仕組み概要
AWSの仕組み
AWSのサービスにはアンマネージド型とマネージド型が存在します。
対比表は以下のようになります。
| アンマネージド型 | マネージド型 |
|---|---|
| ・スケーリング/耐障害性/可溶性を利用者側で管理 ・設定が柔軟だけど管理が面倒 |
・スケーリング/耐障害性/可溶性をAWSサービスに任せる ・設定が楽だけど管理が限定的 |
| ・代表サービス：EC2(サーバー) | ・代表サービス：Route53(DNS) |
AWSのグローバルインフラ
AWSを構成するロケーションに関する用語は以下のものがあります。
- リージョン：国や地域
- アヴェラリティゾーン(AZ)：リージョンの構成概要
- エッジロケーション：配信処理などの細かいロケーション
リージョン
- リージョンに応じてAWSサービスの利用可否と値段が異なる。
- 複数リージョンを作成する必要がある場合は事業系造成計画(BCP)対策のため、
データ予備システムを別リージョンを利用し構築する。 - 会社の規約や監査基準で必要に応じて実装
アヴェラリティゾーン(AZ)
- 同じリージョン内のAZ同士は低レイテンシーのリンクで接続されている
- AZを１つはDC1個とする
- 複数AZ構成で実装する
cf)レイテンシー：データ転送における指標で転送要求を出してから実際にデータが送られるまでに生じる通信の遅延時間
リージョン間で可能な連携
- AWS Direct Connect Gateway経由の接続
- インターリージョンVPC Peeringで接続
- EC2：リージョン間でのAMIコピー
- S3：リージョン間でのレプリケーション
- RDS：リージョン間でリードレプリカ
- DynamoDB：DBリージョン間でのレプリカライブラリ
- Route53：DNSフェイルオーバー
AWS Direct Connect とは - AWS Direct Connect
cf)VPC Peering
Amazon VPC の仕組み - Amazon Virtual Private Cloud
エッジロケーション
- キャッシュデータなどを利用する際、小さなエンドポイントとなる拠点
- 代表サービス：CoudFront、Lambdaエッジ、Route53のルート
AWSサービスでSAAの学習する範囲
よく合格者体験記を拝見するとAWSのドキュメンテーションをきちんと読むことが挙げられます。
AWSが公開しているドキュメントのリンク集を下記のものがあります。
アプリケーション統合(SNS/SQS)
よく出そうな項目など
Amazon SQS の仕組み - Amazon Simple Queue Service
Amazon SNS とは - Amazon Simple Notification Service
コンピューティング(EC2)
Amazon EC2 とは - Amazon Elastic Compute Cloud
Amazon EC2 Auto Scaling とは - Amazon EC2 Auto Scaling (日本語)
ロードバランサーの種類 - Amazon Elastic Container Service
AWS Elastic Beanstalk（ウェブアプリの実行と管理）| AWS
Amazon ECS（Docker コンテナを実行および管理）| AWS
データベース(RDS)
Amazon Aurora（高性能マネージドリレーショナルデータベース）| AWS
Amazon RDS（マネージドリレーショナルデータベース）| AWS
Amazon DynamoDB（マネージド NoSQL データベース）| AWS
Amazon ElastiCache（インメモリキャッシングシステム）| AWS
Amazon Redshift とは - Amazon Redshift
マネイジメントとガバナンス(運用管理系のコンテンツ)
Amazon CloudWatch とは - Amazon CloudWatch
AWS Auto Scaling（需要に合わせて複数のリソースをスケール）| AWS
AWS CloudFormation（テンプレートを使ったリソースのモデル化と管理）| AWS
AWS CloudTrail とは - AWS CloudTrail
AWS OpsWorks（Chef や Puppet を使って運用を自動化する）| AWS
AWS Service Catalog とは - AWS Service Catalog
AWS Systems Manager とは - AWS Systems Manager
ネットワークとコンテンツ配信
Amazon VPC とは? - Amazon Virtual Private Cloud
Amazon CloudFront とは何ですか? - Amazon CloudFront
Amazon Route 53 とは？ - Amazon Route 53
AWS Direct Connect とは - AWS Direct Connect
Amazon API Gateway とは何ですか? - Amazon API Gateway
AWS Transit Gateway（VPC およびアカウント接続を簡単にスケール）| AWS
セキュリティ、アイデンティティ、コンプライアンス
IAM とは - AWS Identity and Access Management
AWS Key Management Service（マネージド型の暗号化キー作成と管理）| AWS
AWS Organizations とは - AWS Organizations
Amazon Cognito（ウェブ/モバイルアプリのユーザー管理）| AWS
AWS Single Sign-On（クラウドシングルサインオン (SSO) サービス）| AWS
Amazon GuardDuty とは - Amazon GuardDuty
Amazon Inspector とは - Amazon Inspector
AWS CloudHSM とは - AWS CloudHSM
AWS Directory Service とは - AWS Directory Service
AWS Shield の仕組み - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced
とはAWS WAF,AWSShieldAWS Firewall Manager? - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced
AWS Artifact とは - AWS Artifact
ストレージ
Amazon S3 とは - Amazon Simple Storage Service
クラウドデータのアーカイブ | 長期オブジェクトストレージ | Amazon S3 Glacier
Amazon EBS（EC2 ブロックストレージボリューム）| AWS
Amazon EFS（EC2 用フルマネージド型ファイルシステム）| AWS
Amazon FSx | 機能が豊富で高性能なファイルシステム | Amazon Web Services
AWS Storage Gateway（ハイブリッドストレージの統合）| AWS
開発者ツール(あまり頻度は多くないけど)
AWS CodeCommit（プライベート Git リポジトリでのコードの保存）| AWS
AWS CodeBuild（継続的スケーリングによるコードのビルドとテスト）| AWS
CodeDeploy とは何ですか？ - AWS CodeDeploy
AWS CodePipeline とは - AWS CodePipeline
AWS コマンドラインインターフェイス（CLI: AWSサービスを管理する統合ツール）| AWS
今回のテーマは以上です。
SAA学習-Day1対応-part4(AWSの請求アラートを有効化にする)
こ最近、本業が少し忙しく勉強しようと思ってましたが、
ちょっと疲労と自分への甘えで実施しておらず反省です。
今回でまずDay1対応の項目が終わります。
今回のテーマ：AWSの請求アラートを有効化にする
やること
・ダッシュボードでアラート設定を有効化する。(初期はルートアカウントのみなので通常使用するIAMユーザで有効化しておくと利用上便利)
・CloudWatchでアラート設定をする。
・ダッシュボードでアラート設定を有効化する。
ルートユーザに代わる際は一度マネイジメントコンソールからサインアウトします。
サインアウト後、ログインの選びなおしを行います。
「ルートユーザのEメールを使用したサインイン」をクリックします。
・サインインはルートユーザを選択し、AWSを使用時に登録したメールアドレスを指定後、次へをクリック
・パスワードを聞かれるため指定後、サイインインをクリック
・最初にMFAを有効化したので、MFAコードを入力後送信をクリック
マネジメントコンソールの右上のところで「アカウント情報」をクリックしてから「IAMユーザ/ロールによる請求情報へのアクセス」へ移動します。
※連絡先情報とか個人情報があるためちょっとここへの遷移は省略させてください。
・画面上見えているところの編集をクリックし、IAMアクセスのアクティブ化へチェック入れて更新クリック
こうすると通常使うIAMユーザでも請求情報が確認取れます。
・実際の請求情報の確認は、同じくマネジメントコンソールの右上のところをクリックし、マイ請求ダッシュボードをクリック
・トップ画面はこんな感じです。(無料枠のみならば費用は発生しませんが、少し検証とかで使用しているため私は若干費用が発生してます。)
・今回アラートを通知を有効化するため、BillingのBillingの設定をクリック
そうするとコスト管理設定で無料枠使用アラートを受信すると請求アラートを受け取るにチェックを入れて設定の保存をクリックしてください。
※気が付いたらよくわからないところから請求があるんだけど？とかならないようにするために必要です。
・CloudWatchでアラート設定をする。
サービスの検索より「CloudWatch」を検索し、表示してください。
・アラーム-請求をクリックし、アラームの作成をクリック
・メトリクス(AWSの監視項目)で具体的な値を次へをクリック。
請求が出る際に確認しやすくかつ支払い額の検視をしやすいように貨幣単価と金額は定義をします。
※あくまでもサンプルです。
Currency:USD → JP(これで日本円に変更)
統計：最大値 → 合計
条件-...よりもに「2000」
とすると2000円超えた際にアラームが出ますよとという設定になります。
設定した監視項目に対する通知方法の設定を行います。
今回はアラームをSNS(メール通知機能)を使用します。
SNSトピックの選択は新しいトピック(送信するための論理アクセスポイント)を作成します。
・トピックの作成が終わったら一番したの次へをクリック
・アラームと名称を定義し次へをクリック。
※英語のみしか設定できないため要注意！
かなり雑多ではありますがこんな感じで定義しました。
・最後に設定した内容確認がするので、値が問題なければアラームの作成をクリック
作成後通知を受けてるためにSNSサブスクリプションを表示をクリックします。
通知確認のメールを受信するので「Confirm subscription」をクリックするとサブスクリプションが有効化されます。
ここまでがAWSアカウントを作ってから最初に有効化しておいた方が推奨される「Day1」対応となります。
記事にしてみると結構ボリュームになったなぁというのが率直な実感でした。
重要事項：
あくまで個人ベースで使用する場合を前提になります。
最初にAWSマネジメントコンソールで操作した際のログの保管をするS3ですが、
有効化していると無料枠を超えやすいため先にバケットごと削除しておくこととよくわからない費用が発生してないと思います。
削除方法としては、マネイジメントコンソールよりS3と検索します。
そうするとログ保管用のバケットが出てきます。
・該当するバケットを選択し、「空にする」をクリック
※何かしらデータが入っているときは、バケット(入れ物)を空にしてから削除が必要となります。
・入力フィールドにこんな感じで記載して空にするをクリック
※ご親切に「」があるのでその箇所をコピペが楽です。
・無事空にできた後はこちらとなるため終了をクリック
・入れ物が空になったので今度は削除をクリック
・何もバケットがないことを確認します。
今回のテーマは以上です。
