aws
⋮
CW

アラーム

メトリクスを監視し、しきい値を超えた状態を検知します。

すべてのアラーム

1

ALARM

0

OK

1

アラーム状態とアクション

メトリクスがしきい値を超えると ALARM 状態になり、設定したアクションが評価されます。この環境から実通知は送信されません。

アラーム (1)

メトリクス、条件、現在の状態を確認します。

アラーム名状態名前空間メトリクス条件期間アクション操作
practice-web-high-cpuarn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:practice-web-high-cpuEC2 · i-0a12bc34de56f7890 OK AWS/EC2CPUUtilization (Average) > 80300 秒1 期間中 1 点NONE

設定を編集

alarm-0a12bc34de56f7890

Amazon CloudWatch

アラームを作成

監視対象のメトリクスとしきい値を設定します。

複合アラームとメトリクス数式

practice-web-high-cpu

複合アラームとメトリクス数式

advanced-cloudwatch:alarm-0a12bc34de56f7890

複合アラームは参照先の状態変更に連動します。数式は上から順にメトリクスを使用し、期間・しきい値・通知はアラームの基本設定を使います。

アラーム条件
数式に使用するメトリクス

Amazon EC2

インスタンスに接続

インスタンス
インスタンス ID
パブリック IPv4
キーペア

接続はシミュレーションです

実際の SSH、Session Manager、EC2 Instance Connect のセッションは開始しません。接続先情報の確認だけを練習できます。

コンソールホーム

ウィジェットを追加

この設定はブラウザ内の表示だけに反映されます。

AWS PRACTICE CONSOLE

CloudShell

表示中の ap-northeast-1 の演習リソースを操作します。実際のAWSには接続しません。

対応コマンド: sts get-caller-identity、ec2 describe-instances / start-instances / stop-instances / terminate-instances、s3 ls、s3api list-buckets、iam list-users / list-roles、lambda list-functions。一般のシェル、ファイル操作、その他のAWSコマンドは未対応です。

AWS CLIの演習画面を開く

通知センター

演習環境で実行された操作の最新履歴

未読 1 件

System · CreateEnvironment新しい演習環境を準備しました東京 未読
AWS Health を開く

AWS PRACTICE

ミッションを選ぶ

0 / 13 クリア · 操作しながら AWS を学ぼう

好きな課題を選んで始めましょう。途中で切り替えても再開できます。演習環境を初期化するとミッションの進捗もリセットされます。

SAA-C03 対策のシナリオ演習と、操作の基礎を学ぶ課題を用意しています。公式試験ガイド ↗

13 件のミッション

Amazon S3 初級 · 目安 5分

操作の基礎

安全な S3 バケットを作ろう

データを誤って公開しないように保護し、バージョニングで変更に備えましょう。

達成条件を見る
  1. 新しいバケットを作成する
  2. パブリックアクセスをすべてブロックする
  3. バケットのバージョニングを有効にする
未挑戦 0 / 3
Amazon EC2 初級 · 目安 10分

操作の基礎

EC2 でサーバーを起動しよう

インスタンスタイプと監視設定を選び、小さなサーバーを起動しましょう。

達成条件を見る
  1. 新しいインスタンスを起動する
  2. インスタンスタイプを t3.micro にする
  3. 詳細モニタリングを有効にする
未挑戦 0 / 3
Amazon VPC 中級 · 目安 10分

操作の基礎

VPC にネットワークを構築しよう

独自の VPC とサブネットを作り、ネットワークの基本構造を学びましょう。

達成条件を見る
  1. 新しい VPC を作成する
  2. 作成した VPC にサブネットを追加する
  3. VPC の DNS 解決と DNS ホスト名を有効にする
未挑戦 0 / 3
AWS Lambda 初級 · 目安 5分

操作の基礎

Lambda 関数を作って実行しよう

サーバーを管理せずに動く関数を作り、テスト実行を体験しましょう。

達成条件を見る
  1. 新しい Lambda 関数を作成する
  2. メモリを 256 MB 以上に設定する
  3. 作成した関数をテスト実行する
未挑戦 0 / 3
Amazon RDS 中級 · 目安 10分

操作の基礎

障害に備えた RDS を構築しよう

Multi-AZ と自動バックアップを設定して、データベースの可用性を高めましょう。

達成条件を見る
  1. 新しい DB インスタンスを作成する
  2. Multi-AZ を有効にする
  3. 自動バックアップを 7 日以上保持する
未挑戦 0 / 3
EC2 × IAM × S3 SAA · 目安 15分

セキュアな設計 · SAA-C03 1.1

アクセスキーを置かずに S3 を読み取る

EC2 上のアプリが設定ファイルを S3 から読み取ります。長期アクセスキーを配置せず、読み取りに必要な権限をロールで渡しましょう。

達成条件を見る
  1. 新しい EC2 インスタンスを起動する
  2. EC2 を信頼する IAM ロールを関連付ける
  3. 演習用バケットの一覧取得とオブジェクト取得を許可する
  4. 同じ対象への書き込みと削除を許可しない

SAA のポイント

EC2 に IAM ロールを関連付けると、一時的な認証情報を利用できます。権限はポリシー名だけで判断せず、許可・明示的な拒否・アクセス許可境界も確認します。この課題ではバケットの ListBucket と、判定用ファイル mission-check.txt の GetObject / PutObject / DeleteObject の可否を確認します。実際の設計では対象リソースと全アクションを必要最小限に絞ります。

AWS 公式ドキュメント ↗: アクセスキーを置かずに S3 を読み取る
未挑戦 0 / 4
S3 × KMS SAA · 目安 15分

セキュアな設計 · SAA-C03 1.3

機密データを KMS キーで暗号化する

機密ファイルの保管先に、暗号鍵を自社で管理する要件があります。非公開バケットで SSE-KMS とキーの自動ローテーションを設定しましょう。

達成条件を見る
  1. 新しい S3 バケットを作成する
  2. パブリックアクセスをすべてブロックする
  3. 同じリージョンの有効な KMS キーで SSE-KMS を設定する
  4. そのキーの自動ローテーションを有効にする

SAA のポイント

SSE-KMS は KMS キーポリシーによるアクセス制御や利用の監査に対応します。キーはバケットと同じリージョンに置きます。自動ローテーションはキーマテリアルの更新であり、既存オブジェクトを再暗号化する操作ではありません。実際の読み書きには S3 と KMS の両方の権限が必要です。

AWS 公式ドキュメント ↗: 機密データを KMS キーで暗号化する
未挑戦 0 / 4
Amazon SQS SAA · 目安 15分

高可用性・耐障害性 · SAA-C03 2.1

処理に失敗したメッセージを DLQ に残す

注文処理をキューで分離します。3 回受信しても削除されないメッセージの退避先を設け、障害調査の時間を確保する設定にしましょう。

達成条件を見る
  1. 新しい標準キューを作成する
  2. 別の標準キューを DLQ に指定し、最大受信回数を 3 にする
  3. 送信元を 4 日、DLQ を 14 日保持する
  4. 送信元のロングポーリングを 20 秒にする

SAA のポイント

DLQ は繰り返し処理に失敗するメッセージを分離します。標準キューでは元の送信時刻が保持されるため、DLQ の保持期間を送信元より長く設定します。ロングポーリングは空の応答を減らします。この課題は設定の演習です。FIFO で厳密な順序が必要な場合は DLQ による順序への影響も検討します。

AWS 公式ドキュメント ↗: 処理に失敗したメッセージを DLQ に残す
未挑戦 0 / 4
Auto Scaling × ALB × VPC SAA · 目安 20分

高可用性・耐障害性 · SAA-C03 2.2

2 つの AZ で負荷に応じてサーバーを増やす

Web サービスを 1 つの AZ に依存させず、アクセス急増にも対応させます。ALB 配下に複数 AZ の Auto Scaling グループを構成しましょう。

達成条件を見る
  1. 新しいグループで 2 つ以上の AZ に正常なインスタンスを配置する
  2. 最小・希望容量を 2 以上、最大容量を 4 以上にする
  3. ALB のターゲットグループに登録し、ELB ヘルスチェックを使う
  4. メトリクスを送ってスケールアウトを成功させる

SAA のポイント

複数 AZ への配置は AZ 障害への備え、Auto Scaling は需要の変化や不健全なインスタンスへの対応に役立ちます。ELB ヘルスチェックを有効にするとロードバランサーの正常性も置換判断に使えます。アプリケーションのセッション情報は外部に保存し、台数が増減しても動作する設計にします。

AWS 公式ドキュメント ↗: 2 つの AZ で負荷に応じてサーバーを増やす
未挑戦 0 / 4
CloudFront × S3 SAA · 目安 15分

高パフォーマンス · SAA-C03 3.4

S3 の静的コンテンツをエッジで配信する

世界各地のユーザーに静的コンテンツを届けます。S3 をオリジンに、HTTPS・OAC・キャッシュ・圧縮の配信設定を組み合わせましょう。

達成条件を見る
  1. 実在する S3 バケットを選び、新しい配信を有効にする
  2. デフォルトビヘイビアで HTTPS を必須にする
  3. OAC の常時署名とオリジンの公開ブロックを設定する
  4. デフォルトのキャッシュ最適化と自動圧縮を有効にする

SAA のポイント

CloudFront はエッジキャッシュで遅延とオリジンへのアクセスを減らします。OAC で S3 へのリクエストに署名し、バケットの公開を避けられます。この課題は配信設定の確認です。実際の配信には、対象ディストリビューションからの読み取りを許可する S3 バケットポリシーも必要です。更新時は TTL と無効化の使い分けを考えます。

AWS 公式ドキュメント ↗: S3 の静的コンテンツをエッジで配信する
未挑戦 0 / 4
EBS × EC2 SAA · 目安 10分

高パフォーマンス · SAA-C03 3.1

容量を増やさず gp3 の性能を確保する

必要な容量は 200 GiB、性能は 6000 IOPS・250 MiB/秒です。gp3 で容量と性能を個別に指定し、EC2 に接続しましょう。

達成条件を見る
  1. 200 GiB の新しい gp3 ボリュームを作成する
  2. 6000 IOPS 以上・250 MiB/秒以上を指定する
  3. ボリュームを暗号化する
  4. 同じ AZ の実行中 EC2 にアタッチする

SAA のポイント

gp3 はストレージ容量と IOPS・スループットを個別に設定できます。容量を増やすだけで性能を確保する設計との違いを押さえましょう。EBS と接続先 EC2 は同じ AZ に置きます。実効性能にはインスタンス側の EBS 帯域も影響し、追加の IOPS・スループットには料金がかかります。

AWS 公式ドキュメント ↗: 容量を増やさず gp3 の性能を確保する
未挑戦 0 / 4
Amazon EFS SAA · 目安 10分

コスト最適化 · SAA-C03 4.1

アクセス頻度に応じて EFS の保管費を抑える

共有ファイルは作成直後によく使われ、その後ほとんど参照されません。複数 AZ の耐久性を保ちつつ、低頻度アクセス用の階層へ自動移行する設定にしましょう。

達成条件を見る
  1. 暗号化した新しい Regional ファイルシステムを作成する
  2. General Purpose と Elastic throughput を選択する
  3. 最終アクセスから 30 日で IA に移行する
  4. 最終アクセスから 90 日で Archive に移行する

SAA のポイント

EFS のライフサイクル管理は、最後のアクセスからの経過時間で IA や Archive に移行します。低頻度アクセスの保管費を抑える一方、取り出し料金や最小保存期間も考慮します。Archive を利用するこの構成では Regional・General Purpose・Elastic throughput を選びます。設定の達成は実際のデータ移行完了を意味しません。

AWS 公式ドキュメント ↗: アクセス頻度に応じて EFS の保管費を抑える
未挑戦 0 / 4
Amazon DynamoDB SAA · 目安 10分

コスト最適化 · SAA-C03 4.3

予測しにくいアクセスを DynamoDB で受け止める

新サービスの利用者ごとのイベントを保存します。アクセス量を予測しにくいため、オンデマンド容量と複合キーを選び、読み書きを試しましょう。

達成条件を見る
  1. 新しい DynamoDB テーブルを作成する
  2. キャパシティモードをオンデマンドにする
  3. userId と eventTime の複合キーを設定する
  4. 同じテーブルにサンプルを書き込み、スキャンする

SAA のポイント

オンデマンドは読み書きのリクエストに応じた課金で、事前の容量計画を減らせます。安定した負荷ではプロビジョンド容量との費用比較も必要です。利用者 ID と時刻の複合キーは利用者ごとの時系列取得に向きます。この演習の Scan は動作確認用で、実際のアクセス設計では Query の活用を検討します。

AWS 公式ドキュメント ↗: 予測しにくいアクセスを DynamoDB で受け止める
未挑戦 0 / 4

ヘルプ

演習環境について

演習状態はサーバーに保存されます。「学習を保存・復元」でファイルに保存すると、セッションが切れた後も再開できます。困ったときはホームの「演習環境を初期化」を使用してください。

統合設定

AWS コンソール全体の表示設定

表示モード

ライト、ダーク、または端末の設定に合わせます。

アカウントカラー

ナビゲーションに色を付け、開発・検証・本番アカウントを見分けやすくします。

変更はこのブラウザに自動保存されます。

practice-lab

PracticeAdmin

セッション
dbb5b076
アカウント ID
123456789012（演習用）
実際の AWS アカウント情報や認証情報は使用していません。

操作の確認

学習を保存・復元

演習リソースとミッション進捗をファイルに保存できます。同じサービスへファイルを読み込むと、別の日や別の端末でも再開できます。

操作がない状態で 120 分経過するとセッションが切れます。サーバーの演習データは最終利用から 30 日を過ぎると定期削除の対象になります。終了前にファイルを保存してください。

ファイルには入力した設定が含まれます。ファイルを持つ人は演習内容を復元できるため、大切に保管してください。サービスの更新により、古いファイルを復元できなくなる場合があります。

最大5MB。このサービスで保存した .awspractice ファイルを選択してください。

プライバシーと保存データ

このサービスは、入力した演習リソースの名前・設定、模擬操作の結果・履歴、ミッション進捗をサーバーに保存します。AWSの認証情報や実データは入力しないでください。

セッションCookieでこのブラウザの演習を識別します。セッション情報にはアクセス時のIPアドレスやブラウザ情報が含まれる場合があります。表示設定、お気に入り、最近使ったサービスはブラウザ内に保存します。

セッションの有効期間は未操作 120 分です。演習データは最終利用から 30 日を過ぎると定期削除の対象になります。学習ファイルは利用者の端末に保存され、自動削除されません。

入力した演習リソースと進捗は、ホームの「演習環境を初期化」で初期状態に戻せます。ブラウザ内の表示設定は「Cookie・表示設定」で削除できます。サーバーの運用ログやバックアップの保存期間は、運用環境の設定に従います。

ご利用にあたって

AWS Practice Consoleは非公式の学習用シミュレーターです。AWSへの接続や実際のリソース作成・課金は行いません。

対応範囲は画面ごとに異なります。実行結果、処理時間、件数、料金は模擬値です。実環境で操作する際は、AWS公式ドキュメントで現在の仕様を確認してください。

実際の認証情報、個人情報、業務データは入力しないでください。大量のリソース作成や過剰な連続操作には制限があります。演習データの継続保存を保証するものではありません。

AWS公式ドキュメント ↗

Cookie・表示設定

演習の識別とフォームの保護にCookieを使用します。Cookieをブラウザ側で削除すると、そのセッションの演習へ戻れなくなります。先に学習ファイルを保存してください。

テーマ、お気に入り、サービスの表示順、最近使ったサービスなどはブラウザ内に保存しています。以下の操作で、このサービスの表示設定だけを削除できます。

フィードバック

困った操作や改善案を記入し、報告内容をコピーできます。入力内容はこの画面だけで扱い、サーバーへ送信・保存しません。

受付先はまだ公開されていません。コピーした内容を、サービスを案内した方へ共有してください。