Amazon Q DeveloperでIaCを試してみよう
投稿日: 2025/08/16
はじめに
こんにちは、高橋です。
前回はAmazon Q Developerで実際にプログラムを書く、読む、変更する、を実施しました。今回は実際にAWSとプログラムの間で切っても切れない関係のIaC(Infrastructure as Code)をAmazon Q Developerを試してみたいと思います。
1.Amazon Q DeveloperとIaC
Amazon Q DeveloperはIaCをサポートしており、以下の様な手法、言語をサポートしています(2025/8時点)。
手法・ツール | 対応言語 | 特徴 |
---|---|---|
AWS CloudFormation | YAML / JSON | AWSネイティブ機能で3つの中では最もシンプル。 ただし構成が固定化される。 |
AWS CDK (Cloud Development Kit) |
TypeScript / Python / Java / C# / Go | プログラミング言語で記載ができ開発者向け。 また動的にパラメータを設定できるため、再利用性が高い。 |
Terraform | HCL | HashiCorp社が開発したマルチクラウド対応IaCツール。 |
今回はAWS CloudFormation テンプレートをYAMLで作成させてみたいと思います。
2.CloudFormationテンプレートの作成
今回は下記の様なよくある冗長化されたWebサーバのシステム用のCloudFormationテンプレートを作成してみたいと思います。

Amazon Q Developerには下記のプロンプトを入力してみます。
下記の構成のCloudFormationテンプレートを作成してください。
### ネットワーク
- 東京リージョンにVPCを作成
- 2つのアベイラビリティゾーンにパブリックサブネットとプライベートサブネットを配置
- それぞれのパブリックサブネットにNATゲートウェイを作成
### コンピュート
- 各プライベートサブネットにEC2を作成
- 役割はWebサーバ
- ALBでWebサーバに負荷分散
- OSはAmazon Linux2023最新版
- ストレージは10GB
これにより下記の様なCloudFormationテンプレートが作成されました。
AWSTemplateFormatVersion: '2010-09-09'
Description: 'High Availability Web Server Infrastructure in Tokyo Region'
Parameters:
InstanceType:
Type: String
Default: t3.micro
Description: EC2 instance type
Resources:
# VPC
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
EnableDnsSupport: true
Tags:
- Key: Name
Value: WebServer-VPC
# Internet Gateway
InternetGateway:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: WebServer-IGW
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref VPC
InternetGatewayId: !Ref InternetGateway
# Public Subnets
PublicSubnet1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.1.0/24
AvailabilityZone: ap-northeast-1a
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: Public-Subnet-1a
PublicSubnet2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.2.0/24
AvailabilityZone: ap-northeast-1c
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: Public-Subnet-1c
# Private Subnets
PrivateSubnet1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.11.0/24
AvailabilityZone: ap-northeast-1a
Tags:
- Key: Name
Value: Private-Subnet-1a
PrivateSubnet2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.12.0/24
AvailabilityZone: ap-northeast-1c
Tags:
- Key: Name
Value: Private-Subnet-1c
# Elastic IPs for NAT Gateways
NATGateway1EIP:
Type: AWS::EC2::EIP
DependsOn: AttachGateway
Properties:
Domain: vpc
NATGateway2EIP:
Type: AWS::EC2::EIP
DependsOn: AttachGateway
Properties:
Domain: vpc
# NAT Gateways
NATGateway1:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt NATGateway1EIP.AllocationId
SubnetId: !Ref PublicSubnet1
Tags:
- Key: Name
Value: NAT-Gateway-1a
NATGateway2:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt NATGateway2EIP.AllocationId
SubnetId: !Ref PublicSubnet2
Tags:
- Key: Name
Value: NAT-Gateway-1c
# Route Tables
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
Tags:
- Key: Name
Value: Public-Route-Table
PrivateRouteTable1:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
Tags:
- Key: Name
Value: Private-Route-Table-1a
PrivateRouteTable2:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
Tags:
- Key: Name
Value: Private-Route-Table-1c
# Routes
PublicRoute:
Type: AWS::EC2::Route
DependsOn: AttachGateway
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
PrivateRoute1:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref PrivateRouteTable1
DestinationCidrBlock: 0.0.0.0/0
NatGatewayId: !Ref NATGateway1
PrivateRoute2:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref PrivateRouteTable2
DestinationCidrBlock: 0.0.0.0/0
NatGatewayId: !Ref NATGateway2
# Subnet Route Table Associations
PublicSubnetRouteTableAssociation1:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet1
RouteTableId: !Ref PublicRouteTable
PublicSubnetRouteTableAssociation2:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet2
RouteTableId: !Ref PublicRouteTable
PrivateSubnetRouteTableAssociation1:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PrivateSubnet1
RouteTableId: !Ref PrivateRouteTable1
PrivateSubnetRouteTableAssociation2:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PrivateSubnet2
RouteTableId: !Ref PrivateRouteTable2
# Security Groups
ALBSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group for Application Load Balancer
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
Tags:
- Key: Name
Value: ALB-SecurityGroup
WebServerSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group for Web Servers
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
SourceSecurityGroupId: !Ref ALBSecurityGroup
Tags:
- Key: Name
Value: WebServer-SecurityGroup
# Application Load Balancer
ApplicationLoadBalancer:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Properties:
Name: WebServer-ALB
Scheme: internet-facing
Type: application
Subnets:
- !Ref PublicSubnet1
- !Ref PublicSubnet2
SecurityGroups:
- !Ref ALBSecurityGroup
# Target Group
TargetGroup:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
Properties:
Name: WebServer-TG
Port: 80
Protocol: HTTP
VpcId: !Ref VPC
HealthCheckPath: /
HealthCheckProtocol: HTTP
HealthCheckIntervalSeconds: 30
HealthyThresholdCount: 2
UnhealthyThresholdCount: 3
Targets:
- Id: !Ref WebServer1
Port: 80
- Id: !Ref WebServer2
Port: 80
# Listener
Listener:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
DefaultActions:
- Type: forward
TargetGroupArn: !Ref TargetGroup
LoadBalancerArn: !Ref ApplicationLoadBalancer
Port: 80
Protocol: HTTP
# EC2 Instances
WebServer1:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0d52744d6551d851e # Amazon Linux 2023 latest in ap-northeast-1
InstanceType: !Ref InstanceType
SubnetId: !Ref PrivateSubnet1
SecurityGroupIds:
- !Ref WebServerSecurityGroup
BlockDeviceMappings:
- DeviceName: /dev/xvda
Ebs:
VolumeSize: 10
VolumeType: gp3
UserData:
Fn::Base64: !Sub |
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Web Server 1 - AZ: ap-northeast-1a</h1>" > /var/www/html/index.html
Tags:
- Key: Name
Value: WebServer-1a
WebServer2:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0d52744d6551d851e # Amazon Linux 2023 latest in ap-northeast-1
InstanceType: !Ref InstanceType
SubnetId: !Ref PrivateSubnet2
SecurityGroupIds:
- !Ref WebServerSecurityGroup
BlockDeviceMappings:
- DeviceName: /dev/xvda
Ebs:
VolumeSize: 10
VolumeType: gp3
UserData:
Fn::Base64: !Sub |
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Web Server 2 - AZ: ap-northeast-1c</h1>" > /var/www/html/index.html
Tags:
- Key: Name
Value: WebServer-1c
Outputs:
LoadBalancerDNS:
Description: DNS name of the Application Load Balancer
Value: !GetAtt ApplicationLoadBalancer.DNSName
Export:
Name: !Sub "${AWS::StackName}-ALB-DNS"
VPCId:
Description: VPC ID
Value: !Ref VPC
Export:
Name: !Sub "${AWS::StackName}-VPC-ID"
システム全体が作成されるため、出力はかなり長くなりましたが、指示通り、前半のネットワーク作成部分ではVPCが作成され(# VPC)、リージョン内の2つのAZにパブリックサブネット(# Public Subnets)とプライベートサブネット(# Private Subnets)が作成され、各パブリックサブネット内にはNATゲートウェイが作成されるようになっています(# NAT Gateways)。
後半では、ALBが作成された後(# Application Load Balancer)、EC2インスタンスがそれぞれのプライベートサブネット内に作成され(# EC2インスタンス)、ALBとWebサーバが関連付けられる構成となっています。
また、明示的な指示はしていませんが、ネットワーク通信やEC2へのアクセスに必要な以下のコンポーネントも組み込まれており、希望するシステムを構成するために必要な要件が過不足なく含まれたテンプレートが生成されました。
- EC2のインスタンスタイプパラメータ化(デプロイ時に指定可能)
- インターネットゲートウェイ(IGW)の作成(# インターネットゲートウェイ)
- パブリックサブネット用のルーティングテーブル(デフォルトルートがIGW)
- プライベートサブネット用のルーティングテーブル(デフォルトルートが同一AZ内のNATゲートウェイ)
- ALBとWebサーバ用のセキュリティグループ
あと追加するとすれば、Webサーバにアクセスする手段がないため、Keypairの作成または設定、もしくはSSMにアクセス可能なIAMロールの設定が必要になるかと思われます。
これを実際にCloudFormationでデプロイしてみると、下記の様に想定通りの構成になることが確認できました(エラーはWebサーバを構成していないだけなので無視してください)。
ネットワーク

ALB+EC2

このように、Amazon Q Developerを使用することで、ある程度こちらの意図を汲み取った、実用性の高いテンプレートファイルを作成できることが確認できました。さらに細かくコントロールしたい場合は、プロンプトにより具体的な指示を加えるだけで対応可能だと考えられます。
3.より少ない労力でいいものを作成してみよう!
先ほどは、システム構成図を言語化してテンプレートを作成しましたが、今回は人の考える負荷を軽減しつつ、高品質な構成が作れるかどうかを試してみたいと考えています。
そのため、AWSのベストプラクティスに沿った希望のシステム構成が作成されるように、以下の内容でプロンプトを入力してみます。
AWSのWell-Architected Frameworkにしたがって、Webサーバを構成するCloudFormationテンプレートを作成してください。
作成されたファイルが長くなったため、割愛させて頂きますが、下記の様な構成が作成されました。
- 1つのVPC内に1つのパブリックサブネットと1つのプライベートサブネット
- Auto-ScalingとALBで可用性と伸縮性に優れたコンピュート層
- EC2へのCloudWatchエージェントとSSM Managerへの対応
- インスタンスタイプをt3インスタンスファミリーのみ選択できるようにすることでコストの削減
CloudFormationにできたテンプレートファイルを読み込ませて、Infrastructure Composerで表示すると下記の様になります。

実際こちらをデプロイしてみれば、問題なくシステムが構成されました。
この結果から、AWSに詳しくない方でも、ベストプラクティスに沿ったシステム構成が可能であることが分かります。また、AWSに慣れている方であっても、まずベースとして、Amazon Q DeveloperにAWSのベストプラクティスに沿ったテンプレートを作成させて、その後自身の考えに基づいてカスタマイズすることで、信頼性や運用性に優れたインフラを効率的に構築できると考えられます。
4.さいごに
今回は、Amazon Q Developerを用いてIaC(Infrastructure as Code)のコード作成を試してみました。
生成AIであれば当然とも言えるかもしれませんが、完全な指定を行わなくても、システム構成図をある程度のレベルで言語化して指示することで、不足している部分を補完し、問題なく動作するテンプレートが生成されることが確認できました。
また、さすがはAWSのツールだけあって「Well-Architected Framework」に準拠するように指示するだけで、AWSのベストプラクティスに沿った信頼性と運用性に優れたシステムテンプレートが作成されることも確認できました。
もちろん、より複雑な構成を作成する場合には、プロンプトの工夫が必要となり、場合によっては人が手動で記述した方が良いケースもあるかと思います。しかし、IaCをこれから始めようとしている方や、作業負荷を軽減したい方にとっては、非常に有用なツールであると言えるでしょう。
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。