AWS What's New Digest

Appearance

2026年02月28日 ​

[Lightsail] Amazon Lightsail expands blueprint selection with a new WordPress blueprint ​

概要 ​

Amazon Lightsailが新しいWordPressブループリントを追加しました。数クリックでWordPressがプリインストールされたVPSを作成でき、コンソール内のウィザードでカスタムドメインやDNS、静的IP、Let's EncryptによるHTTPS設定まで短時間で構成できます。

変更内容・新機能の詳細 ​

新しいWordPressブループリントは、LightsailインスタンスをWordPress動作環境（OS、Webサーバー、PHP、MySQLなど）で事前構成して提供します。インスタンス作成時にバンドル（CPU/メモリ/ストレージ・月間データ転送量含む）を選ぶだけで環境が立ち上がり、コンソール内のステップバイステップのセットアップワークフローにより以下を順に実施できます：カスタムドメインの接続、DNS設定、静的IPの割り当て、Let's Encryptによる無料SSL/TLS証明書の発行とHTTPS有効化。ブループリントはInstance Metadata Service v2（IMDSv2）をデフォルトで強制しており、これによりインスタンスメタデータへのアクセスがより安全になります（IMDSv2トークンの取得を必要とする）。本ブループリントはLightsailが利用可能な全リージョンで提供されています。備考として、Lightsailのブループリントは小中規模のウェブサイトを迅速に開始するのに最適ですが、スケールや高度なネットワーク要件がある場合はEC2やRDS等のサービスを併用する設計検討が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: 小中規模のウェブサイト運営者、個人開発者、スタートアップ、運用/DevOpsチーム
  • 利用シーン: 新規WordPressサイトの迅速な立ち上げ、開発/検証環境の構築、既存サイトの小規模移行
  • 運用効果: GUIベースのウィザードでドメイン設定からTLS導入まで短時間で完了し、運用開始までの時間短縮と設定ミス低減が可能
  • セキュリティ影響: IMDSv2強制によりメタデータ経由の情報漏洩リスク（SSRF等）を低減
  • スケーラビリティ影響: 単一Lightsailインスタンス前提のため、トラフィック急増時はロードバランサーや外部DBへの移行検討が必要
  • コスト影響: Lightsailのバンドル料金で提供されるため初期費用予測が容易だが、データ転送超過やスナップショット、追加サービス（RDS/CloudFront等）で別途費用が発生する可能性がある

技術的な注意点 ​

  • IAM権限: Lightsailリソースの作成には適切なIAMポリシー（lightsail:CreateInstance等）が必要です。DNSやRoute 53連携を行う場合は追加のRoute53権限が必要になることがあります
  • リージョン制限: 記事ではLightsailが利用可能なすべてのリージョンで提供とありますが、利用前に対象リージョンでブループリントが表示されるか確認してください
  • IMDSv2: インスタンスメタデータアクセスはIMDSv2を強制（トークン方式）しています。起動スクリプトやサードパーティツールがIMDSv1を使用している場合はIMDSv2対応に修正が必要です（PUT /latest/api/token でトークン取得）
  • データベース: ブループリントは通常ローカルのMySQL/MariaDBを使用するため、可用性やスケールを求める場合は外部マネージドDB（RDSなど）を検討してください
  • HTTPS/Let's Encrypt: Lightsailコンソールから無料証明書を発行/自動更新可能ですが、DNSが正しく設定されている必要があります。外部DNSを使う場合はTXT/ALIAS/CNAMEの設定を手動で行う必要があります
  • バックアップ/復旧: スナップショット機能でバックアップ可能ですが、スナップショット保存は追加コストが発生します。定期バックアップ方針を検討してください
  • ネットワーク/ファイアウォール: Lightsailはコンソールのファイアウォール設定（ポート単位）でアクセス制御を行います。セキュリティグループやVPCの高度な設定が必要な場合はEC2連携を検討してください
  • コスト: Lightsailは定額バンドル課金モデルですが、データ転送超過、スナップショット、外部サービス併用で追加費用が発生します。トラフィックとストレージ要件を見積もってプランを選んでください

参考情報 ​

[Ec2] EC2 Image Builder enhances lifecycle policies with wildcard support and simplified IAM ​

概要 ​

EC2 Image Builderのライフサイクルポリシーがワイルドカードによるレシピ指定に対応し、コンソールからライフサイクル用IAMロールを作成する際に必要な権限が自動入力されるようになりました。これによりイメージ管理のスケーリングと導入工数が削減されます。

変更内容・新機能の詳細 ​

主な変更点は2点です。1) ライフサイクルポリシーのワイルドカード対応：従来はレシピごとに個別のライフサイクルポリシーを作成するか、個別にレシピを選択していましたが、ワイルドカード（例: my-recipe-1.x.x）を指定することで、複数のレシピに対して単一のライフサイクルポリシーを適用できます。これにより、新規に追加されるレシピもパターンに一致すれば自動的にポリシー管理対象になります。2) IAMロール作成の簡素化：ライフサイクル管理用に必要な権限をコンソールで新規ロール作成時に自動で事前入力（デフォルト権限）するようになり、手動でのポリシー作成や設定ミスを減らせます。これらはイメージの保管・削除ポリシー（ライフサイクルの適用）や、IAM権限設定の運用負荷を低減する機能強化です。ライフサイクルポリシーは全商用リージョンで利用可能と明記されています。

影響範囲・利用シーン ​

  • 対象ユーザー: イメージパイプラインを運用するSRE/プラットフォームエンジニア、CI/CD/イメージ作成を自動化している開発チーム
  • 利用シーンまたは効果: 大量のレシピを扱う環境でのAMI/スナップショットのライフサイクル管理を一元化でき、新規レシピ追加時のポリシー設定作業が不要になる
  • 運用効果: ポリシー作成・IAM設定の工数削減、設定ミスの低減、不要なAMI/スナップショットの自動整理によるストレージコスト削減

技術的な注意点 ​

  • IAM権限: コンソールが自動入力するデフォルト権限は便利だが、最小権限（least privilege）の観点から組織ポリシーに合わせてレビュー・必要に応じて調整してください。自動作成されたロールもCloudTrailで監査可能です。
  • リージョン制限: ライフサイクルポリシーは全商用リージョンで利用可能とされていますが、機能のUI展開や一部細かい挙動はリージョン差が出る場合があります。利用前に対象リージョンでの挙動を確認してください。
  • コスト: 機能自体に直接の追加料金は通常ありませんが、ライフサイクル設定によりAMIやスナップショットの保持ポリシーが変わるため、保存コストの増減につながります（削除設定でコスト削減が期待できます）。
  • 互換性/制限: ワイルドカードはレシピ名（または表示名）のパターンマッチに適用される仕様です。パターンのマッチングルールや適用対象フィールドの詳細は公式ドキュメントで確認してください。重複するポリシーや広すぎるワイルドカード指定は意図しない対象を含める可能性があります。
  • 運用注意: 既存のライフサイクルポリシーとの重複や優先度、意図しない削除を防ぐため、導入前にステージング環境でパターンと影響範囲を検証してください。

参考情報 ​

[RDS] ARC Region switch adds three new capabilities: post-recovery workflows, RDS orchestration and AWS provider support for Terraform ​

概要 ​

Amazon Application Recovery Controller (ARC) の Region switch に、フェイルオーバー後の準備自動化（post-recovery workflows）、RDS のネイティブ実行ブロック、Terraform（AWS provider）対応の3機能が追加されました。これによりマルチリージョン障害復旧のオーケストレーションをより自動化し、IaC 化してCI/CDに組み込めます。

変更内容・新機能の詳細 ​

主な追加機能:

  • Post-recovery workflows: フェイルオーバー／フェイルバック後にスタンバイ側を次の障害に備えて準備するためのワークフローを自動化できます。今回のローンチでサポートされた実行ブロックは、カスタムアクション（Lambda実行ブロック）、Amazon RDS Create Read Replica 実行ブロック、ARC Region switch Plan 実行ブロック、手動承認（manual approval）実行ブロックです。これにより、フェイルオーバー後にリードレプリカの作成、Lambdaでの任意処理、承認ゲートの挿入、子プランの埋め込みなどを組み合わせた複雑な後処理を自動化できます。Post-recovery workflows はアクティブ/パッシブ構成で利用可能で、手動トリガーに対応します。
  • RDS 実行ブロック: RDS に関するオーケストレーションをネイティブにサポートする2種類の実行ブロックが追加されました。RDS Promote Read Replica 実行ブロックはフェイルオーバー時にリードレプリカを昇格してスタンドアロンにする操作を自動化します。RDS Create Read Replica 実行ブロックは post-recovery ワークフローの一部としてリードレプリカの再作成を自動化します。これにより手動でのプロモーションや複製再構築による遅延や人的ミスを低減できます。
  • AWS provider for Terraform サポート: Region switch のリソースが AWS provider for Terraform 経由で管理可能になり、ARC のプランや実行ブロックを IaC として定義し、CI/CD パイプラインに組み込めます。これによりディザスタリカバリ設定のバージョン管理、コードレビュー、パイプライン統合が容易になります。 補足技術情報: これらの実行ブロックはマルチリージョン・マルチアカウントのオーケストレーションを前提としており、Lambda 呼び出しや RDS のレプリカ作成/昇格といった API 呼び出しを自動で実行します。Terraform 経由での運用では AWS プロバイダのバージョンと状態管理、適切な権限設定が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE/クラウド運用チーム、プラットフォームエンジニア、DBA（RDS を運用するチーム）
  • 利用シーン: マルチリージョンの障害発生時に bounded recovery time を達成するフェイルオーバーと、フェイルオーバー後の即時復旧準備（リードレプリカ再作成、設定検証、手動承認フローの挿入等）を自動化する場面
  • 運用効果: 手動操作の削減による復旧時間短縮とヒューマンエラー低減、RDS の昇格/再作成を自動化することで DB 復旧の確実性が向上、Terraform 統合により DR 設定の再現性とCI/CDでの安全な展開が可能

技術的な注意点 ​

  • IAM権限: ARC、Lambda、RDS（CreateDBInstanceReadReplica、PromoteReadReplica、ModifyDBInstance 等）、必要に応じてKMSやCloudWatch Logs の権限、クロスアカウント実行がある場合は信頼ポリシー/ロールの事前設定が必要です
  • リージョン制限: 記事ではリージョン毎の詳細記載はありません。利用前にドキュメントで Region 対応状況を確認してください（リージョンやサービス周期により未対応の場合があります）
  • RDS制約: リードレプリカ作成/昇格の可否は DB エンジン／バージョンやクロスリージョンレプリケーションのサポート状況に依存します。対象エンジンの制約（例: 一部エンジンでの昇格不可や設定差異）を事前確認してください
  • コスト: 追加の RDS インスタンス（リードレプリカ）の稼働料金、クロスリージョンのデータ転送、Lambda 実行料金、ログ保存（CloudWatch）等が発生する可能性があります。Terraform による自動作成でリソースが増えると月次コストが増加します
  • Terraform 留意点: AWS provider の対応バージョンを確認し、State 管理（Remote state、ロック）と CI/CD 統合の設計を行ってください。ARC リソースの Terraform サポート範囲や属性はドキュメントで確認が必要です
  • テスト/検証: 本番運用前に非本番環境でフェイルオーバー/フェイルバックと post-recovery フローの実動作検証（復旧手順、タイムライン、動作権限）を必ず行ってください

参考情報 ​

[Network Firewall] AWS Network Firewall now supports firewall state change notifications through Amazon EventBridge ​

概要 ​

AWS Network FirewallがAmazon EventBridgeと統合され、ファイアウォールの状態変更や設定更新をリアルタイムで通知できるようになりました。これにより、設定変更やルールの更新、エンドポイント状態の変化を即時に検知して自動化ワークフローへ連携できます。

変更内容・新機能の詳細 ​

今回の機能追加により、AWS Network Firewallはファイアウォールの構成変更（Firewall configuration updates）、エンドポイントの状態変更（endpoint status modifications）、およびAWS Managed RulesやPartner Managed Rulesに関する重要な変更をEventBridgeイベントとして発行します。発行されるイベントは標準的なAmazon EventBridgeのイベント形式（source、detail-type、detail）に従い、EventBridgeルールでフィルタしてSNS、Lambda、SQS、外部SIEMやITSMの統合エンドポイントへルーティングできます。これにより、変更検知→通知→チケット起票や自動ロールバックなどの運用自動化を構築でき、運用の可視化と応答速度を向上させます。機能はAWS Network FirewallとAmazon EventBridgeが利用可能なすべてのリージョンで使用可能です（リージョンの可用性はAWS公式ドキュメントで確認してください）。詳しいイベントのスキーマやサンプルはAWS Network Firewallのドキュメントに記載されています。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク/セキュリティエンジニア、SRE、SOC/セキュリティ運用チーム
  • 利用シーン: ファイアウォール設定変更の即時通知（例: 管理ルールの更新、ルールグループの差し替え、エンドポイント状態変化の監視）、SNS経由のアラート、ITSMへ自動チケット作成、SIEMへのイベント連携
  • 運用効果: 設定ミスやルール更新による影響を迅速に検知して対応できるため、ダウンタイムやセキュリティリスクの低減と運用自動化による対応時間短縮が期待できる

技術的な注意点 ​

  • IAM権限: EventBridgeルール作成（events:PutRule、events:PutTargets 等）やターゲットリソース（SNS、Lambda、SQS等）への権限が必要です。発行元のNetwork Firewallに関する閲覧/管理権限も確認してください。
  • リージョン制限: AWS Network FirewallとAmazon EventBridgeが利用可能なリージョンで利用可能です。両サービスの可用性はリージョンごとに異なるため事前に公式リージョン一覧を確認してください。
  • コスト: EventBridgeのイベント受信/ルール実行、SNS/SQS/Lambda等のターゲット呼び出しに対する通常の課金が発生します。高頻度イベント発生時は費用増加の可能性があります。
  • イベントフォーマット: 標準的なEventBridgeイベント形式（source、detail-type、detail）で配信されます。詳細なフィールドやスキーマはNetwork Firewallドキュメントで確認してください。
  • レート制限／スロットリング: EventBridgeおよび各ターゲットサービスのAPI/配信レート制限に注意してください。大量イベントを扱う場合はバッチ化やフィルタリング設計を検討してください。

参考情報 ​

[Bedrock] Amazon Bedrock batch inference now supports the Converse API format ​

概要 ​

Amazon Bedrockのバッチ推論で、モデル呼び出しタイプとしてConverse APIフォーマットが利用可能になりました。これにより、リアルタイム推論とバッチ推論で同一のモデル非依存（model-agnostic）入力/出力フォーマットを使えるようになります。

変更内容・新機能の詳細 ​

従来のBedrockバッチ推論は、InvokeModel APIなど各モデル固有のリクエストフォーマットを必要としていました。今回の更新で、バッチ推論ジョブ作成時に「Converse」をモデル呼び出しタイプとして選択できるようになり、入力データを標準のConverse APIリクエストフォーマット（モデル非依存のチャット/メッセージ形式など）で構成できます。バッチ処理の出力はConverse APIのレスポンスフォーマットに従って返されます。これにより、リアルタイム（同期）推論とバッチ（非同期）推論で同一の入力スキーマを共有でき、プロンプトや入力管理が簡素化されます。設定はAmazon BedrockコンソールおよびAPIの両方から可能で、Bedrockのバッチ推論をサポートするすべてのリージョンで利用できます。実運用に入る前に、バッチ入力ファイルをConverse形式で整形し、S3にアップロードしてジョブを作成するワークフローを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、データサイエンティスト、SRE/運用チーム
  • 利用シーン: 大量データの一括推論（ログ解析、ドキュメント変換、分類、チャット履歴のバッチ処理など）で、リアルタイムと同じ入力フォーマットを使いたい場合
  • 運用効果: プロンプトテンプレートや入力整形の共通化により、モデル切替時の実装コストやバグが減少し、運用負荷が低下する
  • 互換性効果: 異なるモデル間でのフォーマット変換や専用ラッパー実装が不要になり、A/Bテストやモデル切替が容易になる

技術的な注意点 ​

  • IAM権限: バッチジョブ作成・実行、S3アクセス、Bedrockモデル呼び出しに関する権限が必要です（該当するポリシー/ロールを事前に確認・用意してください）。
  • リージョン制限: Bedrockのバッチ推論をサポートする全リージョンで利用可能とされています。対象リージョンでの提供状況はAWSリージョン表を確認してください。
  • コスト: 新機能自体に固有の料金体系は報告されていませんが、バッチ推論の実行料（モデル呼び出しコスト、データ処理時間）、および入力/出力のS3ストレージとデータ転送コストは発生します。ジョブ規模に応じたコスト見積もりを行ってください。
  • データ形式: 入力はConverse APIの標準リクエストフォーマットに準拠する必要があります（例: メッセージ/ロールベースの構造など）。出力もConverseレスポンス形式で返却されます。必ずUser Guideのフォーマット仕様に従ってファイルを作成してください。
  • API/コンソール: Converseモデル呼び出しタイプはコンソールおよびBedrockのAPI経由で設定可能です。既存のInvokeModel向けバッチ入力はそのままではConverseに自動変換されないため、入力ファイルの再フォーマットが必要です。
  • 運用上の注意: 大規模バッチでは入力サイズ、並列度、タイムアウト・エラーハンドリング（再試行ポリシー）を設計に組み込んでください。ログや出力の追跡はS3およびCloudWatchで行うと便利です。

参考情報 ​

[CloudWatch] Amazon CloudWatch logs centralization rules now support customizable destination log group structure ​

概要 ​

Amazon CloudWatch Logs のログ集中（centralization）ルールで、転送先のロググループ名を属性ベースでカスタマイズできるようになりました。アカウントIDやリージョン、組織情報などを使って意味のある階層構造でログを整理できます。

変更内容・新機能の詳細 ​

CloudWatch Logs の centralization ルール作成時に、転送先ロググループ名をプレースホルダ属性で定義できるようになりました。サポートされる属性には source.accountId、source.region、source.logGroup、organizationId、organizationalUnitId、rootId、フル組織パスなどがあり、パターン文字列（例: ${source.accountId}/${source.region}/${source.logGroup}）を指定すると、CloudWatch が実際の値に置換して転送先ロググループを作成・使用します。これにより、複数アカウント／複数リージョンのログをアカウント別／リージョン別／OU別など運用に沿った階層で中央集約できます。機能は centralization rules をサポートするすべてのリージョンで利用可能です。課金面では、centralization ルールを使って1コピー分のログ取り込み（ingestion）は無料で、追加コピーは $0.05/GB の料金が発生します（バックアップリージョン機能は追加コピーとして扱われます）。保存（ストレージ）料金は別途適用されます。既存ルールの更新により転送先が変わるため、運用上のリダイレクトや権限設定の確認が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチアカウント／マルチリージョンでログを集中管理するクラウドエンジニア、SRE、セキュリティ／コンプライアンスチーム
  • 利用シーンまたは効果: アカウントID・リージョン・OU・組織パスなどでログを自動的に階層化し、監査・検索・保持ポリシー適用を容易にする（例: 123456789012/us-east-1/cloudtrail/managementevent 形式で格納）
  • 運用効果: ログの発信元が一目で分かる構造化保存によりトラブルシュート、監査証跡確認、コンプライアンス対応が迅速化される
  • コスト影響: 単一コピーの取り込みは無料だが、追加コピーは $0.05/GB、かつストレージ料金が別途発生するため、コピー数と保存ポリシーを設計時に考慮する必要がある
  • リージョン対応: centralization rules をサポートするリージョンで利用可能（記事時点では対応リージョンに制限なしと明記）

技術的な注意点 ​

  • IAM権限: centralization ルールの作成・更新には CloudWatch Logs のロググループ作成/書き込み権限や centralization 関連の権限、必要に応じて AWS Organizations の読み取り権限が必要です。事前に最小権限ポリシーを確認してください
  • 命名制約: 指定するパターンはプレースホルダが置換された後のロググループ名が CloudWatch Logs の命名規則および長さ制限に収まるよう設計してください。特殊文字やスラッシュの扱いに注意が必要です
  • 既存ルールとの互換性: ルール変更により転送先が変わると既存のログ探索パスやアラーム定義に影響が出るため、変更前に影響範囲を確認し、必要なら移行手順を作成してください
  • コスト: 中央集約での追加コピー（バックアップリージョン含む）は $0.05/GB の課金対象、保存には別途ストレージ料金が発生します。集約設計時に見積もりを行ってください
  • リージョン制限: 記事にある通り centralization rules をサポートするリージョンで利用可能。各リージョンでのサポート状況は公式ドキュメントで確認してください

参考情報 ​

[General] AWS Resource Access Manager now supports maintaining shares when accounts change organizations ​

概要 ​

AWS Resource Access Manager (RAM)に、AWS Organizationsからアカウントが離脱してもリソース共有を維持するための設定（RetainSharingOnAccountLeaveOrganization）が追加されました。これにより合併・買収や組織再編時の共有リソースアクセスの継続化とSCPによる一元管理が可能になります。

変更内容・新機能の詳細 ​

新しいリソース共有設定パラメータ RetainSharingOnAccountLeaveOrganization と、これを参照・制御する条件キー ram:RetainSharingOnAccountLeaveOrganization が導入されました。管理者はリソースシェア作成／更新時にこのフラグを設定でき、設定されたシェアは組織外アカウントと同様に扱われ、アカウントが Organizations を離脱しても共有アクセスを維持します。保持を有効にした場合、離脱するアカウント側では明示的な招待の受諾が必要となり（invitation acceptance）、これによりRAMは組織内アカウントを外部アカウントとして扱います。代表的にRoute 53 Resolverルール、Transit Gateway、IPAMプール等のリソースで利用可能です。セキュリティ管理者はService Control Policies（SCP）で ram:RetainSharingOnAccountLeaveOrganization 条件キーを用いて組織全体でこの設定の強制（必須化）を行えます。本機能は全てのAWS商用リージョンで利用可能で、RAM自体の追加料金はありません（リソースの利用料は別途発生）。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドセキュリティ管理者、SRE、ネットワーク/インフラチーム、M&Aや組織再編を行う企業
  • 利用シーンまたは効果: 組織変更（合併・買収、アカウント移行、組織再編）時にRoute 53 Resolverルール、Transit Gateway、IPAMなど共有リソースへのアクセスを継続させることで業務中断を防止する
  • 運用効果: アカウント移動による一時的なアクセス断を回避し、SCPで設定を強制することで組織全体で一貫した共有ポリシーを適用可能にする
  • リスク: 組織を離れたアカウントが引き続きリソースへアクセスできるため、意図しない権限残存やガバナンス上の懸念が生じる可能性がある

技術的な注意点 ​

  • IAM/権限: リソースシェアの作成・更新にはRAMの関連API権限（ram:CreateResourceShare、ram:UpdateResourceShare等）が必要。SCPでの強制にはOrganizationsのポリシー編集権限が必要
  • 動作: RetainSharingOnAccountLeaveOrganization を有効にすると対象アカウントは外部アカウント扱いとなり、共有を継続するには招待の明示的受諾が必要
  • SCP連携: ram:RetainSharingOnAccountLeaveOrganization 条件キーを使用して、組織単位でこの設定を必須化（拒否ルールの作成）できる。ポリシー設計時は条件ロジックを確認すること
  • 監査/ログ: 共有作成・更新・招待承認はCloudTrailで記録されるため、監査ログの設定と確認を推奨
  • リージョン制限: 本機能は全てのAWS商用リージョンで利用可能（記事時点）。ただし一部リソース固有の制限や未対応リージョンがある場合があるため、対象リソースのドキュメントを併せて確認すること
  • コスト: RAM設定自体に追加料金は発生しないが、共有リソースの使用（データ転送、インスタンス/ゲートウェイの料金等）は通常通り課金される
  • 導入作業: 既存のリソースシェアを更新してフラグを追加する、SCPを作成して強制する、離脱アカウント側での招待承諾フローを運用に組み込む、という手順が必要

参考情報 ​

[Advance Pay] AWS now supports Bacs Direct Debit as a payment method for UK customers ​

概要 ​

AWSは英国在住の顧客向けにBacs Direct Debit（英国の銀行口座からの自動引き落とし）を支払方法としてサポート開始しました。GBP建ての個人・法人いずれの対応口座も接続でき、サインアップ時や請求設定で有効化できます。

変更内容・新機能の詳細 ​

今回の対応により、英国の顧客はAWSアカウントの支払い方法としてBacs Direct Debitを登録できるようになりました。新規サインアップ時は「Bacs Direct Debit」を選択し、対応する銀行を選んで銀行のモバイルアプリやオンラインバンキングの資格情報で認証することで口座所有権を検証し、AWSアカウントにリンクします。既存顧客はAWS BillingコンソールのPayment Preferences（支払い設定）から「Add payment method」→「Bacs Direct Debit」を選択して同様の認証フローで追加できます。検証後、その口座が将来の請求のデフォルト支払い方法として利用可能になります。対象はGBPベースのBacs対応口座（個人・法人）で、追加料金はありません。従来、英国ではクレジット/デビットカードとEUR建ての銀行口座のみの対応でしたが、今回GBP口座での自動引き落としが利用可能になった点が主な変更です。

影響範囲・利用シーン ​

  • 対象ユーザー: 英国内のAWS利用者（個人・法人）でGBP口座を使いたい請求担当者や財務チーム
  • 利用シーンまたは効果: 定期的なAWS利用料の自動回収によりカード管理の手間を削減し、会計処理の自動化やキャッシュフロー管理が容易に
  • 運用効果: カード更新作業やカード決済による拒否（charge decline）に伴う復旧工数を削減できる。銀行取引として直接口座から徴収されるため会計・銀行照合が簡素化される
  • 注意があるユースケース: 即時払いを要するワークフロー（たとえばスポットバイディレクトリの短期即時決済）では、Bacsの処理リードタイムに注意が必要
  • 組織管理: AWS Organizationsを利用している場合、支払い方法は支払い担当（payer）アカウント側で管理される点に留意が必要

技術的な注意点 ​

  • IAM権限: 支払い方法の追加・変更には請求コンソールへのアクセス権限が必要（請求情報の表示/変更を許可するポリシーが必要）
  • リージョン制限: 英国在住の顧客向け（UK地域の利用者）で、Bacs対応のGBP口座が必要。日本含む他国では利用不可
  • コスト: AWS側の追加料金は無し。ただし銀行側で口座振替の手数料や、返金/引き落とし不能時の銀行手数料が発生する可能性あり
  • 認証・セキュリティ: 銀行のモバイルアプリやオンラインバンキングでの認証により口座所有権を検証する。強力な顧客認証（SCA）や銀行の本人確認フローが適用される場合あり
  • 決済タイミング: Bacsのプロセスや口座検証のため、初回設定後すぐに引き落としが行われない可能性がある（数営業日のリードタイムが発生することを想定して運用設計を）
  • 請求/会計処理: 銀行口座からの引き落としはカード決済と異なり、リターン（返戻）や取消しの扱いが異なるため会計・請求フローの調整が必要
  • 組織利用: Organizationsを使う場合、支払い方法の管理は支払い責任のあるアカウント（Payer）で行う必要がある
  • 取消・変更: 口座の削除や支払い方法の切替はBillingコンソールから可能だが、口座側のマンダテ（direct debit mandate）取り消しは銀行側の手続きも必要になる場合がある

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026