最終確認: 2026年5月
SOA-C03 試験の対象となる AWS サービスを、プレーンな Terraform を使用して構築します。1 ブロックずつ、それぞれ試験ドメインに関連付けられています。同じコードが OpenTofu でも動作します。
このラボの終わりまでに、プレーンなTerraformを使用して、完全な監視および自動修復ループをプロビジョニングできます。これは、メトリックフィルター付きのCloudWatchロググループ、人間にページを送信するSNSトピック、自動修正を行うSystems Managerランブック、および重大度の高いイベントをランブックに接続するEventBridgeルールで構成されており、一般的なインシデントは誰も起きる前に自己解決します。
すべてのリソースはプレーンなTerraformです。OpenTofuでも変更なしで同じコードが動作します。変数もモジュールもありません。スニペットを1つの main.tf にドロップし、terraform init を実行してから、terraform apply をステップバイステップで実行してください。
>= 1.5 または OpenTofu >= 1.6。us-east-1 用にAWS CLIが認証されていること。このラボのすべての費用は、アイドル状態では無料です。
自動修復が実際に作動した場合（ステップ5でSSMドキュメントがトリガーされます）、追加費用はかかりません — ここで使用されるアクションについてはSystems Manager Automationは無料です。
標準的な開始。default_tags はスタック全体に適用されるため、運用チームは後でCost Explorer、AWS Config、およびTag Editorを Project = certlabpro-soa-c03 でフィルタリングして、このラボが作成したすべてを確認できます。SOA-C03の「信頼性とビジネス継続性」ドメインでは、この点が明示的にテストされます — タグ付けは、すべての横断的な運用クエリの基盤です。
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-soa-c03"
ManagedBy = "terraform"
}
}
}AWSにおけるすべての運用ストーリーはCloudWatch Logsから始まります。明示的に30日間の保持期間を持つロググループを作成します（無期限というデフォルト設定は、すべてのコスト最適化の質問で出てくるSOA-C03のコストアンチパターンです）。そして、ログストリームで ERROR という単語を監視し、そのカウントをCloudWatch Metricsにパブリッシュするメトリックフィルターを設定します。
メトリックフィルターは、非構造化ログデータを実用的なメトリックに変換します。これがSOA-C03の監視に関する考え方です: ログ → フィルター → メトリック → アラーム → SNS → 人間（または自動化）。このステップから順にチェーンを構築していきます。
resource "aws_cloudwatch_log_group" "app" {
name = "/certlabpro/soa-c03/app"
retention_in_days = 30
}
resource "aws_cloudwatch_log_metric_filter" "app_errors" {
name = "certlabpro-soa-c03-app-errors"
log_group_name = aws_cloudwatch_log_group.app.name
pattern = "ERROR"
metric_transformation {
name = "AppErrorCount"
namespace = "CertLabPro/SOA-C03"
value = "1"
default_value = "0"
}
}次に、ステップ2からのメトリックを人間に接続します。SNSトピックを作成し、それにメールアドレスを登録し、エラーカウントが閾値を超えたときに発火するCloudWatchアラームを設定します。SOA-C03は、監視、ログ記録、および修復ドメイン（試験の約20%）で、この正確なチェーン — メトリック → アラーム → SNS → メール — をテストします。
terraform apply の後、AWSは endpoint に指定されたアドレスに確認メールを送信します — Confirm subscription を一度クリックすると、アラームが作動したときに実際に通知が届くようになります。
treat_missing_data = "notBreaching" は小さいながらも試験に関連する詳細です。デフォルトでは、データポイントの欠落は違反と見なされ、データのない新しいアラームが即座に発火することを意味します。これを notBreaching に設定することで、低ボリュームメトリックに対するSOA-C03の慣例に合致します。
resource "aws_sns_topic" "ops_alerts" {
name = "certlabpro-soa-c03-ops-alerts"
}
resource "aws_sns_topic_subscription" "ops_email" {
topic_arn = aws_sns_topic.ops_alerts.arn
protocol = "email"
endpoint = "ops@example.com" # replace with your real email
}
resource "aws_cloudwatch_metric_alarm" "app_errors_spike" {
alarm_name = "certlabpro-soa-c03-app-errors-spike"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 1
metric_name = "AppErrorCount"
namespace = "CertLabPro/SOA-C03"
period = 300
statistic = "Sum"
threshold = 10
alarm_description = "More than 10 ERROR log lines in 5 minutes."
alarm_actions = [aws_sns_topic.ops_alerts.arn]
treat_missing_data = "notBreaching"
}新しいインシデントに対して人間にページングするのは良いですが、既知の繰り返し発生するインシデントには費用がかかります。SOA-C03は、「すでに修正方法を知っているものを自動修正するにはどうすればよいか？」という問いに対する答えとして、AWS Systems Manager Automationに大きく依存しています — 不健全なサービスの再起動、認証情報のローテーション、ディスクスペースのクリーンアップなどです。
私たちは aws:sleep ステップ（AWSマネージドのステップタイプの一つ）を実行する最小限のSSMドキュメントを作成します — 本番環境では、これは既知のリカバリランブックに対する aws:executeAutomation、またはインスタンスフリートに対する aws:runCommand になるでしょう。形は同じです: 一連のステップを宣言し、ドキュメントに実行ロールを与え、再利用可能な自動化として登録します。
アタッチするIAMロールは、SSM Automationが自身を仮定し、ドキュメント内のアクションを呼び出す権限を与えます。SOA-C03の「信頼性とビジネス継続性」ドメインは、この正確なパターンをテストします: 名前付きのバージョン管理されたランブックは監査可能ですが、「あのサービスを再起動してくれない？」というSlackメッセージは監査可能ではありません。
resource "aws_iam_role" "ssm_automation" {
name = "certlabpro-soa-c03-ssm-automation"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "ssm.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy_attachment" "ssm_automation" {
role = aws_iam_role.ssm_automation.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole"
}
resource "aws_ssm_document" "remediate_app_errors" {
name = "certlabpro-soa-c03-remediate-app-errors"
document_type = "Automation"
document_format = "YAML"
content = <<-EOT
schemaVersion: "0.3"
description: "Lab-only runbook — auto-acknowledges app-error spikes."
assumeRole: "${aws_iam_role.ssm_automation.arn}"
mainSteps:
- name: pause
action: aws:sleep
inputs:
Duration: PT5S
EOT
}ループの最後の部分です。CloudWatchアラームは状態が変化するとEventBridgeのデフォルトバスにイベントを発行します — 私たちはステップ3で作成したアラームが ALARM に遷移するものをフィルタリングし、ステップ4からのSSMドキュメントを応答としてターゲットにします。
EventBridgeルールは、私たちに代わってSSM Automationを呼び出すための独自のIAMロールを必要とします — これは微妙ですが、SOA-C03で繰り返し問われる詳細です。試験では、EventBridgeがあなたに代わってターゲットを呼び出すことは、SSMドキュメント自身の仮定ロールとは異なる、専用の実行ロールが必要なサービス間アクションであることを覚えているかどうかをテストします。
これで完全なチェーンができました: ERROR を含むログ行 → メトリックフィルターがCloudWatch Metricsにパブリッシュ → 5分間にカウントが10を超えるとアラームがトリップ → アラームが状態変更イベントをEventBridgeにパブリッシュし、同時にSNS経由で運用チームにメール送信 → EventBridgeルールが状態変更に一致 → SSM Automationが修復ランブックを実行。ページャが鳴ると同時に修正が並行して開始されます。これがSOA-C03の運用理想です。
resource "aws_iam_role" "eventbridge_invoke_ssm" {
name = "certlabpro-soa-c03-eventbridge-invoke-ssm"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "events.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy" "eventbridge_invoke_ssm" {
name = "start-automation"
role = aws_iam_role.eventbridge_invoke_ssm.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "ssm:StartAutomationExecution"
Resource = "*"
}]
})
}
resource "aws_cloudwatch_event_rule" "app_errors_alarm" {
name = "certlabpro-soa-c03-app-errors-alarm-fired"
description = "Fires the auto-remediation runbook when the app-errors alarm trips."
event_pattern = jsonencode({
source = ["aws.cloudwatch"]
"detail-type" = ["CloudWatch Alarm State Change"]
detail = {
alarmName = [aws_cloudwatch_metric_alarm.app_errors_spike.alarm_name]
state = { value = ["ALARM"] }
}
})
}
resource "aws_cloudwatch_event_target" "run_ssm_doc" {
rule = aws_cloudwatch_event_rule.app_errors_alarm.name
arn = "arn:aws:ssm:us-east-1::automation-definition/${aws_ssm_document.remediate_app_errors.name}"
role_arn = aws_iam_role.eventbridge_invoke_ssm.arn
}terraform destroy を実行すると、このラボのすべてが削除されます。ただし、注意点が1つあります: SNSメールサブスクリプションは、削除後もアカウント履歴に残ります（AWSはコンプライアンスのために購読解除記録を保持します）。料金は発生しませんが、記録は残ります。その他はすべて1分以内にきれいに終了します。
SOA-C03は、このラボではカバーしきれない運用分野を扱います — コンプライアンスドリフトのためのAWS Configルールと適合パック、API監査のためのCloudTrail、Trusted Advisorチェック、マルチアカウント運用におけるCloudFormationドリフト検出とStackSets、AWS Backup、AWS Healthイベント、Resource Explorer、License Manager、およびService Quotas。
私たちはアラームから自動修復までのループに限定します。なぜなら、これは試験で最も頻繁にテストされる運用パターンであり、最も使用頻度の高い4つのサービス（CloudWatch、SNS、SSM、EventBridge）を結びつけるものだからです。他の運用ツールは概念的なカバレッジです — この認定ページの閲覧およびEditorialセクションを参照してください。