RSS DEV コミュニティ
フォロー
1つの組織か、それとも複数か？誰も書きたいと思わない事後分析
金融機関は、コストガバナンスのために単一のAWS Organizationに事業部門を統合しましたが、ルートノードに適用したサービスコントロールポリシー（SCP）の誤りにより、47分間の本番環境停止が発生しました。コストの一元的な可視性、単一ポリシーの強制、自動化の簡素化へのプレッシャーがこのアーキテクチャ上の決定につながりました。コンプライアンスのためにAWSリージョンを制限しようとしたセキュリティチームが、ルートにSCPを適用したことで、意図せず決済パイプラインの重要なDynamoDB呼び出しをブロックしてしまいました。これは、決済アカウントがブロックされたリージョンのDynamoDB Global Tablesエンドポイントを使用しており、初期監視ではエラーが検出されなかったために発生しました。
インシデントのタイムラインは、SDKエラーからサーキットブレーカーのトリップ、そして最終的には当初のトラブルシューティングの方向性を誤らせたアラートへと、段階的な障害を示しています。根本原因は、単一Organizationアーキテクチャに起因する、設計上の制限のない影響範囲（blast radius）であることが特定されました。これは単なる人的ミスではありませんでした。この設計では、決済のような規制対象ワークロードと運用ワークロードとの間に分離が欠けていました。階層的なSCPを持つ単一のOrganizationは、ルートレベルのSCPがすべてのアカウントに同時に影響を与え、ネイティブな段階的ロールバックがないことを意味します。
このテキストは、この問題のある単一Organizationパターンと、より強力な分離境界を提供する修正されたマルチOrganizationアプローチを対比させています。複数のOrganizationは、独立したポリシーライフサイクル、別々の管理アカウント認証情報、そして監査人がより容易に受け入れるクリーンな規制分離を提供します。複数のOrganizationは運用上の複雑さとランディングゾーン自動化の重複を増加させますが、これらは対処可能な問題です。直接的な技術的修正には、ルートまたは重要なOUへのポリシーの添付を防ぐためのガードレールSCPの実装が含まれていました。
中期的には、PCI-DSSワークロードのために2番目のAWS Organizationが作成され、セキュリティとポリシーの独立性が強化されました。AWS OrganizationsイベントをSlackとPagerDutyにキャプチャすることでオブザーバビリティが向上し、平均検出時間（MTTD）が劇的に短縮されました。SCPの根本的な問題は、通常のインフラストラクチャコードとは異なり、即時の伝播とステージングまたは自動ロールバックの欠如です。これを解決するために、SCPのイミュータブルステートレジストリが実装され、数秒以内の自動ロールバックが可能になりました。
