Amazon Web Services ブログ
組織内での AWS CDK 利用拡大のためのベストプラクティス
企業はクラウド移行の加速を常に追求しています。Infrastrcture as Code (IaC) は、クラウドリソースを効率的に自動化および管理するうえで不可欠です。AWS Cloud Development Kit(AWS CDK) を使用すると、お気に入りのプログラミング言語でクラウドインフラストラクチャをコードとして定義し、AWS CloudFormation を使用してデプロイできます。この記事では、組織内での CDK の採用を加速するための戦略とベストプラクティスについて説明します。この記事での議論は、組織がパイロットプロジェクトを成功裏に完了した後に始まります。この記事を読むことで、パイロットプロジェクトから得た教訓をプラットフォームエンジニアリングを通じて組織全体に広げる方法を学ぶことができます。再利用可能なコンポーネントの構築を通じて複雑さを軽減し、開発者ツールを介した高速かつ安全なデプロイ、内部開発者ポータル(IDP) によるプロジェクトのスタートアップの加速などの方法を学びます。CDK コミュニティへの参加とそこからのメリットについても述べます。
はじめに、テクノロジーの新しいトレンドであるプラットフォームエンジニアリングについて簡単に説明します。
DevOps のプラクティスは、IT 部門がより頻繁に、より高品質のソフトウェアを顧客に提供するのに役立っています。
DevOps の最近の進化は、ワークロードチーム (業務部門) をサポートするサービス、ツールチェーン、ドキュメントを構築するためのプラットフォームエンジニアリングチームの導入です。
プラットフォームエンジニアリングチームの重要な責任の 1 つは、ソフトウェアデリバリープロセスの管理です。
Amazon では、プラットフォームエンジニアリングを活用してデプロイメントを加速させてきた長い歴史があります。
これにより、年間 1 億 5 千万回のデプロイを行いながら、143 ものコンプライアンス認定を取得できています。
プラットフォームエンジニアリングは、生産性を向上させ、アイデアと実装の間の摩擦を軽減し、セルフサービスポータルや開発者ツールを通じて安全でスケーラブルで再利用可能なリソースとコンポーネントのセットを介してワークロードの提供を加速することで、アジリティを向上させます。
プラットフォームエンジニアリングは、プラットフォームアーキテクチャ、データアーキテクチャ、プラットフォーム製品エンジニアリング、データエンジニアリング、プロビジョニングとオーケストレーション、モダンアプリ開発、CI/CDの 7 つの機能で構成されています。
プラットフォームエンジニアリングの詳細については、AWS Cloud Adoption Framework をご覧ください。
これらの機能を確立するには、複数のプラットフォームチームとワークロードチームが協力する必要があります。
オペレーティングモデルの観点から、ワークロードチームはプラットフォームエンジニアリングと次の 3 つの方法のいずれかで対話しています (詳細については、Building your Cloud Operating Model を参照してください)。
再利用可能なコンポーネントによる開発者の複雑さと認知負荷の軽減
では、プラットフォームチームはどのように CDK を利用して目標を達成できるのでしょうか。 プラットフォームエンジニアリングチームの一般的な目的の 1 つは、コンストラクトと呼ばれる再利用可能なパターンを公開および提供することです。 コンストラクトは、複数のチームとプロジェクトで共有できる再利用可能な拡張可能な一般的なコンポーネントを作成するメカニズムを提供します。
多くのお客様は、暗号化や特定の AWS Identity and Access Management ポリシーなどのセキュリティのベストプラクティスを適用するために、独自のコンストラクト実装を記述しています。
例えば、デフォルトの Amazon S3 バケットコンストラクトの代わりに、組織のセキュリティ要件を実装したMyCompanyBucketを作成するかもしれません。このバケット構成は、セキュリティおよびコンプライアンスチームによって検証されたコンポーネントを使用していることを確認するために、複数のチームによって実装および拡張できます。
データガバナンスに焦点を当てるお客様の場合、CDK コンストラクトを使用することで、バックアップとアーキテクチャが組織のレジリエンスポリシーを満たすことを保証し、目標復旧時間 (RTO) と目標復旧時点 (RPO) のベストプラクティスを自動的に取り入れられるようになります。
データライフサイクルポリシーを適用したいユーザーの場合、統一されたアクセス制御を作成したり、必要な KPI を出力したりすることができます。CDK コンストラクトでは、デフォルトで安全でセキュアな構成を作成するための手段を提供できます。
CDK コンストラクトを DataOps に適用することで、データ系列のメタデータが保持され、データクレンジングが行われるテンプレート化された ETL パイプラインのメリットを享受できます。
お客様は AWS リソース以外のリソースのコンストラクトも作成しています。チームは、サードパーティの開発者ツール、可観測性システム、テストツールなどのコンストラクトを作成できます。このようにして、ワークロードチームは、1つのコードベースで AWS リソースと非 AWS リソースをコード化できます。独自のコンストラクトを書く際には、標準化を考慮しつつ、CDK パッケージのエコシステムの成長を活用する自由度と柔軟性のバランスが必要です。このバランスの例として、AWS Solutions Constructs があります。これらは通常、標準のコンストラクトに基づいて作成されます。標準のコンストラクトを拡張せずに作成したコンストラクトは、ユーザーがより大きな CDK エコシステムと統合するのが難しくなります。
Construct Hub は、CDK 向けに定義されたクラウドアプリケーションの設計パターンとリファレンスアーキテクチャを発見および共有するための主要な場です。これらは AWS コミュニティによって構築および公開されています。AWS はパブリックな Construct Hub を提供していますが、企業は独自の AWS アカウント内にプライベートな Construct Hub を維持管理できます (construct-hub、GitHub リポジトリ、または CDK ワークショップ で詳細を確認できます)。いずれの場合でも、主な目的は一貫しています。その目的とは、異なるワークロードチームが容易に利用できる共有ライブラリを提供することです。このアプローチにより、一貫性、再利用性が向上し、最終的にコスト削減と開発期間の短縮につながります。
このアプローチを活用する際にしばしばつまずく落とし穴の 1 つは、プラットフォームエンジニアリングチームが最新のテクノロジーを活用するための再利用可能なコンポーネントの構築が追いつかないことです。ここでパイロットプロジェクトからの教訓を活かすことが役立ちます。パイロットプロジェクトチームは、プラットフォームエンジニアリングチームと協力して、セキュリティのベストプラクティスを研究および実装します。一部のお客様は、プラットフォームエンジニアリングチームを新しいコンストラクトの作成者だけでなく、承認者としても機能させています。このモデルでは、パイロットプロジェクトチームは新しいテクノロジーのコンストラクトの構築にも取り組みます。プラットフォームエンジニアが新しいコンストラクトをレビューして承認します。プラットフォームエンジニアは、パイロットプロジェクトチームが保存時の暗号化、転送時の暗号化、最小特権などの必要な基準を満たしていることを確認します。承認されると、パイロットプロジェクトチームは新しいコンストラクトを Construct Hub に公開できます。このようにして、プラットフォームエンジニアリングは実験と革新を促進します。さらに、プラットフォームエンジニアリングチームは、コンストラクトの唯一の作成者ではなく、コンストラクトの作成についてインナーソース (訳註: 企業内でのソフトウェア開発にオープンソースソフトウェア開発の手法を取り入れること。) を推進できます。
DevSecOps のベストプラクティスを使用したアプリケーションのデプロイ
アプリケーション開発者は、ビジネスの課題に直接対処するコードの作成に専門知識が集中すると、最も生産的になります。
組織の基準に沿ってアプリケーションをデプロイおよび運用する複雑なタスクは、特に新しいメンバーにとっては圧倒されるようなタスクになるかもしれません。
この複雑さはしばしばボトルネックとなり、実験的な開発プロセスを遅らせ、新しいアプリケーションの取り組みによる価値の提供を遅らせることがあります。
この課題への解決策は、デプロイパイプラインと運用モデルの自動化にあります。
徹底的にテストされた CDK コンポーネントをチーム間で共有し、堅牢な CI/CD (継続的インテグレーション/継続的デプロイ) プロセスを通じて検証することで、開発者への負担が大幅に軽減されます。
開発者はもはや組織のデプロイ戦略の複雑さに立ち入る必要がなくなり、独創的で革新的なコードの作成に集中できるようになります。
このアプローチは、開発プロセスを効率化するだけでなく、開発と運用の間のギャップを埋め、より緊密なチームとより迅速で効率的なリリースを実現します。
高品質なソフトウェアデリバリーの鍵の 1 つは、適切な継続的インテグレーションと継続的デリバリー (CI/CD)プロセスを整備することです。
実践的な例については、CDK Pipelines: AWS CDK Continuous delivery for AWS CDK applications を参照できます。
この高レベルなコンストラクトは AWS CodePipeline によって動作し、cdk deploy コマンドによるテストデプロイを超えて、異なるリージョンやアカウントの複数の環境への本番デプロイのための自動パイプラインを構築するのに役立ちます。
AWS CDK アプリケーションのソースコードを AWS CodeCommit、GitHub、GitLab、BitBucket、または Amazon CodeCatalyst のソースリポジトリにコミットするたびに、AWS CDK Pipelines が自動的にアプリケーションの新しいバージョンをビルド、テスト、デプロイします。 このパイプラインは、スタック内のリソースが変更されたり、デプロイされる環境が変更されたりすると、パイプラインが自動的に再設定されます。 GitHub Actions ユーザーの場合は、CDK Pipelines for GitHub Workflows をご覧ください。
複数のチームがこれらのパイプラインを拡張し、独自のステージを追加することで、デプロイされたコードが組織の品質、セキュリティ、リスク、コンプライアンス、クラウド財務管理の基準を満たすことを保証します。
パイプライン内にどのような自動化を組み込むかのベストプラクティスについては、AWS Deployment Pipeline Reference Architecture を参照してください。
完全に機能するパイプラインを作成することで、プラットフォームエンジニアリングチームは、開発チームへの認知的負荷を軽減し、開発者体験を向上させることができます。
この戦略には 2 つの実装があります: クイックスタートパイプラインとゴールデンパイプラインです。
クイックスタートパイプラインでは、パイプラインは Construct Hub のコンストラクトとして作成され、再利用可能なコンポーネントに関する上記の議論と同様に扱われます。 パイプラインはシンプルなインターフェースと認知負荷の軽減を提供しますが、ワークロードチームはパイプラインを自身で制御し、自由に変更することができます。 その結果、セキュリティやコンプライアンス検証ツールのような品質管理の仕組みは、ワークロード チームによって無効にされ、パイプライン内のコントロールは保証できなくなります。 これは、コンプライアンスと監査のコストを削減したい組織にとっては望ましくありません。 コンストラクトのバージョン数が増えるにつれて、プラットフォームエンジニアリングチームは、ワークロードチームがどのバージョンを使用しているかを管理することが困難になる可能性があります。
ゴールデンパイプラインでは、パイプラインはコンストラクトとして作成されますが、中央集権化されたチームによって管理されます。
ワークロードチームはこれらのパイプラインを制御したり変更したりすることができません。したがって、セキュリティやコンプライアンスのツールのような品質管理の仕組みは無効化できません。
これらのコントロールは、監査人などのセキュリティ、リスク、コンプライアンスのステークホルダーに対して検証可能なものになります。
一方で、ワークロードチームからのアクセス許可を削除することにはコストが伴います。
ゴールデンパイプラインでは、プラットフォームエンジニアリングチームはしばしば、ワークロードチームのデプロイのトラブルシューティングに時間の大半を費やすことになります。
プラットフォームエンジニアリングチームはトラブルシューティングに時間を費やすことが増え、セキュリティと品質の基準を上げる新しいツールの導入、環境設定と組織の一貫性の改善、監査証跡と実施体制の強化などに時間を割くことがほとんどできなくなります。
2 つのメカニズムがこれらの戦略を補完します。
昔ながらの変更管理委員会 (CCB) は、証拠の収集と実施が困難な状況で検証可能性を提供します。
CCB は、パイプラインとアカウント作成プロセスに IT サービスマネジメント (ITSM) の承認とフリート管理プロセスを統合する CDK コンストラクトの恩恵を受けることができます。
一方で、ソフトウェアアーティファクトのためのサプライチェーンレベル (Supply chain Levels for Software Artifacts, SLSA) に関する新しい話題もあります。
これらのアーティファクトはデジタル証明として使用できます。
Kubernetes では、Tekton chains のようなツールでこのパターンが見られます。OCI イメージに関連付けられた証明書や、証明書の存在を保証するために Kyverno が使用されています (詳細はProtect the pipe! Secure CI/CD pipelines with a policy-based approach using Tekton and Kyverno を参照)。
CDK によるマルチアカウントとクロスリージョンデプロイ
DevOps のベストプラクティスは、本番へのデプロイ前に複数のステージでデプロイとテストを行うことを推奨しています。
さらに、AWS はステージごとに専用のアカウントの利用を推奨しています。これにより、リソースの分離とアクセス制御が容易になります。
このマルチアカウント戦略により、組織は AWS リソースを最大限に活用でき、詳細な制御が可能になります(Recommended OUs and accounts を参照)。
多くの場合、ワークロードごとに指定された AWS アカウントがあり、すべての CI/CD パイプラインがそこに存在します。
開発、ステージング、本番などの段階に対応する他の AWS アカウントにデプロイするために、これらのパイプラインによって実行されます。
AWS 上の CI/CD パイプラインを参照したクロスアカウント戦略の詳細については、Building a Secure Cross-Account Continuous Delivery Pipeline をご覧ください。
自動化されたガバナンス
多くの企業は、CDK を利用してセキュリティ制御とポリシーを適用したり、デプロイパイプラインの一部としてコード解析ツールを使ってデプロイ前にセキュリティ上の問題を未然に防いだりしています。業界標準のツールである cdk-nag を利用することで、多くのチームが利用可能なルールセットを使ってアプリケーションのベストプラクティスをチェックしています。また、企業ではデプロイしたリソースを管理・整理するためのタグ付けの要件など、追加の要件を適用する独自の Aspect を作成している例も見受けられます。
お客様は、CDK によって合成された CloudFormation テンプレート を作成し、CloudFormation Guard を使用して、Policy as Code のドメイン固有言語 (DSL) ルールを使って出力を検証するための追加のチェックポイントを作成できます。プラットフォームエンジニアリングチームは、ルールを作成できます。ワークロードチームは、それらのルールを利用し、パイプライン内で CloudFormation Guard を実行できます。アプリケーションに CloudFormation Guard チェックを簡単に追加できる公式コンストラクトがあります。
AWS CDK では、インフラストラクチャはコードそのものです。
したがって、品質を確保し、開発者体験を向上させるために、すでに使用している標準的なツールを CDK でも使用する必要があります。
組織にコード品質プログラムがある場合は、CDK アプリケーションを Web アプリケーションやマイクロサービスと同様に扱う必要があります。
同様に、Amazon CodeGuru Security と Amazon CodeWhisperer を使用することで、開発者は他アプリケーションと同様に、CDK コードのセキュリティと品質の改善に役立つ実行可能な推奨事項を得ることができます。
Aspects、cdk-nag、コード品質ツールを使用することで、組織はデプロイ前にセキュリティの問題を防ぐことができますが、デプロイ後に機能するコントロールを作成することも重要です。
AWS CloudFormation Hooks を使用することで、お客様は CloudFormation スタックや CDK アプリケーションの作成、更新、削除の前にリソースを検査することができます。
CloudFormation Hooks を使用することで、プラットフォームエンジニアリングチームは、基準に沿っていないリソースのプロビジョニングに対して警告を出したり、防止することができます。
これらのフックは CDK で作成できます (詳細はこちらの Build and Deploy CloudFormation Hooks using A CI/CD Pipelineを参照)。
最後に、CDK を介して AWS Config のコンプライアンスチェックのルールセットをデプロイできます。 これらのルールのコレクションにより、組織は大規模にセキュリティ基準を要求できます。 組織がカスタムルールを作成したい場合、チームは AWS Config ルール のための高レベルのコンストラクトを使用してリアクティブコントロールを作成できます。 これらのパターンの多くは CDK よりも前から存在していましたが、CDK は企業内またはコミュニティ全体で共有されている再利用可能なコンポーネントを活用することにより、クラウドアプリケーションとコントロールの構築とデプロイを加速します。
アプリケーションの運用と可観測性
オープンソースコミュニティは、CDK アプリケーションの基本的なモニタリング機能を拡張する高レベルのコンストラクトライブラリを提供しています。cdk-monitoring-constructs プロジェクトを使用すると、CDK アプリのモニタリングが簡単になります。同様に、CDKWakeful はそれを一歩進め、多くのサービスを追加し、AWS Systems Manager Incident Manager、AWS Chatbot、Amazon Simple Notification Service による通知を自動的に受信するための、簡単に構成できるインターフェイスを提供します。オープンソースコミュニティからの既製ソリューションを活用することで、ビジネスロジックを中心としたカスタムメトリクスとしきい値に集中することができます。プラットフォームエンジニアリングチームは、オープンソースプロジェクトを変更および拡張して、ワークロードチームが運用を簡素化し、ヘルスステータスを集中システムに送信できるように支援できます。
内部開発者プラットフォームによる新規プロジェクトのスタートアップの加速
内部開発者プラットフォーム (Internal Developer Platform, IDP) は、プラットフォームエンジニアリングチームによって構築され、ゴールデンパスを構築し、開発者のセルフサービスを可能にします。これらのゴールデンパスは、ソースコントロールリポジトリとリポジトリ内に格納されたファイルを作成する一連のテンプレートとして表現されます。IDP がこれらのテンプレートを使用してソースコードリポジトリを作成すると、作成されたリポジトリには次のものが含まれる必要があります:
- チュートリアル (通常は
README.mdに記載) - リファレンスドキュメント
- スケルトンソースコード
- 依存関係管理
- CI/CD パイプラインテンプレート
- IaC テンプレート
- 可観測性の設定
CDK を使用すると、CI/CD パイプライン、IaC テンプレート、可観測性設定はすべて、単一の CDK アプリケーションの一部として構築できます。
プラットフォームエンジニアリングチームは、Backstage、Humanitec、Port などのツールを使用して、ゴールデンパスを構築し公開します。 ゴールデンパスの構築には、基盤となるプロジェクト構造について 2 つの一般的なアプローチがあります。 一部の組織では、IaC コードリポジトリをアプリケーションコードから分離するアプローチを選択します。 他の組織では、すべてを 1 つのリポジトリに含めることを選択します。 ゴールデンパスと再利用可能なコンポーネントのどちらにどの程度配置するかについて、それぞれにトレードオフがあります。 両方のアプローチで、プラットフォームエンジニアリングチームは、CDKを活用することでコードの重複を回避できます。 組織が選択するアプローチによって、再利用可能なコンポーネントの整理方法が決まります。 以下では、両方のアプローチと再利用可能なコンストラクトへの影響について説明します。
アプローチ 1: 全てを一つのリポジトリに含める
このアプローチでは、インフラストラクチャ、アプリケーション、設定、デプロイメントのすべてのコードが 1 つのリポジトリに含まれます。このアプローチにより、開発者はコラボレーションし、機能を構築し、迅速にイノベーションを起こすことができるため、推奨されるアプローチです。 詳細については、ベストプラクティスのドキュメントを参照してください。 例については、AWS Deployment Reference Architecture for Applications をご覧ください。
このアプローチは、バリューストリームに沿った (Stream-aligned な) チームで最も効果的です。 バリューストリームに沿ったチームは、同じチーム内に開発と運用の能力を備えています。 これらのチームは、技術的な機能ではなく、顧客の課題を解決することを目的として組織化されています。 プロジェクト内では、チームはアプリケーション階層 (API、データベースなど) やビジネス機能 (注文管理、製品カタログ、配送サービスなど) などの論理単位で組織化できます。 バリューストリームに沿った組織では、大規模で高度に標準化された再利用可能なコンポーネントがより適しています。 このタイプのコンストラクトの極端な例は、マイクロサービス全体のコードを含む単一のコンストラクトです。これらのチームでは、認知負荷は顧客の課題に集中しているため、アプリケーションの開発の複雑さを減らすことが成功の鍵となります。
アプローチ 2: アプリケーションコードのパイプラインを分離する
この代替アプローチでは、アプリケーションコードとインフラストラクチャを別リポジトリに格納し、パイプラインを分離します。
パイプラインを分離すると、機能開発に焦点を当てるワークロード担当者と、それらのアプリケーションが実行されるインフラストラクチャの構築に注力するインフラエンジニアの間で、サイロ化やコラボレーションの減少につながることがしばしばあります。
このアプローチは、「マトリックス型」のチームで最もうまく機能します。 マトリックス型組織は、技術的な能力 (開発、運用、セキュリティ、ビジネスなど) を中心に構築されています。
こうした場合、高度に標準化されたコンストラクトよりも、よりモジュール型のコンストラクトの方がうまく機能します。 各組織のエキスパートは、CDK コンストラクトをメカニズムとして使用して、組織全体に自らの専門知識を共有できます。
この種のコンストラクトの例としては、集中型の監視にプラグインするためのフックを備えた、監視、アラート、セキュリティのためのコンストラクトなどがあります。
プラットフォームエンジニアリングによるコミュニティ・オブ・プラクティスの構築
大規模な組織内で新しいテクノロジーをスケールするには、コラボレーションを促進し、ベストプラクティスを確立し、エコシステムの変化に対応したコミュニティの構築と拡大が必要です。組織内にこれらのコミュニティ・オブ・プラクティスを作成できるようにするために、AWS は CDK ユーザーを教育するコンテンツの作成を中心とした複数のパブリックコミュニティをサポートしています。組織のコミュニティ・オブ・プラクティスのメンバーは、これらのパブリックな AWS サポートコミュニティを通じて、世界中の他の CDK 開発チームとつながることができます。
コミュニティ・オブ・プラクティス
コミュニティ・オブ・プラクティス (CoP) は、非公式な交流や知識共有を通じて、特定のドメインで学習、協働、専門性を高めるために集まる、共通の関心事を持つ人々のグループです。
組織内で CDK を中心としたコミュニティ・オブ・プラクティスを確立することは、メンタリング、問題解決、再利用可能なアセットの実現につながることが証明されています。
はじめに、CDK を使用した再利用可能なコンストラクトと開発者ツールの作成者であるプラットフォームエンジニアリングチームが、コミュニティ・オブ・プラクティスの初期のコンテンツ作成者となります。
これにより、CDK の作成者が CoP を通じて自分の成果を公開するというフィードバックループが確立されます。
ユーザーは作成者に対して質問したり、直接的な指導をすることができます。
CoP がそれを確立した初期グループによって持続可能な形で拡大したら、CoP 内でハッカソンや Game Day を開始することができます。これによりイノベーションがもたらされ、組織全体の課題が解決されます。
完全に成熟したコミュニティ・オブ・プラクティスは、Wiki や知識のデータベースを所有しています。
タウンホール、オフィスアワー、ニュースレター、チャットチャネルなどのメカニズムを使用して、コミュニティを最新の状態に保ちます。
このようにして、CDK の専門知識が組織全体に広まっていきます。
AWS では、この専門知識の拡散により、プラットフォームエンジニアリング以外のチームも再利用可能なコンストラクトの作成者となっています。
再利用可能なコンストラクトを作成できる人を広げることで、自社のイノベーションを加速できます。
コミュニティ
CDKをサポートするコミュニティは成長しつつあり、コンテンツ、コード、サンプル、ミートアップなど、さまざまなプラットフォームが利用できます。
CDK は現在 AWS によってメンテナンスされており、AWS CDK GitHub ページ ではコミュニティのサポートのもと、プラットフォームへの貢献、イシューの提起、バックログの確認、アクティブなコミュニティメンバーとのディスカッションへの参加ができます。
CDK.dev は、CDK エコシステムを取り巻くコミュニティ主導のハブです。このサイトでは、最新のブログ、ビデオ、教育コンテンツをまとめています。また、Slack プラットフォームへの参加リンクも提供しています。
CDK Patterns は、開発者が使用できる CDK で構築された AWS サーバーレスアーキテクチャパターンの オープンソースコレクション を提供しています。 これらのパターンは、AWS コミュニティビルダー / AWS ヒーロー を通じて提供されています。
最後に、AWS re:Post は、コミュニティが解決するための質問応答ポータルを提供します。
AWS コミュニティビルダー プログラムは、知識を共有しテクニカルコミュニティとつながることに情熱を持つ人々に対して、テクニカルリソース、教育、ネットワーキングの機会を提供しています。
コミュニティ・オブ・プラクティスは、cdk.dev のような AWS パブリックコミュニティを活用して、知識のギャップを埋めることができます。 タウンホールミーティングは、AWS Heroes やコミュニティビルダー、GitHub や re:Post への頻繁なコントリビューター、CDK Day のスピーカーなどから恩恵を受けることができます。 ニュースレターは、すべてのAWS チャネルからの最新ニュースを集約および要約できます。 コミュニティ・オブ・プラクティスが CDK の専門知識を確立すると、このコラボレーションは双方向にもなります。 たとえば、組織のコミュニティのエキスパートは、AWS Heroes になることができます。 成功事例は、CDK Day、ゲストブログ投稿を通じて共有でき、AWS Summit、AWS re:Invent、AWS re:Inforce、AWS re:Mars などの主要イベントのいずれかで講演する可能性さえあります。
おわりに
このブログ全体を通して述べてきたように、CDK ではインフラストラクチャはコードそのものです。 これによりインフラストラクチャ管理のパラダイムシフトが可能になりました。 今日、Liberty Mutual、Scenario、Checkmarx、Registers of Scotlandなど、多くのお客様が CDK を使って成熟したエコシステムを構築しています。アクティブなオープンソースコミュニティ、長期サポートのための AWS 開発チーム、知識共有のための複数のプラットフォームがあるため、開発者は迅速に学習、構築、革新することができます。 成功したパイロットプロジェクトにより、CDK を採用した多くの組織が、よりアジャイルに、より速く革新できるようになりました。 これは Amazon でもまさに起こったことで、CDK は新しいサービス構築の第一選択肢です。
組織はしばしば、プラットフォームエンジニアリングを通じてスケールと複雑さの削減を実現します。
これらのチームは、ベストプラクティスを適用することで高レベルなコンストラクトを構築し、CI/CD パイプラインを提供してデプロイメントを加速します。
インフラストラクチャのコードに対するユニットテストや、各段階 (作成から運用まで) の構築者へのガイダンスを提供する堅牢なセキュリティ管理を用いることで、デプロイメントの安全性が高まります。
最後に、コミュニティを構築することで、組織は成熟したエコシステムを構築できるようになります。
内部コミュニティとオープンソースコミュニティの両方を通じて、開発者はつながり、新たな発見や成長が実現されます。
この記事は David Hassler, Amritha Shetty, Chris Scudder, Kumar Karra による Best practices for scaling AWS CDK adoption within your organization を翻訳したものです。 翻訳は Solutions Architect の山崎宏紀が担当しました。