月別アーカイブ: 2015年11月

同一セグメントにて複数インターフェースがある時のNW設定

はじめまして、hatです。

EC2上にてCentOSのマシンを稼動させ、複数のIPを持たせる必要があり作業をしたときのことです。
NWに詳しい方は想定できるかもしれませんが、備忘録をかねて作業内容を書いていきたいと思います。

環境情報

・EC2インスタンス (CentOS5.4を利用)
・ENIを2つ追加し、複数のIPアドレスを追加
・IFのセグメントはすべて同一(eth0,eth1,eth2)

  • eth0:10.6.3.92
  • eth1:10.6.3.96
  • eth2:10.6.3.100

最初にAWSコンソールにてログインし、EC2インスタンスのネットワークインターフェースの追加し、
それぞれのインターフェースにEIPを割り当てました。それではsshにてアクセスしてみます。
結果は下記のようになりました。

  • eth0 → sshアクセス可能
  • eth1  → 応答なし
  • eth2 → 応答なし

あれ、なぜつながらない・・・。ここでしばらく悩んでしまいました。
ふとルーティングテーブルを見てみると下記の状態になっていることに気づきました。

 

【ルーティングテーブルの情報】

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.6.3.0        *               255.255.255.0   U     0      0        0 eth0
10.6.3.0        *               255.255.255.0   U     0      0        0 eth1
10.6.3.0        *               255.255.255.0   U     0      0        0 eth2
169.254.0.0     *               255.255.0.0     U     0      0        0 eth2
default         10.6.3.1        0.0.0.0         UG    0      0        0 eth0

 

ローカルリンクの接続は問題ありませんが、eth1とeth2の外部からの通信は
デフォルトGWであるeth0を通って返されてしまっていました。
これでは正常な通信のやり取りができません。

調べてみるとipコマンドにてルーティングの設定ができるようなので
こちらを利用して設定の導入を進めて行くことにしました。
以下はその時に実施した内容です。

ルーティングテーブルの作成

まずはルーティングテーブルを追加します。
1~252の範囲(0、253~255は予約されている)から作成します。
ここでは100、101を利用しました。

【コマンド】

vi /etc/iproute2/rt_tables

【記載内容】

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
100     subroute-eth1    → ★追加
101     subroute-eth2    → ★追加

 

ルーティングの追加

ルートテーブルにルーティングを追加します。

【コマンド】(eth1の設定)

ip route add table subroute-eth1 10.6.3.0/24 dev eth1 scope link proto kernel
ip route add table subroute-eth1 default via 10.6.3.1 dev eth1

 

【コマンド】(eth2の設定)

ip route add table subroute-eth2 10.6.3.0/24 dev eth2 scope link proto kernel
ip route add table subroute-eth2 default via 10.6.3.1 dev eth1

 

実際に反映されているか確認します。

【コマンド】

ip route show table subroute-eth1

【表示結果】

10.6.3.0/24 dev eth1  proto kernel  scope link
default via 10.6.3.1 dev eth1

 

【コマンド】

ip route show table subroute-eth2

【表示結果】

10.6.3.0/24 dev eth2  proto kernel  scope link
default via 10.6.3.1 dev eth2

ルートテーブル参照条件のルールを追加

作成したルーティングテーブルが参照されるようにルールへ追加します。
mainのテーブル(routeコマンドで参照できるもの)よりも優先的に参照するように
優先度を上げておきます。

【コマンド】

ip rule add from 10.6.3.96 table subroute-eth1 prio 100
ip rule add from 10.6.3.100 table subroute-eth2 prio 110

 

ルーティングテーブルのルール情報を確認します。
【コマンド】

ip rule show

【表示結果】

0:      from all lookup 255
100:    from 10.6.3.96 lookup subroute-eth1   →★追加
110:    from 10.6.3.100 lookup subroute-eth2  →★追加
32766:  from all lookup main                  →routeコマンドで表示されるテーブル
32767:  from all lookup default

OS起動時/ネットワーク再起動時の対処

1.OS起動時対応用、スクリプトを作成しておきます。

【コマンド】

vi /usr/local/sbin/subroute.sh

【記載内容】

#!/bin/sh

#ルーティングルートテーブル追加
#[eth1用]
ip route add table subroute-eth1 10.6.3.0/24 dev eth1 proto kernel scope link
ip route add table subroute-eth1 default via 10.6.3.1 dev eth1

#[eth2用]
ip route add table subroute-eth2 10.6.3.0/24 dev eth2 proto kernel scope link
ip route add table subroute-eth2 default via 10.6.3.1 dev eth1

#ルーティングルール追加
#[eth1用]
ip rule add from 10.6.3.96 table subroute-eth1 prio 100

#[eth2用]
ip rule add from 10.6.3.100 table subroute-eth2 prio 110

 

2.ネットワークコマンド実行時用のファイルを作成します。

【コマンド】

vi /usr/local/sbin/subroute2.sh

【記載内容】

#!/bin/sh

#ルーティングルートテーブル追加
#[eth1用]
ip route add table subroute-eth1 10.6.3.0/24 dev eth1 proto kernel scope link
ip route add table subroute-eth1 default via 10.6.3.1 dev eth1

#[eth2用]
ip route add table subroute-eth2 10.6.3.0/24 dev eth2 proto kernel scope link
ip route add table subroute-eth2 default via 10.6.3.1 dev eth1

 

3.ツールに実行権限を付与

chmod 755 /usr/local/sbin/subroute.sh
chmod 755 /usr/local/sbin/subroute2.sh

 

4.自動起動に対応させるための修正

OS起動時用の登録

vi /etc/rc.local

【記載内容】

sh /usr/local/sbin/subroute.sh

 

5.ネットワークコマンド実行時用の登録

vi /etc/init.d/network

【記載内容】

[抜粋]
         sh /usr/local/sbin/subroute2.sh
         ;; ←閉じ前に記載すること
  stop)  
[抜粋]

終わりに

何とか想定どおりの動きになってくれました。ルーティングについては、奥が深く難しく感じましたが、苦労して分つながるとうれしいものです。すこしでも参考になっていただければ幸いです。

Dockercraftでコンテナを操作する

こんちには。船田です。
先日、こちらでMinecraftからDockerを制御するDockercraftというおもしろそうなツールを見かけたので試してみました。

AmazonLinuxへDockercraftをインストール

対象はDockerが動けば何でもOKですが、今回はAmazonLinuxを使っています。Dockerをインストールして、Dockercraftのコンテナイメージを落としてきます。

# yum install -y docker
# service docker start
# docker pull gaetan/dockercraft

Dockercraftは、それ自体がDocker上で動くコンテナで、Minecraftのサーバとして動作します。
Minecraftサーバは通常ポート25565を使用しますので、セキュリティグループやiptablesなどで接続を許可してあげてください。

Dockercraftを起動

以下のコマンドでDockercraftを起動します。

# docker run -t -i -d -p 25565:25565 \
-v /var/run/docker.sock:/var/run/docker.sock \
--name dockercraft \
gaetan/dockercraft
# docker ps
CONTAINER ID        IMAGE                COMMAND                CREATED             STATUS              PORTS                      NAMES
28b091c98cc3        gaetan/dockercraft   "/bin/bash /srv/star   18 seconds ago      Up 18 seconds       0.0.0.0:25565->25565/tcp   dockercraft

docker psすると、Dockercraftのコンテナが起動していることが確認できます。
準備はこれで終わりです。。

マインクラフトからDockercraftに接続してみる

手元のPCでマインクラフトを起動します。
「マルチプレイ」ー>「サーバー追加」でEC2のIPアドレスをを入力して「完了」し、追加されたサーバを選択して「サーバーに接続」すると、Dockercraftへ接続できます。

dockercraft-container
起動すると、一つだけオブジェクトがあります。これがDockercraftのコンテナです。

それでは、コンテナを起動してみます。
最初に「T」か「/」キーを押すとテキスト入力ができますので、ここで
docker run 【コンテナ名】
とすると、コンテナが起動します。ローカルに無いイメージはDocker Hubから落として来てくれます。

ぽこぽこ起動すると以下のようにどんどんコンテナが増えていきます。
containers
雨が降ってきました。。

起動したコンテナは

# docker ps -a
CONTAINER ID        IMAGE                COMMAND                CREATED             STATUS                      PORTS                      NAMES
1e2da408eeb0        node                 "node"                 13 minutes ago      Exited (0) 13 minutes ago                              tender_poincare
9abcbdc672d6        redis                "/entrypoint.sh redi   13 minutes ago      Up 13 minutes               6379/tcp                   cocky_ardinghelli
63d4a58db41a        postgres             "/docker-entrypoint.   13 minutes ago      Up 13 minutes               5432/tcp                   jovial_euclid
edbc4e5225f8        java                 "/bin/bash"            13 minutes ago                                                             fervent_feynman
a56a41e60a0f        nginx                "nginx -g 'daemon of   14 minutes ago      Up 14 minutes               80/tcp, 443/tcp            boring_wilson
335cc14b49af        wordpress            "/entrypoint.sh apac   15 minutes ago      Exited (1) 15 minutes ago                              mad_mccarthy
06f9f51a05e4        mysql                "/entrypoint.sh mysq   16 minutes ago      Exited (1) 15 minutes ago                              loving_kowalevski
86c1a057bb9b        centos:latest        "/bin/bash"            16 minutes ago      Exited (0) 16 minutes ago                              sad_rosalind
589ecd5577fb        jenkins              "/bin/tini -- /usr/l   16 minutes ago      Up 16 minutes               8080/tcp, 50000/tcp        hungry_bardeen
28b091c98cc3        gaetan/dockercraft   "/bin/bash /srv/star   39 minutes ago      Up 39 minutes               0.0.0.0:25565->25565/tcp   dockercraft

のように、ホスト側でも同期されていることが確認できます。

それぞれのコンテナの入口の看板にはコンテナ名と、CPU、メモリの使用率が書いてあります。
container-entrance
中に入ってみると、
container-on-off-switch
コンテナを開始/停止できるスイッチが付いています。これでコンテナのオフ/オンを制御できます。

まとめ

ネタ的なものかと少し思いながら試したのですが、きちんと作られており、ちゃんと動いて感動します。ChatOpsなども一般的になっていますし、サーバの操作にはコマンドラインだけでなく、いろんなやり方があっても良いかなと思います。
実際のところ、サーバが箱として可視化され、中にはいって操作する、というのは攻殻機動隊のようなイメージで、なかなか未来的で楽しいです。映画に出てくる立方体がくるくる回るハッキングシーンも、将来的にはありえるのかもしれません。。

参考URL(公式):docker/dockercraft

AWS Billingにおけるコスト配分レポートの設定

こんちには。

今回はAWS BillingのTipsについて書いてみたいと思います。

AWSからの請求は通常、アカウント単位でまとめて行われるため1つのAWSアカウント上で複数のシステムを運用している場合、各システムでどれだけのコストが掛かっているかを把握することが困難です。

そんな時に有効なコスト配分タグの機能を利用することで、AWSのコストをカテゴライズすることができます。
各AWSリソースにタグを適用すると、タグごとにグルーピングしたコストレポートが生成されます。

今回はコスト配分レポートを生成してみた手順を記載します。

S3バケットを作成

請求レポートをS3に配信するため、事前にS3バケットを作成しておきます。

2_s3_bucket_create_nzw

S3のバケットポリシーは以下のように設定しておきます。
※バケット名のところを作成したものに置き換えます。
※AWSアカウントIDは共通。

{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::386209384616:root"
    },
    "Action": [
      "s3:GetBucketAcl",
      "s3:GetBucketPolicy"
    ],
    "Resource": "arn:aws:s3:::s3-iesea-billingreport"
  },
  {
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::386209384616:root"
    },
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::s3-iesea-billingreport/*"
  }
  ]
}

請求レポートを有効化する

「請求とコスト管理」のページを開き、「設定」メニューをクリックします。
デフォルトだと『請求レポートを受け取る』にチェックが入っていないと思いますので、チェックを入れ、先ほど作成したS3バケットを入力します。

3.Billing_settei_nzw

バケットが存在し、ポリシーに問題が無ければ、下記のような画面になります。

4.Billing_settei_2_nzw

今回はTagによりコスト配分を可視化する目的のため、「リソースとタグを含む詳細な請求レポート」にチェックが入っていることを確認し、設定を保存します。

EC2インスタンスにタグを追加する

事前にやっておいても良いのですが、配分したいEC2に任意でタグを付けます。

1_tag_create_nzw

今回はキーに”Billing”、値に”production”など、分類したい名前を付与しました。
(ネーミングセンスは置いといて、、、)

5.ec2_tag_nzw

コスト割り当てタグを設定する

「請求とコスト管理」のページを開き、「コスト割り当てタグ」より今回フィルタリングしたいタグキーを有効化します。

6.cost_tag_nzw

コストエクスプローラーで配分コストを確認する

コストエクスプローラーを起動し、GroupingのプルダウンでTag -> フィルタリングしたいタグキーを選択すると、今回の目的のシステム毎による利用額が表示されます。

7.cost_reports_nzw

まとめ

今回はEC2のタグキーで利用額を分類してみました。
システム毎に費用を可視化することができました。
基本的にタグをサポートしているリソースで分類できそうですが、一部制限があるようです。
各リソース別の挙動については別途纏めてみたいと思います。

参考

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/configurecostallocreport.html

Lambdaでmysqldumpを取得する

こんちには。船田です。

先日のre:Invent 2015にて、Lambdaのスケジュール実行サポートが発表されました。
これにより、従来バッチサーバで日次実行していたような処理をLambdaに移行できるのではと期待しています。
今回は、日次バッチでありがちな、mysqldumpを使ったMySQLのデータベースのdump取得をLambdaから実行してみます。

mysqldumpコマンドの調達について

MySQLデータベースのdumpを取得するためには、Lambda Functionからmysqldumpコマンドを実行する必要があります。しかしLambdaのコンテナにはmysqldumpコマンドはインストールされていません。
そのため、あらかじめmysqldumpのバイナリを取得してS3に格納しておき、Lambda Functionは処理内でこれをダウンロードして実行する、という方法をとります。

試してみたところ、AmazonLinuxから拾ってきたmysqldumpは1バイナリでそのままLambdaコンテナ上で動くようです。今回は「Amazon Linux AMI 2015.09 (HVM), SSD Volume Type」でインストールしたmysql55パッケージに含まれるmysqldumpバイナリを使いました。

S3にmysqldumpバイナリを格納

あらかじめ作成しておいたバケットにmysqldumpバイナリをアップロードします。
s3-mysqldump

IAM Roleの作成

Lambda Functionに割り当てるIAM Roleを作成します。
Lambda FunctionからはS3上のmysqldumpバイナリのダウンロードと、dumpファイルのアップロードができる必要があります。また、CloudWatch Logsへ実行ログを格納する必要があります。
これらを満たすため、以下の様なポリシーを割り当てます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::s3-lambda-mysqldump-test/*"
      ]
    }
  ]
}

Lambda Functionの作成

Lambda Functionで実行するコードを作成します。

# -*- coding: utf-8 -*-
import boto3
import os
import commands
import datetime

def lambda_handler (event, context):
    s3_bucket_name = 's3-lambda-mysqldump-test'
    s3_mysqldump_bin = 'mysqldump'
    work_dir = '/tmp'
    
    mysql_endpoint = 'xxx.xxx.xxx.xxx'
    mysql_user = 'root'
    mysql_pass = 'password'
    mysql_dbname = 'sampledb'
    
    #get mysqldump from s3
    s3 = boto3.client('s3')
    s3.download_file(s3_bucket_name, s3_mysqldump_bin, work_dir + '/' + s3_mysqldump_bin )
    ret = os.path.isfile(work_dir + '/' + s3_mysqldump_bin)
    if ret is False:
        print(ret)
        return 1

    #chmod mysqldump
    cmd = 'chmod +x ' + work_dir + '/' + s3_mysqldump_bin
    ret = os.system(cmd)
    if ret is False:
        print('chmod mysqldump failed')
        return 2
        
    #mysqldump
    now = datetime.datetime.now()
    mysqldump_filename = mysql_dbname + '_' + now.strftime("%Y%m%d%H%M%S") + '.sql'
    cmd = work_dir +  '/' + s3_mysqldump_bin + ' -u' + mysql_user + ' -p' + \
          mysql_pass + ' -h' + mysql_endpoint + ' ' + mysql_dbname + \
          ' >' + work_dir + '/' + mysqldump_filename
    ret = commands.getoutput(cmd)
    if ret.find('error') >-1:
        print(ret)
        return 3
        
    #file check
    ret = os.path.isfile(work_dir + '/' + mysqldump_filename)
    if ret is False:
        print('file check failed')
        return 4
    
    #upload to s3
    s3.upload_file(work_dir + '/' + mysqldump_filename, s3_bucket_name, mysqldump_filename)
    
    return 0

zipで固めてaws cliからcreate-functionを実行します。

zip code.zip lambda_function.py

aws lambda create-function \
  --region us-west-2 \
  --function-name mysqldump \
  --runtime python2.7 \
  --role arn:aws:iam::123456789012:role/lambda-test-s3-role \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://code.zip

これでLambda Function作成とコード配備ができましたので、マネジメントコンソールからテスト実行してみます。
exec-mysqldump-lambda-function

Lambda Function実行後、S3のバケット内にdumpファイルが格納されたことが確認できます。
mysqldump-in-s3

続いてスケジュール実行を設定します。
Event sourcesタブを選択し、「Add event source」をクリックします。
create-event-source-01

各項目を埋めていきます。
create-event-source-02
スケジュール設定は、cronのような表記で定義できるのですが、cronのようでcronではありません。
年の指定があるため、cronよりも一桁多いです。また、タイムゾーンはUTCで固定です。少し癖がありますので、
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/getting-started-scheduled-events.html
のサンプルを参考にして作成します。

問題点

これでmysqldumpが日次で実行できそうなのですが、現状ではセキュリティ的に大きな穴があります。

Lambda Functionが実行されるコンテナは実行の度に変わるので、データベースサーバへアクセスするコンテナのIPアドレスも実行のたびに変わってしまいます。そのため、データベースサーバ側ではIPアドレスによるアクセス制限をかけることができず、現状ではデータベースのリッスンポートへのアクセスをフルオープンにしなければなりません。

しかし、
http://aws.typepad.com/aws_japan/2015/10/aws-lambda-update-python-vpc-increased-function-duration-scheduling-and-more.html
に記載があるとおり、LambdaのVPC対応予定が既にアナウンスされていますので、とりあえずはそちらのリリースを待ちたいと思います。

API Gatewayでのインスタンス制御

はじめまして まばおです。

開発期間中や開発環境でAWSを利用する場合、
夜間や土日では起動している意味はないので
今までは必要な時に起動したり、
停止し忘れ防止のため、EC2上に
cronで毎時23時にシャットダウンするように設定することで
無駄なコストがかからないようにしてました。

re:Inventにて発表されたAWS Lambdaのアップデートにより
pythonに対応、スケジュール化ができるようになったので
curl及びブラウザから
起動/停止できるようにし、効率化を図っていきます。

今までの起動停止方法

◆AWSコンソールの場合(例)

  1. AWSコンソールログイン
  2. EC2リソース表示画面に移動
  3. 起動/停止したいEC2を選択
  4. 起動
    ※ここでの例は4STEPとしてますがデフォルトリージョンが異なっていた場合等で手順が増減します。

◆Amazon CLI利用の場合(例)

  1. プロファイル読み込み
  2. 起動/停止したいインスタンスID確認
  3. start-instances stop-instancesコマンドで起動

 

lambda+ API Gatewayを利用した起動停止方法

  1. 起動/停止URLに対象となるメソッドを送信

たった2~3STEPが省かれるだけであまり変わってないように見えますが
繰り返すことが多くなってくることを
考慮すると作業時間へのメリットは大きいと思います。

 

lambda設定

本項では停止の設定を例に記述しています。
起動はstopの箇所をstartに読み換えることで設定可能です。

  1.  Create a Lambda function を押下
  2. Select blueprintの画面でhello-world-pythonを選択
  3. Nameの箇所にわかりやすい名前を記入 例:ec2_stop_instances
  4. Lambda function codeの箇所に以下を記入
    import boto3
    
    def lambda_handler(event, context):
        client = boto3.client('ec2')
        response = client.stop_instances(
            InstanceIds=[
                 '[インスタンスID 1]',
                 '[インスタンスID 2]'
            ]
        )
        print response
    
  5. Roleを設定します。今回は以下ポリシーのRoleを使用します。
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents",
             "ec2:StartInstances",
              "ec2:StopInstances"
          ],
          "Resource": [
              "arn:aws:logs:*:*:*",
              "arn:aws:ec2:*:*:*"
           ]
        }
      ]
    }
  6. Create functionを押下し作成。
  7. Lambda function選択画面に戻るので作成したLambda Funcitonを選択します。
  8. Event sources タブを選択し Add event souceを押下
  9. Event source typeでScheduled Event選択します。
    cronの時間はUTCなので日本時間で23時に稼働したい場合は14にする必要があります
    Lambda_001
  10. 起動も同様に設定しcron設定を以下のように設定します。
 cron(0 1 ? * MON-FRI *)

上記設定により平日月~金 10:00になったら起動し 23:00になったら停止する
スケジュール設定が完了しました。

続いてcurl URLで制御可能にするためAPI Gate wayの設定を行います。

 

API Gateway 設定手順

lambda設定画面でAPI endpointsのタブを選択し赤枠の箇所を押下

APIG_001

 

API endpointの設定画面になるので以下のように設定します。

APIG_002

API Gateway設定画面にてデプロイを実行

実行のURLが出力されます。

ブラウザを開いている時はブラウザから
コンソールを起動している時はCLIからと
アクティブになっている頻度が多いウィンドウから
起動停止することの恩恵も大きいと思います。

 

今後の展望

今回はアクセス元はフルオープンとしていますが
以下2点を取り込んで運用で効率化を図っていきます。
・実行に対し適切なポリシーを適用する。
・起動時に欲しい情報が出力もしくはSNSと連携する。

初めてのAWS CLI

はじめまして。

私は今年の4月から入社した新入社員です。

初のブログへの投稿ということで、何を書こうか悩んでしまったのですが、
入社して間もないころに先輩社員の方に「CLIでも操作出来ますよ」と教えて頂いた時に
困ってしまったことがあったのを思い出しました。
なので、今回はAWS CLIの導入について書きたいと思います。

導入の前にAWS CLIとは何かについて簡単に書きます。
AWS CLIとはAWS Command Line Interface(CLI)のことです。
簡単に言ってしまうとAWSに用意されている多種多様なサービスをコマンドで操作するためのツールになります。
AWSのサービスを操作する方法は主に以下の2つです。

・CLIでコマンドを使って操作する。
・WEBのGUIコンソールを使って操作する。

どちらもそれぞれに利点と欠点があります。
どちらも不慣れな初心者ですが、私の所感でCLIとGUIを比べたものを簡単にまとめました。

GUI CLI
操作性 直感的な操作可能で、日本語化されている部分も多いので操作しやすいので、操作性は高い コマンドや操作するサービスの項目名、IDを調べなければならないので、操作性は低い
記録の残しやすさ 誰にでも分かるように記録をとろうとした場合画面のキャプチャが多数必要で簡単な作業でも手順を残すのが大変 実際に使用したコマンドと出力を記載すればよいだけなので記録するのが楽
汎用性 同じ作業に同じだけの手順が掛かるので汎用性を持たせるにはそれに適したサービスを別途使用する必要があるので汎用性は低い 一度コマンドを調べてしまえば中の値を変更するだけで操作をすることが可能なので汎用性は高い

まとめます。
セキュリティグループに値を追加するといった簡単な作業や設定変更をした後に反映の確認をするなど、
すぐに終わる作業は操作が分かり易く、内容を一目で見れるようになっているGUIの方が向いています。
また、複雑なサービス(私にとってはCloudFormationでした)はGUIの方が入り易いです。
複数のサービスに対して起動や設定の操作を行う場合はCLIの方が手順を残し易く、汎用性を持たせ易いので向いています。
また、CLIはシェルスクリプトと組み合わせて操作することが可能なので、応用性もあります。

AWS CLIの導入

CLI導入は簡単です。

Windowsの場合

  1. インストーラをダウンロード
    64 ビット用
    32 ビット用
  2. ダウンロードした MSI インストーラを実行します
  3. 表示される手順に従います

Linux, OS X, or Unixの場合

  1. pip のウェブサイトからインストールスクリプトをダウンロードし実行します
    [vagrant@localhost ~]$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
    ~出力略~
    [vagrant@localhost ~]$ sudo python get-pip.py
    ~出力略~
    
  2. pip を使用して AWS CLI をインストールします。
    [vagrant@localhost ~]$ sudo pip install awscli
    ~出力略~
    
  3. インストール確認
    [vagrant@localhost ~]$ aws --version
    aws-cli/1.9.1 Python/2.6.6 Linux/2.6.32-504.el6.x86_64 botocore/1.3.1
    

AWS CLI プロフィール設定

インストールが完了したら、設定です。
CLIでAWSのサービスを操作する場合
どのユーザでどのリージョンにアクセスするかを設定する
必要があります。
設定はaws configureコマンドを使用します。

[vagrant@localhost ~]$ aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:

上記の4つを入力します。
この4つの項目はaws configureコマンドを
使用することでいつでも変更が可能です。

AWS Access Key ID [None]:
AWS Secret Access Key [None]:

この2つでどのアカウントのどのユーザとして操作するかを
設定します。2つはセットです。

Default region name [None]:

どこのリージョンを使うかの設定です。
リージョンとは物理的に離れている
Amazonのデータセンターのことです。
現在指定できるリージョンは以下の10個です。
指定するときは”コード”の方を入力します。

コード 名前
ap-northeast-1 アジアパシフィック(東京)
ap-southeast-1 アジアパシフィック(シンガポール)
ap-southeast-1 アジアパシフィック(シンガポール)
ap-southeast-2 アジアパシフィック(シドニー)
eu-central-1 欧州(フランクフルト)
eu-west-1 欧州 (アイルランド)
sa-east-1 南米(サンパウロ)
us-east-1 US East (N. Virginia)
us-west-1 米国西部(北カリフォルニア)
us-west-2 米国西部(オレゴン)
Default output format [None]:

出力形式の設定です。

現在指定できる形式は[ json | text | table ]の3つです。

複数のプロフィール設定を保持する

aws configure --profile 【profile名】を使って
4つの項目を設定すると、複数の設定を用意することが出来ます。

--profileで設定したユーザを使用する場合は以下の方法でコマンドを実行します。

aws 【コマンド】 --profile 【profile名】

これを使うことで、例えばテスト用の環境と本番用の環境両方に対して頻繁にコマンドを打ちたい時などに
いちいちaws configureを使って対象を変更する手間を省くことが出来ます。
ただし、--profile 【profile名】を指定しないでコマンドを打ってしまうと、
aws configureで設定した先にコマンドを実行してしまいます。
「テスト環境に試すはずだったコマンドを本番環境に行ってしまった」というような事故も有り得るので、注意が必要です。

AWS CLI コマンド補完設定

この作業は必須の作業ではありませんが、AWSのコマンドは種類が多く、長いコマンドも多いので補完機能が使えると大変便利です。
設定はShellによって若干違います。

現在のShellは以下のコマンドで確認出来ます。

[vagrant@localhost ~]$ echo $SHELL
/bin/bash

今回はbashの場合の作業です。

  1. aws_completerを探す
    [vagrant@localhost ~]$ type aws_completer
    aws_completer is /usr/bin/aws_completer
    
  2. completeコマンドで設定
    [vagrant@localhost ~]$ complete -C '/usr/bin/aws_completer' aws
    
  3. bashrcに追加
    [vagrant@localhost ~]$ echo "complete -C '/usr/bin/aws_completer' aws" >> $HOME/.bashrc
    

まとめ

AWS CLIとは何か調べる時は少し敷居が高いように感じましたが、
実際に作業してしまえば導入は簡単でした。
最初はGUIだけでもいいのではないかと思ったこともありましたが、
実際に使ってみると必須と言っても過言では無いツールでした。

(参考)
https://aws.amazon.com/jp/cli/
http://docs.aws.amazon.com/ja_jp/kinesis/latest/dev/kinesis-tutorial-cli-installation.html