AWS IAM Identity Centerのアイデンティティストアに「楽観的ロック」が導入され、更新競合を丢失-防止可能に

AWS IAM Identity Centerのアイデンティティストアにおいて、ユーザーおよびグループに対する「楽観的ロック（Optimistic Locking）」がサポートされました。各ユーザーとグループには属性変更のたびに更新される Revision 値が導入されました。UpdateUser や DeleteUser などの操作において、この Revision 値をリクエストに含めることで、自身が最後に読み取った状態から変更がない場合のみ操作を成功させることが可能です。値が一致しない場合は ConflictException が返されます。本機能は、Identity Store API を通じてのみサポートされており、SCIMエンドポイントやグループメンバーシップ操作には対応していません。既存の統合環境への影響はなく、追加料金なしで利用可能です。

🛠️ エンジニアへの技術的アドバイス

🚀 Problem/Solution: なぜこの機能が必要だったのか

以前の IAM Identity Center では、複数の管理者や自動化スクリプトが同時に同じユーザーやグループを更新しようとした際、後から実行された書き込みが、先に実行された変更を「知らないうちに」上書きしてしまう（Lost Update）問題がありました。今回の「楽観的ロック」の導入により、Revision 値による整合性チェックが可能になり、このような競合合意を確実に防ぐことができるようになります。

📍 日本国内の利用状況

リサーチ結果に基づくと、本機能は 東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) を含む、IAM Identity Center が利用可能なすべての AWS リージョンで利用可能です。日本の運用環境でもすぐに導入検討が可能です。

💡 運用上の注意点とアドバイス

• API利用時の実装変更: 楽観的ロックを利用するには、まず Describe や List 操作で最新の Revision を取得し、それを Update や Delete リクエストに含める必要があります。単に Revision を指定しない指定なしの場合は、従来の動作（上書き）として動作するため、既存のシステムへの影響（破壊的変更）は発生しません。
• 制限事項の把握: 注意が必要なのは、SCIMエンドポイント経由の操作は対象外である点です。Identity Store API を直接叩くワークフローを自作している場合は非常に有用ですが、SCIMを利用した外部IDP連携（OktaやAzure AD等）による属性同期では、このロック機能は効かない点に留意してください。
• コスト: 追加料金はかかりません。

✅ Next Action: まず何をすべきか

自動化スクリプトやカスタム管理ツールを IAM Identity Center のユーザー管理を行っている場合、ConflictException が発生した際の「再読み込み → 再試行」のロジックを実装するか検討してください。特に、複数のプロセスが並列で動いている環境では、整合性を担保するための強力な武器になります。

Reference: Identity Store API Reference (UpdateUser) AWS What's New