re:Invent 2024: Capital OneのIaCによるガバナンスとセキュリティ強化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Governance and security with infrastructure as code (DOP203)
この動画では、Infrastructure as Codeがクラウドにおけるガバナンスとセキュリティ戦略の重要な要素となる方法について解説しています。AWS CloudFormationやAWS CDKなどのツールを活用したInfrastructure as Codeの実践方法と、それらを補完するcfn-lintやCloudFormation Guard、cdk-nagといったセキュリティツールの具体的な活用方法を紹介しています。また、Capital Oneの事例として、CI/CDパイプラインの近代化戦略における3つの柱（コンプライアンスロジックの分離、Infrastructure as Codeへのシフト、CDK Constructライブラリの構築）を実装し、デプロイメント時間を40-50%改善した取り組みが共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Infrastructure as Codeがクラウドガバナンスとセキュリティに果たす役割
みなさん、こんにちは。re:Inventへようこそ。Las Vegasへようこそ。本日は、Infrastructure as Codeがクラウドにおけるガバナンスとセキュリティ戦略の重要な要素となり得る方法について、多くの方々にご参加いただき、大変嬉しく思います。私はAWSのSolutions ArchitectのEric Z. Beardです。本日は、同じくAWSのMac Merrittと、Capital OneのIshu Guptaと共に登壇させていただきます。まず私から導入部分をお話しし、その後、MacがAWSが提供するInfrastructure as Code関連ツールについて説明します。そして、IshuがCapital OneのDevOps現代化の取り組みにおいて、これらのツールをどのように活用してきたかについてお話しします。
まず最初に、会場の皆さんのことを少し知りたいと思います。どのような役割の方々がいらっしゃるでしょうか。プラットフォームチーム、Cloud Center of Excellence（CCoE）、インフラチームの方はいらっしゃいますか？かなりの数の方がいらっしゃいますね。開発者の方はどうでしょう？ソフトウェアエンジニアの方は何人いらっしゃいますか？何人か手が挙がりましたね。セキュリティ担当の方は？セキュリティの方々は目立ちたがらないかもしれませんが、誰にも言いませんよ。ビジネスサイドの方々は？営業や、マーケティング、経営層の方はいらっしゃいますか？数名いらっしゃいますね。このように、様々な役割や責任を持つ方々にお集まりいただいています。ここで強調したいのは、クラウドにおけるコンプライアンスに関して、皆さん全員がステークホルダーであり、それぞれが果たすべき役割を持っているということです。そして、今お話しした各役割には、それぞれ克服すべき課題があります。
DevOpsとデリバリーパイプラインの重要性
ビジネスサイドは常にコスト削減の方法を探しています。コスト削減によって、その恩恵を顧客に還元したり、利益を増やしたり、あるいはその両方を実現したいと考えています。そして、セキュリティチームは当然ながらリスクの低減と安全性の向上に注力しています。全社的なセキュリティ態勢に責任を持つ中央のセキュリティチームは重要です。しかし、本当に目指すべきは、会社全体でセキュリティ文化を醸成することです。先ほど申し上げたように、これらすべてのステークホルダーが、このことを念頭に置いています。そして、開発者たちは新機能を市場に投入するための絶え間ないプレッシャーにさらされています。新規顧客の獲得と、既存顧客の維持を目指しています。では、これらすべてのグループが課題を克服するために使える戦略とは何でしょうか？その戦略とは、自動化です。
ここで少し寄り道して、DevOpsとデリバリーパイプラインについてお話ししたいと思います。 今日はセキュリティとInfrastructure as Codeについてお話しする予定ですが、クラウドへのソフトウェアデリバリーの自動化は、コンプライアンスとセキュリティの重要な部分です。Infrastructure as Codeを使用するにあたって、私たちはアプリケーションの他の部分、つまりウェブサイトやAPIに対して行うのと同じような手法を、インフラストラクチャの変更にも適用していきます。まず開発者から始めましょう。ここでいう開発者には全員が含まれます。必ずしもオブジェクト指向のソフトウェアエンジニアである必要はありません。Infrastructure as Codeを書いているのであれば、あなたは開発者です。
開発フェーズでは、スピードを最適化することが本当に重要です。開発者ができるだけ生産性を高められるようにしたいと考えています。そして、開発者が正しいことを簡単に行えるようにしたいのです。開発者がデフォルトで安全なアプリケーションを開発していると確信を持って作業できるようにしたいと考えています。そのため、多くのセキュリティチェックを実施しています。コンプライアンスとセキュリティに関してよく耳にするフレーズですが、これらのチェックを「左にシフト」したいと考えています。開発者が早期かつ頻繁にコードをチェックできるようにすることで、本番環境で予期せぬ問題が発生することを防ぎたいのです。
開発者は自分のローカル環境でインフラストラクチャの変更作業を行います。コードレビューを受け、ソースコントロールにチェックインした後、中間段階であるビルドステージに進みますが、これは全て自動化されています。ここではコードのビルドや依存関係のチェックを行い、セキュリティスキャナーも再度実行します。静的スキャナー（AWS CloudFormation GuardやOpen Policy AgentのRegoなど）を使用して、作成したコードが安全でコンプライアンスに準拠していることを確認します。開発者側でこれらのチェックを左シフトしているので、ここでは驚くような問題は出てこないはずですが、信頼は検証とともにという考えで、ここにガードレールを設置します。本番環境でもさらにガードレールを設置してチェックを行いますが、予期せぬ問題は起きないことを期待しています。私がよく使う例え話があります。何年か前、雨の夜に高速道路を運転していた時、車がハイドロプレーニングを起こして、対向車線との間にある左側のガードレールに衝突したことがありました。
とても怖い経験で最悪でしたが、車は少し傷ついただけで、私は死ななくて良かったです。ガードレールに衝突したくはありませんでしたが、あそこにあって良かったと思います。このように、私たちもガードレールを設置しますが、それに衝突することは避けたいと考えています。これが、開発者が正しいことを簡単に行えるようにすることの重要性について話した理由で、そうすればガードレールに衝突することはないはずです。
アプリケーションをビルドし、これらの静的チェックを全て実行した後、実行時コードやアプリケーションコードと同様に、インフラストラクチャのコードを本番環境にデリバリーしていきます。まず共有開発環境にデリバリーします。ここで言う環境とは、通常1環境につき1つのAWSアカウントを指します。全ての開発者がこの環境を所有する共有開発環境から始めます。このアカウントには管理者がいて、本番データは存在しません。テストのために本番データを開発環境にコピーしたくなる誘惑には常に抵抗する必要があります。常に合成データを使用すべきです。
ソフトウェアを統合して動作確認をする際には、ここで問題が発生することを想定しています。全てが正常に動作し、全てのテストにパスしたら、Stagingステージに進みます。このステージはロックダウンされており、ユーザーがログインすることはできません。本番環境と同様に扱い、より現実的な負荷テストを実行するかもしれません。全てが成功したら本番環境に進み、おそらく段階的にロールアウトを行います。例えば、最初に1つのリージョンで展開し、その後2つのリージョンに展開するといった具合です。非常に慎重に進め、失敗の可能性を探し、問題があれば巻き戻してパイプラインをやり直します。
これら全ての目的は、スピードを維持しながらセキュリティも確保することです。そのためにDevOpsについて少し寄り道して説明しましたが、最新のDevOpsプラクティスを採用することでそれが可能になります。開発者が正しいことを行えるようサポートし、迅速に進めながら、同時にセキュリティも確保できます。Amazonでは、このように私たちはソフトウェアを開発しています。何千もの自律的な開発チームが、チームごとに1日に何度もコードを本番環境にプッシュしており、年間で数百万回のデプロイメントを実現しています。これを迅速かつ安全な方法で行っています。90年代後半から2000年代初頭にかけてこれらのプラクティスを採用した際、より速く、より安全に進められるようになっただけでなく、インシデントが減少し、変更のデプロイ時の障害も少なくなることがわかりました。
Infrastructure as Codeの採用とそのメリット
インフラストラクチャの変更においても、DevOpsの考え方を取り入れることには多くのメリットがあります。これが、私たち全員にとって本当に重要な要素であるInfrastructure as Codeにつながっています。多くの人が同じようなクラウドジャーニーを歩んできたのではないでしょうか。Webコンソールにログインし、あちこちクリックしながら、システムの仕組みやAWSの使い方を学び、アプリケーションを構築していく。今でも多くの人がこのような方法で運用しています。これはClick Opsと呼ばれ、本番環境への変更をコンソールにログインしてクリックで行う方法です。これを否定的な意味で捉えたくはありません。ある規模までなら、このような運用でも問題ありません。
会場の皆さん、手を挙げていただけますか。本番システムを今でもコンソールに入って手作業で管理している方は何人いらっしゃいますか？かなりいらっしゃいますね。それは、ある規模までは全く問題ありません。AWSコンソールは素晴らしく、多くの機能を提供してくれる便利なものです。しかし、一定の規模や複雑さに達すると、とても脆弱になってきます。複雑な運用手順書が必要になり、環境を再現するために詳細なドキュメントに従わなければならず、結果として時間がかかり、エラーが発生しやすくなり、セキュリティの問題にもつながる可能性があります。
この便利で使いやすいコンソールから、すべてをInfrastructure as Codeで行う方式に移行するのは、確かに大変な作業です。学ぶべきことが多く、かなりの学習曲線がありますが、それだけの価値があります。DevOpsやDevSecOps（業界でよく使われすぎて誤解されがちなバズワードですが）を採用したい場合、本質的に重要なのは、これらすべての活動を一つの活動にまとめることです。3つの異なるチームが、異なる場所で異なるタイミングで3つの別々のことをするのではなく、コードを開発し提供する際に、全員が運用とセキュリティを意識することが大切なのです。
Infrastructure as Codeを採用すると、素晴らしいメリットが得られます。まず、開発者向けツールを活用できるようになります。コードレビューが可能になり、より多くの目でインフラストラクチャの設定をチェックし、ベストプラクティスに従っていない箇所を見つけることができます。そして、CloudFormation GuardやCheckovなどの静的スキャナーを導入し始めることができ、バージョン管理も可能になります。
バージョン管理により、すべての変更履歴が記録されます。本番環境にデプロイしたものがアラームを発生させたり障害を引き起こしたりした場合でも、常に前のバージョンに戻すことができ、すぐに復旧できるはずです。また、IDEプラグインも使えるようになり、VS CodeやJetBrainsなどのツールを使用して、IDEの中で問題点を指摘したり、改善点を示唆したりする便利な機能が使えるようになります。しかし、Infrastructure as Code採用の最大のメリットは、一貫性のあるデプロイメントが可能になることだと思います。
複数の環境で全く同じアーキテクチャを確実に展開できるようにしたいものです。まずは開発者のローカル環境とSandboxアカウントから始めましょう。Sandbox環境について話す時は、いつも少し時間を取って、Sandboxとマルチアカウントアーキテクチャについて持論を展開させていただきます。ベストプラクティスとして、AWSを利用する開発者やオペレーターには、テストや実験用に独自のAWSアカウントを持っていただくことを強く推奨しています。さらに理想的なのは、複数のアカウントを持ち、開発やテストのために自由に実験用アカウントを作成できる環境を用意することです。
この考え方に対して、「コストがかかりすぎる」「セットアップが複雑になる」という反論をよく耳にします。しかし、長年の経験から言えることは、多くの開発者や本番アプリケーションを単一のAWSアカウントに詰め込もうとすると、かえって複雑でコストのかかる事態を招くということです。マルチアカウント戦略を採用する方が、常にコスト効率が良く生産性も高くなります。これはコストや生産性だけの問題ではありません。今回のテーマであるセキュリティの観点からも重要です。AWSを学び始めたばかりの新人開発者やオペレーターが実験する場合、変更の影響範囲が小さい独立した環境で行う方が望ましいのです。AWSの使い方を学ぶ際に、共有アカウントや本番アカウントを使用するのは避けるべきです。
本番環境でなくても、多くの開発者が単一の開発アカウントを共有している状況で何か問題が発生すると、全員の作業が止まってしまい、生産性が低下します。このように、マルチアカウントには多くのメリットがあります。さて、開発者が自分の作業に満足したら、 先ほど説明した自動デプロイメントパイプラインを開始します。 そして、Dev環境、Staging環境、Production環境に全く同じインフラストラクチャを展開していきます。これらのテンプレートは、アカウント間の小さな違いに対応できるようパラメータ化することができます。例えば、Dev環境では小規模で安価なEC2インスタンスを使用し、Production環境では大規模で高価なインスタンスを使用するといった具合です。ただし、基本的には同一のインフラストラクチャが展開されます。
AWSがInfrastructure as Codeを実現するための基盤サービスとして提供しているのがCloudFormationです。この概念に馴染みのない方のために、CloudFormationについて少し説明させていただきます。これはAWSのサービスで、YAMLまたはJSONでインフラストラクチャの設定を記述できるサーバーサイドのオーケストレーションエンジンです。JSONは主にマシンが読むためのものと考えており、人間が読み書きしやすいYAMLの使用を推奨しています。テンプレートを作成してCloudFormationに送信すると、それがStackと呼ばれるものになります。これらのStackには関連するリソースのグループが含まれます。例えば、ロードバランサーを前面に配置したEC2インスタンスのフリートとネットワーク設定を含むStack、静的WebサイトをホストするためのS3バケットとCloudFront distributionを含むStack、あるいはWeb APIとして機能するAPI GatewayとDynamoDBテーブルを含むStackなどが考えられます。
CloudFormationの優れた点の1つは、変更をアトミックに行うことです。設定変更や新しいリソースを送信すると、すべてが正常に作成されるか、何か問題が発生した場合は以前の状態にロールバックして、一貫性のある状態を維持します。デプロイメントが途中で失敗した場合の巻き戻しは非常に複雑になる可能性がありますが、CloudFormationがアトミックな変更を実現するための複雑な作業を全て処理してくれます。以前お話ししたように、長年クリックオペレーションやコンソールの操作、実行手順書やドキュメントに頼ってきた場合、これを採用するのは大変な作業になる可能性があります。習得には学習曲線があり、最初は少し気後れするかもしれません。
新しいサービスとして、IaC Generatorという非常に便利なものがあります。すでにリソースを作成して、すべてが望み通りに動作しているアカウントがあれば、Generatorを使ってアカウントをスキャンし、そのリソースと関連リソースを選択して、CloudFormationテンプレートを生成することができます。さらに数回クリックするだけで、それを管理されたスタックに変換でき、より簡単に学べて、より早く始められる方法でInfrastructure as Codeを採用できます。また、CloudFormationテンプレートの書き方を学ぶのにも最適です。コンソールで必要なリソースを作成し、アカウントをスキャンしてテンプレートを作成することで、テンプレートの構造を理解することができます。
AWS CDKとCloudFormationの活用
Macに話を譲る前に最後に紹介したいのが、AWS Cloud Development Kit（CDK）です。これはオープンソースプロジェクトで、おそらくAmazonで最も成功したオープンソースプロジェクトの一つだと思います。CDKはCloudFormationの上に構築されており、より高級なプログラミング言語でインフラストラクチャをコードとして記述することができます。TypeScriptやPython、C#などのオブジェクト指向言語を好むチームであれば、それらの言語でコードを書くことができ、CDKがCloudFormationテンプレートを生成してくれます。CDKはコードジェネレーター以上のものです - アセットのデプロイメントやデプロイも処理します。コード生成以外にもたくさんの機能がありますが、その核心はCloudFormationテンプレートを生成することです。
後ほどIshuがCapital Oneでの活用について話すように、CDKはクラウドにおけるコンプライアンスやセキュリティ、ガバナンスのための優れた戦略となり得ます。なぜなら、CDKではConstructsと呼ばれる再利用可能なコンポーネントを作成できるからです。CDKのもう一つの素晴らしい点は、GitOpsと呼ばれるものを採用できることです。GitOpsという言葉は通常Kubernetesコミュニティで使われていますが、ここでも同じように使えます。アプリケーションに対して帯域外の変更を一切行わないという考え方です。デプロイされたクラウドアプリケーションへのすべての変更は、ソースコントロールを通じて行われます。コードレビューを行い、自動テストを実施し、先ほど説明した自動デリバリーパイプラインを通過します。
これらのCDKアプリケーションでは、インフラストラクチャだけでなく、ランタイムコードもすべて含めることができます。WebサイトやREST APIがある場合、AWS Lambda関数のコードをCDKアプリに直接組み込むことができます。また、デリバリーパイプライン全体も指定できます。先ほど説明したdev、stage、prodの3段階のデリバリーパイプラインについて、それらすべてをCDKアプリで記述し、各ステージの設定もすべてアプリ内に含めることができます。環境設定を別々に管理する必要はなく、すべてが一箇所にまとまっているので、パイプラインのdev、stage、prodを含む環境全体へのあらゆる変更が、単一のCDKアプリケーションを通じて行われます。
ここでMacに話を譲りたいと思います。彼がInfrastructure as Codeのガバナンスとセキュリティを支援する具体的なツールについて説明します。ありがとう、Eric。これから数分間、開発者の生産性とスピードを犠牲にすることなく、必要なセキュリティとガバナンスを維持するという目標を実現可能にするAWSの様々なツールと機能について詳しく見ていきましょう。私はAWS IaC組織でSenior Engineerとして働いており、この話に関連する最近リリースした多くの機能についてお話できることを嬉しく思います。 また、これらの多くのツールを日常的に使用しているエンジニアとしての視点からもお話しします。AWS内の私が所属するすべてのチームは、インフラストラクチャのデプロイにInfrastructure as Codeを利用しており、セキュリティを最優先事項としながらも、結果を出して素早く前進するために、まさにこれらのツールを使用しています。
まずは、優れたコーディングの旅の出発点となるコードの作成から始めていきましょう。皆さんのバックグラウンドとツールの使用経験について、簡単に確認させてください。CloudFormationのYAMLやJSONのLinterであるcfn-lintを使用したことがある方は手を挙げていただけますか？ありがとうございます。では、テンプレートにポリシー実施ルールを記述するためのツールであるCloudFormation Guardについてはどうでしょうか？少し手が挙がりましたね。CDKユーザーの方で、CDKコードのポリシー実施ツールであるcdk-nagを使用したことがある方は？はい、何人かの方が手を挙げていますね。最後に、コーディング支援のための生成AIツールであるAmazon Q Developerについては？会場で何人かの手が挙がりましたね。今手を挙げた方もそうでない方も、これから数分間は非常に有意義なものになると思います。これは今回紹介する全てのツールに当てはまりますが、
新機能の具体例や、これまで考えていなかった使い方について、コーディング時のツールに限らずお話しします。今手を挙げなかった方も、ご自身のアプリケーションやニーズに応じて、これらのツールが役立つかどうかを判断できるよう、十分に分かりやすい説明を心がけます。
CI/CDパイプラインとAWSツールの統合
最初に紹介するのはcfn-lintです。Linterは従来、ベストプラクティスを適用し、コードの可読性を向上させるためのツールでした。しかしcfn-lintはそれ以上の機能を備えています。CloudFormationで定義された全てのリソースの仕様を使用し、CloudFormationの構文と動作を理解しているため、構文のハイライト表示や潜在的な問題の早期発見が可能です。また、CloudFormationエンジン自体への深い理解に基づくベストプラクティスも提供します。これらのベストプラクティスは、より信頼性が高く安全なインフラストラクチャの構築に役立ち、問題をより早く発見してプロダクティビティを向上させ、Shift Leftを実現することができます。
この具体例では、CloudFormationの動作を理解して活用する方法の一つを見ることができます。このリソース（KMSキー）において、DeletionPolicyが明示的に定義されていないことがハイライトされています。CloudFormationでDeletionPolicyが明示的に定義されていない場合、テンプレートからリソースが削除されると、AWSからそのリソースも削除されてしまいます。KMSキーのような重要なリソースの場合、これは停止やセキュリティの問題を引き起こす可能性があります。そのため、ベストプラクティスとしてこれを明示的に定義し、開発者が誤ってコードを多くコピー＆ペーストしてしまった場合でも、予期せぬ停止が発生しないようにすることが推奨されています。
2つ目の例では、cfn-lintがこのテンプレートで不必要なDependsOn関係を指摘しています。これは単にテンプレートの冗長性を減らしたり可読性を向上させたりするだけのように見えるかもしれませんが、実はそれ以上の意味があります。CloudFormationは宣言的な言語であり、通常は依存関係を明示的に定義する必要はありません。テンプレート内で自動的に依存関係を見つけることができます。これを削除することで、可読性が向上するだけでなく、パフォーマンスの最適化も活用できます。今年初めに、より高い同時実行性を実現するために依存関係の管理方法が改善され、CloudFormationが依存関係を最適化できるようになりました。テストでは、最大40%以上のパフォーマンス向上が報告されています。しかし、ここでDependsOn関係を明示的に指定すると、CloudFormationはその最適化を実行せず、代わりにここで定義された依存関係に従うことになります。
cfn-lintはガバナンスとコンプライアンスに役立ちますが、CloudFormation Guardは主にポリシー実施を念頭に置いて構築されており、生産性とスピードの面でより重点が置かれています。これは、テンプレートに適用できる任意のルールを定義し、最も重要な特定のベストプラクティスを監視または確認できるツールです。今回は、Guardで確認できるような特定の問題やコンプライアンスの懸念事項の一例を見ていきますが、他にもさまざまなルールを定義することができます。
いくつかの機能を確認する際の継続性を保つため、この例に戻ってみましょう。Infrastructure as Codeの強力な点の1つは、アプリケーションの関連リソースをまとめて定義できることです。つまり、アプリケーションの実行ロールを、そのアプリケーションのインフラストラクチャと一緒に定義できるということです。ただし、これにはリスクも伴います。アプリケーション内のポリシーが適切にスコープされていることを確認する必要があるからです。ここでは、このアプリケーションで指定したロールに対して「resource *」が定義されています。これは、このロールが私のアカウント内の任意のインスタンスを停止できることを意味します。おそらく、ここで構築しているアプリケーションには必要ないでしょう。リソースをこのアプリケーションで作成されたEC2インスタンスだけに指定することもできたはずです。
このようなケースをチェックするGuardルールを作成するのは良いアイデアでしょう。そこで、テンプレート内の「resource *」ステートメントをチェックするGuardルールを作成しました。実行すると、どのGuardルールが失敗したのか、具体的にどれが失敗したのかを確認できます。そして下部には、失敗した特定のルールが強調表示されます。ここでは言語が少し見慣れないものかもしれませんが、実際にはGuardの学習曲線は非常に速く、自分でGuardルールを書き始めるのが予想以上に簡単だったことに嬉しく驚きました。下部では、テンプレートのどの部分で違反が発生したかが具体的に強調表示されるため、開発者は素早く問題を修正できます。
これらのツールは、CloudFormationのYAMLやJSONを書く場合には素晴らしいものです。しかし、CDKユーザー、つまりInfrastructure as Codeにプログラミングスタイルのインターフェースを好む人々はどうでしょうか？そこで登場するのがcdk-nagです。CDKをCDK synthで合成すると、デプロイされるCloudFormationファイルが生成されます。その生成されたテンプレートに対してCloudFormation lintやCloudFormation Guardを実行することもできますが、開発者はCDKコードに存在しないConstructsやリソースに関するエラーを見ることになるため、トラブルシューティングが困難になります。
CDKでは抽象化やL2 Constructsなど、より高レベルのユースケースが可能なため、1対1のマッピングにはなりません。cdk-nagは、CDK自体の中で気になるルールを適用できるよりネイティブな体験を提供し、CDK-nag packsと呼ばれる多数のルールがすぐに使える形で同梱されています。この例では、AWS Solutions Checkを有効にしています。12行目でインポートして追加するだけで、HIPAAやその他の様々な基準など、いくつかの選択肢から適用したいものを選べます。
CDK synthを実行すると、この特定のCDKスタックを評価できます。Solutions Checkが発見する可能性のある問題の例として、ここではパブリックアクセスをブロックする設定が有効になっているS3バケットを定義しています。しかし、CDK synthを実行すると、このバケットにアクセスログが有効になっていないことがわかります。これは、バケットへのアクセス履歴を適切に監査するためのベストプラクティスです。また、SSLが必須に設定されていませんが、これは暗号化ポリシーを通じてリソースが意図した通りにアクセスされることを確保するために重要です。
テンプレートのデプロイを開始する前に、作成段階で最後に紹介するツールはAmazon Q Developerです。私個人としては、Q Developerは生産性向上に非常に役立つと感じています。アプリケーションコードやInfrastructure as Codeを書くときは、常にIDEで起動しておき、異なる言語間の切り替えやコードベースの理解、それらに関する質問をサポートしてもらっています。また、面倒なコーディング作業の自動化や、メソッドの素早い作成にも役立ちます。今回の話題に関連して言えば、CDKやCloudFormationなどのInfrastructure as Codeについての理解が組み込まれており、これまで議論してきた問題と同様のセキュリティ上の問題や脆弱性を特定できる最高クラスのスキャナーです。先ほど話したSSLの問題も同様に特定しますが、単に問題を指摘するだけでなく、修正案も提示してくれます。これらの提案を参考に自分で修正することもできますし、プレビューの内容に問題がなければ、修正を適用するボタンを押すだけでコードが更新され、セキュリティの修正が適用されます。これにより、開発者はセキュリティと開発スピードの両方を維持しながら、セキュリティの問題に対処しやすくなります。
CloudFormationテンプレートや一般的なInfrastructure as Codeのテンプレートができたら、それをデプロイしてインフラを実際に展開する必要があります。ここでContinuous IntegrationとContinuous Deploymentが関係してきます。Infrastructure as CodeとCI/CDの関係について混乱しているケースをよく目にします。私は、これらのツール間には2つの接点があると考えています。Infrastructure as CodeはCI/CDパイプラインの設定と定義に使用できます。Amazonで私が一緒に仕事をしているすべてのチームが、CI/CDパイプラインをInfrastructure as Codeファイルで定義しています。これにより、CI/CDシステム自体が非常に複雑になり、インフラストラクチャとアプリケーションロジックの両方が安全にデプロイされることを保証する上で重要であるため、一貫性とコードレビューを確保することができます。
CI/CDパイプラインが設定されると、Infrastructure as Codeを使用してインフラストラクチャ自体をデプロイすることができます。これにより、ロールバックやモニタリング、テストなどのCI/CDツールの安全性を活用して、アプリケーションコードと同じような安全性チェックでインフラストラクチャをデプロイすることができます。AWSでCI/CDを始めるためのツールは、AWS CodePipelineです。これはCI/CDの設定方法を定義するための上位レベルのツールで、ソースコードからビルド、テスト、ステージング、ステージング環境でのモニタリング（潜在的なロールバックのため）、そして最終的に本番環境への移行まで、様々なAWSツールとの統合機能を備えています。
CodePipelineの具体的な統合機能の1つとして、AWS CodeBuildについて説明したいと思います。Infrastructure as Codeテンプレートは、実行可能ファイルに変換される従来の意味でのコンパイルされるコードのような「ビルド」は必要ありませんが、AWS CodeBuildはInfrastructure as Codeにとって依然として大きな価値があります。なぜなら、気になる点をチェックするためのソフトウェアコンポジション分析などの様々なテストを適用できるからです。プラットフォームレベルでは、先ほどのGuardルールと同様のルールを定義して、CI/CDパイプラインを通過するコードがIAMポリシーでリソースにワイルドカード（*）を使用することを禁止するなどの設定ができます。そして、これらのプラットフォームレベルのチェックは、より具体的なアプリケーション固有のチェックを作成・定義する開発者定義のチェックと競合する必要はありません。
CloudFormationの機能とセキュリティ強化
AWS CodePipelineは、デプロイメントプロセスをサポートするために、CloudFormationの多くの機能と連携しています。CloudFormation内のこれらの機能は、CI/CDパイプラインと統合できるという点で価値があるだけでなく、CI/CDの範囲外からのインフラストラクチャ・アズ・コードのデプロイメントも保護します。インフラストラクチャ・アズ・コードのセキュリティとガバナンスについて話す際、最初に取り上げるツールはCloudFormation Hooksです。
HooksはCloudFormation内のポリシー実施メカニズムです。AWSのCloudFormationアカウントでHookを有効にすると、特別に除外されない限り、すべてのCloudFormationデプロイメントでそのHookが適用されます。今年、私たちはHooksについて、必要なセキュリティチェックをより簡単に実装できるよう、いくつかの新機能をリリースしました。例えば、カスタマイズしたロジックをより迅速に作成できるLambdaベースのカスタムHookを導入しました。
先ほどGuardルールで使用したのと同じテンプレートをCloudFormationにデプロイしようとした際、まさにそのGuardルールを使用するHookが有効になっていました。これは非常に強力な機能です。なぜなら、コードの作成時のチェックとデプロイメント時のチェックの一貫性を保つことができ、ベストプラクティスに従っている場合はガードレールが発動する必要がないからです。開発者がコードを出荷する前にGuardを適用していれば、本番環境でこのHookを気にする必要はありませんが、Hookはバックアップメカニズムとして存在し続けます。
ここでイベントをよく見ると、このデプロイメントで失敗したリソースがないことがわかります。これは、リソースに触れる前にスタックレベルでこのチェックが適用されたことを意味し、より早い段階でエラーを検出できます。また、スタックが予期しない状態に陥ったり、面倒なロールバックプロセスを経る必要がないという安心感も得られます。代わりに、素早くチェックして早期に失敗することで、リソースレベルからスタックレベルへのシフトレフトを継続できます。
さらに良い方法として、スタック自体に触れる前に事前チェックを実行することはできないでしょうか？そこで登場するのがCloudFormation Change Setsです。Change Setsは、デプロイメントの一部としてどのような変更が行われるかを事前に確認できるプロアクティブなメカニズムです。 Change Setsは今年、プロパティレベルの解決機能が強化され、どのリソースがデプロイされるかだけでなく、どのプロパティが変更されるかを正確に確認できるようになりました。また、CloudFormation Hooksとの統合も追加され、変更が期待通りかどうかを手動でチェックする必要がなくなりました。代わりに、気になるポリシーに違反がある場合にChange Setを失敗させたり、実行不可能にしたりするHookを定義できます。
Hooksとchange setsは、あるテンプレートから別のテンプレートへ、つまりある望ましい状態から別の状態へと移行する際のデプロイメントをチェックするのに役立つツールです。これは、インフラストラクチャのすべてをInfrastructure as Codeで管理するというベストプラクティスに従っている場合に特に効果を発揮します。しかし、意図しない変更や運用上必要な影響、その他のメカニズムにより、Infrastructure as Code以外の方法でインフラストラクチャの変更が発生することがあります。Drift detectionは、そのような変更を発見し、理解し、対処するための方法です。Drift detectionは、リソースの実際の状態をチェックし、テンプレートに記述された望ましい状態と比較して、両者の間に不一致や齟齬がないかを教えてくれます。これは定期的なジョブとして実行することも、CodePipelineとのカスタム連携として実行することもでき、リソースが常に期待される状態を維持していることを確認できます。
この例では、あるリソースの実際の状態でDNS設定を変更し、Drift detectionを実行してその変更を確認しました。これは、コンソールでDrift detection違反を調査する場合のイメージをつかんでいただくためです。プロパティの両方の状態を並べて表示することで、違いを確認することができます。その後、テンプレートを実際の変更に合わせて更新するか、リソースの実際の状態をテンプレートに合わせて更新するかを決めることができます。
ここからは、単一のデプロイメントから一歩進んで、組織全体への展開と、Infrastructure as Codeが1つのアカウントの境界を超えて複数のアカウントや組織全体にどのように広がっていくかについて考えていきましょう。CloudFormation StackSetsは、CloudFormationのパワーを組織全体に展開できるツールです。これは、非常に細かなLanding Zoneの定義や、特定のアカウントやアプリケーションの初期設定など、すべてのアカウントで実行する必要があるものに役立ちます。 また、データを完全に分離する必要がある大規模なシングルテナントアプリケーションで成功を収めている顧客も多く見てきました。
このようなアプリケーションのベストプラクティスは、真の分離を実現し、適切なセキュリティポスチャを維持するために、各アプリケーションインスタンスを独自のAWSアカウントで実行することです。アカウントとアプリケーションインスタンスの数が数千や数万に増加すると、従来のツールでは非常に困難になる可能性があります。AWS CloudFormation StackSetsは、このような規模に対応できるように設計されており、1つのStack Setあたり10万のStackインスタンスというデフォルトの制限と、AWS Organizationsとのネイティブな統合により、アプリケーションを一度定義するだけで、組織に新しいアカウントが追加されたときに自動的にインスタンスをスピンアップすることができます。
私たちは、StackSetsでこのような規模に対応する能力を常に改善しています。昨年、soft concurrency modeと呼ばれる同時実行管理の改善をリリースし、この機能を採用したお客様の中には95%のパフォーマンス向上を報告する例もありました。さらに、CloudFormation open repositoryにサンプルテンプレートをリリースし、すべてのデプロイメントの問題に関するログを一元化することで、トラブルシューティング時に個々のターゲットアカウントにログインすることなく、管理アカウントから問題をデバッグして解決できるようになりました。
最後にご紹介するツールは、AWS Control Towerです。これは従来の意味でのInfrastructure as Codeツールではありませんが、これまで説明してきた保護機能をアカウント全体で一貫して適用できる、非常に推奨されるベストプラクティスです。 この例では、AWS Control Towerを使用して、組織内のすべてのアカウントでリソースチェックを設定しました。これにより、作成時、CI/CDプロセス中、CloudFormationに組み込まれた形で、そして Control Towerを通じて組織全体にスケールアウトされた形で、同じスタイルのチェックを実施できることを示しています。
短時間で多くのツールを説明したことは承知していますし、具体的にどのツールを使うかはアプリケーションによって異なります。私が伝えたかったのは、セキュリティと開発者の生産性、そしてスピードを同時に実現できるということです。使用する具体的なツールはアプリケーションによって異なりますが、この説明で、どのツールを検討すべきかの大まかな方向性をつかんでいただけたと思います。ここからは、Infrastructure as Codeを使用して一貫性とセキュリティを実現した Capital Oneでの経験について、Ishuにバトンタッチしたいと思います。
Capital OneのDevOps現代化への取り組み
Capital Oneは、最新のテクノロジースタック、最新のツール、革新的な製品で知られる国内最大級の銀行です。また、パブリッククラウドを採用した最初のメジャーな銀行でもあります。私は Capital Oneで Director of Software Engineeringとして、 CI/CDパイプラインとCI/CDプラットフォームの構築を担当しています。詳しい経緯をお話しする前に、私たちがDevOpsの取り組みをどこから始めたのかについてお話ししたいと思います。当時は、パイプラインの特定の部分を担当するチーム、つまり特定のツールやプロセスの専門家がいました。アーキテクチャを構築するアーキテクチャチーム、アプリケーションコードを書くエンジニアリングチーム、セキュリティのベストプラクティスを実装するセキュリティチーム、そして品質管理と運用のチームがありました。このモデルは上手く機能していましたが、ほとんどのチームがサイロ化しており、各実践は他のチームにとってブラックボックスでした。
これによって生じた課題は、本番環境でインシデントが発生した際、運用チームが問題解決のために適切なチームを探さなければならなかったことです。このモデルは当初うまく機能していましたが、パブリッククラウドを採用した際に、 変革の必要性を感じました。私たちは異なるアプローチを取り、アプリケーションチームが自分たちのユースケースに最適なパイプラインを構築できるように権限を与えました。しかし、これにより新たな課題が生まれました。チームが特定のユースケースのために独自のパイプラインを作成し、多くのチームが同じことを繰り返し作り直していたのです。DevOpsエンジニアを雇用するチームまで出てきました。
一部のチームは、アプリケーション固有のカスタムパイプラインを開発しましたが、これは私たちが意図していたアプローチではありませんでした。大企業として、即座に一元化するのではなく、段階的に進めることにしました。 パイプラインとソフトウェアデリバリーを事業部レベルで一元化することを決定し、これは成功を収め、大幅な標準化を実現することができました。しかし、チームがその事業部レベルでもサイロ化した状態でソフトウェアを構築していたという根本的な問題は残ったままでした。
私たちは、全社的なCI/CDプラットフォームを採用することで、さらなる重要な一歩を踏み出しました。過去の反省として、中央チームが全てを管理し、他の人々にとってブラックボックス化してしまうという失敗を繰り返したくありませんでした。私たちが構築したCI/CDプラットフォームにより、アプリケーションチームはアプリケーションロジックとビジネス上の課題に集中できるようになり、一方で私たちは銀行組織として必要なボイラープレートコードや標準規格を担当することになりました。開発者の作業をより効率的にするため、Peer Reviewのチェック、OSSの脆弱性検査、デプロイメントのベストプラクティス、その他の要件を裏側で標準化しました。
このモデルは成功を収めましたが、AWSが継続的に新しいサービスを導入する中で、私たちは戦略を見直す機会に気づきました。私たちのパイプラインにはComposabilityが欠けており、パイプラインは事前に定められた特定のタスクしか実行できませんでした。CI/CDプラットフォームチームとして、チームが新機能を必要とする際にボトルネックとなってしまい、評価から実装までに数日から数週間かかることもありました。また、大規模なアーキテクチャに対して手動での介入が必要となり、本番環境でのインシデントにつながる可能性のある、包括的なアプリケーションデプロイメント機能も不足していました。さらに、Infrastructure as Codeで通常提供される状態管理機能については、SDKコールを使用して機能を構築する必要がありました。
私たちはパイプラインの長期的な近代化戦略を評価するため、一歩下がって考えることにしました。そして3つの主要な柱を確立しました。第一に、コンプライアンスロジックをデプロイメントロジックから切り離しました。これは、長年のパイプライン構築によってデプロイメントロジック内にコンプライアンスが密接に結合されていたためです。コンプライアンスロジックを文書化し、そのライフサイクルを作成し、中央コンプライアンスプラットフォームを確立する包括的な取り組みを行いました。第二に、AWS CloudFormation、AWS CDKなどのツールを使用して、状態管理が可能で組み合わせ可能なInfrastructure as Codeデプロイメントへとシフトしました。第三に、開発者が車輪の再発明をしないよう、ベストプラクティスに基づくアーキテクチャパターンを含む広範なCDK Constructライブラリを作成し、パターンカタログを構築しました。
高いレベルで見ると、CI/CDパイプラインは基本的な構造を維持しながらも、これらの変更から大きな利点を得ることができました。例えば、コンプライアンスのためのテンプレートスキャンに関して、中央集権化されたコンプライアンスプラットフォームにより、パイプラインの早い段階でCloudFormationテンプレートをスキャンできるようになりました。
本番環境で何かをデプロイしようとして、本番レベルで失敗するような状況を想像してみてください。私たちは同様のチェックをチェックアウトフェーズで実行できるようになり、開発者の時間を何時間も節約することができました。CloudFormationを使用していたため、宣言的な構文のスキャンがより簡単になりました。カスタムビルドのSDKコールを、Macが先ほど説明した優れた機能を提供する宣言的な構文に置き換えました。例えば、TagSetsやChainSetsを活用することで、デプロイメントの事前把握が可能になりました。
CloudFormationの特性を活用することができました。つまり、CloudFormationが提供する優れた機能の1つとして、CloudFormationを使ってインフラストラクチャをデプロイした後、同じインフラストラクチャを再デプロイする場合、デプロイメントの大部分をスキップするということです。インフラストラクチャに変更がない場合、あるいはCloudFormationの定義に変更がない場合、以前の定義と異なる部分のみを実行します。この機能により、40〜50%の改善が見込めることがわかりました。
先ほど説明したように、RTEコストの削減、フィードバックループの高速化、市場投入までの時間短縮、そして使いやすさと信頼性の向上が実現できました。前のスライドで触れ忘れた点が1つあります。ポリシーを一元化したことで、それらのポリシーをAPIを通じて提供し、そのAPIをプラグインを通じて公開しました。開発者は自分のローカルマシンで、VS Codeやその他の好みのツールでこれらのプラグインを採用することができました。CloudFormationテンプレートやCDKを作成する際に、コンプライアンスポリシーと同期が取れていないためデプロイできないという警告や失敗を示す波線が表示されるようになりました。これは開発者がGitHubにコードをチェックインする前に、自分のマシンで直接確認できる大きなメリットでした。
エンタープライズレベルでのAWS CDK活用戦略
もう1つの利点として、多くの改善機会がAWSによってもたらされたことが挙げられます。Macが言及した40%の改善は、私たちが投資をしなくても、基盤となるエンジンの改善によって最初から得られたものでした。現在、中央プラットフォームチームとして、何千人もの開発者がGitHubリポジトリでCloudFormationを書き始め、同じアーキテクチャをデプロイするというのは理想的ではありません。会社全体で大規模なアップグレードを行いたい場合、それらの開発者のメンテナンス、管理、アップグレードの展開、サポートを行うのに最適な方法とは言えないでしょう。
AWS CDKはこの問題を解決するために人気を集めました。CDKは、この例のように、開発者が4〜5行のコードでAPIによってバックアップされたFargateサービスをデプロイできるという、適切な抽象化レベルを提供します。これをCloudFormationで書こうとすると、おそらく830行以上になっていたでしょう。そのため、CDKコンストラクトライブラリを管理することで、アップグレードの展開、新しいコンストラクトの追加などが可能になりました。
オンラインではCDKとその利点、実装方法について多くの情報が見つかります。今日は、エンタープライズレベルでどのように実現したかについてお話ししたいと思います。CI/CDパイプラインとベストプラクティスの管理を担当する中央プラットフォームとして、中央のAWS CDKライブラリを構築しました。L2.5コンストラクト、L3コンストラクト、L4コンストラクトを、それぞれのユースケースに最適なものを構築しました。例えば、企業全体で最も一般的なユースケースであるAPIをデプロイしたい場合、それに対応するL4コンストラクトを構築しました。また、コンストラクトライブラリのパイプラインを構築し、複数の異なる言語でコンストラクトを公開できるようにしました。これらのコンストラクトをバイナリリポジトリに公開することの大きな利点は、開発者が自分のGitHubリポジトリに好みの言語でインポートできることで、より簡単でシームレスな体験を提供できることでした。CDKライブラリでもう1つ行ったことは、リグレッションスイートの構築です。公開するライブラリとコンストラクトが最初からコンプライアンスに準拠していることを確認したかったため、以前構築したコンプライアンスエンジンと同じものを通す、非常に包括的なリグレッションスイートを構築しました。
このアプローチにより、社内の開発者コミュニティが私たちのCDKライブラリを活用するようになりました。また、私たちにとって非常に重要だった3つ目の要素は、独自のStack Synthesizerを使用することでした。これは、私たちが構築しているCDKコンストラクトとCDKのデプロイメント戦略が、社内のコンプライアンスに準拠していることを確実にするためでした。私たちは、自社のユースケースにより適合した独自のIAMルールを使用しています。
私たちのチームによる革新的なアプローチの一つが、これらのリソースの可視化でした。AWS CDKは開発者に大きな柔軟性を提供し、デプロイしたいサービスとその方法を自由に選択できるようになりました。しかし、これは中央チームにとって、誰がどのようなリソースを使用しているのか把握できないという課題を生み出しました。私たちは、パイプラインとコンストラクトを計測し、そのデータをCI/CDパイプラインの一部として公開し、中央のデータベースとダッシュボードにストリーミングすることでこの問題を解決しました。これらのサンプルダッシュボードが示すように、その結果は驚くべきものでした。例えば、開発者はCloudWatch、CodeDeploy、Lambdaを組み合わせて使用している11のリポジトリを確認することができます。プラットフォームの中央チームとして、これは明らかに人気のあるパターンであることを示しており、そのコンストラクトをより重点的にメンテナンスし始めることができます。
コミュニティにとっての利点は、これらのダッシュボードがすべてリポジトリにハイパーリンクされていることです。開発者がリファレンス実装を必要とする場合、これらのダッシュボードをクリックしてコンストラクトの使用例のリポジトリにアクセスし、同様のベストプラクティスを参照することができます。これはこれらのライブラリの計測の効果的な活用でした。そして同様に重要な3つ目の側面は、実践コミュニティの構築でした。AWS CDKを企業で使用することは言うは易く行うは難しですが、企業全体で大規模に使用するにはスキルが必要です。私たちは活気のある開発者コミュニティの構築を強く推奨しています。私たちのCDKライブラリではInner Sourcingを確保しており、機能の開発を待つのではなく、開発者が中央プラットフォームのすべての使用に貢献できるようにしています。Pull Requestを送ってくれた開発者には報酬を与え、迅速に対応しています。
また、エンジニアが自身の実装を紹介し、プラクティスについて議論する実践コミュニティも確立しました。さらに、自社に特化したハンズオントレーニングを作成し、AWS STMとパートナーシップを組みました。オンラインのトレーニング教材は豊富にありますが、終日のハンズオンセッションに代わるものはありません。私たちは、AWS STMと協力して、CDKを正しく使用する方法や、一から作り直すことなく私たちのライブラリを活用する方法について議論する、特別なカタログとワークショップを構築しました。それでは、Ericにバトンタッチします。ありがとう、Ishu。Capital Oneのような大企業がどのようにソフトウェアを構築・提供しているのかを内部から見るのは、いつも非常に興味深いですね。最後に、ご参加いただいた皆様に感謝申し上げます。CloudFormationやCloud Development Kitなどの AWSサービスが、ガバナンスとセキュリティ、そしてインフラストラクチャの変更を提供するための戦略と強力なプロセスの構築にどのように役立つかについて、少しでも学んでいただけたことを願っています。セッションのアンケートへの回答をお忘れなく、私たちのパフォーマンスについてご意見をお聞かせください。私たち3人は可能な限りここに残り、また外でもご質問にお答えできると思います。ご参加ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion