タグ: AWS

AWSの障害

昨日のAWSの障害、バージニア（us-east-1）の障害は、、、影響範囲が大きかった。そこに、いろいろな管理機能が集約されているのね。いまは使っていないから直接の影響はなかったけれど。サポートチケットの発行もできないとか、使っているSaaSが機能不全になっていたり、いろいろとあぶりだされるな、と感じた。復旧したようでよかった。

バージニア北部リージョンで障害が発生するとヒヤヒヤする理由
https://dev.classmethod.jp/articles/us-east-1-global/

↑のような背景があるからなのね。障害になると調べるし、実感できた。

2025年10月21日
AWSの教訓

Amazon SES（Amazon Simple Email Service）で、サンドボックス環境から本番環境へのリクエストが却下されまくる、という状況になった。

SESの本番化で、これの問い合わせ上限になり、どうにもならなくなり、問い合わせレベルをDeveloper（有料化）にしたら、さくっと、SESがサンドボックスから本番になった。

そもそもAmazon SESの申請内容じゃなくて、サポートレベルから判断しているのではないかという疑念がうまれた。どちらにしても、いい教訓になった。

2025年9月27日
メモ：Amazon WorkmailのSMTPにメール送信するときの送り先
Amazon Workmailのアカウントを使って、別のメールクライアントやスクリプトからメール送信したい。そのときの送信先のSMTPサーバの情報と、参照URLのメモ。
- SMTPサーバー（エンドポイント）：　smtp..amazonaws.com
- 例：東京リージョン（ap-northeast-1）の場合　smtp.ap-northeast-1.amazonaws.com
- ポート：　465（TLS/SSL専用、STARTTLSは非対応）
- 認証：　WorkMailユーザーのメールアドレスとパスワードを使用
参考URL https://repost.aws/knowledge-center/workmail-on-premises-multifunction
2025年8月20日
AWSでインスタンスを終了しようとすると、エラーになる。
AWSでEC2のインスタンスを終了（インスタンスを削除）しようとすると、下記のエラーになったEC2インスタンスがあった。
```
The instance 'i-0ac3a4fb7XXXXXXX' may not be terminated. Modify its 'disableApiTermination' instance attribute and try again. 
```
エラーになった理由は、EC2インスタンスに保護設定されていたから。インスタンスの保護設定を解除しないと削除はできないので、削除する場合は保護設定を外す。

保護を解除するには、次の手順。

1. EC2の画面で、インスタンスを選んで、右クリックから、「インスタンスの設定」「終了保護を変更」を選択する。

2. 「終了保護」の部分の「有効化」のチェックを外して、保存する。

これで終了保護の解除は終了。あとは、もう一度、インスタンスの終了を試す。
2021年6月28日
EC2のインスタンスを起動させたら、ELB経由でアクセスすると503エラーになる
AWSのELBで経由でSSL接続していたEC2のインスタンスを起動させたところ（ちょっと使わない期間があったので停止してた）、ELB経由でアクセスすると、503エラーを返すようになった。503エラーなので、EC2のウェブコンテンツは表示されない状態だ。

設定を見直し整理してみると・・・
- EC2のインスタンスを起動したら、503エラーに。前は表示できていた。
- ELBは、マニュアルに従い、2つのアベイラビリティゾーンを指定。
- EC2のインスタンスは、2つのアベイラビリティゾーンのうち、1つに属する。
- ELBのキープアライブは、EC2のインスタンスが使用していないアベイラビリティゾーンを見ているっぽい。
という状況だった。

使っていないアベイラビリティゾーンからアクセスをしようとして、キープアライブが取れず、アクセスすると503エラーになっている模様。このような状況なので、可用性は下がるが（というかどうせ動いていない）、使用していないアベイラビリティゾーンの設定をELBから削除した。これにより正常にSSL経由でウェブが表示されるようになった。

ELBを使って、AmazonのSSL証明書を使うときは、EC2側がシングル構成だったりするので注意が必要。
2019年11月6日
ELB+ACMでSSL通信を行うときのメリット・デメリット
AWSで、SSL通信を行う設定をすることになったので、ELB（Elastic Load Balancer）＋ACM（Amazon Certificate Manager）でSSLを通信を行うときのメリット・デメリットを考えてみた。癖はあったけれど、驚くほど設定が簡単。

デメリット
- ELBのコストがかかる、ELBは従量課金
- ELB経由で、アクセスするためには、ELBのアドレスをCNAMEで指定する必要がある（ELBのIPアドレスは変動するから）
- ELBでSSL通信がオフロードされるので、アプリケーション側の対応が必要（Wordpressだと、追加設定必要だった）
メリット
- ELBがSSL通信の終端になる
- ELBがSSLのオフロードをしてくれるので、EC2側のSSL設定はいらない
- EC2にSSL設定をしないので、OpenSSLの脆弱性と闘わなくていい（アップデートの手間が軽減される）
- Amazon発行のSSL証明書が無料で使える（ELBにはコストがかかる）
- ELBを使用するので、スケールアウトが用意になる
- 証明書の設定が簡単にできる（認証キーとかの知識もいらないので楽ちん）
2019年7月6日
AWSのELBでWordPressを使うと”ERR_TOO_MANY_REDIRECTS”がでる
AWSで、WordpressとSSLを使うためにELB（Elastic Load Balancer）を設定したのだが、アクセスすると、”ERR_TOO_MANY_REDIRECTS” が表示される。

調べてみると、Wordpress＋SSL＋ELBの組み合わせで発生しているとのこと。Amazonの公式ページの内容も試してみたが、効果なし。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/redirect-http-https-elb/

Nginxを使ったので、その設定を試したが効果なし。

WordPressの設定で回避できることがわかったので、その設定を実施。

“wp-config.php” の「wp-settings.php」の読み込み前に設定を追加。これで、アクセスしたところ、見事に成功。このとき、Nginxの設定は元に戻した状態で実施しても問題なかったので、Nginxの設定ではなく、Wordpress側の設定で回避できる問題だったようだ。
```
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
        define( 'ABSPATH', dirname( __FILE__ ) . '/' );
}

/** 追加した設定 **/
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
    $_SERVER['HTTPS'] = 'on';
    $_ENV['HTTPS'] = 'on';
}


/** Sets up WordPress vars and included files. */
require_once( ABSPATH . 'wp-settings.php' );
```
参考： https://qiita.com/katzueno/items/ec4cb5997eb8a066fefc
2019年7月6日