ＥＣ2インスタンスのデータを作成してＳ３にアップしようとしたら以下のエラーが出てしまいました。

ERROR: Error talking to S3: Curl.Error(35): error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm.

一年前は大丈夫だったんですが、何かが変わってしまったみたいです。

調べてみたら、openssl が古かったようで

yum update openssl

でアップデートをかけたら無事に動くようになりました。

AWS からお知らせが来て、Cloud Front の Invalidation にワイルドカード指定ができるようになったらしい。

Invalidation とは、各サーバにキャッシュされたファイルを削除して、新しいファイルが配信されるようにすることです。

Invalidation しないとキャッシュサーバに古いファイルが24時間ぐらい残っているので、元ファイルを更新してもエンドユーザには古いファイルが配信されます。

今までは、ファイル一つ一つを指定して Invalidate していたものが、今回ワイルドカード指定で、例えばあるディレクトリの下のファイル全部、というような指定のしかたができるようになったとのこと。

で、このお知らせに書いてあったのが、Invalidation には費用がかかるということ、最初の1000回は無料だが、それ以降は 1 invalidation 毎に $0.005 かかるそうな。

そんなの知らんかったなぁ。。。

まぁ、私の場合は機械的に Invalidate したりしていないので特に影響は無いのですが、大量に Invalidation する際は注意しましょう。

ワイルドカードを使った場合、該当するファイルがいくつになっても 1 Path 1 Invalidation とカウントするようですので、ワイルドカードを効率的に使えば安くすませられるかもしれません。

AWS で新規の CentOS 6.5 インスタンスを起動して、最初だから yum update でアップデートしてから始めようとしたら

ERROR with rpm_check_debug vs depsolve:
yum-plugin-fastestmirror is needed by yum-3.2.29-60.el6.centos.noarch
** Found 1 pre-existing rpmdb problem(s), ‘yum check’ output follows:
yum-3.2.29-43.el6.centos.noarch has missing requires of yum-plugin-fastestmirror
Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2015-04-26-08-54pY64yt.yumtx

という、わけのわからんエラーで update が止まってしまう現象となりました。

よくわからんので、おっしゃられるとおり

yum install yum-plugin-fastestmirror

として、インストールしてみたら yum update も通りました。

yum-plugin-fastestmirror は一番速いダウンロードサイトを選択してそこからダウンロードしてくれるプラグインのようです。

にしても、それでエラーになるって本末転倒なような。。。

すでに VPC 内に起動している RDS に既存の EC2（Classic） から接続したくなったので、接続を試してみたら接続できませんでした。

どうやら VPC 内の RDS には VPC 外からは接続できないようです。

ただし、Publicly Accessible という設定が ON になっていれば外からでも接続できるとのこと。

早速 Publicly Accessible の設定をON にすべく、いろいろと調べてみたところ、どうやらこの設定は後から変更することはできないようです。。。

従って、接続できるようにするには、RDS のスナップショットを取り、別のインスタンスを Publicly Accessible ON で起動し、そちらにつなぎ直す、という手順が必要なようだ、、、ちょっとめんどくさいですね。

GoogleさんがSMTPサーバを貸してくれなくなったので、仕方なくEC2でSMTPサーバを立ち上げました。

しばらく運用していたらユーザから、メールが戻ってきてしまう、という指摘をもらいました。

戻ってきたメールには以下のようなメッセージが
unavailable; Client host[xxx.xxx.xxx.xxx] blocked using TrendMicro RBL+

どうやら立ち上げたSMTPサーバのアドレスがトレンドマイクロさんのブロックリストに載っていて、メールがブロックされているようだ。

https://ers.trendmicro.com/reputations

でSMTPサーバのIPアドレスを見てみると Reputation: Bad だそうで、このメールサーバからのメールは拒否される。

これは正当なメールサーバだからリストから外してよ、とRequestを送ってみたが

xxx.xxx.xx.xxx is listed on our Dynamic User List (DUL) because
Amazon has told us that this is not a static IP address.

とのことで、 Staticアドレスじゃないのでダメ、アマゾンに以下のお願いをしてください。とのこと

1) properly setup an rDNS for this IP to reference static
2) update us with the latest list

1) は以下のフォームからリクエストできるらしい。

https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

このページで設定をお願いしてみる。

Use Case Descriptionに使い方の説明。（use as a smtp serverみたいな）
Elastic IP Address 1にSMTPサーバのIPアドレス（xxx.xxx.xxx.xxxみたいな）
Reverse DNS Record for EIP 1にSMTPサーバのドメイン名（smtp.example.comみたいな）

以上のような情報でリクエストすると

Request to Remove Email Sending Limitations Received
Thank you for submitting your request.
It is our intention to meet your needs.
We will review your use case and normally respond to requests within 2-3 business days.
検討するからちょっと待って。だいたい２～３営業日中には回答します。とのこと。

数時間後、アマゾンから
We have configured the reverse DNS record you requested.
ご所望の設定終わったよ。というメールが届く。

nslookup xxx.xxx.xxx.xxx
で確認してみると、おぉ、ドメインが登録されている。

しかし、この時点で再度

https://ers.trendmicro.com/reputations

を見てみると、まだ Reputation: Bad のままである。

少し待ってみよう。。。

5時間ぐらい待ってみたが Reputation は変わっていないので、再度Trend Microに以下のようなRequestを送ってみる。

Amazon has properly setup an rDNS for this IP.
Could you please remove this IP from the blocked list?

しかし、数分後に一回目と同じ内容（アマゾンにお願いしてください）のメールが届く。
どうやら Trend Micro は Amazon の IP アドレスで削除依頼がくると定型の文章で返信しているようだ。

仕方がないのでしばらく待つことにする。。。

翌日、確認してみるが Reputation : Bad のまま。。。

2日後、確認したところ Reputation : Unlisted in the spam sender list になっていました！

めでたしめでたし。

EC2 で、Community Instance を使い、新しいSecurity Group と Key Pair を作って起動したのだが、秘密鍵を指定して root でログインしようとすると、まずは root 以外でログインしてください、というメッセージが出てログインできませんでした。

いろいろと調べた結果、作成した秘密鍵で ec2-user というユーザ名でログインできました。

ログイン後に
sudo su
とすれば root になれるので、そこで root のパスワード設定など必要な処理を行いました。

ec2-user というユーザ名は AMI によって違うかもしれませんが、迷ったので備忘録として書きました。

EC2でマーケットプレイスにあるインスタンスイメージを起動するときにEBSのサイズを10GB から 20GB に変更して起動したのだが、起動した後に df コマンドで見てみるとサイズが10GB のままになっていました。

でも EBSの設定をみると 20GB になっているので料金は 20GB 分取られているわけです。

そんなときは、df コマンドで確認したデバイス名に対して以下のコマンドを実行して、容量がフルに使えるようにします。

＊ /dev/xvda1 の部分は自分の環境に合わせた名前にしてください。

以上で無事 20GB が使えるようになりました。