AWS CLIでVPCは作成済みの状態からサブネットなどを作っていきます。
以下の公式チュートリアルを参考にしてます。
docs.aws.amazon.com
サブネット作成
aws ec2 create-subnet --vpc-id vpc-02479fa33475f641d --cidr-block 10.0.1.0/24
--vpc-idに設定しているのは先に作成済みのVPCのもの --cidr-blockでVPCのCIDRをより細かく分割したものを設定する。
以下のようなJSONが出力される。
{
"Subnet": {
"AvailabilityZone": "ap-northeast-1c",
"AvailabilityZoneId": "apne1-az1",
"AvailableIpAddressCount": 251,
"CidrBlock": "10.0.1.0/24",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "subnet-0d6f762206638a34b",
"VpcId": "vpc-02479fa33475f641d",
"OwnerId": "XXXXXXX",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"SubnetArn": "arn:aws:ec2:ap-northeast-1:428351874559:subnet/subnet-0d6f762206638a34b"
}
}
JSONを見てみると、当たり前だと思いますがVpcIdの値はコマンドで入力したものと同じになってますね。 アベイラビリティーゾーンはVPC作成時から特に指定していなかったのですが、ap-northeast-1cになってました。
マネジメントコンソールではサブネット作成画面は以下のようになっています。
試しにVPCの範囲外のCIDRを入力すると警告が出てサブネット作成できませんでした。
サブネットをパブリックにする
下記コマンドを実行してインターネットゲートウェイを作成します。
aws ec2 create-internet-gateway
すると以下のようなJSONが出力されます。
{
"InternetGateway": {
"Attachments": [],
"InternetGatewayId": "igw-018f9fcec0e9b94b3",
"OwnerId": "XXXXXXXX",
"Tags": []
}
}
マネジメントコンソールで確認するとインターネットゲートウェイが想定通り作成されてました。
JSONの出力でもAttachmentsが[]になっているように、「状態」の項目がDetachedになっていてまだどのVPCにもアタッチされていない状態になっています。
以下のコマンドでVPCにインターネットゲートウェイをアタッチします。
aws ec2 attach-internet-gateway --vpc-id vpc-02479fa33475f641d --internet-gateway-id igw-018f9fcec0e9b94b3
JSONの出力はなし。
マネジメントコンソールで確認すると上記コマンドで設定したVPCにインターネットゲートウェイがアタッチされてました。
以下のコマンドでVPCに対してカスタムルートテーブルを作成。
aws ec2 create-route-table --vpc-id vpc-02479fa33475f641d
以下のようなJSONが出力されます。
{
"RouteTable": {
"Associations": [],
"PropagatingVgws": [],
"RouteTableId": "rtb-02764c54f3e3c886f",
"Routes": [
{
"DestinationCidrBlock": "10.0.0.0/16",
"GatewayId": "local",
"Origin": "CreateRouteTable",
"State": "active"
}
],
"Tags": [],
"VpcId": "vpc-02479fa33475f641d",
"OwnerId": "XXXXXXXX"
}
}
マネジメントコンソールでもルートテーブルが作成されてました。
インターネットゲートウェイへのすべてのトラフィック(0.0.0.0/0)をdestination-cidr-blockに持つ(外部インターネットに繋がっている)ルートを作成する。
aws ec2 create-route --route-table-id rtb-02764c54f3e3c886f --destination-cidr-block 0.0.0.0/0 --gateway-id igw-018f9fcec0e9b94b3
以下のJSONが出力されました。実行結果がbooleanで返ってくるっぽい。
{
"Return": true
}
以下のコマンドでルートが有効になっているかを確認。
aws ec2 describe-route-tables --route-table-id rtb-02764c54f3e3c886f
以下のようなJSONが出力されます。
コマンドで入力した末尾94b3のインターネットゲートウェイに0.0.0.0/0のDestinationCidrBlockを持つルートがあるので成功しているようです。
{
"RouteTables": [
{
"Associations": [],
"PropagatingVgws": [],
"RouteTableId": "rtb-02764c54f3e3c886f",
"Routes": [
{
"DestinationCidrBlock": "10.0.0.0/16",
"GatewayId": "local",
"Origin": "CreateRouteTable",
"State": "active"
},
{
"DestinationCidrBlock": "0.0.0.0/0",
"GatewayId": "igw-018f9fcec0e9b94b3",
"Origin": "CreateRoute",
"State": "active"
}
],
"Tags": [],
"VpcId": "vpc-02479fa33475f641d",
"OwnerId": "XXXXXXX"
}
]
}
マネジメントコンソールで確認すると以下のようになっており、ルートが設定されているのがわかりました。
localとなっているのはアタッチされているVPCだと思います。
一応サブネットがまだ関連づけられていないのを確認。
まだルートテーブルはサブネットに関連付けられていないので、サブネットからのトラフィックがインターネットゲートウェイにルーティングされるよう設定していきます。
以下のコマンドでサブネットIDとCIDRのみ出力されるように--queryオプションを設定してIDを確認する。
今はサブネットひとつしかないので使用しないが、サブネットが複数ある場合は--filterオプションも使ったほうがいいはず。
aws ec2 describe-subnets --query 'Subnets[*].{ID:SubnetId,CIDR:CidrBlock}'
すると以下のJSONが出力されました。
[
{
"ID": "subnet-0d6f762206638a34b",
"CIDR": "10.0.1.0/24"
}
]
外部インターネットに接続しているカスタムルートテーブルにサブネットを関連づけます。
このサブネットはパブリックサブネットになります。
aws ec2 associate-route-table --subnet-id subnet-0d6f762206638a34b --route-table-id rtb-02764c54f3e3c886f
以下のJSONが出力されました。
{
"AssociationId": "rtbassoc-0c95861b03611fb26",
"AssociationState": {
"State": "associated"
}
}
マネジメントコンソールから確認するとインターネットゲートウェイにサブネットが関連づけられていました。
次の記事でEC2を立ち上げてアクセスするところまでやってみます。
