記事公開日
Kiro Powersとは？ インストールしてAWS環境を構築してみた②
この記事のポイント
本記事では、AIアシスタント「Kiro Powers」の実装フェーズにおけるIaC生成能力を検証します。「安全・安価・運用が楽」という抽象的なプロンプトから、AWS Well-Architected Frameworkに準拠した高度な構成案が即座に生成される過程を、実際のAWS CDKコードと共に解説。エンジニアの設計工数を大幅に削減しつつ、セキュアなインフラを構築する実戦的なTipsを紹介します。
- AWSベストプラクティスに基づいた自動設計：
ABAC（属性ベースアクセス制御）によるIAMポリシー制御や、外部通信を遮断した「PRIVATE_ISOLATED」サブネット構成など、エンタープライズレベルのセキュリティ設定を自動で出力します。 - 3つのエンドポイント活用によるコスト最適化：
高価なNAT Gatewayを排除し、SSM / EC2 Messages / SSM Messagesの3つのVPCエンドポイントを介した閉域通信を採用。セキュリティを高めつつ、月間の固定費（インフラ維持費）の大幅な削減を両立させています。 - 運用証跡の自動可視化：
Session Managerの操作ログをCloudWatch Logsへ自動転送する定義など、筆者が独自に検証した「運用の手間を省きつつ、万全な証跡管理を実現する」実践的な環境構築手法を明示しています。
はじめに
こんにちは。DXソリューション営業本部の岡田です。
前回のブログで「Kiro Powersを導入した場合と、していない場合でSpec機能を使用したらどのように要件定義／設計は変わるのか」を検証しました。
今回は実装フェーズに入り、Powersを使用することで、どのようなIaCコードを生成してくれるか検証してみましょう。
こちらからは「AWSのプライベートサブネットにあるEC2に、安全にログインできるようにして。なるべく安く運用が楽な方法がいい。」という曖昧な指示しか与えない場合でも、AWS Well-Architected Frameworkに沿ったIaCを書いてくれるのでしょうか。
実際に動作を確認してみましょう。
検証
前回同様、Powersの「Build AWS infrastructure with CDK and CloudFormation」がインストールされていることを確認します。
こちらは最新のドキュメント、ベストプラクティス、コードサンプルを活用し、CDKやCloudFormation で AWS Well-Architected Framework に準拠した AWS インフラストラクチャを構築します。
前回は設計ドキュメントの完成まで完了したので、次のステージの実装フェーズに進むよう指示を出し、作成されたCDKコードを見てみます。
① セキュリティ：ABACによるアクセス制御
まず、セキュリティの観点に注目します。
IAMポリシーを「操作者の属性」と「インスタンスのタグ」が一致する場合のみ許可する設定になっています。
ユーザーがログインしようとするとき、IAMポリシーが「操作する人の権限」と「インスタンスのタグ」が一致するかをチェックします。
そのため、「開発環境用の権限を持つ人が、誤って本番環境のインスタンスを操作する」といった事故を防いでくれます。
sid: 'AllowStartSession',
effect: iam.Effect.ALLOW,
actions: ['ssm:StartSession'],
resources: [ `arn:aws:ec2:${this.region}:${this.account}:instance/*`
],
conditions: {
StringEquals: {
'ssm:resourceTag/Environment': environment
}
}
})
② 信頼性：VPCエンドポイントによるプライベート通信
次に信頼性です。
VPCエンドポイント（InterfaceVpcEndpoint）を作成することで、VPC内のインスタンスがインターネットゲートウェイを通らずに、内部のネットワークだけでAWSサービスと通信できるようになります。
データが外部に出ないためセキュリティが向上し、インターネット経由の通信障害の影響を受けにくくなります。
※Session Managerの利用には、SSM / EC2 Messages / SSM Messages の3つのエンドポイントが必要です。ここでは例としてSSMエンドポイントの例を記載します。
vpc: this.vpc,
service: ec2.InterfaceVpcEndpointAwsService.SSM,
subnets: {
subnets: this.privateSubnets
},// ※内部的にIsolated Subnetを参照
securityGroups: [this.vpcEndpointSecurityGroup],
privateDnsEnabled: true,
policyDocument: vpcEndpointPolicyDocument
});
③ 優れた運用効率：全操作のログ記録
運用効率についてはどうでしょうか。
Session Managerの設定（下記CfnDocument）で、セッション内容をCloudWatch Logsへ転送するように定義しています。
誰が、いつ、何を変更したという作業ログが保存されます。
万が一の障害や不具合などが発生した場合でも、ログを遡るだけで原因が特定できるため、可視化が可能になり、運用効率があがります。
documentType: 'Session',
documentFormat: 'JSON',
name: `${this.stackName}-SessionManagerRunShell`,
content: {
schemaVersion: '1.0',
description: 'Document to hold regional settings for Session Manager',
sessionType: 'Standard_Stream',
inputs: {
cloudWatchLogGroupName: sessionManagerLogGroup.logGroupName,
cloudWatchEncryptionEnabled: true,
cloudWatchStreamingEnabled: true,
kmsKeyId: isProduction && this.kmsKey ? this.kmsKey.keyId : '',
// ... (以下略)
}
}
});
④ コスト最適化：NAT Gatewayの排除
最後にコスト最適化についてです。
PRIVATE_ISOLATED サブネットという、外部への通信が一切不要な、秘匿性の高いワークロードに適した構成です。
維持費(固定費)が高価なNAT Gatewayを設置せず、比較的安価なVPCエンドポイントで代用することで、月間のインフラ維持費を大幅に削減しています。
maxAzs: enableMultiAz ? 2 : 1,
cidr: '10.0.0.0/16',
subnetConfiguration: [
{
cidrMask: 24,
name: 'Private',
subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
}
],
enableDnsHostnames: true,
enableDnsSupport: true
});
まとめ
今回の検証を通じて、Powersの有用性が確認できました。抽象的な指示からでも、目視の範囲ではAWS Well-Architected Frameworkに沿ったベストプラクティスを反映したIaCコードを即座に生成できることがわかりました。
先述した通り、こちらからは「AWSのプライベートサブネットにあるEC2に、安全にログインできるようにして。なるべく安く運用が楽な方法がいい。」という抽象的な指示しか出していません。
インフラ設計における検討、作成などの時間を大幅に短縮できるツールとして可能性を感じました。
次回の構築してみた③では、生成されたコードをデプロイして検証したいと思います。生成されたコードを使って実際に環境を構築できるか、確認していきます！
もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください。 複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。 また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞
※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
