継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

CloudWatch Logs の Intelligent Tiering 設定が Terraform でサポートされたので import して試したメモ✍

タダです.

前回記事で AWS CLI から有効化した CloudWatch Logs の Intelligent Tiering ですが,AWS プロバイダー v6.57.1 でこの設定を管理する新リソース aws_cloudwatch_log_storage_tier_policy が追加されました.CLI で有効化したまま Terraform 管理外になっていた設定を terraform import で取り込んだのでそのメモをまとめます.

sadayoshi-tada.hatenablog.com

アップデートの概要

2026/7/29 リリースの AWS プロバイダー v6.57.1 で aws_cloudwatch_log_storage_tier_policy リソースが追加されました.書けるのは storage_tier(STANDARD / INTELLIGENT_TIERING)だけのシンプルなリソースで,アカウント×リージョン単位の設定をそのまま表現します.

resource "aws_cloudwatch_log_storage_tier_policy" "example" {
  storage_tier = "INTELLIGENT_TIERING"
}

registry.terraform.io

注意したいのは削除時の挙動で,ドキュメントに「Deletion of this resource will reset the storage tier policy to STANDARD」と明記されています.destroy するとリージョン内の全ロググループが Standard のストレージ料金に戻る点です.

有効化済みの設定を import ブロックで取り込む

検証環境は前回記事で put-storage-tier-policy を実行した東京リージョンです.get-storage-tier-policy で現状を確認すると,有効化した時のまま INTELLIGENT_TIERING になっていました.

aws logs get-storage-tier-policy --region ap-northeast-1
{
    "storageTier": "INTELLIGENT_TIERING",
    "lastUpdatedTime": 1784433656442
}

import ブロックとコード生成

Terraform 1.12.2 の import ブロックで取り込みます.import の ID はリージョン名です.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 6.57.1"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

import {
  to = aws_cloudwatch_log_storage_tier_policy.this
  id = "ap-northeast-1"
}

terraform init の後に plan を実行すると,現在の設定が読み取られて import 対象として表示されました.

terraform plan

  # aws_cloudwatch_log_storage_tier_policy.this will be importeds
    resource "aws_cloudwatch_log_storage_tier_policy" "this" {
        id           = "ap-northeast-1"
        region       = "ap-northeast-1"
        storage_tier = "INTELLIGENT_TIERING"
    }

Plan: 1 to import, 0 to add, 0 to change, 0 to destroy.

import の実行と差分確認

apply で import を確定させます.

terraform apply

aws_cloudwatch_log_storage_tier_policy.this: Importing... [id=ap-northeast-1]
aws_cloudwatch_log_storage_tier_policy.this: Import complete [id=ap-northeast-1]

Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed.

再度 plan して差分が出ないこと,state に取り込まれたことも確認できました.

terraform plan
No changes. Your infrastructure matches the configuration.

terraform state show aws_cloudwatch_log_storage_tier_policy.this
# aws_cloudwatch_log_storage_tier_policy.this:
resource "aws_cloudwatch_log_storage_tier_policy" "this" {
    id           = "ap-northeast-1"
    region       = "ap-northeast-1"
    storage_tier = "INTELLIGENT_TIERING"
}

これで CLI から入れた設定がコード管理に乗りました.アカウント×リージョン単位の設定なので,個別のアプリケーションではなくロググループの基盤定義と同じレイヤーに置いておくと,どのリージョンで有効化しているかをコードで追えるようになります.

まとめ

CloudWatch Logs の Intelligent Tiering 設定が Terraform の aws_cloudwatch_log_storage_tier_policy リソースでサポートされたので,CLI で有効化済みだった東京リージョンの設定を import ブロックで取り込みました.

Amazon ECS のデプロイ操作を可視化する Action Logs が出たメモ✍

タダです.

Amazon ECS にサービスデプロイや Managed Daemon 更新時の内部動作を記録する新しいオブザーバビリティ機能「Action Logs」がリリースされました.デプロイのトラブルシューティングに役立ちそうなアップデートなので,ドキュメントをもとに内容を整理します.

aws.amazon.com

Action Logs の概要

Action Logs は,ECS がユーザーに代わって実行するアクションをタイムスタンプ付きの構造化 JSON で記録する機能です.これまで ECS のリソースは開始と終了の状態しか観測できませんでしたが,Action Logs を有効化するとコンテナイメージのダウンロード,ロードバランサーへの登録,セキュリティグループの設定といった中間ステップまで見えるようになります.

記録対象は以下の操作です.

  • サービスデプロイ : 状態遷移,ロールバック,ライフサイクルフックの実行
  • Managed Daemon のライフサイクル : 作成・更新・削除,インスタンスのドレイン操作

各ログエントリには timestamp,logLevel(INFO/WARN/ERROR),resourceArn,actionSourceId,eventName(例 : DAEMON_DEPLOYMENT_IN_PROGRESS),detail などのフィールドが含まれます.クラスター単位でオプトインする方式で,ログの配信先は CloudWatch Logs,S3,Data Firehose から選べます.また,ログ発行は fire-and-forget 方式のため,配信に一時的な失敗があっても ECS のリソース操作をブロックしない設計になっています.

失敗したタスクのメタデータを標準の1時間の保持期間を超えて確認できる点や,コンソールの Amazon Q が Action Logs と統合されてサーキットブレーカーによるロールバックなどの根本原因分析・復旧ガイダンスを提示してくれる点も特徴です.

docs.aws.amazon.com

料金

Action Logs は有料の機能で,標準の CloudWatch Vended Logs の料金体系が適用されます.クラスターが生成するログ量に応じた取り込みと保存の料金がかかり,保持期間は配信先の設定で調整できます.なお,ECS コンソールから有効化した場合の CloudWatch Logs のデフォルト保持期間は7日です.

対応リージョン

AWS GovCloud (US) を含む全ての AWS リージョンで利用可能です.

Action Logs を有効化して確認する手順

事前準備

有効化する IAM アイデンティティに以下の権限が必要です.

{
    "Effect": "Allow",
    "Action": [
        "logs:PutDeliverySource",
        "logs:PutDeliveryDestination",
        "logs:CreateDelivery",
        "logs:GetDelivery",
        "ecs:AllowVendedLogDeliveryForResource"
    ],
    "Resource": "*"
}

配信先の CloudWatch Logs ロググループには delivery.logs.amazonaws.com からの書き込みを許可するリソースポリシーも必要です.

コンソールでの有効化

  1. ECS コンソールで対象クラスターを選択
  2. 「Configuration」タブの「Action logs」セクションで「Add」を選択
  3. 配信先を CloudWatch Logs(デフォルト)/ Amazon S3 / Amazon Data Firehose から選択
  4. 「Save」を選択

CloudWatch Logs を選んだ場合,/aws/vendedlogs/ecs/action-logs/{クラスター名} という名前のロググループが保持期間7日で自動作成されます.

AWS CLI での有効化

CloudWatch Logs の Vended Logs 配信 API を使って,配信ソースの登録,配信先の設定,配信の作成の3ステップで有効化します.東京リージョンの demo-cluster クラスターで実際に実行したコマンドが以下です.

# 配信ソースの登録
aws logs put-delivery-source \
    --name ecs-action-logs-demo \
    --resource-arn arn:aws:ecs:ap-northeast-1:123456789012:cluster/demo-cluster \
    --log-type ACTION_LOGS \
    --region ap-northeast-1

# 配信先の設定
aws logs put-delivery-destination \
    --name ecs-action-logs-demo-dest \
    --output-format json \
    --delivery-destination-configuration '{"destinationResourceArn": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/ecs/action-logs/demo-cluster"}' \
    --region ap-northeast-1

# 配信の作成
aws logs create-delivery \
    --delivery-source-name ecs-action-logs-demo \
    --delivery-destination-arn arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:ecs-action-logs-demo-dest \
    --region ap-northeast-1

なお,執筆時点のドキュメントでは --log-type EcsActionLogs と記載されていますが,実際に実行すると Provided LogType is not valid. Supported options are [ACTION_LOGS]. とエラーになり,ACTION_LOGS を指定する必要がありました.

ログ配信の確認

有効化後,クラスター内の demo-service サービスに対して desiredCount の変更と --force-new-deployment でデプロイを発生させて動作を確認しました.

aws ecs update-service \
    --cluster demo-cluster \
    --service demo-service \
    --desired-count 1 \
    --force-new-deployment \
    --region ap-northeast-1

デプロイ開始からまもなく,ロググループ配下に actionSourceId をログストリーム名とした service/demo-cluster/demo-service というログストリームが作成されました.

aws logs describe-log-streams \
    --log-group-name /aws/vendedlogs/ecs/action-logs/demo-cluster \
    --region ap-northeast-1 \
    --query 'logStreams[*].logStreamName'
# [
#     "service/demo-cluster/demo-service"
# ]

ログイベントを取得すると,デプロイの開始から完了までの状態遷移が3件記録されていました.

aws logs get-log-events \
    --log-group-name /aws/vendedlogs/ecs/action-logs/demo-cluster \
    --log-stream-name 'service/demo-cluster/demo-service' \
    --region ap-northeast-1 \
    --start-from-head \
    --query 'events[*].message'
  1. SERVICE_DEPLOYMENT_IN_PROGRESS(INFO): デプロイ開始
  2. SERVICE_REVISION_STABLE(INFO): サービスリビジョンの安定化
  3. SERVICE_DEPLOYMENT_SUCCESSFUL(INFO): デプロイの正常完了

実際のログエントリは以下のような JSON です.SERVICE_REVISION_STABLEstatusReason にはロックされたコンテナイメージの digest まで記録されていて,どのイメージでデプロイが確定したかをログだけで追跡できます.

{
  "resourceArn": "arn:aws:ecs:ap-northeast-1:123456789012:cluster/demo-cluster",
  "actionSourceId": "service/demo-cluster/demo-service",
  "logLevel": "INFO",
  "eventTimestamp": 1785031373006,
  "detail": {
    "statusReason": "Service revision marked stable. Locked to container image(s): 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app:latest@sha256:96419b83f29b198ae9f63670d5a28325a8bc9ebaf76c1260cf15eca3a521ebd0.",
    "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-revision/demo-cluster/demo-service/4844142804337893415",
    "status": "SUCCEEDED",
    "eventName": "SERVICE_REVISION_STABLE"
  }
}

docs.aws.amazon.com

ログ量に応じた課金が発生するため,有効化するクラスターの範囲と配信先の保持期間は運用に合わせて見直すのが良さそうです.

まとめ

ECS のデプロイや Managed Daemon 更新の内部動作を記録できる Action Logs についてまとめました.

Amazon CloudWatch Logs がIntelligent Tieringに対応してログを自動で階層化できるようになったメモ✍

タダです.

Amazon CloudWatch Logs がIntelligent Tieringに対応し,ログデータを自動でストレージ階層化できるようになったので,その内容をまとめます.

aws.amazon.com

何ができるようになったのか

CloudWatch Logs のログデータを,アクセス頻度に応じて自動で 3 つのストレージ層に振り分けてくれるようになりました.層の構成と移行ルールは以下です.

  • Standard: 従来どおりの層.取り込み直後や,アクセスがあったログはここに置かれる
  • Infrequent Access: 30 日間アクセスがないログが自動で移行される層
  • Archive Instant Access: 90 日間アクセスがないログがさらに移行される層

一度移行したログもクエリやエクスポートでアクセスすると Standard 層へ自動で昇格し,その後 30 日間は Standard として扱われます.移行やエクスポートを自前で組む必要がなく,アクセスパターンに合わせて勝手にコスト最適化してくれるのがポイントです.

長期保存が必要な大容量ログを CloudWatch の中に置いたまま低コストで保持でき,S3 への切り出しやフィルタリングを別途用意しなくて済むので,ログの置き場所を CloudWatch に統一しやすくなりそうです.

既存の Standard 層のログもそのまま対象になる

Intelligent Tieringは リージョン単位・アカウントレベル で有効化する設定で,有効にするとそのリージョン内のすべてのロググループが対象になります.新しく作り直す必要はなく,これまで Standard 層に貯めてきた既存のログもそのまま自動階層化の対象になるのがポイントです.

同じ「Infrequent Access」という名前でも,ロググループ作成時に選ぶログクラス(Infrequent Access クラス)は後から変更できず,作り直しが必要でした.今回のIntelligent Tieringは Standard クラスのまま透過的に階層化してくれるので,既存環境への導入ハードルが低いのが嬉しいところです.

なお有効化には以下の IAM 権限が必要です.CloudWatchLogsFullAccess マネージドポリシーがあれば両方含まれています.

  • logs:PutStorageTierPolicy — ストレージ階層の設定・変更
  • logs:GetStorageTierPolicy — 現在の設定の取得(コンソールからの有効化にも必要)

docs.aws.amazon.com

AWS CLI で有効化してみる

有効化はコンソール(Settings → Logs タブ → Intelligent Tiering)からもできます.有効化前は StatusDisabled になっています.

有効化前の Intelligent Tiering 設定(Disabled)

コンソールで有効化する場合は Enable Intelligent Tiering のトグルを ON にするだけですが,今回は AWS CLI で試します.

なお storage-tier 系のサブコマンドは比較的新しいため,古い AWS CLI では Found invalid choice 'get-storage-tier-policy' のようなエラーになります.その場合は最新の AWS CLI v2 へアップデートしてから実行してください.

この設定はリージョン単位なので,ここでは東京リージョン(ap-northeast-1)を対象に --region を明示して実行します.まずは有効化する前に,現在の設定を get-storage-tier-policy で確認しておきます.

aws logs get-storage-tier-policy --region ap-northeast-1

有効化前は Standard 層のままなので,以下のように返ってきます.

{
    "storageTier": "STANDARD"
}

現状を確認できたら,put-storage-tier-policyINTELLIGENT_TIERING を指定して有効化します.

aws logs put-storage-tier-policy --storage-tier INTELLIGENT_TIERING --region ap-northeast-1

実行すると,設定された階層と更新時刻が返ってきます.

{
    "storageTier": "INTELLIGENT_TIERING",
    "lastUpdatedTime": 1784433656442
}

有効化後にもう一度 get-storage-tier-policy を叩けば,storageTierINTELLIGENT_TIERING に変わっていることを確認できます.コンソール側でも StatusEnabled になり,トグルが ON になっていることを確認できました.

有効化後の Intelligent Tiering 設定(Enabled)

元の Standard に戻したい場合は STANDARD を指定します.戻すとそのリージョンのすべてのロググループが Standard のストレージ料金で課金されます.

aws logs put-storage-tier-policy --storage-tier STANDARD --region ap-northeast-1

階層ごとの保存量を確認する

有効化すると,ロググループごとに階層別の保存量が AWS/Logs 名前空間の StoredBytes メトリクスとして発行されます.StorageType ディメンション(Standard / Infrequent_Access / Archival_Instant_Access)で切り分けられるので,どのくらい低コスト層に移ったかをダッシュボードやアラームで追えます.ただしこのメトリクスは 1 日 1 回の発行なので,階層移動がリアルタイムに反映されるわけではない点に注意です.

対象リージョンと料金

すべての AWS コマーシャルリージョンで利用できますが,中東(バーレーン)と中東(UAE)は対象外です.料金については,Intelligent Tieringの有効化に追加料金はかからず,階層間の移動にも料金は発生しません.支払うのは各階層で消費したストレージ分だけです.

Amazon CloudWatch の料金 | 無料利用枠をご利用いただけます

自動で階層化されるのは便利ですが,StartQuery(Logs Insights)や FilterLogEvents / GetLogEvents,S3 へのエクスポートといった読み取り操作を行うと対象データが 30 日間 Standard 層へ昇格します.古いログを頻繁にクエリするワークロードでは昇格が繰り返されてコストの見込みが変わることもあるので,自分のアクセスパターンと料金体系を突き合わせてから有効化するのが安全だと感じました. なおこの昇格の仕様は公式ドキュメントの「Actions that constitute access」に記載されています.30 日のタイマーはアクセスのたびにリセットされる点も押さえておくとよいです.

The following access patterns automatically promote log data from the Infrequent Access tier or Archive Instant Access tier back to the Standard tier. When any of these operations read log events in a lower-cost tier, those log events move back to the Standard tier for 30 days. The timer resets on each subsequent access.

docs.aws.amazon.com

Standard と比べてどれくらい安くなるか試算してみる

実際にどのくらい効くのか,ストレージ料金だけをざっくり試算してみます.東京リージョンの各層のストレージ単価は以下でした(圧縮後の GB あたり・月額,料金ページの Store (Archival) より).

ストレージ単価(GB・月) Standard 比
Standard USD 0.033 -
Infrequent Access USD 0.0198 約 40% 安
Archive Instant Access USD 0.0066 約 80% 安

長期保存のログを 1,000 GB(圧縮後)貯めているロググループを例にします.古いログはほとんどアクセスされない想定で,層ごとの内訳を「Standard 100 GB / Infrequent Access 200 GB / Archive Instant Access 700 GB」と仮定します.

Standard 固定のままだと,全量が Standard 単価なので以下です.

保存量 計算 月額
Standard 1,000 GB 1,000 GB × $0.033 $33.00

Intelligent Tieringで上記の内訳に振り分けられると,以下になります.

保存量 計算 月額
Standard 100 GB 100 GB × $0.033 $3.30
Infrequent Access 200 GB 200 GB × $0.0198 $3.96
Archive Instant Access 700 GB 700 GB × $0.0066 $4.62
合計 1,000 GB - $11.88

このケースだと $33.00$11.88 で,ストレージ料金がおよそ 64% 下がる計算になりました.アクセスされないログの割合が多いほど効果が大きくなるので,長期保存メインのロググループほど恩恵を受けやすそうです.なお内訳の GB 数はアクセスパターン次第で変わる仮定値なので,実際は先ほどの StoredBytes メトリクスで自分の環境の層別内訳を見ながら見積もるのが確実です.

まとめ

Amazon CloudWatch Logs がIntelligent Tieringに対応し,ログを自動で階層化できるようになったアップデートをまとめました.長期保存するログのコスト最適化に効きそうなので,一度有効化して挙動を確認してみようと思います.

『The SRE Backlog: 蔵出し事例共有会』でアラート調査向け AI エージェントの本番導入について登壇したレポート✍

タダです.

「The SRE Backlog: 蔵出し事例共有会」で登壇させてもらったので振り返ります.

layerx.connpass.com

発表資料

発表資料は以下になります.

speakerdeck.com

もともとは下記の記事で書いた SRE Kaigi 2026 延長戦での発表内容の続編として,アラート調査向けの AI エージェントを本番導入した後に見えてきた課題とその改善を話しさせてもらいました.

sadayoshi-tada.hatenablog.com

所感

PoC をしていたエージェントが一定動作することが確認できたため本番導入してみることにしました.運用を始めてみるとシステム特有のコンテキストを持たず広く探索してしまうため調査が非効率になる課題や,アラートの探索が適切な時とそうじゃない時があり(ex. レイテンシーアラートの時に遅い RPC 名を見ただけで根本原因を断定してレポートしてしまう等)調査精度の課題が見えてきました.前者には Strands Agents の Skills 機能でシステム固有の調査観点を段階的に読み込ませることで無駄な探索を減らし,後者には投稿前チェック機構を入れて根本原因や数値など必要な情報が揃わないレポートは投稿しないようにして対処しました.

作って終わりではなく,現場の調査観点をどう与えるか・出力の品質をどう担保するかという運用に入ってからの改善こそが本番導入の肝だと改めて感じています.今後は内製ツールとの統合を強化して過去の対応データを参照させ,人間同様に滑らかに調査へ入ってプロアクティブに動けるエージェントへ改善していきたいです.

まとめ

「The SRE Backlog: 蔵出し事例共有会」で登壇させていただいたのでその振り返りをしました.

Amazon ECS のデプロイ状況をマネジメントコンソールでリアルタイムに確認できるようになったメモ✍

タダです.

Amazon ECS のデプロイ状況を AWS マネジメントコンソール上でリアルタイムに確認できるアップデートが 2026/7/1 に入ったので,その内容をまとめます.

aws.amazon.com

何ができるようになったのか

これまで ECS のデプロイ進捗を細かく追うには CloudWatch やサービスイベントを個別に確認する必要がありましたが,今回のアップデートで ECS コンソールの Deployments タブから直接デプロイの状況を追えるようになりました.主なポイントは以下です.

  • ライブデプロイタイムライン: 各フェーズ,サービスイベント,タスクの起動・終了の進捗が自動更新で表示される
  • リアルタイムヘルスモニタリング: サーキットブレーカーの状態,タスク障害の追跡,デプロイアラームの状態を監視できる
  • 障害診断: 失敗したタスクをタイムライン上で確認でき,CloudTrail など関連サービスへのディープリンクからそのまま調査に移れる

デプロイが進んでいる最中にコンソールを開いておけば状況が自動で更新されるので,別画面を行き来せずに済むのが便利そうです.

利用方法と対象

ECS コンソールで対象のサービスを選択し,Deployments タブを開くと確認できます.対象はローリングアップデートのデプロイタイプを使っているサービスです.

すべての AWS コマーシャルリージョンと AWS GovCloud (US) リージョンで利用でき,追加料金はかかりません.

実際にデプロイ状況を確認してみた

検証用のサービス test2(ローリングアップデート)でデプロイを流しながら Deployments タブを眺めてみました.

デプロイが正常に完了すると,タイムラインが Deployment startedIn progressComplete と順に埋まり,右側の Monitoring でサーキットブレーカーやヘルスチェックの状態も一目で確認できます.画面下部には対象のサービスリビジョンやデプロイ ARN もまとまっています.

デプロイが正常完了したときのタイムラインと Monitoring 表示

次に,あえて起動に失敗するタスク定義でデプロイしてみると,Latest service eventsTask failed to start がリアルタイムで流れ,New task launch progress が 0% のまま止まる様子まで追えました.失敗したタスクからは View task detailsView logs へそのまま飛べるので,原因調査の導線が短いのが良いです.

タスク起動に失敗して進捗が止まっている様子

失敗したデプロイを手動でロールバックすると,Rollback の枠が表示され Rollback successful に変わりました.Inspect with Amazon Q から調査に入れる導線も用意されています.

ユーザー操作でロールバックした様子

ロールバック後に正しいタスク定義で再デプロイすると,再びタイムラインが Complete まで進み,デプロイ状態が Success に戻ることも確認できました.

再デプロイが正常完了した様子

デプロイ失敗時の切り分けが速くなる一方で,タイムラインで見える情報だけで判断せず,最終的には CloudWatch アラームやログと突き合わせて確認するのが安全だと感じました.

まとめ

Amazon ECS のデプロイ状況をコンソールからリアルタイムに追えるようになったアップデートをまとめました.ローリングアップデート中の切り分けが手軽になりそうなので,一度触ってみようと思います.