AWSの各サービスについて

コンソール画面
AWSの使用開始ドキュメント

Contents

1 VPC
- 1.1 仕様
- 1.2 使用方法
  - 1.2.1 VPCの作成
  - 1.2.2 Public DNS名の取得
2 EC2
- 2.1 仕様
  - 2.1.1 NATインスタンスについて
- 2.2 使用方法
3 Auto Scaling
- 3.1 仕様
  - 3.1.1 設定項目
- 3.2 使用方法
4 Security Group
- 4.1 仕様
- 4.2 使用方法
  - 4.2.1 グループの新規作成
  - 4.2.2 ルールの追加・削除
5 ネットワークACL
- 5.1 設定方法
6 Load Balancer
- 6.1 仕様
- 6.2 使用方法
  - 6.2.1 新規作成
7 ストレージ (S3)
- 7.1 使用方法
  - 7.1.1 新規作成
  - 7.1.2 パーミッション設定
8 Relational DBMS (RDS)
- 8.1 仕様
  - 8.1.1 MySQL
- 8.2 使用方法
9 メッセージQueueサーバ (SQS)
10 DNS (Route53)
11 CDN (CloudFront)
12 CloudWatch
- 12.1 用語
- 12.2 使用方法(CLI)
13 VPN
14 Hadoopクラスタ (Elastic MapReduce)
15 新規サービス構築フロー
16 API

VPC

仕様

IPアドレス

v6は使用不可
インスタンスにはプライベートアドレスのみ割り当て可能
サブネットは/28～/16の間で作成可能
サブネット内のアドレスのうち、先頭の4アドレス、最後の1アドレスはAmazon側で使用するため割り当て不可
サブネットは最大200作成可能
インスタンスに複数のIPアドレスを付与可能。ただしインスタンスのタイプによって個数は異なる。
インターネットと通信する場合、固定IPを取得して紐付けるか、NAT(OUTGOING NAPT)を設定するかする必要がある。

ACL

自由にホストの組み合わせ設定ができるグループ単位、作成したサブネット単位でのみ設定可能
グループ単位の制御が「Security Group」、サブネット単位の制御が「ネットワークACL」と言い、それぞれ別の機能である
Inbound通信に関しては送信元情報のみで宛先IPアドレス、宛先ポートによる制限は不可
Outbound通信に関しては宛先情報のみで、送信元IPアドレス、送信元ポートによる制限は不可
ホワイトリスト方式、ブラックリスト方式による設定が可能
詳細な情報で、特定のインスタンスのみで制御を行いたい場合はサーバ内で制御を行う必要がある

ルーティング

スタティックルーティングのみ使用可能
デフォルトではプライベートネットワークのみルーティングテーブルに登録されている
インターネットと通信する場合、デフォルトルートを登録する必要がある

リージョン

東京を含む、複数のリージョンから選択して使用可能
リージョンをまたがるVPCは作成できない
リージョンごとにインスタンスの価格が異なる

Availability Zone (AZ)

特定のリージョン内に通常複数存在するインスタンスを作成できる場所
異なるAZは電源やラックなど物理的に分けられている（地理的にどの程度離れているのかは不明）
AZをまたがるサブネットを作成することはできない
AZ間は専用線で接続されており、高速に通信できるが僅かながらの費用が必要

使用方法

コンソール
https://console.aws.amazon.com/vpc/home

VPCの作成

Your VPCs画面へ
1. Create VPC
2. VPC全体で使用するネットワークアドレスを指定
Subnets画面へ
1. Create Subnet
2. VPCに作成したVPCを指定
3. VPCのネットワーク内で分割するサブネットを記載して作成
Internet Gateways画面へ
1. Create Internet Gatewayで作成
2. 作成したGatewayを選択し、Attach to VPCで作成したVPCと紐付け
Route Tables画面へ
1. 作成したサブネットがインターネットと通信する場合はデフォルトルートの登録を行う

Public DNS名の取得

グローバルアドレスを持っているインスタンスにDNS名でアクセスしたい場合、
自動でドメイン名を取得できる。
ただし、名前にIPが含まれており、IPが勝手に変化することは無いと思われるため、
IPアドレスでアクセスしたほうが、名前解決のオーバーヘッドが無いため、
IPアドレスでアクセスするほうがよい。
なお、デフォルトVPCの場合は、デフォルトでこの機能が有効になっている。

手順
1. Your VPCsページを開く
2. DNSの取得をしたいVPCを選択する
3. 画面下部のDNS SettingsタブでEnable DNS resolutionのチェックを入れる

EC2

EC2単独で使用することもできるが、現在はVPC内でEC2を使用することが主流である。

仕様

Private IPは固定にできる
eth0に割り当てたIPアドレスは変更、切り離しができないが、2つ目以降のアドレスは付け替え可能
グローバルアドレスは変動自動取得が可能であるが、インスタンス作成時にしか有効・無効の設定ができない
グローバルIPの動的取得を後から有効にはできないが、ElasticIPを割り当てることで、ElasticIPの使用が優先される

NATインスタンスについて

NAT専用のコンポーネントがAWSで用意されているわけではなく、NATを行うEC2インスタンスを立ち上げる。
NATインスタンスではデフォルトでNAPTを行うデーモンが起動しており、
プライベートアドレスしか持たないインスタンスのデフォルトルートとして登録することで、
そのインスタンスはインターネットへのOutgoing通信のみ行うことができるようになる。
デフォルトルートは次のようにして登録する。

route add default gw <NATインスタンスのプライベートIP>

デフォルトゲートウェイとしてAWS標準のルータへのルートが存在するのでデフォルトルートが２つになるが構わない。
パブリックネットワークとプライベートネットワークが完全に分離している環境では、
AWSのサブネットごとで設定できるルーティングで一括してデフォルトルートを登録できる。

使用方法

コンソール
https://console.aws.amazon.com/ec2/v2/home

スナップショットの作成

稼働中・停止中のインスタンスのスナップショット（ディスクイメージ）を作成することができる。
作成したスナップショットは同一のAZからのみ利用できる。

手順
1. メニューからInstancesを開く
2. 移動したいインスタンスを選択する
3. 詳細情報から”Block devices”をクリックし、EBS ID情報を記憶する
4. メニューからSnapshotsを開く
5. Create Snapshot をクリックします。
  Create Snapshot ダイアログボックスが表示されます。
6. スナップショットを作成するボリュームを選択し、Create をクリックします。
  Amazon EC2 によってスナップショットの作成が開始されます。

カスタムAMIの作成

稼働中のインスタンスをAMI化し、それを基にしたインスタンスを作成できるようにする。
AMI作成時には対象となるインスタンスがデフォルトで再起動してしまう。
再起動させたくない場合は、実行時にオプションで再起動させないようにすること。ただしこの場合、書き込み途中のストレージの整合性が担保されなくなる。

手順
1. メニューからInstancesを開く
2. AMI化したいインスタンスを選択する
3. 右クリックメニューから「Create Image」を選択する
4. イメージの名前、説明を入力する
5. 対象インスタンスを再起動させたくない場合は、再起動しないにチェックを入れる
6. ボリュームのサイズを変更する場合は、サイズを入力する
7. 合わせて削除にチェックを入れる
8. 「Create Image」ボタンを押す

カスタムAMIの削除

不要なAMIを削除する。当該AMIを利用して作成したインスタンスには影響はない。

手順
1. メニューからAMIを開く
2. 対象インスタンスを選択する
3. 詳細タブの「ブロックデバイス」の値を確認する
4. 登録解除
5. メニューからスナップショットを開く
6. 「ブロックデバイス」の値にある、スナップショットIDで検索する
7. 対象のスナップショットを選択し、右クリック、削除

AMIのアカウント間共有

あるアカウントで作成したAMIを別のアカウントからも利用できる設定ができる。

手順
1. 共有したいアカウントのアカウントID（12桁の数字）を調べる（My Account ページに記載）
2. AMIを提供する側のアカウントでログインする
3. メニューからAMIsを開く
4. 共有したいAMIを選択する
5. 画面下部のPermissionsタブを開き、AWS Account Numberを編集して上記アカウントIDを追加する

NATインスタンスの作成

マニュアル

手順
1. EC2作成画面を開く
2. AMI選択時に「Community AMIs」から「ami-vpc-nat」で検索する
3. その他は通常通り作成する。
  プライベートIPは固定とする。
  グローバルIPは動的取得にする。
  これによってElasticIPの節約ができる。
  グローバルIPは固定にする必要がある場合、後から割り当てればよい。
  グローバルIPの動的取得を後から有効にはできないが、ElasticIPを割り当てることで、ElasticIPの使用が優先される。
4. 作成後、インスタンスページから送信元/送信先チェックを無効にする
5. NATインスタンスを使用するインスタンスは以下コマンドを実行する
```
sudo route add default gw <NATインスタンスのプライベートIP>
```

TeratermからSSHログインする

EC2インスタンスにはSSHでログインするが、よくわるユーザ名＋パスワードのログインではない。
AWSコンソールで作成したキーペアファイルを使用してログインを行う。
インスタンス作成時にこのキーペアを割り当てることで、そのキーを使用してログイン可能となる。
キーペアファイルを紛失した場合は再発行は不可で、新しく生成して既存のインスタンスに再割り当ても不可。

手順
1. 作成したキーペアファイルを、ローカルPCに用意する
2. Public DNSもしくはグローバルアドレスの値を調べる
  （インスタンス作成時に自動でPublic IP割り当てをしていない場合は「Elastic IPs」から割り当てる）
3. インスタンスの状態がrunning状態であることを確認する（Status Checkも完了している）
4. インスタンスのSecurity Groupの内容でSSHが許可されていることを確認する
5. teratermを起動する
6. ホストに「Public DNS/グローバルIP」の値、サービスをSSH、SSHバージョンをSSH2、ポートを22にする
7. ユーザ名に「ec2-user」を入力し、パスフレーズを空のままにする
8. 「RSA/DSA鍵を使う」にチェックを入れ、キーペア（.pem）ファイルを選択する
9. 「OK」を押すとログインできる

rootでログイン

rootではリモートログインできないようになっているので、
ec2-userでログインした後にsudo suコマンドでrootになる。

ユーザを追加

デフォルトではインスタンス作成時に指定したキーペアでec2-userでしかSSHログインできない。
他のユーザや、別のキーペアを使用してログインできるようにする。
公知のアカウントのec2-userは使用停止しておいた方が良い。
ただし、削除はaws使用に影響が出る可能性があるのでしない方が良い。

手順

新規にユーザを作成する

rootになる
```
sudo su
```

ユーザの作成

useradd --user-group --create-home <ユーザ名>

そのユーザに対するパーミッションの変更などあれば行う

sudo権限を与える

echo "<ユーザ名> ALL = NOPASSWD: ALL" >> /etc/sudoers.d/myadmin

キーペアファイルを作成する

su - <ユーザ名>
mkdir -m 700 .ssh
ssh-keygen
# Enter file in which to save the key (/home/awstest/.ssh/id_rsa): 　に何も入力せずにエンター
# Enter passphrase (empty for no passphrase):　に何も入力せずにエンター
# Enter same passphrase again:　に何も入力せずにエンター
mv .ssh/id_rsa.pub .ssh/authorized_keys
chmod 400 .ssh/id_rsa
chmod 400 .ssh/authorized_keys

ローカル側ファイルを確認

cat .ssh/id_rsa
# PCにテキストファイルを作成して中身をコピー

他のホストにもユーザを追加

rootになる
```
sudo su
```

ユーザの作成

useradd --user-group --create-home <ユーザ名>

そのユーザに対するパーミッションの変更などあれば行う

sudo権限を与える

echo "<ユーザ名> ALL = NOPASSWD: ALL" >> /etc/sudoers.d/myadmin

キーをコピーする

su - <ユーザ名>
mkdir -m 700 .ssh
vi .ssh/authorized_keys
# 最初に作ったキーをコピーする

vi .ssh/id_rsa
# 最初に作ったキーをコピーする

chmod 400 .ssh/authorized_keys
chmod 400 .ssh/id_rsa

ec2-userの無効化
1. rootになる
```
sudo su
```
2. ログイン禁止
```
usermod --shell /sbin/nologin ec2-user
```

いずれのホストでも確認無しでSSHログイン

SSHで接続する際に接続したことがないホストだと確認のプロンプトが表示される。
また、IPアドレスが同じで、インスタンスが変更された場合はエラーメッセージが表示される。
IPアドレスが変動したり、自動でホストが生成されたりし得るEC2ではこれを省略した方が便利である。

手順

特定のユーザのみに適用する場合

configファイルがないかを確認
```
ls ~/.ssh/config
```

以下をconfigに書く

~/.ssh/configがあった場合は編集して以下を追記

vi ~/.ssh/config

host *
	StrictHostKeyChecking no
	UserKnownHostsFile /dev/null
	LogLevel ERROR

ない場合は以下を実行

echo "host *" > ~/.ssh/config
echo -e "\tStrictHostKeyChecking no" >> ~/.ssh/config
echo -e "\tUserKnownHostsFile /dev/null" >> ~/.ssh/config
echo -e "\tLogLevel ERROR" >> ~/.ssh/config

全体に適用する場合

sudo vi /etc/ssh/ssh_config
# 以下を追記する。
# 既に "host *" 行があれば、それ以外の行のみ追記。
host *
	StrictHostKeyChecking no
	UserKnownHostsFile /dev/null
	LogLevel ERROR

タイムゾーンの変更

dateコマンドで表示される時刻がUTC等、JSTでない場合はJSTに変更する。

rm -f /etc/localtime
ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

sysstatによるパフォーマンスのロギング

sysstatパッケージをインストールすることで、各種パフォーマンスの値を記録することができる。

yum install sysstat -y

sysstatにより、記録されるログはそのホストの識別子が埋め込まれるので、オートスケールで立ち上がるホストの場合は
一度ログファイルを削除する必要がある。

vi /etc/rc.local

以下を追記する

sar -A || rm -f /var/log/sa/*

インスタンスストア（インスタンスストレージ・エフェメラルストレージ）の使用

EC2ではインスタンスストア（インスタンスストレージ・エフェメラルストレージとも呼ばれる）と言う、EC2のクラスに応じた容量を持つ揮発性のディスクを使用することが出来る。
これはデフォルトでは使用できないようになっており、インスタンス作成時、イメージ作成時に使用するよう設定すると、
そのインスタンス起動時にマウントされている状態となる。（２つ以上のインスタンスストアが使用できる場合、２つ目以降は自動でマウントされない）
インスタンスストアは無料で使用でき、クラスによっては高速なSSDが使用できる
なお、インスタンスストアに起動時にrsyncし、起動スクリプトで何らかのデーモンのrootをインスタンスストア上にすると、rc.localの実行が最後であるために起動に失敗する。
そのデーモンの起動もrc.localに記述することで回避できる。

各インスタンスクラスで使用できるインスタンスストア
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html#StorageOnInstanceTypes

使用方法
- Rootデバイスとして使用する
  RootデバイスをインスタンスストアにするとSTOPができないので注意。
  AMIの作成も出来ない。

新規インスタンスの作成
AMI選択時に「Community AMIs」から「Root device type: instance-store」と表示されているインスタンスを選択する

既存インスタンスへの適用
EBSをRootデバイスとして使用しているインスタンスやイメージのRootデバイスをインスタンスストアに変えることはできない。

追加ストレージとして使用する
- 新規インスタンスの作成
  1. Storage画面まで進める
  2. 「Add New Volume」ボタンをクリックする
  3. 「Type」の項目を「Instance Store X」に変更する
    使用できるインスタンスストア数だけ追加することが可能

既存インスタンスへの適用
1. コンソール画面から「Create Image」を行う
2. 「Add New Volume」ボタンをクリックする
3. 「Type」の項目を「Instance Store X」に変更する
  いくつでも設定可能であるが、作成したインスタンスのクラスによっては全数使用できない

複数のインスタンスストアを使用する
複数のインスタンスストアを使用する場合は、２つ目以降は自動でマウントされない。
自動でマウントするために、/etc/fstabを編集して、１つ目のものと同様の設定を行う
ただし、行末の数字は１つ繰り上げる。

起動スクリプト内でsudoを行う

telnetやsshなどのtty経由でないsudoは通常許可されない
これを許可する場合、以下を行う必要がある。

rootになる
```
sudo su
```
変更を許可する
```
chmod 640 /etc/sudoers
```

変更する

vi /etc/sudoers

# 下記の行を#コメントアウトする
# Defaults    requiretty

パーミッションを戻す
```
chmod 440 /etc/sudoers
```

インスタンスの移動

あるVPCで稼動しているインスタンスを別のVPCに移動させる。
EC2インスタンスのVPC間の移動はできないので、スナップショットを作成し、それを基にしたインスタンスを作成する。

手順
1. EC2コンソールを開く
2. スナップショットの作成を行う
3. スナップショットからボリュームを作成する
4. EC2インスタンスの新規作成を行う。
5. 作成したインスタンスを停止する
6. インスタンスのボリュームをDetachする
7. 事前に作成したボリュームをAtachする。
  その際、Root deviceとして認識されるよう、/dev/sda1としてマウントする。

ボリューム容量追加

EC2で使用するボリュームは後から容量を変更できない。
ディスク容量を追加する場合はスナップショットを取って新しく作成する必要がある。

手順
1. EC2コンソールを開く
2. 対象インスタンスを停止する
3. ボリュームページを開く
4. 対象のインスタンスにアタッチされたボリュームを選択し、右クリックメニューからスナップショットを作成する
5. スナップショットページを開く
6. スナップショット作成が完了したことを確認し、対象のスナップショットを選択、”Create Volume”ボタンをクリックする
  1. ボリュームタイプ、新しいディスク容量、元のインスタンスのAZを選択してCreateする
7. ボリュームページを開く
8. 作成したボリュームが作成完了したことを確認する
9. 元のボリュームを選択し、右クリックメニューからDetachする。
  その際ディスクの識別子を控える（/dev/sdXX）
10. 作成したボリュームを元のインスタンスにAttachする。
  その際ディスクの識別子（Device項目）を元と同じものにする。
11. インスタンスページを開く
12. インスタンスをStartさせる
13. インスタンスにログインし、ディスク容量が増えていることを確認する
```
fdisk -l
```
14. 増加したディスク容量が認識されていないことを確認する
```
df
```
15. 増加したディスク容量を認識させる
```
resize2fs <デバイス名>
```
16. 増加したディスク容量が認識されていることを確認する
```
df
```

インスタンス間でキーペアを使用してSSHする

手順
1. ログイン元サーバへログインする
2. 現在存在するファイルを確認する
```
ls
# デフォルト状態ではauthorized_keysのみあれば良い
```
3. .sshへ移動する
```
cd .ssh
```
4. 認証キーファイルを作成する
```
vi id_rsa
# ダウンロードしている XXX.pem ファイルの中身をコピーする
```
5. パーミッションを変更する
```
chmod 400 id_rsa
```

認証用公開鍵は既にauthorized_keysに記述されているのでログイン先の設定は不要

プライベートインスタンスの動的NATゲートウェイ設定

・同一サブネットにインターネットと直接通信するインスタンスとしないインスタンスが混在する
・直接通信しないインスタンスはNATインスタンスを利用して通信する
・複数の同様のサブネットが混在する
・同じAMI・インスタンスのコピーを複数のサブネットで使用したい
上記の場合、サブネットが複数あるため、元となるインスタンスに固定のルーティング設定ができない。
また、パブリックインスタンスとプライベートインスタンスが混在するためにAWSのルーティング機能で、
デフォルトゲートウェイをNATインスタンスに設定することはできない。
そのため、NATを使用したいインスタンスの起動スクリプトで動的にルーティングの設定を行う。

手順
例として10.0.0.0/16のVPC内に10.0.0.0/17と10.0.128.0/17のサブネットが存在し、
10.0.0.254、10.0.128.254がそれぞれのNATインスタンスとする。

スクリプトを作成する

sudo su
vi /usr/local/bin/setRoutingForNAT.pl

以下の内容を入力する

use strict;
use warnings;

my @result = `ifconfig`;
my $localIP2nd;
my $localIP3rd = -1;
for(my $i=0;$i<@result;$i++)
{
	chomp($result[$i]);
	
	if($result[$i] =~ /10\.([0-9]+)\.([0-9]+)\.[0-9]+/)
	{
		$localIP2nd = $1;
		$localIP3rd = $2;
		last;
	}
}

if($localIP3rd != -1)
{
	if($localIP3rd < 128)
	{
		`route add -net 10.$localIP2nd.128.0 netmask 255.255.128.0 gw 10.$localIP2nd.0.1`;
		`route add default gw 10.$localIP2nd.0.255`;
		`route del default gw 10.$localIP2nd.0.1`;
	}
	else
	{
		`route add -net 10.$localIP2nd.0.0 netmask 255.255.128.0 gw 10.$localIP2nd.128.1`;
		`route add default gw 10.$localIP2nd.128.255`;
		`route del default gw 10.$localIP2nd.128.1`;
	}
}

アクセス権を変更する

chmod 700 /usr/local/bin/setRoutingForNAT.pl

起動スクリプトとして登録する
```
vi /etc/rc.local
```
ファイル末尾に以下を追記する
```
perl /usr/local/bin/setRoutingForNAT.pl
```

AutoScale起動時のコンテンツの同期

AutoScaleでインスタンスが作成されるとき、事前に用意したAMIから行われるが、WEBサーバなどコンテンツファイルが頻繁に変わるものは
都度AMIを再作成し、AutoScale設定を修正するのは工数がかかる。
そのため、インスタンス起動時に指定したファイルを同期するようにする。

手順

別のサーバから同期する

同期元サーバ（AMI用）

rootになる
```
sudo su
```

起動スクリプトに同期処理を記述する

vi /etc/rc.local

# インスタンスストア上に同期する場合は以下も記述する。
chmod 777 /media/*
# 以下を記述する
sudo -u ec2-user rsync -av --delete <同期先IPアドレス>:<同期先パス> <同期元パス>

起動スクリプト内でsudoを行えるように設定する

chmod 640 /etc/sudoers
vi /etc/sudoers

# 下記の行を#コメントアウトする
# Defaults    requiretty

ec2-userになる
```
su ec2-user
```

SSHログインキーを登録する

ls ~/.ssh/id_rsa
# ファイルが存在しない場合は以下を実施

vi ~/.ssh/id_rsa
# EC2用のSSHキーペアのログインキーを記述

chmod 400 ~/.ssh/id_rsa

SSH時に確認・エラーが出ないようにする

vi /etc/ssh/ssh_config
# 以下をhost * 行の後に追加
	StrictHostKeyChecking no
	UserKnownHostsFile /dev/null
	LogLevel ERROR

同期先サーバ

SSHログインキーを登録する

vi ~/.ssh/authorized_keys
# EC2用のSSHキーペアのログインキーを記述

Auto Scaling

仕様

Auto Scalingはアカウント単位で設定される。
アカウントの認証はAuto Scalingを行ったインスタンスではなく、Security Credentialという認証情報を用いて行われる。
そのため、Auto Scalingを実施する前にはSecurity Credentialの設定を行う必要がある。

設定項目

Auto Scalingは以下の４つの設定を行うことで使用可能となる。

launch-config
インスタンスの設定。AMI、インスタンスタイプ、キーペア、セキュリティグループなどを設定する。
auto-scaling-group
Auto Scaling対象となるインスタンスのグループとそのグループに対するAuto Scaling自体の振る舞いの設定。
最大・最小起動インスタンス数、ELB、AZなどを設定する。
scaling policy
インスタンス増減方法の設定。一度に立ち上げるインスタンス数などを設定する。
metric-alarm
CloudWatchにおける閾値の設定。Auto Scaling起動トリガを設定する。

使用方法

「Auto Scaling Command Line Tool」という専用のツールが必要だが、AWSのAMIを使用している場合は標準でインストールされている。
※/opt/aws/bin/。ただし内部的に/opt/aws/apitools/asが呼び出される。
そうでない場合は別途ダウンロードする必要がある。
as-cmdコマンドで「Auto Scaling Command Line Tool」一覧が表示される。

事前準備

AWS_AUTO_SCALING_HOMEの設定
環境変数AWS_AUTO_SCALING_HOMEが設定されていなければ、設定する必要がある。
- 手順
  1. AWS_AUTO_SCALING_HOMEが設定されていないことを確認
```
echo $AWS_AUTO_SCALING_HOME
```
  2. 環境変数を設定
```
export AWS_AUTO_SCALING_HOME=$AWS_PATH/apitools/as/
```
  3. ログイン時に環境変数を設定する
```
# ec2-userのみに反映させる場合
vi ~ec2-user/.bashrc
# 全ユーザに反映させる場合
vi /etc/bashrc
```
    以下を記述する
```
export AWS_AUTO_SCALING_HOME=$AWS_PATH/apitools/as/
```
API認証設定
こちらを参照

regionの設定

regionは東京など複数あるが、東京しか使用しない場合、環境変数として設定しておくことで、
ツールでリージョンの指定を省略できる。

手順
1. 環境変数を設定する
```
export EC2_REGION=ap-northeast-1
```
2. ログイン時に環境変数を設定する
```
vi /etc/bashrc
```
  以下を記述する
```
export EC2_REGION=ap-northeast-1
```

Auto Scaling Command Line Toolのバージョン確認

as-versionコマンドを使用する

出力例

[root@ip-10-0-86-19 ec2-user]# as-version
Amazon AutoScaling CLI version 1.0.61.3 (API 2011-01-01)

Auto Scaling Command Line Toolのバージョンアップ

手順

バージョンを確認
```
as-version
```
ダウンロードページからアーカイブのURLを取得する

ダウンロードする

wget http://ec2-downloads.s3.amazonaws.com/AutoScaling-2011-01-01.zip

展開する
```
unzip AutoScaling-*.zip
```
アーカイブを削除する
```
rm -f AutoScaling-*.zip
```
ツールのディレクトリに移動させる
```
mv AutoScaling-* /opt/aws/apitools/
```

リンクを差し替える

# 現在のリンク先を確認
ls -l /opt/aws/apitools/as

# 変更
cd /opt/aws/apitools/
rm -f /opt/aws/apitools/as
ln -s AutoScaling-1.0.61.3 /opt/aws/apitools/as

# 現在のリンク先を確認
ls -l /opt/aws/apitools/as

バージョンを確認
```
as-version
```

launch-configの作成

手順

作成するコンフィグが存在しないことを確認する
```
as-describe-launch-configs <コンフィグ名> --show-long
```

コンフィグを作成する
<セキュリティグループ>は,で区切って複数列挙可能

as-create-launch-config <コンフィグ名> --image-id <AMI ID> --instance-type <インスタンスタイプ> --group <セキュリティグループ> --key <ssh key名> --monitoring-disabled

作成したコンフィグが存在することを確認する
```
as-describe-launch-configs <コンフィグ名> --show-long
```

launch-configの削除

手順
1. 削除するコンフィグが存在することを確認する
```
as-describe-launch-configs <コンフィグ名> --show-long
```
2. コンフィグを作成する
```
as-delete-launch-config <コンフィグ名>
```
3. 削除したコンフィグが存在しないことを確認する
```
as-describe-launch-configs <コンフィグ名> --show-long
```

auto-scaling-groupの作成

vpc-zone-identifierは複数指定でき、指定したサブネットの中から各サブネットのインスタンス数が均等になるようにスケールされる。
auto-scaling-groupを作成すると即座にAuto Scalingが開始され、インスタンス最低数までインスタンスが作成される。

手順

作成するグループが存在しないことを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

グループを作成する
<ゾーン名>は,で区切って複数列挙可能

as-create-auto-scaling-group <グループ名> --launch-configuration <launch-config名> --vpc-zone-identifier <サブネット名> \
 --load-balancers <バランサ名> --min-size <最小インスタンス数> --max-size <最大インスタンス数> --tag "k=Name, v=<インスタンス名>, p=true"

作成したグループが存在することを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

パラメータ
- vpc-zone-identifier
  VPCのサブネット識別子を記載する
- availability-zones
  インスタンスを作成したいAZを記載する。
  ただし、vpc-zone-identifierを指定した場合は不要。
- desired-capacity
  グループ内で現在稼動させたいインスタンス台数を指定できる。
  指定した台数まで瞬時にインスタンス台数が調整される。
  ただし、min-size ～ max-sizeの間の台数である必要がある。

auto-scaling-groupの修正

作成した既存のauto-scaling-groupの内、任意のパラメータを指定して変更できる

手順

修正するグループが存在すること、変更前のパラメータを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

グループを修正する

as-update-auto-scaling-group <グループ名> [任意のパラメータ名とその値]

修正したグループのパラメータを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

auto-scaling-groupの削除

手順
1. 削除するグループが存在することを確認する
```
as-describe-auto-scaling-groups <グループ名>
```
2. グループを削除する
```
as-delete-auto-scaling-group <グループ名>
```
3. 削除したグループが存在しないことを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

auto-scaling-groupへインスタンスの追加

インスタンスを追加するグループにそのインスタンスが存在しないことを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

インスタンスをグループに追加する

as-attach-instances <インスタンスID> --auto-scaling-group <グループ名>

インスタンスを追加するグループにそのインスタンスが追加されたことを確認する
```
as-describe-auto-scaling-groups <グループ名>
```

scaling-policyの作成・修正

指定したパラメータでscaling-policyの作成・修正を行う。

パラメータ
- adjustment
  このポリシーが起動されたときに増減するインスタンスの数値。typeの値によって意味が変わる。
  負数をとる場合、 –adjustment=-1 のように記述する。
  なお、インスタンス数の増減が発生して上限、下限を超える場合はその限界値までは増減する。
- cooldown
  このポリシーが起動されたときに再度同じポリシーが起動可能となるまでの時間（秒）
- min-adjustment-step
  typeにPercentChangeInCapacityを選択したときに有効。
  このポリシーが起動されたときに最低限増減させるインスタンス数を指定できる。
- type
  以下の値を設定できる。必須のパラメータ。
  - ExactCapacity
    既存の値に関係なく指定した値にする
  - ChangeInCapacity
    指定した値だけ既存の値から増減させる
  - PercentChangeInCapacity
    指定した値を百分率とした割合で増減させる

手順

作成するポリシーが存在しないことを確認する
```
as-describe-policies <ポリシー名>
```

ポリシーを作成する

as-put-scaling-policy <ポリシー名> --auto-scaling-group <auto-scaling-group名> --type ChangeInCapacity --adjustment <増減数>

作成したポリシーが存在することを確認する
```
as-describe-policies <ポリシー名>
```

scaling-policyの削除

手順
1. 削除するポリシーが存在することを確認する
```
as-describe-policies <ポリシー名>
```
2. ポリシーを削除する
```
as-delete-policy <ポリシー名> --auto-scaling-group <auto-scaling-group名>
```
3. 削除したポリシーが存在しないことを確認する
```
as-describe-policies <ポリシー名>
```

metric-alarmの作成・修正

指定したパラメータでscaling-policyの作成・修正を行う。
修正の場合も全てのパラメータを指定する必要があり、それで上書きされる。
scaling-policyは同名のポリシーで複数のグループ分作成できるが、metric-alarmは作成できない。

パラメータ
- actions-enabled
  アラームが起動したときにalarm-actionsで登録したアクションを実行するかどうか。
  trueかfalseで指定し、trueがデフォルト。
- alarm-actions
  アラームが起動したときにSNSにプッシュする内容。
  Auto Scaling使用時にはas-put-scaling-policyの出力結果をそのまま引数とする。
- alarm-description
  アラームの説明分
- comparison-operator
  閾値と比較して、どうであるときアラームが起動するかを指定する。
  以下の値が選択可能。
  - GreaterThanOrEqualToThreshold
  - GreaterThanThreshold,
  - LessThanThreshold
  - LessThanOrEqualToThreshold
- dimensions
  アラームが起動したときに影響を及ぼす対象
- evaluation-periods
  アラーム起動の条件となる、連続して閾値を超えた回数。
  閾値を超えてから、監視間隔×この値秒後にアラームが起動する。
- insufficient-data-actions
  このアラームを作成した今、SNSにプッシュする内容
- metric-name
  閾値として利用する値。
  mon-list-metricsコマンドで一覧を確認可能。
  namespaceはAWS/EC2の時に使用できるのは以下。
  - CPUUtilization
  - DiskReadBytes
  - DiskReadOps
  - DiskWriteBytes
  - DiskWriteOps
  - NetworkIn
  - NetworkOut
  - StatusCheckFailed
  - StatusCheckFailed_Instance
  - StatusCheckFailed_System
- namespace
  適用するサービス名。
  EC2の場合、”AWS/EC2″
- ok-actions
  アラームが起動状態から復帰したときにSNSにプッシュする内容
- period
  監視間隔（秒）
- statistic
  閾値として利用する数値の種類。
  - SampleCount
  - Average
  - Sum
  - Minimum
  - Maximum
- threshold
  アラームを起動する閾値
- unit
  閾値で使用する単位
  - Seconds
  - Microseconds
  - Milliseconds
  - Bytes
  - Kilobytes
  - Megabytes
  - Gigabytes
  - Terabytes
  - Bits
  - Kilobits
  - Megabits
  - Gigabits
  - Terabits
  - Percent
  - Count
  - Bytes/Second
  - Kilobytes/Second
  - Megabytes/Second
  - Gigabytes/Second
  - Terabytes/Second
  - Bits/Second
  - Kilobits/Second
  - Megabits/Second
  - Gigabits/Second
  - Terabits/Second
  - Count/Second
  - None

手順
1. 作成するアラームが存在しないことを確認する
```
mon-describe-alarms <アラーム名>
```
2. アラームを作成・修正（上書き）する
```
mon-put-metric-alarm <アラーム名> --namespace AWS/EC2 [任意のパラメータ名とその値]
```
3. 作成したアラームが存在することを確認する
```
mon-describe-alarms <アラーム名>
```

metric-alarmの削除

手順
1. 削除するアラームが存在することを確認する
```
mon-describe-alarms <アラーム名>
```
2. アラームを削除する
```
mon-delete-alarms <アラーム名>
```
3. 削除したアラームが存在しないことを確認する
```
mon-describe-alarms <アラーム名>
```

Security Group

ACL機能の１つで、アクセスコントロールリストを作成して、ホスト単位で適用できる。

公式ページ

仕様

ホワイトリスト方式で各インスタンスのInboud、Outbound通信に対する通信の許可を行うリストを作成できる。
作成したリストはEC2インスタンスやRDSインスタンス、ロードバランサなど、様々なものに適用することができる。

設定はICMP/TCP/UDPなどのプロトコルと、送信元ネットワークアドレス、ポート番号のみで、Denyは定義できない。

ネットワークやホストのセットに対してではなく、各ホストに対して個別に適用するので、
同一のセキュリティグループを適用したインスタンス間通信においても、アクセスコントロールが動作する。
適用対象は複数のセキュリティグループを適用することができる。

送信元ネットワークアドレスにグループ名を指定することで、グループ内通信に関してのみの特定の許可を定義することができる。
ただし、localhostへの通信についてはローカルIPやグローバルアドレスを指定するなど、
どのような宛先指定の方法であっても通信は可能である。

IPを使用した送信元の指定の他、特定のセキュリティグループを適用したホスト全てと言う指定もできる。
別アカウントのセキュリティグループを指定することもできるが、これはClassic-EC2用で、VPCを使用している場合は使用しても意味を成さない。
同一のアカウント内でもグローバルアドレス経由のアクセスの場合、セキュリティグループを使用した制御はできない。
直接IPアドレスを記載する必要がある。

使用方法

コンソール

グループの新規作成

新しくセキュリティグループを作成する。
新しいグループではInboundは全て拒否、Outboundは全て許可のデフォルトのルールが存在する。

“Create Security Group”ボタンをクリックする
名前、説明、使用できるVPCを選択して、作成する
リストが作成されるが、初期状態ではリスト内にルールは無い状態である

ルールの追加・削除

セキュリティグループにルールを追加・削除する。
変更は保存時に即時反映される。

マニュアル

追加したいグループを選択する
画面下部の詳細情報部分で、追加・削除したい方向（Inbound、Outbound）を選択する
追加するルールがあれば、記述して、”Add Rule”ボタンをクリックする
不要なルールがあれば削除する
“Apply Rule Change”ボタンをクリックして保存する

ネットワークACL

サブネット単位で指定できるアクセスコントロールリスト。
特定通信の許可と拒否とを定義できる。
Inboud通信において定義できるのはプロトコル、送信元ポート、送信元アドレス、ALLOW/DENYのみで、宛先は定義できない。
Outbound通信において定義できるのはプロトコル、宛先ポート、宛先アドレス、ALLOW/DENYのみで、送信元は定義できない。
ステートレスであるため、Outbound通信においてPermit Anyとしない場合は戻りの通信の許可を設定する必要がある。
ACLはエントリー番号の昇順にチェックされる。エントリー番号は32766以下で作成できる。

Security GroupとネットワークACLの違いについて。

設定方法

マニュアル

ACLの作成
1. Amazon VPC コンソールを開きます。
2. ナビゲーションペインで [Network ACLs] をクリックします。
3. [Create Network ACL] ボタンをクリックします。
4. [Create Network ACL] ダイアログボックスで [VPC] リストから VPC の ID を選択してから、[Yes, Create] をクリックします。

サブネットへの適用
1. Amazon VPC コンソールを開きます。
2. ナビゲーションペインで [Network ACLs] をクリックしてから、ネットワーク ACL を選択します。
3. 詳細ペインの [Associations] タブで、テーブルに関連付けるサブネットを選択してから、[Associate] をクリックします。
4. [Associate Network ACL] ダイアログボックスで [Yes, Associate] をクリックします。

Load Balancer

仕様

VPCを超えて、つまりリージョンを超えてのバランシングはできないが、AZを超えては可能
固定IPを取得することは不可能
インスタンスの停止はできないのでが内部でIPが変わることがある
そのためDNSはAレコードではなく、CNAMEレコードでの登録が必要
代理SSL機能がある
バランサインスタンス自体のAZは指定できないが、特定のAZでのみ動き続けるわけではない（AZ障害の場合もAZ間でのフェイルオーバが自動でされるらしい）
バランシングアルゴリズムはLeast Connection
IPアドレスはNATされるので、バランシング対象サーバはグローバルアドレスは不要
バランシング対象インスタンスをSTOP状態にし、再度STARTさせても対象として動作しないので、
（インスタンスとして登録はされているが、HealthCheckが失敗し続ける）一度外して再登録する

使用方法

コンソール
https://console.aws.amazon.com/ec2/home?#s=LoadBalancers

新規作成

マニュアル
http://docs.aws.amazon.com/ja_jp/gettingstarted/latest/computebasics-linux/getting-started-create-lb.html

フロー
1. [Navigation] ペインで、[Load Balancers] をクリックします。
2. [Load Balancers]ペインにある [Create a New Load Balancer] ウィザードで、[Create Load Balancers] をクリックします。
3. [Define Load Balancer] ページで、ロードバランサーの名前を入力します。
4. Listener Configurationの設定で、バランサで受け付けるプロトコルとポート番号、インスタンスへ転送するポート番号とプロトコルを指定します。
5. Security Groupを設定、もしくは作成してそれを設定します。
6. バランシング対象のインスタンスを追加します。
7. Createボタンで作成完了

作成時の注意
- バランサ作成後に「Instances」のタブで、HealthyがYesになるまでアクセスできないが、Yesになるのに時間がかかる。
- アクセスする際に「DNS Name」を使用するが、Amazon側のDNS登録が遅いのか、
  DNSネガティブキャッシュの原因かは不明だが、名前でのアクセスに非常に時間がかかる。
  適当なAWSサーバで名前解決してIPを取得すれば、そのIPからはアクセス可能。

ストレージ (S3)

S3という名前で提供される。

ストレージの容量は予め決まっておらず、使用した分だけ課金される
通信の費用はストレージへのデータ配置は無料で、データ取得にのみ課金される
99.99%の可用性と、99.999999999%の堅牢性(1万個のオブジェクトを保存したとして、そのうちの1つが障害によって失われるのに平均で1000万年ほどかかるレベル)
通常のストレージサービスのほかバックアップ用の低速ストレージ「Glacier ストレージ」がある。
テープバックアップのようなもので、低速アクセスではあるが、安価に使用できる。

使用方法

コンソール
https://console.aws.amazon.com/s3/home

新規作成

Create Bucket
バケット名（ストレージの識別子）、リージョンを入力する。バケットは既に存在するものは使用できない。
Createボタンをクリック

ディレクトリの作成
ディレクトリを作りたいパスでCreate Folderを行う。
階層はコントロールパネルの下に表示されており、上位のディレクトリをクリックすることで移動できる。

ファイルのアップロード
1. ActionメニューからUploadを選択
2. Add Filesボタンを押し、ファイルを選択する
3. Start Uploadボタンでアップロードを実行する
4. https://s3-ap-northeast-1.amazonaws.com/<バケット名>/<ファイルパス>のURLが発行されるが、パーミッションが設定されていないので、直接アクセスできない。
  右クリックメニューからOpenでアクセスして確認する。これにより一時的に有効なパスが発行される。

ファイルの削除
削除したいファイルを選択し、右クリックでDelete

パーミッションの設定
公開したいファイルを選択し、右クリックでMake Public。
より詳細なパーミッションを設定したい場合はPropertyから行う。

パーミッション設定

AWSで複数ユーザによる管理を行っている場合、ユーザごとにS3で行える操作の設定が行える。
また、ファイルやフォルダを外部に公開したり、アップロードを許可したりする際もパーミッションの設定が必要となる

手順
1. バケット、もしくはファイルを選択する
2. Propertiesを開き、Permissionを選択する
3. パーミッション編集操作を行う

Relational DBMS (RDS)

RDSという名前で提供される。
公式ページ

仕様

MySQL、Oracle、SQLServerが使用可能
Multi-AZ Deploymentという、自動で複数のAZにDBインスタンスを作成し、更にレプリケーションなども行われる機能がある
サブネットは指定できるが、固定IPアドレスは設定できない
EC2のようにインスタンスの停止はできない（mysqladminコマンドによる停止もできない）。停止を行いたい場合はスナップショットをとったうえで削除するしかない。
DBへのコネクションは作成できるが、SSHやPINGも含めてその他の一切のアクセスができない
インスタンスの作成に非常に時間がかかる（25分程度）。ただし、作成完了前の状態でも途中からDB接続できるようになってはいる。
Multi-AZ構成は通常のMaster-Slave構成とは異なり、データの同期のみが行われている状態で、Slaveプロセスが起動しておりSQLを転送しているのではない。
そのため、Slaveサーバはアクセスすることができず、Failover時も瞬時に切り替えが行われるわけではない。
Failoverを稼動系の再起動に伴い行うことができる。これはドメイン名(CNAME)の切り替えを行うことによって行われる。
ただし、待機系の稼動開始には、プロセス起動と（クラッシュによるFailoverか、手動Failoverかにかかわらず）クラッシュリカバリが行われるのでサービス断時間が数分発生する。
Failoverを伴わない再起動は単にプロセスの再起動が行われる
設定変更などで再起動が求められることがあるが、上記理由からFailoverを伴わない再起動の方が断時間が短くなる
インスタンスクラス変更時にはインスタンス稼働環境の移行が行われるため、必ず再起動相当の断時間が発生する

MySQL

マイナーバージョンに限り、自動でアップグレードされるよう設定可能
ストレージ容量、IOPS（I/O per Second）を指定可能

使用方法

コンソール
https://console.aws.amazon.com/rds/home

MySQL DBの作成

DB用のサブネットが未作成の場合、作成を行う
1. 管理メニューからSubnet Groupsを選択する
2. Create
3. VPCを選択し、VPC内のサブネットを最低２つ指定する
4. Yes, Createボタンをクリックする
DBMSの種類を選択する
製品用途かどうか選択する。Noを選択した場合、後の選択肢が限定されるので簡単に進められるが、通常はYesでよい。
インスタンスの詳細を入力する
1. ライセンスが複数ある場合は選択する
2. DBのバージョンを選択する
3. インスタンスのスペックを選択する
4. Multi-AZ構成にするかどうかを選択する
5. ストレージ容量を入力する
6. IOPSを指定するか、自動スケールアップするかどうかを選択する
7. DBインスタンスの識別子を入力する
8. 管理用のユーザ名、パスワードを入力する
追加の詳細設定を行う
1. DB名を入力する
2. ポート番号
3. インターネットからアクセス可能かどうか（デフォルトがアクセス可能であるので注意）
管理設定を行う
1. 自動バックアップを行うかどうか。行う場合、以下も設定する。
  1. バックアップの保存日数を選択する
  2. バックアップを行う時間を指定する場合、入力する
2. AWS側からDBにメンテナンスを行っても良い時間指定があれば、入力する

スナップショットの作成

スナップショットを作成すると、DBのデータに加え、
AWS上での設定項目のいくつかを保存したデータを作成できる。
スナップショットからDBをリストアすることで、元の状態に復元できる。
ただし、DB IDは既存のものが存在する場合は、同じものを使用できない。

手順
1. “Instances”ページからスナップショットを取得したいインスタンスを選択する
2. 右クリックメニューから”Take DB Snapshot”を選択する
3. スナップショットの名前を入力し、作成ボタンをクリックする

ログの確認（CUI）

RDSのログファイルを見る場合、サーバ自体にはアクセスできないので、専用のツールを使用する必要がある。
ただし、ログを閲覧など、標準ではインストールされていないコマンドがあるので、インストールする必要がある。

手順

認証設定を行う

Amazon RDS Command Line Toolkitをインストールする

Amazon RDS Command Line ToolkitのアーカイブファイルのURLを取得する

ツールをダウンロードする

wget http://s3.amazonaws.com/rds-downloads/RDSCli.zip

展開する
```
unzip RDSCli.zip
rm -f RDSCli.zip
```

環境変数が設定されているかを確認する

echo $AWS_RDS_HOME
# 出力されない場合、次を実行
export AWS_RDS_HOME=$AWS_PATH/apitools/rds

次回以降ログイン時に環境変数を設定する

vi /etc/bashrc

以下を記述する

export AWS_RDS_HOME=$AWS_PATH/apitools/rds

AWS用ディレクトリに移動する

ls -d RDSCli-*
# バージョンを調べる
# RDSCli-1.15.001

# 既に存在するバージョンか調べる
ls -d $AWS_PATH/apitools/rds-1.15.001
# /opt/aws/apitools/rds-1.15.001
# 上記のように表示された場合、存在するので、以降は不要
rm -rf $AWS_PATH/apitools/rds-1.15.001

mv RDSCli* $AWS_PATH/apitools/rds-1.15.001
rm -f $AWS_RDS_HOME
ln -s $AWS_PATH/apitools/rds-1.15.001 $AWS_RDS_HOME

バイナリファイルをAWS用のパスが通ったディレクトリにリンクする

# windows用コマンドを削除
rm -f $AWS_RDS_HOME/bin/*.cmd

ln -s $AWS_RDS_HOME/bin/* $AWS_PATH/bin/
# 既に存在するファイルはエラーが出るが無視する

environment.shをコピーする
environment.shファイルだけダウンロード版に存在しないので、コピーする
```
cp $AWS_PATH/apitools/rds-1.3.003/environment.sh $AWS_RDS_HOME/environment.sh
```

環境変数を設定する
1. 現在設定されているかを確認する
```
echo $EC2_REGION
# 出力されていなければ設定を行う
```
2. 現在のログインで使用できるように設定する
```
export EC2_REGION=ap-northeast-1
```
3. 次回以降ログイン時に環境変数を設定する
```
vi /etc/bashrc
```
  以下を記述する
```
export EC2_REGION=ap-northeast-1
```

以下コマンドを実行する

rds-watch-db-logfile <DB名> --log-file-name slowquery/mysql-slowquery.log

フェイルオーバーによるAZ変更

Multi AZを使用している場合、マスターのインスタンスは設定しているAZのいずれかで稼動する。
DBを利用するサーバがそのAZと異なるAZで稼動する場合、いくらかのAZ間通信のオーバーヘッドが発生してしまうため、DBとサーバのAZをそろえたい。
ただし、DBはAZを明示的に指定して起動できないため、フェイルオーバーを行うことで、AZの変更を行う。

手順
1. RDBコンソールを開く
2. Instances一覧からフェイルオーバーしたいインスタンスを選択する
3. Rebootを行い、その際「Reboot With Failover?」にチェックを入れる
4. 再起動が実行され、しばらくするとAZが変更される

タイムゾーン設定

RDBはrootユーザが使用できず、また、権限がないのでタイムゾーンの設定が行えない。
そのため、ストアドプロシージャを作成し、init_connectパラメータに設定して、
接続時に呼び出すことで、タイムゾーンの変更を行う。

手順
1. mysqlコマンドでDBに接続する
```
mysql -h <ホスト名> -u <ユーザ名> -p
```
2. 以下コマンドを実行する
```
DELIMITER |
CREATE PROCEDURE mysql.`set_time_zone`()
IF NOT (POSITION('rdsadmin@' IN CURRENT_USER()) = 1) THEN
SET SESSION time_zone = 'Asia/Tokyo';
END IF |
DELIMITER ;
```
3. パラメータを編集し、init_connectにCALL mysql.set_time_zone;を設定する
4. 対象となるパラメータを適用しているインスタンスを再起動する

VPC移動

RDBのインスタンスを別のVPCやAZに移動する。

手順
1. DBの更新を停止する
2. 対象のDBのスナップショットを作成する
3. 作成したスナップショットをリストアする
  その際、移動先のVPCを指定する

databaseの文字コード変更

パラメータで、character_set_databaseをUTF8系に変更しても
インスタンス作成時に同時に作成したDBはlatin1になってしまっている。
DBサーバにログインして、別途修正が必要。

手順
この手順ではutf8mb4に変更しているが、utf8等でも可。

mysqlコマンドでDBに接続する

mysql -h <ホスト名> -u <ユーザ名> -p

以下コマンドを実行する

# DEFAULT CHARACTER SET latin1 であることを確認
show create database <DB名>;

alter database <DB名> default character set utf8mb4;

# DEFAULT CHARACTER SET utf8mb4 であることを確認
show create database <DB名>;

メッセージQueueサーバ (SQS)

公式ページ
サーバ間のメッセージを非同期で行いたい場合に使用できるキューサーバ。
メッセージの保存と取得を行える。

必ずしもメッセージがFIFOで取得できるわけではない
メッセージ取得を行いキューが空の場合、空であることを即座に応答するショートポーリングと
しばらくメッセージがキューイングされるまでブロックされるロングポーリングが提供されている
以下のパラメータが存在する
- Visibility Timeout
  ある端末がキューからメッセージを受け取った後、別の端末からのそのメッセージの取得をブロックする時間。
  複数端末でキューを使用する際に重複してメッセージを取得して処理することを防ぐことができる。
  メッセージは取得と同時に消えないので、最初にメッセージを受け取った端末はVisibility Timeout時間内にメッセージを処理して削除する必要がある。
  設定可能な値は0秒から12時間。
- Message Retention Period
  削除されないままのメッセージをキューに残す時間。
  設定可能な値は1分から14日。
- Maximum Message Size
  １メッセージの最大サイズ。
  設定可能な値は1KBから256KB。
- Delivery Delay
  キューに追加したメッセージを、追加された直後から一定時間まで取得不可能にする時間。
  設定可能な値は0秒から15分。
- Receive Message Wait Time
  ロングポーリングでメッセージを取得する際に、キューが空の場合に応答を待つ時間。
  設定可能な値は0秒から20秒。

用語

Message ID

各メッセージに割り当てられる100文字以下のID。
クライアント側システムで使用するだけでメッセージをSQSに対して指定するときには使用できない。

Receipt Handles

SQS内部でメッセージを識別するための1024文字以下の文字列。
メッセージを削除するときなどで指定する。

使用方法

コンソール
https://console.aws.amazon.com/sqs/home

新規作成

Create New Queue
キューの情報を入力する
1. キューの名前を入力する
2. 各種パラメータを設定する
3. createボタンをクリックする

パーミッションの設定

キューに対して特定のAWSユーザが行える、メッセージの追加や削除などに対してパーミッションを設定する。

キューを選択する
パーミッションの種類をAllow/Denyから選択する
キューにアクセス可能/不可なAWSユーザを入力する
キューに対するアクション（追加や削除など）を選択する

アプリケーションからの使用

PHP

保存、取得、削除のサンプル

<?php
require_once('aws.phar');

const AWS_KEY = "XXXXXXXXXXXX";
const AWS_SECRET = "XXXXXXXXXXXXXX";
const SQS_URL = "https://sqs.ap-northeast-1.amazonaws.com/XXXXXXX";
const RECEIVE_COUNT = 10; // 1 - 10

$sqsClient = Aws\Sqs\SqsClient::factory(array(
		'key'    => AWS_KEY,
		'secret' => AWS_SECRET,
		'region' => Aws\Common\Enum\Region::AP_NORTHEAST_1,
));

// send messages
print("* Message Send Test\n");

$startTime = microtime(true);
for($i=1;$i<=1000;$i++)
{
	$messageID = $sqsClient->sendMessage(array(
			'QueueUrl' => SQS_URL,
			'MessageBody' => "message test $i",
	))['MessageId'];
	print("$i - MessageId : $messageID\n");
}
$endTime = microtime(true);
print("processing time = ".($endTime-$startTime)." seconds\n");
print("\n");

print("sleep ...\n");
sleep(5);
print("\n");

// receive messages
print("* Message Receive Test\n");
$cnt = 1;
while(true)
{
	$messages = $sqsClient->receiveMessage(array(
			'QueueUrl' => SQS_URL,
			'MaxNumberOfMessages' => RECEIVE_COUNT,
	))['Messages'];
	
	if($messages)
	{
		$deleteID = 1;
		$deleteMessagesArg = array();
		
		$count = count($messages);
		print("Message Count $count: \n");
		
		foreach($messages as $next)
		{
			$messageId = $next['MessageId'];
			$receiptHandle = $next["ReceiptHandle"];
			$body = $next["Body"];
			print("$cnt - MessageId : $messageId  /  Body : $body\n");
			$cnt++;
				
			$deleteMessagesArg[] = array("Id"=>$deleteID++, 'ReceiptHandle' => $receiptHandle);
		}
		
		// message must be deleted after got
		$sqsClient->deleteMessageBatch(array(
				'QueueUrl' => SQS_URL,
				'Entries' => $deleteMessagesArg
		));
		
		if($count != RECEIVE_COUNT)
			break;
	}
	else
		break;
}

print("Finish !\n");

Tips

パフォーマンスについて

PHPを使用して検証した。
保存に関して、mysqliを使用したRDSアクセスと比較したが、1000件の保存では
mysqli : 6～9秒
SQS : 16～25秒
とSQSが非常に遅い。（それぞれ10回試行。毎回データは消していない。）
SQSはグローバルアクセス+HTTPSがネックになっているのか、この性能差であれば、
非同期のSQSよりも同期のMySQLの方が良いようである。

DNS (Route53)

レジストラからドメインの取得は独自に行う必要がある

CDN (CloudFront)

CloudFrontという名前で提供される。
公式ページ

静的コンテンツを配信するキャッシュサーバである。
DNSサーバで問い合わせ元のIPから、そのIPから最も近いであろうサーバのIPを返す。
コンテンツのオリジンサーバとして別途S3やEC2などが必要となる。
配信に独自のドメイン名を使用できるが、別途設定が必要となる。
Route53で管理しているドメインのサブドメインも使用可能で、CloudFrontで設定したドメインをRoute53で別途登録する必要がある。

用語

ディストリビューション
CDNで使用する単位。
１つのディストリビューションに１つのドメイン名を対応付けてそのドメイン名によるアクセスへコンテンツを配信する。
詳細な設定もディストリビューション単位で行う。

仕様

HTTP(S)配信の他、RTMPを使用した配信も可能

使用方法

コンソール
https://console.aws.amazon.com/cloudfront/home

ディストリビューションの作成

“Create Distribution”をクリックする
コンテンツ配信のプロトコルを選択する。Web(HTTP(S))、RTMPが選択可能。
詳細情報を入力する
1. オリジンについての情報を入力する
  1. オリジンサーバのドメイン名を入力する
  2. “Origin ID”として、任意の識別子を入力する
  3. オリジンに対する以下の追加情報を入力する
    - オリジンサーバにS3を指定しなかった場合
      HTTPのみを使用するかどうか、ポート番号を指定する
    - オリジンサーバにS3を指定した場合
      バケットへのアクセスを明示的にしてせずとも全てCloudFront経由にするかどうかを入力する
2. キャッシュの動作についての設定を入力する
  1. HTTPのみにするか、HTTPSも許可するかを選択する
  2. 許可するプロトコロルを選択する
  3. コンテンツをキャッシュする時間を手動設定するかどうかを選択し、手動設定する場合はその時間を入力する
  4. クッキーを転送するかどうかを選択する
  5. クエリストリングを転送するかどうかを選択する
  6. 署名付きURLのみのアクセスを許可するかどうかを選択する
3. コンテンツ配信についての設定を入力する
  1. 配信地域を選択する
  2. （オプション）配信に使用する（CNAMEで使用する）ドメイン名を入力する
    Route53で管理するドメインのサブドメインを使用する場合は別途Route53でも登録を行う
  3. （オプション）URLのRoot（http://XXX/）で配信されるコンテンツのパスを指定する
  4. アクセスログを取得するかどうかを選択する
  5. （オプション）コメントを入力する
  6. CloudFrontを使用開始するかどうかを選択する
4. “Create Distribution”をクリックする

CloudWatch

公式ページ

CloudWatchはEC2やELBなどのリソースのモニタリング機能を提供する。
EC2やRDSでは標準で有効になっており、CPUやメモリ使用率を無料でモニタリングできる。
それらはEC2やRDSのそれぞれのコンソール画面から直接グラフを見ることができる。

用語

メトリックス
監視項目のこと。
標準で用意されているメトリックスと自分で定義するカスタムメトリックスがある。

使用方法(CLI)

事前準備

APIを使用するので、こちらで鍵などの設定を行う

ツールのアップグレード

現在のバージョン・リリース日を確認する
```
mon-version
```
最新版のリリース日をこちらで確認する
バージョンアップの必要があればダウンロードする
```
wget http://ec2-downloads.s3.amazonaws.com/CloudWatch-2010-08-01.zip
```

展開し、移動させる

unzip CloudWatch-*.zip
rm -f CloudWatch-*.zip
sudo su
mv CloudWatch-* $AWS_PATH/apitools/

windows用のコマンドは削除する

rm -f $AWS_PATH/apitools/mon-1.0.13.4/bin/*.cmd

リンクを再作成する

cd $AWS_PATH/apitools/
rm -f mon
ln -s mon-1.0.13.4 mon

実行パス内の古いファイルを置き換える

cd $AWS_PATH/bin/
# 正しく出力されることを確認する
ls -l | grep mon-1.0.13.4
ls -l | grep mon-1.0.13.4 | cut -d " " -f 11

# 削除する
ls -l | grep mon-1.0.13.4 | cut -d " " -f 11 | xargs rm -f

# リンクを作成する
ln -s $AWS_PATH/apitools/mon-1.0.13.4/bin/* .

バージョン・リリース日が更新されていることを確認する
```
mon-version
```

カスタムメトリックスの作成

カスタムメトリックスは自前で取得した値をCloudWatchへ送ることで実現することができる。
これはmon-put-dataにより実現することができる。
インスタンスIDが必要になるので、こちらを参考に、起動時にファイルに保存するようにしておく

書式

mon-put-data --metric-name <監視項目名> --namespace <監視項目グループ> --dimensions "InstanceId=<インスタンスID>" --value <値> [--unit <単位>]

サンプル

load average

mon-put-data --metric-name LoadAverage --namespace MY/EC2/WEB --dimensions "InstanceId=`cat /var/run/instance-id`" \
  --value `uptime | sed -e "s/.*load average: //g" -e "s/,.*//g"`

メモリ使用率

mon-put-data --metric-name MemoryUtilization --namespace MY/EC2/WEB --dimensions "InstanceId=`cat /var/run/instance-id`" --unit Percent \
  --value `expr 100 \* \`free | grep Mem | sed 's/\s\{1,\}/ /g' | cut -f 3 -d " "\` / \`free | grep Mem | sed 's/\s\{1,\}/ /g' | cut -f 2 -d " "\``

HTTPアクセス数

HTTP_REQUEST_COUNT_NOW=`/usr/sbin/apachectl status |& grep "accesses" | sed -e "s/.*accesses: //" -e "s/ .*//g"`
if test -e /var/log/http-request-count ; then
	HTTP_REQUEST_COUNT_PAST=`cat /var/log/http-request-count`;
	if [ "$HTTP_REQUEST_COUNT_PAST" = "" ]; then
		HTTP_REQUEST_COUNT=0
	elif [ "$HTTP_REQUEST_COUNT_NOW" = "" ]; then
		HTTP_REQUEST_COUNT=0
	else
		HTTP_REQUEST_COUNT=`expr "$HTTP_REQUEST_COUNT_NOW" - "$HTTP_REQUEST_COUNT_PAST" - 1`
		if [ "$HTTP_REQUEST_COUNT" -lt 0 ]; then
			HTTP_REQUEST_COUNT=0
		fi
	fi
else
	HTTP_REQUEST_COUNT=0
fi
$AWS_PATH/bin/mon-put-data --metric-name RequestCount --namespace MY/EC2/WEB --dimensions "InstanceId=`cat /var/run/instance-id`" --unit Count --value $HTTP_REQUEST_COUNT
echo $HTTP_REQUEST_COUNT_NOW > /var/log/http-request-count

※Cronで実行する場合はApacheの起動スクリプトに以下を追記する。

sudo vi /etc/init.d/httpd

# start() {～} の中に次を記述
# rm -f /var/log/http-request-count

ディスク使用率

df -h | egrep -v "^Filesystem" | while read line; do
	disk=`echo $line | cut -f 1 -d " "`
	usage=`echo $line | cut -f 5 -d " " | sed "s/%//"`
	$AWS_PATH/bin/mon-put-data --metric-name "DiskUsage($disk)" --namespace MY/EC2/WEB --dimensions "InstanceId=`cat /var/run/instance-id`" --value $usage
done

cronに登録（毎分実行）

rootになる
```
sudo su
```

スクリプトを作成

vi /usr/local/bin/put-cloudwatch.sh

以下のように記述する

export EC2_REGION=ap-northeast-1
export JAVA_HOME=/usr/lib/jvm/jre
export AWS_PATH=/opt/aws
export AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon
export AWS_CREDENTIAL_FILE=$AWS_PATH/secrets/AWSAccessKey-XXX
export EC2_PRIVATE_KEY=$AWS_PATH/secrets/pk-XXX.pem
export EC2_CERT=$AWS_PATH/secrets/cert-XXX.pem

$AWS_PATH/bin/mon-put-data ～～～

パーミッションを変更

chmod 744 /usr/local/bin/put-cloudwatch.sh

cronにスクリプトを登録

vi /etc/cron.d/monitor
# 以下を記述して保存
* * * * * root /usr/local/bin/put-cloudwatch.sh

値の確認

mon-get-stats <メトリック名> --namespace <ネームスペース> -s <統計方法> --dimensions "InstanceId=<インスタンスID>"

統計方法では次の値が取得できる。

Average
Sum
SampleCount
Maximum
Minimum.

VPN

公式ページ

用語

Virtual Private Gateway
VPN接続のAmazon側にある仮想VPN装置のこと

Customer Gateway
VPN接続のユーザー側にある物理的なデバイスまたはソフトウェアアプリケーションのこと

VPN Connection
Virtual Private GatewayとCustomer Gateway間の１つのVPNリンクのこと

仕様

スタティックルーティングと、ダイナミックルーティングが可能
ダイナミックルーティングにはBGPが必要

使用方法

コンソール（Virtual Private Gateway）
https://console.aws.amazon.com/vpc/home?region=ap-northeast-1#s=vpn-gateways

コンソール（Customer Gateway）
https://console.aws.amazon.com/vpc/home?region=ap-northeast-1#s=customer-gateways

コンソール（VPN Connection）
https://console.aws.amazon.com/vpc/home?region=ap-northeast-1#s=vpn-connections

Virtual Private Gatewayの作成

“Create Virtual Private Gateway”ボタンをクリックする
作成されたVirtual Private Gatewayを選択し、VPCにAttachする

Customer Gatewayの作成

“Create Customer Gateway”ボタンをクリックする
ルーティング方法をStaticかDynamicか選択する
- Staticの場合、Customer Gatewayとして使用するホストのグローバルIPアドレスを入力する
- Dynamicの場合、Customer Gatewayとして使用するホストのグローバルIPアドレスとAS番号（プライベート可）を入力する

VPN Connectionの作成

“Create VPN Connection”ボタンをクリックする
接続するVirtual Private GatewayとCustomer Gatewayを選択する
Staticルーティングを行う場合、Customer Gateway側のローカルネットワークアドレスを入力し、Addをクリックする
Createする
作成したVPN Connectionが使用可能となるまで待つ
作成したVPN Connectionを選択し、”Download Configuration”を行う
使用するCustomer Gatewayの情報を選択し、Configurationをダウンロードする
ダウンロードしたConfigurationを機器に投入する。
この時、通常そのまま投入すればよいが、Tunnelインタフェースの番号やIPsecのパラメータなど、
グローバルコンフィギュレーションは既存設定と重複しないか確認する必要がある。
Route Tableを開き、VPN Connectionで利用するネットワークアドレス宛のルーティングをVirtual Private Gatewayへ向ける

Cisco IOSコンフィグレーション例
次のようなコンフィグがダウンロードされる。
IPsecトンネルが２つ作成されるよう設定が行われるが、冗長用なので１つだけでもVPNは使用できる
- isakmp policy
  既存のポリシー番号と重複しないように注意
```
crypto isakmp policy 2
  encryption aes 128
  authentication pre-share
  group 2
  lifetime 28800
  hash sha
exit
```

ipsecパラメータ

! df(Don't fragment) bitを無効にする。通常入れておけばよい。
crypto ipsec df-bit clear
! isakmpのkeepalive。既存の設定があるなら不要。
crypto isakmp keepalive 10 10 on-demand
! IPsecのリプレイ攻撃防止の検知シーケンスサイズ。デフォルト1024より小さいので、通常不要。
crypto ipsec security-association replay window-size 128
! フラグメンテーションを暗号化前に行うようにする。通常入れておけばよい。
crypto ipsec fragmentation before-encryption

１つ目のトンネルで使用するIPsec設定

crypto keyring aws-vpn-1-key
  local-address <IPアドレス or インタフェース名>
  pre-shared-key address <AWSのIP> key <キーの値>
exit

crypto isakmp profile aws-vpn-1-isakmp-profile
  local-address <IPアドレス or インタフェース名>
  match identity address <AWSのIP>
  keyring aws-vpn-dev-1-key
exit

crypto ipsec transform-set aws-vpn-1-transform-set esp-aes 128 esp-sha-hmac 
  mode tunnel
exit

crypto ipsec profile aws-vpn-dev-1-ipsec-profile
  set pfs group2
  set security-association lifetime seconds 3600
  set transform-set aws-vpn-dev-1-transform-set
exit

! 既存のインタフェース番号と重複しないように注意
interface Tunnel11
  description ### AWS VPN TUNNEL ###
  ip address <169.254.のリンクローカルアドレス> 255.255.255.252
  ip virtual-reassembly
  tunnel source <IPアドレス or インタフェース名>
  tunnel destination <AWSのIP>
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile aws-vpn-dev-1-ipsec-profile
  ! This option causes the router to reduce the Maximum Segment Size of
  ! TCP packets to prevent packet fragmentation.
  ip tcp adjust-mss 1387 
  no shutdown
exit

１つ目のトンネルのルート監視設定
VPNトンネルの対向にPINGしてAWSのVPC宛のルーティングの監視を行う。
インタフェースがUPしたまま疎通不能となったときに、ルーティングテーブルから
削除できるが、他の代替ルートが無い場合や監視にリソースを使いたくない場合は、特に監視しなくても良い。
監視しない場合でもスタティックルートと、そのルートの優先度の設定は行う。
```
ip sla 11
   icmp-echo <169.254.の対向リンクローカルアドレス> source-interface Tunnel11
   timeout 5000
   frequency 5
exit

ip sla schedule 11 life forever start-time now
track 11 ip sla 11 reachability

ip route 10.0.0.0 255.255.0.0 Tunnel11 track 11

! 監視しない場合
! ip route 10.0.0.0 255.255.0.0 Tunnel11 50
```

２つ目のトンネルで使用するIPsec設定

crypto keyring aws-vpn-dev-2-key
  local-address <IPアドレス or インタフェース名>
  pre-shared-key address <AWSのIP> key <キーの値>
exit

crypto isakmp profile aws-vpn-dev-2-isakmp-profile
  local-address <IPアドレス or インタフェース名>
  match identity address <AWSのIP>
  keyring aws-vpn-dev-1-key
exit

crypto ipsec transform-set aws-vpn-dev-2-transform-set esp-aes 128 esp-sha-hmac 
  mode tunnel
exit

crypto ipsec profile aws-vpn-dev-2-profile
  set pfs group2
  set security-association lifetime seconds 3600
  set transform-set aws-vpn-dev-2-transform-set
exit

! 既存のインタフェース番号と重複しないように注意
interface Tunnel12
  description ### AWS VPN TUNNEL ###
  ip address <169.254.のリンクローカルアドレス> 255.255.255.252
  ip virtual-reassembly
  tunnel source <IPアドレス or インタフェース名>
  tunnel destination <AWSのIP>
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile aws-vpn-dev-2-profile
  ip tcp adjust-mss 1387 
  no shutdown
exit

２つ目のトンネルのルート監視設定
VPNトンネルの対向にPINGしてAWSのVPC宛のルーティングの監視を行う。
インタフェースがUPしたまま疎通不能となったときに、ルーティングテーブルから
削除できるが、他の代替ルートが無い場合や監視にリソースを使いたくない場合は、特に監視しなくても良い。
監視しない場合でもスタティックルートと、そのルートの優先度の設定は行う。
```
ip sla 12
   icmp-echo 169.254.252.29 source-interface Tunnel12
   timeout 5000
   frequency 5
exit

ip sla schedule 12  life forever start-time now
track 12 ip sla 12 reachability 

! 監視しない場合
ip route 10.0.0.0 255.255.0.0 Tunnel12 70
```

Hadoopクラスタ (Elastic MapReduce)

sshログインする際はhadoopユーザで行う
```
ssh <接続先> -l hadoop
```

新規サービス構築フロー

標準的なWEBサービスの構築フローを記載する。
構成は以下のとおりである。

VPCの作成

使用するレンジを決める
リージョンを選択し、VPCを作成する
サブネットを作成する
使用するルーティングテーブルを選択し、不要なものは削除しておく
ルーティング追加が必要な場合は併せて行う

Tips

固定Private IPの割り当て

インスタンス作成時にSubnetを指定すると、IPアドレスを指定するテキストフィールドが現れる。
そこに任意の値を入力することで、固定IPが使用可能となる。
ただし、先頭の4アドレス、最後の1アドレスはAmazon側で使用するため割り当て不可。

VPCネットワークの拡張

できない。
再度作成しなおす必要がある。

初期化

root化
```
sudo su
```

タイムゾーン変更

\cp -f /usr/share/zoneinfo/Japan /etc/localtime

既存パッケージアップデート
```
sudo yum update
```
volumeの拡大
インスタンス作成時に設定したディスク容量よりも少ない場合、ボリュームの拡大を行う
- 確認
```
df -h
```
- 設定
```
resize2fs /dev/xvda1
```
rootパスワード設定
```
passwd
```
再起動
```
reboot
```

? SELinuxのインストール
```
yum install *selinux*
```

API

準備

APIを使用する場合、使用するサーバに認証用のファイルを設定する必要がある。

手順
1. rootになる
```
sudo su
```
2. key保存場所を作成する
```
mkdir $AWS_PATH/secrets
```
3. Security Credentialにアクセスする
4. Access Keysを設定する
  1. Access Keysを作成してキーをダウンロードする
  2. テキストファイルでキーを開き、中身をコピーする
  3. Auto Scalingの設定を行うインスタンスにログインし、任意の場所に同じ内容のキーファイルを作成する
```
vi $AWS_PATH/secrets/AWSAccessKey-<Access Key ID>
```
  4. キーファイルのパスを環境変数として設定する
```
export AWS_CREDENTIAL_FILE=$AWS_PATH/secrets/AWSAccessKey-<Access Key ID>
```
5. X.509 Certificatesを設定する
  1. X.509 Certificateを作成してPrivate Key File、X.509 Certificateファイルをそれぞれダウンロードする
  2. Private Key Fileファイルを開き、中身をコピーする
  3. Auto Scalingの設定を行うインスタンスにログインし、任意の場所に同じ内容のファイルを作成する
```
vi $AWS_PATH/secrets/pk-<Thumbprint>.pem
```
  4. Private Key Fileファイルのパスを環境変数として設定する
```
export EC2_PRIVATE_KEY=$AWS_PATH/secrets/pk-<Thumbprint>.pem
```
  5. X.509 Certificateファイルを開き、中身をコピーする
  6. Auto Scalingの設定を行うインスタンスにログインし、任意の場所に同じ内容のファイルを作成する
```
vi $AWS_PATH/secrets/cert-<Thumbprint>.pem
```
  7. X.509 Certificateファイルのパスを環境変数として設定する
```
export EC2_CERT=$AWS_PATH/secrets/cert-<Thumbprint>.pem
```
6. アクセス権を変更する
```
chmod 444 $AWS_PATH/secrets/*
```
7. ログイン時に環境変数を設定する
```
vi /etc/bashrc
```
  以下を記述する
```
export AWS_CREDENTIAL_FILE=$AWS_PATH/secrets/AWSAccessKey-<Access Key ID>
export EC2_PRIVATE_KEY=$AWS_PATH/secrets/pk-<Thumbprint>.pem
export EC2_CERT=$AWS_PATH/secrets/cert-<Thumbprint>.pem
```

AWS コマンドラインインターフェイス (AWS CLI)

EC2やELBなど一部のコンポーネントは専用のツールが用意されているが、S3などは用意されていない。
そういった場合、AWS全コンポーネントに対してのCLIツール”AWS コマンドラインインターフェイス”を使用する。
ただし現在ではAWS CLIを使用してEC2等含む全サービスを操作するのが主流である。

公式ページ
http://aws.amazon.com/jp/cli/

準備

インストール
Amazon AMIでは既にAWS CLIはインストールされているが、そうでない場合は新規にインストールする必要がある。

pythonのインストール
```
yum install python
```
python pipのインストール
```
yum install python-pip
```
AWS CLIのインストール
```
pip install awscli
```

アップグレード
AWS CLIは常に最新版を使用すべきである。
最新版はリファレンスにて確認可能である（ページタイトル部参照）。

現在のバージョンを確認する
```
aws --version
```

python pipのインストール

yum list installed | grep python-pip
# インストールされていなければインストールする
yum install python-pip

バージョンアップを行う
```
pip install --upgrade awscli
```

リージョンの設定

リージョンの環境変数を設定する
```
export AWS_DEFAULT_REGION=ap-northeast-1
```

自動設定を行う

vi /etc/bashrc
# 以下を記述する
export AWS_DEFAULT_REGION=ap-northeast-1

共通オプション

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/index.html

出力形式

書式
```
--output <形式>
```
- 形式
  - json
  - text
  - table

EC2

書式
```
aws ec2 <サブコマンド>
```

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html

情報表示

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html

すべて表示

aws ec2 describe-instances --output text

インスタンスIDで検索

aws ec2 describe-instances --instance-ids <ID>

条件で検索

aws ec2 describe-instances --filters "Name=<検索対象>,Values=<検索値>"

名前で検索

aws ec2 describe-instances --filters "Name=tag:Name,Values=<名前>"

ステータス表示

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-status.html

すべて表示

aws ec2 escribe-instance-status --output text

インスタンスIDで検索

aws ec2 escribe-instance-status --instance-ids <ID> --output text

インスタンス起動

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html

aws ec2 start-instances --instance-ids <インスタンスID>[ ...]

インスタンス停止

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html

aws ec2 stop-instances --instance-ids <インスタンスID>[ ...]

S3

書式
```
aws s3 <サブコマンド>
```

リファレンス
https://docs.aws.amazon.com/cli/latest/reference/s3/index.html

使用方法
s3でファイルを指定する場合、以下のようにパスを指定する
```
s3://<バケット名>/<フォルダ>/<ファイル>
```
また、設定したアクセスキーの所有者によるパーミッションが捜査対象バケット・ファイルに必要

ヘルプを確認する
```
aws s3 help
```

バケット一覧を確認する
```
aws s3 ls
```

ファイル一覧を取得する
```
aws s3 ls s3://<パス>
```

ファイルをコピーする
```
aws s3 cp <コピー元> <コピー先>
```

EC2 API Tools

EC2専用のコマンドラインツール。現在ではAWS CLIを使うのが主流で、こちらは使用しない。

アップグレード

現在のバージョン・リリース日を確認する
```
ec2-version
```
最新版のリリース日をこちらで確認する
バージョンアップの必要があればダウンロードする
```
wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
```

展開し、移動させる

unzip ec2-api-tools.zip
rm -f ec2-api-tools.zip
sudo su
mv ec2-api-tools-* $AWS_PATH/apitools/

windows用のコマンドは削除する

rm -f $AWS_PATH/apitools/ec2-api-tools-1.6.12.0/bin/*.cmd

リンクを再作成する

cd $AWS_PATH/apitools/
rm -f ec2
ln -s ec2-api-tools-1.6.12.0 ec2

実行パス内の古いファイルを置き換える

cd $AWS_PATH/bin/
# 正しく出力されることを確認する
ls -l | grep ec2-1.6.8.1
ls -l | grep ec2-1.6.8.1 | cut -d " " -f 11

# 削除する
ls -l | grep ec2-1.6.8.1 | cut -d " " -f 11 | xargs rm -f

# リンクを作成する
ln -s $AWS_PATH/apitools/ec2-api-tools-1.6.12.0/bin/* .

バージョン・リリース日が更新されていることを確認する
```
ec2-version
```

インスタンス一覧の表示

ec2-describe-instances --region ap-northeast-1

必ずリージョンをつける必要がある。
vオプションをつけることでXML出力が付加される。

ec2-describe-instances --region ap-northeast-1 -v

aliasを設定し、リージョンを自動設定することも出来る。

alias ec2-describe-instances-ap-northeast-1='ec2-describe-instances --region ap-northeast-1'

再起動時も有効なようにbashrcファイルにも記述しておく。

vi /etc/bashrc

RDS Command Line Toolkit

RDS専用のコマンドラインツール。現在ではAWS CLIを使うのが主流で、こちらは使用しない。

インスタンス一覧の取得

rds-describe-db-instances

ログの確認

slow query log

rds-watch-db-logfile <DB名> --log-file-name slowquery/mysql-slowquery.log

メタデータの取得

EC2ではリンクローカルアドレス宛にHTTPでインスタンスIDなど自身の情報を取得することができる。

URL

http://169.254.169.254/latest/meta-data/<データID>

ターミナルに表示

wget -q -O - http://169.254.169.254/latest/meta-data/<データID>

ファイルに保存

wget http://169.254.169.254/latest/meta-data/<データID> -O /var/run/<データID>

データID
- インスタンスID
```
instance-id
```
- プライベートIPv4
```
local-ipv4
```
- AMI ID
```
ami-id
```
- ブロックデバイスのパス割り当て
```
block-device-mapping/XXX
```
- ホスト名
```
hostname
```
- インスタンスタイプ
```
instance-type
```
- カーネルID
```
kernel-id
```
- プライベートネットワーク用ホスト名
```
local-hostname
```
- MACアドレス
```
mac
```
- availability zone
```
placement/availability-zone
```
- 仮想タイプ
```
profile
```
- パブリックネットワーク用ホスト名
```
public-hostname
```
- パブリックIPv4
```
public-ipv4
```
- 公開鍵名
```
public-keys/
```
- reservation id
```
reservation-id
```
- セキュリティグループ
```
security-groups
```

AWS SDK for PHP

公式:http://docs.aws.amazon.com/aws-sdk-php/guide/latest/index.html
参考:http://docs.aws.amazon.com/aws-sdk-php/latest/

インストール

いくつかの方法が用意されている
http://docs.aws.amazon.com/aws-sdk-php/guide/latest/installation.html

ダウンロードして配置
ダウンロードして任意の位置に配置する
http://pear.amazonwebservices.com/get/aws.phar