【AWS入門】AWS CLIでEC2を作成・起動してsshでログインする方法

当ページのリンクには広告が含まれています。
AWSCLIでEC2を構築する

AWSのリソースを作成するときはマネジメントコンソール画面で行うことが多いかと思います。

マネジメントコンソールではなく、AWS CLIでもさまざまなAWS環境を構築することが可能です。

今回はAWS CLIでEC2を作成し、ローカルのPCからSSHで接続する環境を構築します。

AWS CLIを使用するとマネジメントコンソールよりも複雑になってしまいますが、細かい部分までパラメータで指定する必要があるのでいい勉強になると思っています。

以下の記事では、現役のAWSエンジニア目線でAWSが学べるスクールを4つ厳選したのでぜひ参考にしてください。

>>【2023年最新】AWS初心者におすすめAWSが学べるスクール4選を見る

目次

AWS CLIを使うメリット

私は、AWSの環境設定を行う場合、マネジメントコンソールではなくAWS CLIを利用することをおすすめします。

以下、その理由を記載していますが、そんなのどうでもいいからとりあえずやり方だけ教えて!という方はこちらから先に進んでください。

なぜAWS CLIを使うのか?

AWSでEC2の起動などの操作を行う場合、一般的にはマネジメントコンソールから操作を行うかと思います。

もちろん、マネジメントコンソールのほうがグラフィカルな画面で操作できるため、初心者の方でもわかりやすく操作が可能です。

AWS CLIでも、基本的にはマネジメントコンソールと同等な操作が行えます。

といっても、AWS CLIでは分かりやすい画面もなく、細かいコマンドを実行していくため初心者の方には分かりにくい部分も多いでしょう。

それでも、私は以下の理由からAWS CLIコマンドを使用することをおすすめします。(もちろんすべての操作をCLIでやれというわけではないです)

  • Infrastructure As Code(IaC)が実現できる
  • マネジメントコンソールの画面がよく変わる
  • aws cliだと細かいパラメータを設定する必要があって理解が深まる
  • そもそもマネジメントコンソールで操作する権限がない場合がある

Infrastructure As Code(IaC)が実現できる

IaCとは、AWSの環境をコードで管理するという考え方で、非常に重要な考え方です。(AWSに限らずあらゆるITインフラに共通していえます)

マネジメントコンソールだとどうしてもヒューマンエラーが発生する可能性があります。(私も現場でよく見てきました)

一方で、環境をコードに落とし込んでおけば、あとはそのコードを実行するだけなので誰がやっても同じ環境ができあがります。

一般的にAWSでのIaCといえば、TerraformやCloudFormationを使用することが多いです。

しかしながら、AWS CLIでも一連のコマンドをスクリプト化すれば立派なIaCになります。

Terraformなどの方がIaCに特化しているため理想的ですが、IaCの入口としてはaws cliはちょうどいいでしょう。

もちろん、AWS CLIのコマンドをすべて覚える必要は一切ありません。

なぜなら、分からなければその場でWeb検索などですぐに調べられるからです。

調べながら使っているうちに覚えれればいいし、覚えられなければ毎回調べればいいと私は思います。

マネジメントコンソールの画面がよく変わる

AWSのマネジメントコンソールのUIはよく変わります。

なので、AWSに関する古い記事だと画面のキャプチャ画像が古いUIの画像だったりして、参考にならないときもありますよね。

一方で、aws cliだとそこまで大きく変わることはないですし、バージョンが変わってもある程度互換性を考慮されているため、昔のコマンドが使えなくなる!ということはめったにないかと思います。

もちろん、今後どうなるかはわかりませんが、少なくともバージョン1から2になったときは、そこまで大きな影響はありませんでした。

aws cliだと細かいパラメータを設定する必要があって理解が深まる

これはIaCとも関連しますが、マネジメントコンソールの場合、良くも悪くも操作がとても簡単です。

簡単であるゆえに、細かいところはあまり気にしなくてもいい感じに環境ができあがります。

そのため、AWSの細かい設定などの知識がつきづらいんですよね。

一方でAWS CLIだと細かいパラメータまで自分で指定する必要があります。

どんなパラメータを設定する必要があるのか?などを調べているうちに、自然と知識も身に付いてくるので一石二鳥だと思っています。

そもそもマネジメントコンソールで操作する権限がない場合がある

例えば本番環境で、それぞれのIAMユーザーには権限があまり設定されていないが、運用EC2にはそこそこの権限が設定されたIAMロールがアタッチされているパターンがあるかと思います。

こういう場合はマネジメントコンソールからはそもそも操作ができません。

運用EC2上で操作をする必要がありますが、そうなるとaws cliを使用せざるを得ないですね。

特に本番環境などの権限を細かく設定したい場合は、こういった制約もあるのでaws cliに慣れておくのもいいでしょう。

EC2にアタッチされたIAMロールでawscli操作をする

AWS CLIのインストールと初期設定

まずは事前準備としてaws cliを導入します。

すでに導入済みの方はこちらへ飛んでください。

事前準備の部分は本質ではないので、基本的に外部のサイトを参照してもらいます。(適切な参照先は紹介します)

  • AWS CLIのインストール
  • aws configureの設定

私はMac環境ですが、Windows環境でも同様に設定可能です。

AWS CLIのインストール

awc cli自体のインストールは以下のAWS公式ドキュメントを参照ください。

Mac、Windows両方のインストール方法が記載されています。

aws configureの設定

AWS CLIをインストールしたら、コマンドを使うための権限が必要です。

aws configureコマンドを入力して、アクセスキー、シークレットキー、リージョンを設定すればいいですが、アクセスキー、シークレットキーの取得方法が分からない方は以下の公式ドキュメントを参照してください。

ちなみに、リージョンはap-northeast-1(東京リージョン)を使用します。(どこでもいいですが)

私の環境では以下のバージョンがインストールされています。

$ aws --version 
aws-cli/2.8.0 Python/3.9.11 Darwin/21.3.0 exe/x86_64 prompt/off

EC2インスタンス作成の事前準備

AWS CLIが使えるようになったら、次はEC2インスタンスを作成するのに必要なAWSリソースを用意します。

EC2インスタンスに必要なものは以下のリソースですが、今回はこれらもAWS CLIで作成していきましょう。

これらのリソースがすでにある人は、こちらからEC2インスタンスの作成へ進んでください。

  • VPCとサブネット
  • キーペア
  • セキュリティグループ

VPCとサブネット

VPCとサブネットを新規に作成してもいいのですが、今回はAWS側がせっかく初めから用意してくれているデフォルトのVPCとサブネットを使用しましょう。(他にVPCを作成しているのであれば、それでもよいです)

マネジメントコンソールの「VPC」の画面から、すでにあるVPCの「VPC ID」を控えておいてください。

以下の記事では、VPCとパブリックサブネット、プライベートサブネットをAWS CLIで構築する方法を紹介しています。

VPCもAWS CLIで作成してみたい方はぜひトライしてみてください。

キーペアの作成

続いてEC2のログインに必要なキーペアを作成します。

aws ec2 create-key-pairコマンドを使うことでキーペアの作成が可能です。

このコマンドには以下のパラメータがあります。(もちろんほかのパラメータもありますが、今回はこれらだけで大丈夫です)

  • –key-name
    キーペアの名前を指定します。名前はなんでもいいですが、後で使用するので覚えておいてください。
  • –query
    コマンドの実行結果のうち、出力するパラメータを指定します。今回はKeyMaterialとしておけばよく、深く考える必要はありません。
  • –output
    出力形式を指定します。jsonやyamlなどが選べますが、今回はtextとします。こちらも深く考えなくてよいです。

このコマンドの出力はそのまま秘密鍵の内容を返すので、結果をローカルのファイル(今回はMyKeyPair.pemとしました)に出力します。

$ aws ec2 create-key-pair --key-name MyKeyPair --query 'KeyMaterial' --output text > MyKeyPair.pem 

Windowsの場合は、リダイレクト部分を以下のように変更してください。

aws ec2 create-key-pair --key-name MyKeyPair --query 'KeyMaterial' --output text | out-file -encoding ascii -filepath MyKeyPair.pem

LinuxまたはMacの場合は、セキュリティ面を考えて以下のようにローカルの鍵の権限を変更しておいてください。

また、慣例としてホームディレクトリの.sshディレクトリ以下に鍵を置くことが多いので、移動しています。

$ chmod 400 MyKeyPair.pem     # 権限を変更(ファイル所有者の読み取り権限のみに制限)
$ mv MyKeyPair.pem ~/.ssh     # .sshディレクトリ以下に移動

セキュリティグループの作成

次にEC2インスタンスに設定するセキュリティグループを作成します。

セキュリティグループの作成コマンドはcreate-security-groupコマンドです。

以下のパラメータを使用します。

  • –group-name
    セキュリティグループ名を指定します。何でもいいですが、今回はmy-sgとします。
  • –description
    セキュリティグループの説明文です。こちらもなんでもいいですが、適当に”My security group”としておきます。
  • –vpc-id
    セキュリティグループを作成するVPCのIDを指定します。最初に控えたVPCのIDを設定してください。
$ aws ec2 create-security-group --group-name my-sg --description "My security group" --vpc-id vpc-xxxxxx
{
    "GroupId": "sg-xxxxxx"
}

コマンドを実行すると、作成したセキュリティグループのIDが返ってきます。

作成したセキュリティグループがどのような設定になっているのか確認してみましょう。

セキュリティグループの詳細はaws ec2 describe-security-groupsコマンドで確認できます。

注意点として、最後の–group-idsパラメータの値は、my-sgなどのセキュリティグループ名ではなく、sg-xxxxxxのようなセキュリティグループIDを指定する必要があります。

aws ec2 describe-security-groups --group-ids sg-xxxxxx

以下のようなJSON形式で設定内容が返ってきます。

{
    "SecurityGroups": [
        {
            "Description": "My security group",
            "GroupName": "my-sg",
            "IpPermissions": [],
            "OwnerId": "123456789123",
            "GroupId": "sg-xxxxxx",
            "IpPermissionsEgress": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": []
                }
            ],
            "VpcId": "vpc-xxxxxx"
        }
    ]
}

主なパラメータを解説します。

パラメータ内容
OwnerIdセキュリティグループを作成したAWSのアカウントID
IpPermissionsEgressセキュリティグループのアウトバウンドルール
IpProtocol許可するプロトコル、ポート範囲。-1はすべての値を表す。
IpRanges許可するIPアドレスの範囲。0.0.0.0/0はすべてのIPアドレスを表す。

実際にマネジメントコンソールを確認してみると、確かに上記のルールのセキュリティグループが作成されていることがわかります。

セキュリティグループの初期状態

セキュリティグループにSSHポートを許可する設定を追加する

デフォルトのセキュリティグループではインバウンドルールが設定されていなかったので、インバウンドルールにSSHのポートと設定します。

セキュリティグループの設定変更にはauthorize-security-groupコマンドを使用します。

各種パラメータは以下の通りです。

  • –group-id
    セキュリティグループのIDです。
  • –protocol
    許可するプロトコル名です。今回はSSHなのでtcpとします。
  • –port
    許可するポート番号です。今回はSSHなので22とします。
  • –cidr
    許可するIPアドレス範囲です。本来は特定のアドレスを指定する方がいいですが、今回はとりあえずすべてのIPを許可するように0.0.0.0/0とします。
aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 22 --cidr 0.0.0.0/0

コマンドを実行したら以下のように変更後の設定内容が返ってきます。

{
    "Return": true,
    "SecurityGroupRules": [
        {
            "SecurityGroupRuleId": "sgr-0c61bf1b794aa07b5",
            "GroupId": "sg-04588bf40ab0244da",
            "GroupOwnerId": "441966062653",
            "IsEgress": false,
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIpv4": "0.0.0.0/0"
        }
    ]
}

マネジメントコンソールで確認すると、確かにインバウンドルールが追加することがわかります。

SSH接続を設定したインバウンドルール

AWS CLIでEC2インスタンスを作成する

以上で準備が完了したのでEC2インスタンスを起動しましょう。

一応公式ドキュメントのリンクを載せておきます。

AMIのIDを調べる

まずはEC2インスタンスのベースとなるAMI(OSのようなもの)を決める必要があります。

今回は無料利用枠でも使用できるAmazon Linux 2のAMIを使いましょう。

EC2のマネジメントコンソールから「AMIカタログ」>「クイックスタートAMI」から一番上にある「Amazon Linux 2 AMI」と記載されたものを使います。

ここの「ami-xxxxxx」のようなAMI IDを控えておいてください。

AMIカタログからAMI IDを調べる

EC2インスタンスを作成・起動する

EC2インスタンスの作成・起動にはaws ec2 run-instancesコマンドで使用します。

コマンドのパラメータは以下の通りです。

  • –image-id
    さきほど控えたAMI IDを指定します。
  • –count
    起動するインスタンス数を指定します。今回は1とします。
  • –instance-type
    t2.microのようなインスタンスタイプ(インスタンスの性能)を指定します。無料利用枠が使えるt2.microとします。
  • –key-name
    使用するキーペアの名前を指定します。最初に作成したキーペア名にしてください。私の場合はMyKeyPairです。
  • –subnet-id
    EC2を設置するサブネットのIDです。後ほどSSHで接続するのでパブリックサブネットを指定して下さい。(デフォルトのVPCにあるサブネットでよいです)
aws ec2 run-instances --image-id ami-0bba69335379e17f8 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-xxxxxx --subnet-id subnet-xxxxxx

コマンドを実行すると、以下のような結果が出力されます(長いので省略しています)。

Instances.InstanceIdの部分にEC2のインスタンスIDが出力されるので、こちらも控えておいてください。

{
    "OwnerId": "123456789012",
    ・・・
    "Instances": [
        {
            ・・・
            "InstanceId": "i-xxxxxx",
            ・・・
            ],
        ・・・
    ]
}

マネジメントコンソールで実際に作成されているか確認しましょう。

以下のように、作成したインスタンスIDのインスタンスが作成されていることが確認できました。

EC2起動直後のマネジメントコンソール画面

タグを付ける

このままでもいいですが、一応Nameタグをつけてわかりやすくしておきましょう。

EC2インスタンスにタグを付与するコマンドはaws ec2 create-tagsです。

パラメータは、インスタンスIDとタグのキー・バリューを指定します。

  • –resources
    作成したインスタンスIDを指定します。
  • –tags
    付与したいタグを、「Key=タグ名,Value=タグの値」の形式で指定します。今回は、NameタグにMyInstanceという値を設定します。
aws ec2 create-tags --resources i-xxxxxx --tags Key=Name,Value=MyInstance

実際にタグが追加されたかマネジメントコンソール画面で確認します。

以下のように、インスタンスのName欄に先ほど設定した値が設定されていればOKです。

Nameタグを付与したインスタンスのマネジメントコンソール画面

インスタンスの詳細情報を取得する

続いてSSHで接続するために、EC2インスタンスのパブリックIPアドレスを取得します。

こちらはマネジメントコンソールで確認してもいいですが、せっかくなのでaws cliで調べてみましょう。

EC2インスタンスの詳細設定を取得するにはaws ec2 describe-instancesコマンドを使用します。

–filtersパラメータでどのEC2インスタンスの情報を取得するかをフィルタリングできます。

今回は先ほど設定したNameタグでフィルタリングします。(フィルタリングの結果が複数の場合は、複数の結果が返ってきます)

aws ec2 describe-instances --filters "Name=tag:Name,Values=MyInstance"

以下のような結果が返ってくると思います。

この結果のPublicIpAddressに、パブリックIPアドレスが記載されているのでこちらを控えておきましょう。

{
    "Reservations": [
        {
            "Groups": [],
            "Instances": [
                {
                    ・・・
                    "ImageId": "ami-0bba69335379e17f8",
                    "InstanceId": "i-xxxxxx",
                    "InstanceType": "t2.micro",
                    "KeyName": "MyKeyPair",
                    ・・・
                    "PublicIpAddress": "xx.xx.xx.xx",
                 }
            ]
        }
    ]
}

EC2にSSHで接続する

最後にEC2インスタンスにSSHで接続してみましょう。

ssh -i <秘密鍵のパス> <ユーザー名@EC2のパブリックアドレス>コマンドで接続します。

ユーザー名は、Amazon Linux 2のAMIを使用しているEC2の場合はec2-userです。

コマンドを実行すると、yes/noと聞かれるので、yesと打ってエンターするとEC2に接続できます。

$ ssh -i ~/.ssh/MyKeyPair.pem ec2-user@xx.xx.xx.xx                                            
The authenticity of host '18.177.139.242 (18.177.139.242)' can't be established.
ED25519 key fingerprint is SHA256:ppIPBld3q4hGs0YauvYbmMwD+yGhvimM3Idxh1KY/2w.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '18.177.139.242' (ED25519) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

EC2の停止・再開・削除

無事にEC2にログインできたので、EC2の停止・終了方法も記載しておきます。

作成したEC2インスタンスはもう不要であれば、終了してEC2インスタンスを削除してしまいましょう。

EC2の停止・再開

EC2は起動している間課金されるので、使用しない間は停止しておくといいです。(EC2を停止していても、EC2にアタッチされているボリュームの料金はかかります)

無料利用枠であれば基本的に起動しっぱなしでもほとんど課金される心配はありませんが、念の為停止しておくといいです。

EC2インスタンスの停止はaws ec2 stop-instancesコマンドを使用します。

–instance-idsパラメータに、停止するインスタンスIDを指定します。

aws ec2 stop-instances --instance-ids i-xxxxxx

停止したEC2インスタンスは、aws ec2 start-instancesコマンドを使います。

パラメータは停止のときと同じです。

EC2インスタンスを停止・再開すると、パブリックIPアドレスが変わることに注意してください。(Elastic IPアドレスを付与することで、IPアドレスを固定することが可能です)

aws ec2 start-instances --instance-ids i-xxxxxx

EC2の終了(削除)

作成したEC2インスタンスが二度と必要ない場合はインスタンスごと終了(削除)しましょう。

削除はaws ec2 terminate-instacesコマンドで行えます。

–instance-idsパラメータに、停止するインスタンスIDを指定します。

aws ec2 terminate-instances --instance-ids i-xxxxxx

まとめ

今回はAWS CLIを使用してパブリックサブネット上にEC2を構成しました。

マネジメントコンソールだともっと簡単に作成できますが、AWS CLIを使うことでEC2の作成方法やパラメータをより詳しく理解できるかと思います。

TerraformやCloudFormationなどのIaCツールでも、同様に細かいパラメータ等を調べて構築する必要があるため、勉強になると思いますのでぜひトライしてみてください。

もっと詳しくAWSを知るには

さらにAWSを詳しく知りたいという方は、スクールでAWSを学ぶのもおすすめです。

AWSをスクールで学習するのは、以下のメリットがあります。

  • 必要最低限のサービスを厳選して学習できる
  • ハンズオン形式で効率的に学習できる
  • AWS以外のエンジニアに必要なスキルも同時に学習できる

以下の記事では、AWSが学べるスクールを現役のエンジニア目線で4つに厳選してランキングしているので、ぜひ参考にしてみてください。

よかったらシェアしてね!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA


目次