[レポート] AWS CDK / Grafana / OpenTelemetryを組み合わせたAmazon ECSのオブザーバビリティソリューションの構築方法を学んできました #AWSreInvent #DEV338

はじめに

皆様こんにちは、あかいけです。

AWS re:Invent 2025に参加しており、
「Secure Amazon ECS observability with CDK and Grafana」というセッションを聞いてきました。

オブザーバビリティはセキュアなワークロードを運用する上で非常に重要ですが、非技術者のユーザーにもアプリケーションの状態を分かりやすく伝えるにはどうすればよいでしょうか?

このセッションでは、AWS CDK、Grafana、OpenTelemetryを組み合わせてAmazon ECS上にオブザーバビリティソリューションを構築する実践的な方法が紹介されました。

セッション概要

タイトル
Secure Amazon ECS observability with CDK and Grafana (DEV338)

概要

Observability is critical for running secure workloads. This session shows how to combine the AWS Cloud Development Kit (CDK), Grafana, and OpenTelemetry to build an observability solution for Amazon ECS. Learn practical methods to detect anomalies, strengthen security posture, and improve developer productivity.

オブザーバビリティは、セキュアなワークロードを運用する上で不可欠です。このセッションでは、AWS Cloud Development Kit (CDK)、Grafana、OpenTelemetryを組み合わせて、Amazon ECS向けのオブザーバビリティソリューションを構築する方法を紹介します。異常検知、セキュリティ態勢の強化、開発者の生産性向上のための実践的な手法を学びます。

スピーカー

• Chibuike Wachuku, Software Engineer, Micro1

セッション情報

• レベル: 300 - Advanced
• セッションタイプ: Lightning talk
• トピック: Security & Identity

セッション内容

なぜこのトークが生まれたか

スピーカーのChibuike氏は、ヘルスケアスタートアップで働いていた際にCTOから相談を受けました。

• 課題
  • 非技術職のスタッフがアプリケーション内で何が起きているのかを理解するのに困っていた

• 患者がどのように登録しているか
• 医師とのライブ通話がどのように行われているか
• これらを確認するためにCloudWatch Logsを操作する必要があったが、非技術者には難しかった

そこで、オープンソースのツールを活用して、非技術者でも直感的に状況を把握できるソリューションを模索することになりました。

CTOからの指示は「オープンソースの世界を探索せよ」というものでした。

なぜGrafanaとLokiを選んだのか

CloudWatchを補完するソリューションとして、GrafanaとLokiを選択した理由は以下の通りです。

• リアルタイムインサイト: リアルタイムで状況を把握可能
• 美しく直感的なダッシュボード: 非技術者でも理解しやすいUI
• ベンダー非依存: 特定のベンダーにロックインされない
• オープンソースの柔軟性: カスタマイズが容易

AWS CDKによるIaCアプローチ

AWS CDKを採用することで、デプロイの複雑さを60%削減し、インフラのプロビジョニングを高速化できたとのことです。

アジェンダ

セッションでは以下の内容が紹介されました。

1. Why this talk? - このトークの背景
2. Observability - The AWS way - AWSにおけるオブザーバビリティ
3. Security, CDK, GitHub - 3つの柱
4. How the app works - アプリケーションのデモ
5. Actions and resources - 追加リソース

オブザーバビリティとは

オブザーバビリティとは、システムの内部状態を外部出力から理解する能力です。

• システム内部に入らずに、何が起きているかを把握できる
• アプリケーションがユーザーインタラクションにどう応答しているかを確認できる
• これを実現するには、アプリケーションがtraces、metrics、logsというテレメトリシグナルを発信する必要がある

OpenTelemetry (OTel)

OpenTelemetryは、テレメトリデータの計装、収集、エクスポートのためのオープンソースフレームワークです。

OpenTelemetryの特徴

• Instrument once, Send to multiple destinations: 一度計装すれば、複数の送信先にデータを送れる
• CNCFで2番目に大きいプロジェクト: Kubernetesに次ぐ人気
• 複数のプロバイダーと言語をサポート
• オープンソース & コミュニティ主導: ベンダーロックインなし

OTelのデータソース

オブザーバビリティの3つの柱について詳しく説明されました。

AWS Distro for OpenTelemetry (ADOT)

ADOTは、AWSがサポートするセキュアで本番環境対応のOpenTelemetryディストリビューションです。

• OTelプロジェクトのアップストリームファーストのディストロ
• 自動計装エージェントにより、アプリケーションコードを変更せずにトレースを収集
• セキュア & シンプルなデプロイメント

デプロイ方法はサービスによって異なります。

• ECS Fargate: サイドカーコンテナとしてアプリケーションの近くで実行
• AWS Lambda: Lambdaレイヤーとして追加

Instrument once - Distribute multiple

ADOTを使用すると、一度計装するだけで複数のAWSサービスやパートナーソリューションにデータを配信できます。

• データの流れ

  • 1. AWS Distro for OpenTelemetry (セキュアで本番対応)
  • 2. Collect Traces (リクエストごとのデータ収集)
  • 3. Collect Application Metrics (カスタムメトリクス収集)
  • 4. Correlate Traces & Metrics (トレースとメトリクスの相関)
  • 5. AWS Resource & Contextual Data (コンテキスト情報の収集)

• 送信先

  • AWS X-Ray
  • Amazon CloudWatch
  • Amazon Managed Service for Prometheus
  • Partner monitoring solutions

アーキテクチャ

セッションで紹介されたアーキテクチャは、VPC内にパブリックサブネットとプライベートサブネットを配置し、セキュリティを確保しながらオブザーバビリティを実現しています。

Security First Approach

セキュリティを最優先としたアプローチが紹介されました。

オブザーバビリティセキュリティの二層構造

セッションでは、オブザーバビリティのセキュリティについて二層構造が紹介されました。

第一層: ADOTからAWSサービスへの通信

• ADOTサイドカーがメトリクスとトレースを収集し、AWS X-RayやAmazon Managed Service for Prometheusに送信
• この通信はIAMロールによって保護され、外部からのアクセスを防止

第二層: アプリケーションからADOTへの通信

• アプリケーションはローカルホスト(localhost:1337)経由でADOTコレクターにアクセス
• この通信はコンテナのローカルネットワーク内で完結するため、外部からのアクセスは不可能
• ネットワークを離れない安全な接続でトレースとメトリクスを送信

Firelensサイドカー

ECSタスク定義でFirelensサイドカーを設定し、ログをLokiに送信する方法が紹介されました。

logger_task_def.add_firelens_log_router(
    "LogRouter",
    image=ecs.ContainerImage.from_registry("grafana/fluent-bit-plugin-loki:latest"),
    essential=True,
    firelens_config=ecs.FirelensConfig(
        type=ecs.FirelensLogRouterType.FLUENTBIT,
    ),
    logging=ecs.LogDrivers.aws_logs(stream_prefix="firelens")
)

Firelens as logging option

Lokiへのログ送信設定例です。URLがプライベートネットワーク内のLokiエンドポイントを指していることがポイントです。

logger_task_def = ecs.FargateTaskDefinition(
    self, "LoggerTaskDef",
    memory_limit_mib=1024,
    cpu=512,
    task_role=task_role,
    execution_role=execution_role
)

# Logger app container
logger_container=logger_task_def.add_container(
    "LoggerAppContainer",
    image=ecs.ContainerImage.from_ecr_repository(ecr_logger),
    essential=True,
    logging=ecs.LogDrivers.firelens(
        options={
            "Name": "grafana-loki",
            "Url": "http://loki.internal.com/loki/api/v1/push",
            "LabelKeys": "container_name,ecs_task_definition,source,ecs_cluster",
            "LineFormat": "key_value",
            "RemoveKeys": "container_id,ecs_task_arn"
        }
    ),
)

IaC & AWS CDK

AWS CDKを使用する利点が紹介されました。

Resource sharing

CDKでのリソース共有の例です。EFSアクセスポイントを作成し、Lokiタスク定義でボリュームとして使用しています。

# Loki Access Point
self.loki_ap = file_system.add_access_point(
    "LokiAccessPoint",
    path="/loki-data",
    create_acl=efs.Acl(owner_uid="10001", owner_gid="10001", permissions="750"),
    posix_user=efs.PosixUser(uid="10001", gid="10001"),
)

loki_task_def.add_volume(
    name="loki-efs",
    efs_volume_configuration=ecs.EfsVolumeConfiguration(
        file_system_id=efs.file_system_id,
        authorization_config=ecs.AuthorizationConfig(
            access_point_id=efs_loki_ap.access_point_id,
            iam="ENABLED"
        ),
        transit_encryption="ENABLED"
    )
)

GitHub

GitHubとの連携についても紹介されました。

デモ: アプリケーションの動作

OpenTelemetryパッケージのインポート

デモでは、OpenTelemetryの必要なパッケージをインポートし、AWSサービス(DynamoDB、SQS、S3)の計装を自動的に行う様子が紹介されました。

Auto-instrumentation

自動計装の設定は非常にシンプルです。以下のコードスニペットを追加するだけで、FastAPIとAWS SDKの計装が有効になります。

try:
    FastAPIInstrumentor.instrument_app(app)
    RequestsInstrumentor().instrument()
    Boto3SQSInstrumentor().instrument()
    BotocoreInstrumentor().instrument()
    logger.info("FastAPI and AWS SDK instrumentation enabled")
except Exception as e:
    logger.error(f"Failed to instrument FastAPI/AWS SDK: {e}")

このコードにより、SQSやDynamoDBなどのAWSサービスへのリクエストが自動的にトレースされます。

カスタムメトリクスとトレースの取得

自動計装だけでなく、カスタムメトリクスやメタデータを追加する方法も紹介されました。

if tracer:
    with tracer.start_as_current_span("send_sqs_message") as span:
        try:
            # Generate message data
            message_id = str(uuid.uuid4())
            message_data = {
                "id": message_id,
                "timestamp": datetime.utcnow().isoformat(),
                "source": "logger-app",
                "content": f"Test message {message_id}",
                "client_ip": request.client.host
            }

            span.set_attribute("sqs.queue_url", message_queue_url)
            span.set_attribute("sqs.message_id", message_id)

            # Send message to SQS

            # Record metrics
            if sqs_messages_sent:
                sqs_messages_sent.add(1, {"queue": "message-queue", "status": "success"})

GrafanaでのMetrics確認

Amazon Managed Service for PrometheusからGrafanaでメトリクスを確認できます。カスタムメトリクスsqs_messages_sent_totalが正しくカウントされているのが分かります。

エラーシミュレーション

404エラーをシミュレートして、オブザーバビリティソリューションがどのように異常を検知するかをデモしました。

Trace shows failure

Application Signalを使用して、404エラーのトレースを確認できます。
logger-app-client → logger-app → logger-app-data(DynamoDB) の流れで、どこでエラーが発生したかが一目で分かります。

Trace detail

トレースの詳細を確認すると、各スパンの所要時間やエラーの発生箇所が分かります。

• logger-app: 8.87ms
• get_dynamodb_data: 7.67ms
• GET /get-data/data_id: 39.06μs (エラー発生)

Metrics on Grafana

Grafanaでメトリクスを確認すると、operationごと(get_item、put_item)やstatusごと(not_found、success)のブレークダウンが可能です。

Lessons Learnt

セッションの最後に、3つの重要な教訓がまとめられました。

• 1. Start with security, not as an afterthought
  • セキュリティは後付けではなく、最初から組み込むべき
  • 後から追加しようとすると多くの問題が発生する
• 2. Use OpenTelemetry for Vendor Neutrality
  • AWSは2-3ヶ月前にAWS X-RayデーモンからOTELへの移行を発表
  • OpenTelemetryはオープンソースコミュニティで大きな支持を得ており、AWSもその流れに沿っている
  • ベンダーロックインを避け、柔軟性を確保するためにOpenTelemetryを活用
• 3. Automate everything with CDK & GitHub
  • CDKとGitHubで全てを自動化
  • CDK以外にもGitLabやBitbucketなど、好みのCI/CDツールを選択可能

リソース

スピーカーのChibuike氏は、このトークの内容を2部構成の技術記事としてMediumに公開しています。
また、GitHubリポジトリでサンプルコードも公開されているので、気になる方は覗いてみて下さい。

さいごに

以上、「Secure Amazon ECS observability with CDK and Grafana」セッションのレポートでした。

このセッションでは、実際の業務での課題(非技術者がアプリケーションの状態を把握できない)から出発し、OpenTelemetry、Grafana、AWS CDKを組み合わせた実践的なソリューションが紹介されました。

個人的に特に印象的だったのは、以下の3点です。

• セキュリティを最初から組み込むアプローチ
  • 後付けではなく設計段階からセキュリティを考慮することで、多くの問題を回避できる
• OpenTelemetryによるベンダー中立性
  • AWSも2-3ヶ月前にX-RayデーモンからOTELへの移行を発表しており、今後OpenTelemetryの重要性はさらに高まっていく
• IaCによる自動化
  • AWS CDKを使用することで、インフラのプロビジョニングを効率化し、開発者の生産性を向上できる

非技術者も含めた組織全体でオブザーバビリティを活用したい場合、GrafanaとLokiの組み合わせは有効な選択肢になりそうなので今後の参考にしたいと思います。