![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
サーバーインスタンスだが、他のサービスもEC2ベースとしており、AWSの基本中の基本サービス。
| EC2 | サーバー本体 |
| EBS | ディスク |
| ENI | ネットワークインターフェース。１つのEC2に複数アタッチ可能だが、最初のENIのIPは固定になるので、作成時に指定し忘れるとDHCPの割当となる。なおEC2からデタッチして、別のEC2にあタッチできる(IPの引き継ぎ) |
起動、停止、terminateは削除なので間違わないように
インストール後に実行するコマンド。base64エンコード
sudo yum install -y java-1.8.0-openjdk-devel
#!/bin/bash sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" sudo sh -c "echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects" sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 目的のIP:目的のポート sudo iptables -t nat -A POSTROUTING -j MASQUERADE sudo service iptables save
Elastic Block Storeの略。スナップショット機能など多彩な機能がある。通常インスタンスストレージは停止したら消えるのであまり使わずEBSがEC2のメインストレージとなるだろう。EBSは同一AZでのインスタンスにしかアタッチできない。スナップショットから別AZへコピーできる
GP2は容量を増やすとパフォーマンスが伸びる。Provisioned IOPSは自分でパフォーマンスを指定できるが、増やしすぎると値段が上がるので注意。
マシンのOSイメージのこと。マイクロインスタンスであれば、RHELもWindowsも無料の枠内に収まるとのこと。「free tier eligible」とあればマイクロインスタンスとの組み合わせで無料。自分でAMIを作ることが可能で、実用上は公式提供のAMIをカスタマイズして自分のシステムのベースを作る。仮想マシンの方式がhvmとparavirtualがあるが、今後の主流はhvmであるのでhvmベースで作成すべし！
起動時に設定などを実施できるcloud-init(yml)かシェルスクリプトを設定できる。APIからも設定可能。
#!/bin/bash #TIMEZONE JST /bin/cp -f /usr/share/zoneinfo/Asia/Tokyo /etc/localtime yum install -y postfix yum install -y mysql-server yum install -y nginx # start service /etc/init.d/postfix start /etc/init.d/mysqld start /etc/init.d/nginx start # enable service auto start chkconfig --level 345 postfix on chkconfig --level 345 nginx on chkconfig --level 345 mysqld on
無料枠を超えないようにインスタンスはT2.micro、その他はデフォルトで進める。秘密鍵のペアはpemファイルとなるが、puttygenでインポートしてからputty形式のファイルにして、ec2-userでログイン成功
| 名称 | 備考 |
| t1,t2 | CPUがバースト可能。しかし低コストなので常時CPUが必要ならC1,C2を |
| c1,c2 | CPUに重点を置いたタイプ。 |
| r3 | データベース向け |
静的なIPでインスタンスにひもづけることができる。起動していないインスタンスにEIPを確保しておくと課金対象。ここを見るとPrivate IPとの紐づけも見られる。 一応使わないでも再起動しなければ起動時に動的に割り当てられたpublic IPでアクセスできる。PublicIPの自動割り当て機能は起動時のみ利用出来る為、起動後に付与したくなった場合にはEIPを利用する必要がある。
Elastic Load Balancing。インスタンスを複数ぶら下げて振り分ける。異常からの復帰時はデフォルトだと最低300秒かかるので気長にまつか、設定を変更する。それぞれのAZで等しい台数とスペックをぶら下げるのが基本。
名前解決はpublicなDNSで行うため、利用側にインターネット接続必要。またスケールアップ時にIPが変わるため、直接IPでアクセスしてはいけない。
ELBのスケールアップ・スケールアウトはAWS側で勝手にやってくれる。配下でインスタンスが全滅していると勝手に一個になる。復帰すると2個になる。apache benchをやり続けるとそのIPだけタイムアウトになってしまう！なにか見ているのかも？
こちらで負荷監視する項目はCloudWatchから取得できる処理数や処理待ちなどのデータ。
クラウド時代にはあまり好ましくはないが、特定のサーバーに振り分けるスティッキーセッションの設定もできる。ELBの説明欄から維持設定をクリック
HTTP_X_FORWARDED_FOR HTTP_X_FORWARDED_PORT HTTP_X_FORWARDED_PROTO
所属するサブネットに最低8IPの空きが必要。
負荷状況に合わせて増やしたり、一定数以上の稼働を保証させることができる仕組み。もととなるAMIを使って起動するので、そのAMIを作成しておく。起動設定でアプリのデプロイをしてELBに関連づけ(AutoScaleの設定画面から既存ELBを選択)しておくとよい。
インスタンス単位で設定。サブネット単位で設定するACLよりもよく使われる。セキュリティGを持つものを許可するという設定があり、デフォルトSGを許可しておけば内部通信は問題なくなる。ネットワークACLと違ってステートフルなので、INが許可されていれば、OUTは拒否されていても大丈夫（SSHのクライアントポートが10000以上でも22のINが許可されているので問題なし。ネットワークACLだとステートレスなのでNGとなる。）
同じインスタンスにアクセスする場合PrivateIP指定の場合は内回りとなり、SGのアクセス元としてSGを持っていることが指定できる。Global IPを指定した場合は外回りのアクセスとなり、一般的なIP制限と同じようにIP指定で許可しないとつながらない。
基本的にプライベート内部は全部の通信が許可されるデフォルトSGが存在する。
特に支障がない限りこれを各インスタンスにつけておくことをお勧めする。 デフォルトSGを持っているのものを全部許可する設定になっているので
サブネット単位で設定するが、ポート単位で指定すると動的にポートが変わるものがブロックされてしまうので、ポートでは絞らずに、送信元IPで制限するのがよい。
固定PrivateIPだと既存EC2消さないとダメ
これは複製ではなく障害復旧だな。
上記2パターンがうまくいかないときの最終手段。
