AWS EC2のデプロイを方法別で比較。最速のデプロイ方法はどれ？
こんにちは、クララTAMの石川です！
AWS（Amazon Web Service）はElastic Compute Cloud（EC2）というサービスでVirtual Machine（VM）を提供していますね。
そして、AWSではEC2を複数の方法でデプロイすることができます。
今回は、いくつかあるEC2のデプロイについて、どの手段が一番早くEC2を構築できるのか、それぞれのメリット・デメリットは何かを比較・纏めてみました。
この記事の目次
今回比較するEC2のデプロイ方法と要件
今回利用するデプロイ方法は以下
・コントロールパネルでの操作
・AWS CLI(CloudShell)での操作
・CloudFormationの操作
また、共通の結果として、EIPを付与して、Nginxのデフォルトページが表示されることが確認できる状態まで設定、とします。
今回の要件はこちら
OS：Amazon Linux 2 AMI (HVM) – Kernel 5.10, SSD Volume Type
※ami-0f7691f59fd7c47af (64 ビット Arm)
インスタンスタイプ：t4g.micro(2vCPU、1GiB)
ディスクサイズ：8GB(default)
SecurityGroup：80
（※メイン要件ではないので…）
GUIデプロイ
AWSマネジメントコンソールから計測スタート
- Amazonマシンイメージ（AMI）
- インスタンスタイプの選択
- インスタンスの詳細の設定
- ストレージの追加
- タグの追加
- セキュリティグループの設定
- インスタンス作成の確認
- 細かいところはSSHで調整
GUIデプロイにかかった時間
大体・・・30分ぐらい。
PC前で張ってれば10分。
GUI操作：2分
待ち ：3分
SSH操作：5分 →構築時にユーザデータとして記載可能。その場合は0分に。
AWS コマンドラインインターフェイス（CLI）デプロイ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
aws ec2 create-security-group \ --group-name deploy-cli \ --description "My security group" \ --vpc-id vpc-6a3b310e aws ec2 authorize-security-group-ingress \ --group-id <上記のSGID> \ --protocol tcp \ --port 80 \ --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress \ --group-id <上記のSGID> \ --protocol tcp \ --port 22 \ --cidr 0.0.0.0/0 aws ec2 create-key-pair \ --key-name ishikawa-deploy-cli \ --output text aws ec2 run-instances \ --image-id ami-0f7691f59fd7c47af \ --count 1 \ --instance-type t4g.micro \ --key-name ishikawa-deploy-cli \ --security-group-ids <上記のSGID> \ --subnet-id subnet-989aecee |
CLIデプロイにかかった時間
大体・・・30分ぐらい
CLI作成：10分
CLI操作：10分
待ち ：3分
SSH操作：5分
AWS CloudFormation（CFn）デプロイ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
Parameters: KeyName: Description: The EC2 Key Pair to allow SSH access to the instance Type: "AWS::EC2::KeyPair::KeyName" VPCID: Type: String Default: "vpc-6a3b310e" SubnetID01: Type: String Default: "subnet-989aecee" Resources: DEPLOYSG01: Type: AWS::EC2::SecurityGroup Properties: GroupName: deploy-CFn GroupDescription: Allow SSH and HTTP access only MyIP VpcId: !Ref VPCID SecurityGroupIngress: # http - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: "0.0.0.0/0" # ssh - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: "0.0.0.0/0" DEPLOYEC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0f7691f59fd7c47af KeyName: !Ref KeyName InstanceType: t4g.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref SubnetID01 GroupSet: - !Ref DEPLOYSG01 UserData: !Base64 | #!/bin/bash sudo yum update -y sudo amazon-linux-extras sudo amazon-linux-extras install nginx1 -y sudo systemctl enable nginx sudo systemctl start nginx Tags: - Key: Name Value: deploy-CFn |
CFnデプロイにかかった時間
大体・・・15分ぐらい
yaml作成：10分
(AWSが)構築：2分
待ち ：3分
SSH操作：0分
まとめ・比較表
| GUI | CLI | CFn | |
|---|---|---|---|
| 事前準備 | 特になし◎ | 十分時間が必要
・コマンドオプション ・事前に何が必要なのか |
十分時間が必要
・Yaml作成 ・CFnに対応していないものの作成 |
| 構築中の手離れ | 悪い✖
構築中は逐一気にかける |
良い◎
コマンドごとに確認が必要だが、シェル化等により対応可能 |
良い◎
yamlに構築情報が乗っているので、分割の程度により放置でもよい |
| 操作のしやすさ | 断然良い◎ | 悪い✖
オプションを調べるのに時間がかかる |
かなり悪い✖
yamlに特化したものを作る必要がある。対応していないサービスもある。 |
| 環境再現性 | 難しい✖
手順書が無いと厳しいが、ユーザIFは頻繁に変わるため、作りきりの手順では後々で厳しそう |
あり◎
同じコマンドを流せば同じものができる。コマンドは頻繁に変更が入らない。 |
あり◎ |
| 削除 | 自動で作成されるものもあり、どれが消していいものかがわからなくなる。 | 作ったものがどれかわからない。が、作成時にタグを付与する等で対応可能。 | 作ったものがきれいに消える。◎ |
| こんなところに使うのがおすすめ | 試験的構築 | 変更が頻繁にかかるが履歴をとっておきたい環境 | インフラ構築の自動化も視野に入れた環境 |
以上、今回は方法別のEC2デプロイ時間・メリット・デメリットを検証してみました。
