# Amazon Web Services
AWSの情報について調査してわかったことをまとめておく。

# EC2
## Public IP(≠Elastic IP)は、instance stopしてstartしても、「Public IPを割り当てる設定」は引き継がれる模様
- つまり、Public IPそのものは初回起動時とは別のものが割り当てられる可能性がある
- 同じPublic IPを割り当てたいなら、Elastic IPを使えということだと思う、たぶん

## Elastic IPはデフォルトで5つまでしか取得できない
- 仮に5つ以上のグローバルアドレスが必要になった場合は、Amazonに対して解除申請をする必要がある
- ちなみに、VPCとEC2でそれぞれで5つずつ取れる模様
- 関連URL
 - https://aws.amazon.com/jp/contact-us/eip_limit_request/

## SMTPでのメール送信に制限値が設定されている
- らしいので、EC2から外部へメールを送信する際は要注意
- 関連URL
 - http://frmmpgit.blog.fc2.com/blog-entry-107.html

## CUIで叩くツール関係
### aptでインストールする方法
- http://qiita.com/EugeneAshizawa/items/216e0f8b69f20d5b07d3

### APIでアクセスするために設定する必要があること
+ 鍵、証明書を作成する
 - http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_UploadCertificate.html
 - 鍵、証明書をopensslコマンドで作成する方法が記載されている
+ 生成した証明書をIAMに登録する
+ APIでアクセスするマシンに、以下の環境変数を設定する
 - 例
```
EC2_CERT=/home/ubuntu/rufeinadmin-cert.pem
EC2_PRIVATE_KEY=/home/ubuntu/rufeinadmin-privkey.pem
EC2_URL=http://ec2.ap-northeast-1.amazonaws.com
```

## Elastic Block Store(EBS)関係
### インスタンスのroot deviceは、インスタンスをstop状態にすればdetach/attach可能
- EC2のVolumes管理画面からdetachして、attachすればOK

### 動作中のインスタンスからsnapshot/AMIを作成して、新規インスタンスを起動した場合は起動できなさそう？？ *(調査中)*
- 作成したAMIを基にインスタンスを作成して「Get System Log」を見ると、Kernel panicが発生し起動できなかった
- 調査中

## 一度インスタンスに紐づけたIAM roleは、launch後変更できない
- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
- OpsWorksなどインスタンスの管理までやってくれるものを使っているときは、紐づけたIAM roleをlaunch後削除しないよう注意が必要!!


## Security Groups 関係
- http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
 - VPCに紐付く
 - deny のルールは書けない
 - inbounds で張られたコネクションでの復りは、無条件で allow (statefulでフィルタが勝手に開く)
 - outbounds も然り
 - outbounds にルールを一つも書かない場合、パケットが一切外に出せなくなる
 - マニュアルには全パケットが allow になると記載されているが、たぶんウソ

# Elastic Load Balancing(ELB)
## Availability ZoneとELBに割り当てられるグローバルアドレス
- ELBに割り当てられるグローバルアドレスは、Availability Zoneごとに1つ割り当てられるらしい
 - 1つのELB配下に2つの別ゾーンにあるインスタンスが登録されている場合、2つのグローバルアドレスが返される
- 関連URL
 - http://www.dondari.com/index.php/Elastic_Load_Balancing%E3%81%A8Availability_Zone

## Pre-warming申請
- Pre-warming申請とは、ELBのスケールをAmazonに事前に行ってもらうための申請
 - ELBはトラフィック量に応じて自動的にスケールしてくれるが、瞬間的にトラフィックが増加する場合にELBのスケールが間に合わ ず、一時的にトラフィックが捌けなくなる可能性がある
 - これを防ぐために、瞬間的なトラフィック増加が予測される場合は予めPre-warming申請を行える
- ただし、Pre-warmingの申請には、Business/Enterpriseサポートが必要らしい…
- 関連URL
 - http://ttcloud.net/aws/ec2/elb/20110211/626
 - http://kunihikokido.tumblr.com/post/55654918757/pre-warming

## Multi-AZ(Availability Zone)環境におけるBest Practice
- が紹介されていた
 - http://support.rightscale.com/09-Clouds/AWS/02-Amazon_EC2/Designing_Failover_Architectures_on_EC2/00-Best_Practices_for_using_Elastic_IPs_%28EIP%29_and_Availability_Zones

## 一度「Out of Service」となったインスタンスは、単純に立ち上げ直しただけでは「In Service」にならない
- ELB -> インスタンスの疎通が通らなくなった後は、インスタンスを単純に立ち上げただけじゃLBが立ち上がったことを認識してく れない
 - AWS ELBが応答ファイルが存在しEC2インスタンス起動しているのにOut Of Serviceとなる場合の対処
 - http://tech.guitarrapc.com/entry/2013/08/13/220859
- 一旦、LBのメンバから外して、再度追加するとちゃんと「In Service」に切り替わる

## ヘルスチェック用のURLから返ってきた応答で200以外のものは、全て異常状態とみなされる
- http://docs.aws.amazon.com/ja_jp/ElasticLoadBalancing/latest/DeveloperGuide/ts-elb-healthcheck.html
 - 302も従ってくれない

# VPC
## VPC配下に置くインスタンスのIPアドレス
- privateなsegmentにいるインスタンスに付与するIPアドレスは、DHCPで付加する
 - インスタンス作成時のみ、Web上のコントロールパネルで付与するIPアドレスをコントロールできる
 - 各インスタンスに紐づくNIC(ENI)のMACアドレスと付与するIPアドレスを、DHCPサーバ側でコントロールしている模様

## サブネット削除時の注意点
- 削除するサブネットに属するIPアドレスを持ったインスタンスが全部なくなっている状態じゃないと削除できない
 - インスタンスをterminateし終わるのにしばらく時間がかかるので、実質的にすぐに削除できないので要注意

## ELBが置かれるセグメントは、最低/25必要
- ELBが足を出すセグメントの利用可能IPアドレスに最低123個必要らしい
- 関連URL
 - http://blog.suz-lab.com/2012/01/vpcsubnetelbavailability-zone.html
 - http://blog.cloudpack.jp/2012/01/aws-news-vpc-subnet-elb-available-zone.html

## ELBにprivateなsubnet上のEC2インスタンスのLBをやらせる場合
- インスタンスと同じsubnet上にELBの足を生やしてもダメ
 - 外からELBへのアクセスもその足が使われるため、privateなsubnetだと外への到達経路がない
 - privateなsubnet = subnetに紐づくルーティングテーブルのデフォゲが、Internet Gatewayではない
- 対策として、対象のインスタンスがいるゾーンと同じゾーンで別にpublicなsubnetを作り、そこにELBの足を生やす
 - publicなsubnet = subnetに紐づくルーティングテーブルのデフォゲが、Internet Gatewayである
- 関連URL
 - https://github.com/mechamogera/MyTips/wiki/VPC%E3%81%A7ELB%E3%81%ABPrivate-Subnet%E3%81%AEEC2%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%82%92%E7%B4%90%E4%BB%98%E3%81%91%E3%82%8B

# Elastic Beanstalk
## 複数のenvironment間でアプリを公開しているURLを入れ替えることができる
- メンテナンス、バージョンアップの際に無停止で入れ替えられるといいよね
- 関連URL
 - http://www.slideshare.net/AmazonWebServicesJapan/getting-startedwithbeanstalk-20130111

## Custom AMIの作り方
- 関連URL
 - http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.customami.html
 - http://d.hatena.ne.jp/j3tm0t0/20120404/1333539328
 - http://stackoverflow.com/questions/12002445/customizing-an-elastic-beanstalk-ami

### Amazon Linuxへ最新版のnginxをインストールする
- 関連URL
 - http://www.presentation.bz/26
 - CentOS用のyumリポジトリを入れて、インストールすればOKそう

## Environmentを作るときは、作られるEC2インスタンスからインターネットへの接続性がないとダメらしい…
- じゃないと、起動時に自動設定するスクリプトを落としてこられない…

# OpsWorks
## Lifecycle
- http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-events.html
- Shutdownはリクエストしてから45秒待つらしい
 - Shutdownに登録されたレシピを実行するために待ってくれる

## Layer/Instance周り
### Instanceを立ち上げるときはインターネット接続性がないとコケる
- NAT経由でアクセスする場合は、NAT-boxのSecurity Group設定に要注意！
 - OpsWorksで立ち上げるインスタンスに紐づくSecurity Groupからの%%全アクセス%%を許容しておく必要がある
 - outbound 80/tcp, 443/tcpだけでOKそう
- 一度初期化(cloud-init)にコケたら、もう一回インスタンスを作り直す必要がある
- http://docs.aws.amazon.com/opsworks/latest/userguide/workingstacks-vpc.html
 - 以下の記述が当該部分

```
Working with private resources

The private subnet isolates the instances from Amazon EC2 direct user access, but they must still send outbound requests to AWS and the appropriate Linux package
repositories. To allow such requests you can, for example, use a network address translation (NAT) instance with its own Elastic IP address and then route the
instances' outbound traffic through the NAT. You can put the NAT in the same public subnet as the load balancer, as shown in the preceding example.
```
### 「Root device type」で「Instance store」を選択した場合、後からt1.microへ変更することができない
- t1.microは「EBS backed」でしか動かすことができないため
- 「Root device type」は、インスタンス作成後に変更することが不可能

### ~~Load-based instanceは「Start All Instances」で起動する~~(obsoleted)
- 24/7タイプのインスタンス以外は、インスタンス単体でのstart/stopができない
- 「Start All Instances」でも、Load-based instanceは起動しない仕様になった模様(2014/08/05)

### Load-based instanceの準備方法
- Load-based instanceは、Management Consoleからは手動でstart/stopすることができない
- AWS CLI経由では、start/stopすることができる
 - AWS CLI経由でのstart-instance/stop-instanceは受け付けてくれる
 - ただし、Load-based instanceの設定で「Load-based auto scaling enabled」を「no」にしておかないと、インスタンスが起動中 でもOpsWorksがstopしにかかる
 - Downの「If thresholds are exceeded/undershot for」と「After scaling up/down, ignore metrics for」に十分大きな値を入れておけば、stopされないかも？
 - 完全な確認はとれず

### LayerにELBを紐付けておくと、そのLayerにInstanceが追加された際に自動的にインスタンスが追加される
- あらかじめELBインスタンスを用意しておく必要あり
 - OpsWorksがインスタンスを自動的に作成してくれるわけではない

### EBS Volumesについて
- 追加はインスタンスをstop/startしないと反映されない
 - 追加した瞬間にChefが走る、という仕様ではないらしい
- 削除はインスタンスをstop/startしても反映されない
 - 削除はホストからVolumeをunmountして、EC2の管理画面から削除する必要がある模様

## Custom AMIの作り方
- OpsWorksインスタンスを基にCustom AMI用のディスクイメージを作成しようとするとめんどくさそうなので、OpsWorks管理外のインスタンスをEC2で立ち上げて、基となるマシンイメージを作っていく
 - http://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-custom-ami.html

## アプリケーション周り
### アプリケーションを削除すると、自動的にundeployが走る
### Application nameにハイフンが入ってると、勝手にアンダーバーに変わってデプロイされてしまう
- どこのレシピでそうなってしまうのかは要調査

## Tips
### InstanceのStatusがいつまでたっても「online」にならないときは
- 手でsudo /etc/init.d/opsworks-agent startしてみる
 - たまに、インスタンスをstop/startした後、なぜかopsworks-agentがうまく立ち上がらないことがある
 - 一回手で起動した後は、なぜかそのあと何度やってもうまくいくように見える
 - 何が原因かよくわからない謎事象

### インスタンス立ち上げ時に「setup_failed」となっても、setup lifecycleを手動で回せば「online」になる
- setupがうまくいくと、configureも勝手に回る

### OpsWorks管理下のインスタンス上にある各種ログのファイル格納場所
- Chef実行ログ
 /var/lib/aws/opsworks/chef
 - http://docs.aws.amazon.com/opsworks/latest/userguide/troubleshoot-debug-log.html
 - ファイル名は実行日時になっており、.logにChef実行結果、.jsonにChef実行時に渡されたJSONオブジェクトの中身が書き出される
 - ユーザawsしか読めないので、awsさんかrootさんで読むのが吉
- opsworks-agentログ
 /var/log/aws/opsworks
 - opsworks-agent.log : エージェントのログ
 - opsworks-agent.process_command.log : 管理コンソールなどでコマンドを発行したときに、コマンドを受け取る様子がわかる

### OpsWorks管理下のインスタンスでChef作業を行う
- http://qiita.com/sawanoboly/items/147f550878477ff7723e

### EBS backedで既に作成されたインスタンスをstop/startしても、Custom cookbooksは自動的に更新されない
- インスタンス起動時にCustom cookbookを格納するディレクトリが既に存在している場合は、update_custom_cookbooksしてくれない
 - https://github.com/aws/opsworks-cookbooks/issues/44
 - マニュアルにも明記されているので、「仕様」らしい
- インスタンス起動後、手動でupdate_custom_cookbooksを走らせる必要がある

### Auto Healingのテストをするには
- opsworks-agentが定期的にOpsWorksのセンターへ定期的にインスタンスの状況をアップロードしている
- そのときの通信手段に、outbound方向への443/tcpを使用している
```
ubuntu@apps1:/etc/rsyslog.d$ sudo lsof -i | grep 'opsworks'
opsworks-  995      aws    6u  IPv4  11973      0t0  TCP apps1:57823->176.32.100.148:https (ESTABLISHED)
opsworks- 1006      aws    5u  IPv4  11979      0t0  TCP apps1:38553->205.251.242.78:https (ESTABLISHED)
opsworks- 1008      aws    5u  IPv4  11960      0t0  TCP apps1:57822->176.32.100.148:https (ESTABLISHED)
```
- ので、443/tcpをブロックして上げればOK
 sudo iptables -I OUTPUT -p tcp --dport 443 -j DROP
- ブロックしてしばらくすると、勝手にinstanceを復旧してくれる様が見られるはず
 - OpsWorksによってインスタンスが落ちたと判断されるまで、おおよそ3～5分かかるらしい
 - http://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html

### APIでcreate-deploymentしたときに「ValidationException」が返ってくる
+ デプロイ対象のインスタンスのステータスが「online」になっているか確認
+ app-idが指定されているか確認
 - AWS CLI Referenceのsyntaxではoptional parameterのように見えるが、deploy時はオプション必須
 - http://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html
- 参考ページ
 - http://www.atmarkit.co.jp/ait/articles/1308/06/news012_3.html

### custom cookbookの中身が正常実行できる状態じゃなくなり、update_custom_cookbooksも動かなくなってしまったとき
- 以下のコマンドを叩くと、OpsWorks管理化の全インスタンスのcustom cookbookを更新できる
```
aws opsworks describe-instances --region us-east-1 --stack-id "<Stack ID>" | \
  jq -r '.Instances[] | select(.Status != "stopped") | .PrivateIp' | \
  while read ip; \
    do echo ${ip}; ssh -n ${ip} 'echo "cd /opt/aws/opsworks/current/site-cookbooks; git pull origin master; git submodule update" | sudo -s bash'; \
  done
```
 - IAMでOpsWorksのDescribeInstancesをAllowにしておく必要がある

### VPCを変えてClone stackする場合の注意点 **(最近のOpsWorksでは修正された模様)**
- Clone元のLayer設定で、Custom Security Groupを追加している場合、それを削除しないと起動できない
 - 起動時に以下のようなエラーが出力される

```
An error occurred while starting the instance db-dev1

Security group sg-8808ede7 and subnet subnet-2a97bb6c belong to different networks.
```
- 上記のSecurity Groupを削除しようとしてLayer設定画面に行っても、Custom Security Groupの欄は空になっている
 - 違うVPCのものは、表示されない仕様らしい。。。
 - (2014/07/25) 最近のManagement Consoleは、たとえ違うVPCのSGであってもちゃんと表示される
- しかし、APIを叩いてStack情報を引いてくると、実際はCustom Security Groupに指定されている
- ので、削除もAPI経由で行う必要がある
 - 例
 aws opsworks describe-layers --profile rufein --region us-east-1 --layer-ids 1676be5b-1888-492c-b79f-ce9ef2aeef40
 aws opsworks update-layer --profile rufein --region us-east-1 --layer-id 1676be5b-1888-492c-b79f-ce9ef2aeef40 --custom-security-group-ids "[]"

## 自動化してくれる箇所
+ ELBへの追加
+ /etc/hosts の自動更新
 - 同一Stack内の全ホスト名が自動で登録される
+ ログインユーザの管理
 - 予め公開鍵を登録しておくと、インスタンス生成時に自動的にユーザを作ってくれる
+ Auto Healing
+ Load-based instances
+ デプロイが簡単になる
 - ユーザがどのホストが稼働中か意識する必要がない

## attributes
- opsworks_java
 - http://docs.aws.amazon.com/opsworks/latest/userguide/attributes-recipes-java.html

# Simple Storage Service(S3)
## バケットに対する権限設定について
- S3のバケットに対しては、以下の3種類の観点から権限設定を行うことが可能である
 - ACL
 - バケットポリシー
 - IAM
 - 併用した場合は、ORで権限評価が行われる模様
- 基本的に同一のAWSアカウント内だけで使う場合は、権限設定箇所を1箇所にまとめた方が運用的によい
 - ''IAMとバケットポリシーを併用していると、アクセス権限の運用が困難になる''
- 参考ページ
 - S3のアクセスコントロールまとめ
 - http://qiita.com/ryo0301/items/791c0a666feeea0a704c

## s3cmd利用時の注意点
- 「s3cmd --configure」を実行して作成されるコンフィグのままでは、アップロードがうまくいかない
- .s3cfg内の変数を書き換えてやる必要あり
 - 参考URL: http://xoxo-infra.hatenablog.com/entry/2013/02/06/020930

# Simple Email Service(SES)
## Postfixとの連携設定
- Integrating Amazon SES with Postfix
 - http://docs.aws.amazon.com/ses/latest/DeveloperGuide/postfix.html


---

## Page Navigation

- Canonical URL: https://tips.weseek.co.jp/Tips/Amazon%20Web%20Services(AWS)
- Permalink: https://tips.weseek.co.jp/5fb748c9a1ba4200489a4acc
- Parent: [Tips](/5e44f1546857420048c06de8.md)
- Children: 0 total
- Total descendants: 0
- Siblings: 49 of 71 total (22 more not shown; see the page list API below for the full listing)
  - [Admin.js](/6505e03558d21abbb3ac8575.md)
  - [Agile](/5fb747a7a1ba4200489a4a89.md)
  - [Angular](/65069da24603e7ff39a6b3d6.md)
  - [Ansible](/6505dfaa58d21abbb3ac837d.md)
  - [Apache2](/65069da24603e7ff39a6b3d5.md)
  - [Base64と仲良くなる](/5e9309f511007300489677f8.md)
  - [BuildKitによりDockerとDocker Composeで外部キャッシュを使った効率的なビルドをする方法](/5e67aea878bd2f0048680af1.md)
  - [CSS](/5fb74873a1ba4200489a4abb.md)
  - [Cocos-creator](/5fb74b6aa1ba4200489a4b2e.md)
  - [GROWI開発の知見でLINE_bot作ってみた](/5fd1d3fa0899d80049ff9a1c.md)
  - [Git](/5fb748dfa1ba4200489a4ad7.md)
  - [Grails](/65069da24603e7ff39a6b3f0.md)
  - [Hyperledger fabric](/5fcb12a2550066004845743c.md)
  - [Java](/5fb74daba1ba4200489a4ba8.md)
  - [JavaScript](/5fb74e7aa1ba4200489a4bd1.md)
  - [Jenkins](/5fb74feba1ba4200489a4c17.md)
  - [KVM](/5fbdbc17daa51800482d2227.md)
  - [Keycloak](/5fbdbffcdaa51800482d22b3.md)
  - [Kubernetes](/600522a79662740048b34bb5.md)
  - [Let's Encrypt](/65069da24603e7ff39a6b3d8.md)
  - [Linux](/5fc0ae238b05ce0048ff5a31.md)
  - [MongoDB](/5fc0af488b05ce0048ff5a6b.md)
  - [Mutagen](/6505de1458d21abbb3ac7ecd.md)
  - [Node.js](/60a62549a0d804004912d94b.md)
  - [OpenLDAP](/5fcda4862553a0004852b0dd.md)
  - [Prometheus](/5fc0b3058b05ce0048ff5af6.md)
  - [Python](/5fc0b3218b05ce0048ff5b00.md)
  - [RaspberryPiとArduinoで作る360度回転リモートワークカメラ](/5fccce3e3a4fec004844a01b.md)
  - [RaspberryPiとArduinoで作る360度回転リモートワークカメラ_ソフトウェア構築編](/5fdab8ad04dc4f00483b8d20.md)
  - [RaspberryPiとArduinoで作る360度回転リモートワークカメラ_ハードウェア製作編](/5fd7972a5fc9220048844c35.md)
  - [Redmine](/5fcd9bdd2553a0004852b012.md)
  - [Ruby](/5fc0b2588b05ce0048ff5ada.md)
  - [Single Sign On(SSO)](/5e97bf6876311900487c3c55.md)
  - [Slack](/5fc0ae7b8b05ce0048ff5a45.md)
  - [SourceTree](/5fc0ae0c8b05ce0048ff5a2b.md)
  - [StackStorm(st2)](/65069da24603e7ff39a6b3da.md)
  - [Stripe](/5fc0aff58b05ce0048ff5a8d.md)
  - [Tomcat](/5fcda2772553a0004852b0ac.md)
  - [Turborepo](/6505dee958d21abbb3ac80cf.md)
  - [TypeScript](/5fc0a7ac8b05ce0048ff58f4.md)
  - [URLでベーシック認証を突破](/5fc0b2d98b05ce0048ff5af2.md)
  - [Unity](/5fc0ace98b05ce0048ff59f5.md)
  - [VSCode](/5e9b270093fd090048cc8acb.md)
  - [WSL2](/65069da24603e7ff39a6b403.md)
  - [Wordpress](/5fc0af488b05ce0048ff5a6d.md)
  - [XSS](/5fbe723e36ac6300497c2194.md)
  - [brigade](/600523119662740048b34be0.md)
  - [cert-manager](/65069da24603e7ff39a6b3f9.md)
  - [devcontainer](/5fd54b8eedce4f00482fa36d.md)
- Last updated: 2020-11-20T04:40:41.403Z by syunsuke
- Full page listing (all children regardless of count): https://tips.weseek.co.jp/_api/v3/page-listing/children?id=5fb748c9a1ba4200489a4acc