直近の AWS アップデート解説：Lambda IAM ポリシー強化と IoT Core InfluxDB 統合ほか

はじめに

今回は、直近で発表された10件のAWSアップデートを紹介します。なかでも実運用への影響が大きいのは、AWS Lambda のフル IAM リソースベースポリシー対応と、AWS IoT Core の InfluxDB 直接ルーティング機能です。Lambda のアクセス制御でポリシーを一本化できるようになり、マルチアカウント環境での権限管理エントリが集約されます。一方、IoT Core の新機能では、カスタムコードや中間のクラウドサービスなしで時系列データを InfluxDB へ直接書き込めるようになります。その他にも、ECS のエージェント接続自動修復、RDS の最新セキュリティパッチ対応、IAM Roles Anywhere の Java プラグインなど、運用効率とセキュリティを向上させるアップデートが揃いました。

注目アップデート深掘り

AWS Lambda のフル IAM リソースベースポリシー対応

Lambda 関数のアクセス制御が大きく進化しました。これまで Lambda 関数に対する権限付与は、プリンシパル（IAM ユーザー、IAM ロール、AWS サービス）ごとに AddPermission API を呼び出して個別に設定する必要がありました。複数のアカウントや複数のサービスから Lambda を呼び出す構成では、プリンシパルの数だけ権限エントリが増えていき、管理が煩雑になっていました。

今回のアップデートにより、Lambda 関数に対してフル IAM リソースベースポリシーを設定できるようになりました。これにより、複数のプリンシパルと複数のアクションを単一の JSON ポリシードキュメントで定義できるようになります。さらに、IAM の全条件キーが利用可能になります。告知で例示されているのはソース IP アドレスによる制限（aws:SourceIp）とプリンシパルタグによる制御（aws:PrincipalTag）で、これらを使ったきめ細かなアクセス制御を実装できます。

従来の方式との比較

従来は、組織内の複数アカウントから Lambda 関数を呼び出す場合、アカウントごとに以下のような権限追加が必要でした：

• アカウント A に lambda:InvokeFunction を許可
• アカウント B に lambda:InvokeFunction を許可
• アカウント C に lambda:InvokeFunction を許可

これが、今回のアップデートでは単一のポリシードキュメントで以下のように表現できます：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111111111111:root",
          "arn:aws:iam::222222222222:root",
          "arn:aws:iam::333333333333:root"
        ]
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MyFunction",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

このポリシーは、AWS Lambda コンソールの JSON エディタ、AWS CLI、AWS SDK、または AWS CloudFormation / AWS SAM といった IaC ツールから 1 ステップで更新でき、変更も一箇所で管理できます。特にマルチアカウント環境や、組織タグに基づいた動的なアクセス制御が必要な場合に、権限管理の変更箇所が一か所に集約されます。

活用シーン

プラットフォームチームが複数の開発チームの Lambda 関数を一元管理する場合、タグベースのアクセス制御と組み合わせることで、「Team=DataScience タグを持つロールのみが特定の Lambda 関数を実行できる」といったポリシーを簡潔に定義できます。また、セキュリティ要件として特定の IP レンジからのみ関数実行を許可する場合も、条件キーを活用して実装できます。

Note: 本機能は全 AWS 商用リージョンで追加料金なしで利用可能です。

AWS IoT Core の InfluxDB 直接ルーティング機能

AWS IoT Core に InfluxDB への直接ルーティング機能が追加されました。これまで IoT デバイスから送信される時系列データを InfluxDB に格納する場合、Lambda 関数でデータ変換を行うか、Kinesis Data Streams や Kinesis Data Firehose を経由してカスタムコードで処理する必要がありました。

今回の新機能により、IoT Core のルールエンジンから InfluxDB データベース（Amazon Timestream for InfluxDB または自社ホスト型 InfluxDB）へ、カスタムコードやクラウド中間サービスを使わずに直接データを送信できるようになりました。データは自動的に InfluxDB のラインプロトコル形式に変換されるため、デバイス側やサーバー側での変換処理が不要です。

アーキテクチャの変化

従来のアーキテクチャでは以下のような構成が一般的でした：

IoT デバイス → AWS IoT Core → Lambda（データ変換） → InfluxDB

または

IoT デバイス → AWS IoT Core → Kinesis → Lambda/Firehose → InfluxDB

新機能では以下のようにシンプルになります：

IoT デバイス → AWS IoT Core（ルールエンジン） → InfluxDB

この変化により、運用・監視すべき中間コンポーネントが減り、パイプラインを構成する要素そのものが少なくなります。

バッチング機能によるコスト最適化

本機能にはデバイス側とサーバー側の 2 つのバッチングオプションが用意されています。デバイス側バッチングでは、IoT デバイスが複数のメトリクスをまとめて送信することで、IoT Core へのメッセージ数を削減できます。サーバー側バッチングでは、IoT Core が複数のメッセージを集約してから InfluxDB に書き込むため、データベースへの書き込み回数を最適化できます。これらの機能を組み合わせることで、大量のセンサーデータを扱う環境でのコストとスループットを最適化できます。

ユースケース

告知では、ライフサイエンス企業が科学機器から得られる数千件のテレメトリー測定値をミリ秒単位のグラニュラリティでバッチ化し、カスタムデータパイプラインを構築することなく InfluxDB へ直接書き込んでモニタリングする例が挙げられています。

Note: InfluxDB ルールアクションは、Amazon Timestream for InfluxDB が利用可能なすべての AWS Global リージョンで提供されます。Amazon Timestream for InfluxDB と自社ホスト型 InfluxDB のどちらを選択するかは、管理の自動化レベル、コスト、既存システムとの統合要件によって判断します。

SRE視点での活用ポイント

Lambda のフル IAM ポリシー対応は、マルチアカウント環境での権限管理エントリを一本化できます。Terraform や CloudFormation でインフラを管理している環境では、これまで複数の aws_lambda_permission リソースや個別の AddPermission 呼び出しが必要だったものが、単一のポリシードキュメントで管理できるようになります。特に組織の成長に伴ってアカウント数が増加する場合、新しいアカウントを追加する際のポリシー更新が一箇所で完結するため、変更の追跡と監査が容易になります。

ただし、導入時には既存の権限設定との互換性を確認する必要があります。従来のプリンシパル単位の権限追加から単一ポリシードキュメントへ移行する際は、意図しない権限の重複や欠落が発生しないよう、移行計画を慎重に設計することが重要です。IAM Policy Simulator を活用して、ポリシー変更前後のアクセス可否を検証することを推奨します。

IoT Core の InfluxDB 統合は、大量のセンサーデータを扱う環境で運用負荷を削減できます。Lambda や Kinesis を経由するパイプラインでは、それぞれのサービスの監視、ログ管理、エラーハンドリングが必要でしたが、直接ルーティングによりこれらの中間層が不要になります。CloudWatch メトリクスで IoT Core のルール実行成功率とエラー率を監視し、InfluxDB 側のメトリクスと相関させることで、エンドツーエンドの可視性を確保できます。

障害対応のランブックに組み込む際は、InfluxDB への認証エラーやネットワーク到達性の問題を想定したトラブルシューティング手順を事前に整備しておくと、インシデント発生時の MTTR（平均修復時間）を短縮できます。また、バッチング設定はコストとレイテンシーのトレードオフとなるため、本番投入前に負荷テストを実施し、要件に合った設定値を見極めることが重要です。

全アップデート一覧

IAM Roles Anywhere とは？ AWS 外のワークロード（オンプレミスサーバー、他クラウド、CI/CD 環境）が X.509 証明書を使って一時的な AWS 認証情報を取得できる仕組みです。EC2 インスタンスプロファイルと同等の権限管理を AWS 外の環境に適用できます。

Amazon Timestream for InfluxDB とは？ AWS が管理するマネージド型の InfluxDB サービスです。InfluxDB OSS と互換性があり、インフラ管理なしで時系列データベースを運用できます。自社ホスト型 InfluxDB と同じ InfluxDB ラインプロトコルで書き込みが可能です。

まとめ

今回紹介したアップデートは、運用の自動化とセキュリティ強化という 2 つの軸で整理できます。Lambda のフル IAM ポリシー対応や ECS のエージェント自動修復は運用負荷を削減し、RDS の最新セキュリティパッチや Secrets Manager の外部シークレット管理はセキュリティ体制を強化します。IoT Core の InfluxDB 統合は、時系列データパイプラインのアーキテクチャをシンプル化し、運用とパフォーマンスの両面でメリットをもたらします。

また、Lambda の新ランタイムプレビューや AWS Batch の ECS MI 対応は、本番投入前に動作検証できる設計で、GA 前のフィードバック収集を意識した構成です。IAM Roles Anywhere の Java プラグインは、オンプレミスの Java アプリケーションからの一時認証情報の取得を、別プロセスや credential_process 設定なしで実装できる選択肢です。

これらのアップデートを活用することで、より安全で効率的な AWS 環境を構築できます。特に Lambda のポリシー管理と IoT Core のデータパイプライン簡素化は、既存構成の置き換え先がはっきりしているため、優先的に検証することをお勧めします。

📚 AWSをもっと深く学ぶなら

AWS認定ソリューションアーキテクト - アソシエイト 完全攻略（楽天ブックス）

• AWS公式ドキュメント