Multi-AZ配置とSingle-AZ配置とは?

こんにちは。SKMです。

今回はAWSをやっていてよく耳にするけど詳しく分からなかった、

Multi-AZ配置とSingle-AZ配置について説明してみます。

そもそもどのタイミングで活用されるのか?

RDS(Relational Database Service)で、DBインスタンスの高可用性とフェイルオーバーを実現するために使われます。

マスター(M)が存在するアベイラビリティゾーンとは異なるアベイラビリティゾーンに同期スタンバイのスレーブ(S)を配置します。 →高可用性

異常や障害が発生したとき、冗長な待機系コンピュータサーバ/システム/ネットワークに切り替える機能。 →フェイルオーバー

どのタイミングでフェイルオーバーするのか?

下記の状態が発生した場合、プライマリBDインスタンスがスタンバイレプリカに自動的に切り替えられる。(フェイルオーバーする)

・アベイラビリティゾーンの機能停止

・プライマリDBインスタンスのエラー

・DBインスタンスのサーバータイプ変更

・DBインスタンスのオペレーティングシステムでソフトウェアのパッチ適用中

・DBインスタンスの手動フェイルオーバーが [Reboot with failover] を使用して開始された

 

 

Multi-AZとSingle-AZの違い

Multi-AZ配置

複数のアベイラビリティゾーンに配置される、自動でフェイルオーバーが行われる。AZ

 

Single-AZ配置

1つのアベイラビリティゾーンに配置される、手動で復元する必要がある。

singleAZ

 

1つのリージョンに複数のAZがあり、その中にマスターやスレーブがある。

マスターは管理・制御する元のデータであり、

それに対してスレーブがマスターを複製したものになる。

スレーブはマスターに問題が生じたときに、常に最新の状態に更新されているため、マスターに昇格する。しかし、マスターが動いている間は読み書きしないため、マスターの負荷を減らすことはない。

それと合わせて、Multi-AZ配置する際に覚えておきたいのが、リードレプリカです。

データの読み書きはマスターのみ可能で、スレーブは読み取りも出来ない完全なスタンバイになるので、データベースの読み取り性能を上げたい場合はリードレプリカを作成するかElastiCacheを配置します。リードレプリカは読み込みが可能なため、マスターの読み取り負荷を軽減させることが出来ます。

先程スレーブは自動的に同期されると記載しましたが、リードレプリカは非同期です。

 

Multi-AZとSingle-AZに関する説明は以上になります。

今までマスターとスレーブの存在をそもそも知らなかったため、なぜデータベースで可用性を高めるのがMulti-AZ配置なのか分かりませんでした。

マスターとスレーブの役割を知ったのでMulti-AZ配置について理解出来ました。

以上になります。

 

IPアドレスの変換方法

こんにちは。SKMです。

前回の投稿の続きになります。

私はIPアドレスからサブネットマスクへの変換が出来ませんでした。

自分なりに理解が追いついてきたので、ご説明したいと思います。

AWSのEC2とVPCにおいてIPv4とIPv6のアドレス設定で割り当てることが出来ますが

今回の変換方法はサブネットマスクに関する基礎的な知識となります。

AWSに限ったものではありません。

例えば、10.10.1.164/27が属するネットワークのサブネットマスク、ネットワークアドレス、ブロードキャストアドレスを求める場合。

●サブネットマスクの求め方

/27でサブネット化されているため、サブネットマスクの第4オクテットは2進数で「11100000」になります。

サブネットマスク

 

上記からサブネットマスクは255.255.255.224になります。

 

●ネットワークアドレスの求め方

第4オクテットの「164」を2進数に変換すると「10100100」になります。

先程の第4オクテットとAND演算します。

11100000 + 10100100 = 10100000

10100000を10進数に変換すると160になるので、ネットワークアドレスは10.10.1.160になります。

 

●ブロードキャストアドレスの求め方

ブロードキャストアドレスを求める時はサブネットマスクのホスト部をすべて1に変換します。

サブネットマスクの第4オクテットは「11100000」なので、右側5ケタはすべて「1」にします。

先程の第4オクテットの「164」を2進数に変換して「10100100」になった右側5ケタを「1」にして

「10111111」になります。

101111111を10進数に変換すると191になるので、ブロードキャストアドレスは10.10.1.191になります。

 

 

計算方法の説明は以上になります。

さりげなくネットワーク部とホスト部の話が出ましたが、ネットワーク部はサブネットマスクが「1」になっている範囲になり、ホスト部はサブネットマスクが「0」になっている範囲になります。

私はいつもネットを調べながらではないと計算出来ない状態ですので、

自分の頭で出来るように訓練したいと思っております・・・。

 

 

 

VPCとサブネットについて

こんにちは。SKMです。
私はサブネットの理解が不十分でしたので、記事にしてみたいと思います。

基本知識
VPCを作成する際は、IPv4アドレスの範囲をCIDR(Classless Inter-Domain Routing)ブロック形式で指定する必要がある。
VPCを作成したら、Availability Zoneごとに必ず1つ以上のサブネットを追加する。
1つのサブネットが複数のAvailability Zoneにまたがることは出来ない
(VPCはAZにまたげるのでサブネットもまたげると勝手に思ってましたが、サブネットはAZをまたがることが出来ないのですね・・・)

サブネットの種類
パブリックサブネット -> インターネットゲートウェイにルーティングされている
プライベートサブネット -> インターネットゲートウェイへのルートがない
VPNのみのサブネット -> インターネットゲートウェイへのルートがなく、トラフィックがVPN接続の仮想プライベートゲートウェイにルーティングされている

subnet

VPCとサブネットのサイズ設定

今回はIPv4用のVPCとサブネットのサイズ設定をご紹介(ほかにIPv6用がある)
1つのCIDRブロックをVPCに割り当てることが出来る。
許可されているのは/16ネットマスクから/28ネットマスクの間のブロックサイズ。
(16~65,536個のIPアドレスを含めることが出来る)

VPCを作成する場合は、プライベートIPv4アドレス範囲からCIDRブロックを指定することを勧めている。

10.0.0.0~10.255.255.255
172.16.0.0~172.31.255.255
192.168.0.0~192.168.255.255

一度作成したVPCはサイズの変更が出来ない。
VPCが小さい場合は、新しい大きなVPCを作成し、インスタンスを移行する。
→実行中のインスタンスからAMIを作成し、新しいVPCで代替インスタンスを起動する。
古いインスタンスを終了し、元のVPCを削除する。

サブネットCIDRブロックの最初の4つのIPアドレス(10.0.0.0~3)と
最後のIPアドレス(10.0.0.255)は使用ができず、
インスタンスに割り当てることが出来ない。
その場合は下記のIPアドレスが予約される。

10.0.0.0:ネットワークアドレス
10.0.0.1:VPCルーター用にAWSで予約されている
10.0.0.2:AWSで予約されているDNSサーバーの IP アドレス
10.0.0.3:将来の利用のためにAWSで予約されている
10.0.0.255:ネットワークブロードキャストアドレス。VPCではブロードキャストアドレスがサポートされていないため、予約されている

これらの情報をもとにサブネットマスク、ネットワークアドレス、ブロードキャストに変換する問題が出題される可能性もあります。覚えておく必要があります。

次回は今回の内容を踏まえ、IPアドレスからサブネットマスクの変換方法を説明出来るようになれればと思います。

こんにちは、hmです。

ここ最近、監視ツールの調査をしており、面白そうなものを見つけたので、
紹介したいと思います。

なお、今回はあくまで特徴をお伝えするにとどめます。
構築手順は別途お伝えしますが、すごく楽です。
(この点もPrometheusのいいところでもあります。)

Prometheus

ふわっと特徴をお伝えすると、

1.Pull型のOSS監視ツール
Pull型とは、サーバー側から監視先ホストのポートをたたいて回ります。
そのため、サーバー側にはホストの情報を覚えさえてなければなりませんが、
すべて書く必要はなく、service discoveryを使えば簡単に設定、かつ監視対象の絞り込みが
できます。

scrape_configs:
- job_name: ‘my_ec2_hosts’

# EC2 Service Discovery Config
ec2_sd_configs:

- region:
access_key:#アクセスキー
secret_key:#シ-クレットキー
port: 9100 # 監視対象ポート

2.Golang製

3.扱えるのは数値のみ(ログ監視もできそうですが、まだ調査中です)
ここは私がまだわかってないところですが、サーバーがとってくる情報は、数値情報です。
ログの文字列をとってくるというのは、exporter(エージェント)を書かなければならないのですが、あるのかは今はまだ調査中です。

4.ラベルで監視したい項目の絞り込みが簡単
例えば、「この役割で、このステージで、こういうグループの…」
みたいな絞り込みが可能です。

・サービスやステージにかかわらず、Webサーバーのロードアベレージが見たい!
ということであれば、下記のようなクエリを投げれば見ることができます。
node_load5{Role="web"}

また、クエリ自身もぱっとみてわかりやすく、使いやすいです。
クエリ詳細はこちらから!

アーキテクチャ
Prometheusでやっていることは、主に下記の3つです。
・情報をあつめて、ためる。
・アラートを上げる
・クエリへの回答

architecture of prometheus

Web UI
下記は実際に構築したものです。ただし、このWeb UIだけではパッと見て、
わかりづらいかなというのが個人的な意見です。ですので、Grafanaで可視化をしてあげると
よりわかりやすいのかなと。別の記事で紹介をしようかと思います。

下記はホーム画面です。デフォルトは、http://localhost:9090/graphです。
WS000003
クエリはこんな感じでリストになってます。
WS000004
これはmetricsです。監視対象にexporter(エージェント)が入ってないため、
prometheusサーバー自身の情報を表示してます。
WS000005
PrometheusのコンフィグもWeb UIからのぞけます。
WS000000

今回は、ここまでです。次回は、Grafanaの可視化とservice discoveryを設定してみたいと思います。

お付き合いいただきありがとうございました。

備考:
性能については、ユースケースをもとにKibana+Elasticsearchとの組み合わせと比較をしている下記が参考になります。
http://qiita.com/sugitak/items/ff8f5ad845283c5915d2#%E9%AB%98%E6%80%A7%E8%83%BD

ALBでパスベースのルーティングができると何が嬉しいのか~中継ぎ編~

batchiです。

前回の続きからです。
http://www.simpline.co.jp/tech/?p=1739

パスベースのルーティングが必要となるのはどんな場合?というところからです。

ケース1:同じFQDNで別サーバで稼働している場合

パスベースの振り分け

HPと技術ブログを、同じFQDNで異なるサーバ上で動かしていた場合。

ALBであればパスで判断してサーバの振分けが可能ですが、CLBだとそれができません。

上記の構成でCLBを採用した場合、CLBのルーティングアルゴリズムによって
いずれかのサーバにルーティングされ、
運が良ければ然るべきサーバにたどり着くかもね、という状態になります。

ケース2:同一サーバの別ポートで稼働している場合

パスベースの振り分け2

HPと技術ブログが、同一のサーバ上で、異なるポートで動いていた場合。

CLBの場合、下記のような縛りがあるので、基本的に対応できません。

  • ロードバランサーのポート1つあたり設定できるインスタンスのポートは1つ
  • ロードバランサーのポートを重複して指定できない

(80で待ち受けてインスタンスの80に渡す、443で待ち受けて8080に渡す、という無理くりならできる?)

ALBであれば「単一のインスタンスで複数のポートにルーティング」ができます。

CLBを使わざるを得ないのであれば、
FQDNの異なる2つのCLBを用意する、といった対策が必要になります。

余談

「ALBでパスベースのルーティングできると何が嬉しいのか」に対する答えは、
「上記のケースにも対応できるから」で終了なのですが、
自分がこんがらがっていた部分があるので、
FQDNがらみでの「こんな時どうする?」のケースを書きます。

異なるドメインで同一サーバにルーティングしたい

例えば、https://infilic.co.jpでも、
https://simpline.co.jpでも、同じサーバを向かせたい。

こうしましょう。これはCLBでもALBでも変わりません。

異なるFQDN

…と書いていて思ったのですが、
異なるDomeinNameのHostedZoneが、
同一のELBに対してAレコードのエイリアス設定をすれば、
ELBは1つで済んだりするのでしょうか。

HTTPSで待ち受けたい時どうするの、
(どっちか片方の証明書しかELBにインストールできないでしょ、)と思いましたが、
ACMであれば複数ドメインに対する証明書を用意できると聞いたような聞いてないような。

宿題としてとっておきます。

同じドメインで複数のホスト名を持たせて同じサーバにルーティングしたい

例えばhttps://simpline.co.jpでも、
https://www.simpline.co.jpでも、
https://hoge.simpline.co.jpでも、同じサーバを向かせたい。

Route53でがんばりましょう。CLBでもALBでも変わりません。

ホスト名異なる

レコードセットではワイルドカードが使えるので、
最少で、zoneapexである「simpline.co.jp」と、
「*.simpline.co.jp」の2つを作ってあげれば事が足りそうです。
証明書が対応している前提で。

同じドメインで複数のホスト名を持たせて違うサーバにルーティングしたい

上に同じです。
レコードセットごとに、エイリアス設定するELBを分ければ実現可能です。

続く

実際にパスベースのルーティングをどう実現するかの設定を書くつもりでしたが、
構成図を書くのに疲れたので次回にします。

以上です。

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する②

こんにちはmollyです。

前回のXenServer6.5へXenCenterから接続+Zabbix2.4で監視する①の続きになります。

 

1. XenCenter(Windows専用GUI)をインストールする

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する①の最初にダウンロードした
”XenServer-6.5.0-xenserver.org-install-cd.iso”をダブルクリックすると、
ローカルPCの[スタート]→[コンピュータ]で以下のようにXenServerがBD-ROMドライブとして表示されます。

479f17e8-bf9d-8598-899b-d1c286aedcfe

・「BD-ROM ドライブ(E:)XenServer-6.5.0」→「client_install」と開き、「XenCenterSetup.exe」というアプリケーションを選択すると以下のようなセットアップウィザードが表示されます。そして[Next]をクリック。

WS000005

・XenCenterをどこに置くか、XenCenterを誰が使用するかを決定し、[Next]をクリック。
(インストール作業者のみでなく、全員が利用できるようにする場合はAll Usersを選択します)WS000007

・画面が切り替わって[Install]をクリックすると、インストールが始まります。インストールが終わったら[Finish]を押してセットアップウィザードを閉じます。

WS000008

 

2. XenCenterを利用してXenServerへ接続する

・Windows画面左下の[スタート]から「citrix」と検索するとXenCenterが出ます。
・XenCenterを選択すると以下の画面が表示されます。

WS000009

・画面中央の[ADD a server]を選択すると以下の画面が表示されるので接続先のXenServerの情報を入力して[Add]をクリックします。(XenServerのネットワーク設定が出来ているかチェックしておく)

WS000011

・接続できました。

無題

 

3. XenServerにZabbixエージェントをインストール/設定する

・まずXenServerにSSHで接続します。
・SSHで接続できたら以下のコマンドでzabbix-agentのリポジトリを登録します。

rpm -ihv http://repo.zabbix.com/zabbix/2.4/rhel/5/x86_64/zabbix-release-2.4-1.el5.noarch.rpm

・次に以下のコマンドでzabbix-agentをインストールします。

yum install zabbix-agent --disablerepo=citrix,base,epel

◆/etc/zabbix/zabbix_agentd.confの中を編集

Zabbixサーバーを指定
Server=192.168.XX.XX

Zabbix サーバーを指定
ServerActive=192.168.XX.XX

XenServerのホスト名を指定
Hostname=test-XenServer

◆zabbix-agentの起動と自動起動設定

service zabbix-agent start
chkconfig zabbix-agent on

◆XenServerのポートの開放
zabbixと通信するにはデフォルトで10050ポートを使用する為、10050ポートを開放します。

/etc/sysconfig/iptablesの中に以下の一文を追加
-A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 10050 -j ACCEPT

追加したらiptablesを再起動します
/etc/init.d/iptables restart

 

4. Zabbixサーバのブラウザ上で設定する

・zabbixサーバのダッシュボードにアクセスし、[設定]→[ホスト]→[ホスト作成]を選択します。
「ホスト」タブで以下のように設定します。(例)
  【ホスト名】XenServer
  【所属グループ】Virtual machines
  【エージェントのインターフェース】IPアドレス/ポート10050

・「テンプレート」タブで[Template OS Linux]を選択し、そこまで設定したら一旦[追加]します。

zbxagnt

・テンプレートまで設定すればグラフが自動で出来るのでそれらでスクリーンを作成すればXenServerに関するグラフを一気に見ることが出来ます。

graph

 

長々と書いてきましたが以上になります。
AWSはまったく関係のない記事でしたがXenAppやXendesktopがバージョン7.5からAWSでも使えるようになったみたいなので、そちらもキャッチアップ出来たら挑戦してみたいと思います。

ありがとうございました。

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する①

初めまして、mollyです。

技術ブログを更新する機会をいただきました。
AWS関連ではないのですが、自分がせっかく学んで実践してみたことを
共有したいので今回はXen+Zabbixのお話を書かせて頂きます。
長くなってしまいそうなので2つに分けて投稿します。

新しく携わる案件のためにXenを学んだので、XenServer6.5の構築と
継続して勉強していたZabbix2.4での監視をしてみようと思いました。
今回、XenServer6.5はVirtualboxに構築します。

前提
・Zabbixサーバ2.4構築済み+ブラウザでダッシュボードが見られる環境
・Virtualboxにエクステンションパックが入っている

 

1. まずVirtualboxにXenServerの起動準備をします。

ここから「XenServer Installation ISO」を選択してダウンロードします。
・Virtualboxを管理者権限で開いて、[新規]をクリックします。
・【名前】XenServer→【タイプ】Linux→【バージョン】Other Linux(64-bit) このように設定しました。
・次からは以下のように設定しました。
  【メモリサイズ】4096
  【仮想ハードディスク】仮想ハードディスクを作成する
  【ハードディスクのファイルタイプ】VDI(VirtualBox Disk Image)
  【物理ハードディスクにあるストレージ】(可変サイズ)
  【ファイル名】XenServer
  【仮想ハードディスクのサイズ】16GB
・作成した仮想マシンを選択し、画面上の[設定]を押して[システム]→[プロセッサー]→プロセッサー数を2CPUに設定します。

 

2. XenServerを起動します。

・作成した仮想マシンを選択し、画面上の[起動]を押します。
・「起動ハードディスクを選択」という画面が出るので、先ほどダウンロードしてきた”XenServer-6.5.0-xenserver.org-install-cd.iso”を選択する。
・言語選択画面で日本語([qwerty] jp106)を選択。

WS000001

・インストールを続行するか聞かれるので[OK]を選択してEnterを押します。

WS000002

・「End User License Agreement」は、ライセンスに関する同意画面なので[Accept EULA]を選択してEnterを押します。

WS000020

・インストール先のストレージを選択する画面が表示されるので対象のディスクを選択して[OK]を押します。

WS000022

・「Select Installation Source」画面では[Local media]を選択して[OK]を押します。

WS000023

・Supplemental Packのインストールをするかどうか聞かれるので、[Yes]を選択(自由)する。
次に聞かれるテスト(Verify Installation source)も行うかはどちらもでもよい。

WS000024

WS000025

・その他もろもろの設定をします。
  【rootのパスワード】自由に設定(2回入力して[OK])
  【NetWorking】DHCPか固定IP(今回は固定IPにしました)
  【ホスト名/DNSサーバ】環境に合わせて設定
  【タイムゾーン】Asia>>Tokyo
  【System Time】Manual time entry(NTPを使う場合は次の画面で設定)

・ここまで設定したら以下の画面になるので[Install XenServer]を選択してEnterを押すとインストールが始まります。
(Supplemental Packのインストールを行うと選択している場合、「New Media」という画面が表示されるが特にインストールしないので、[Skip])

WS000032

・しばらく待つとインストールが終了し、「Installation Complete」という画面になるので[OK]を押して再起動します。

WS000035

・起動すると、以下の画面になるのでここからはWindows専用XenClientのXenCenterから設定などの変更が出来るようになります。

WS000034

この段階ではXenServerを構築したのみで、まだ何と接続しているわけではありません。
きりが良いので一旦ここまで、、、②に続きます。
次回はXenCenterのインストール~接続~Zabbixでの監視編です。

ALBでパスベースのルーティングができると何が嬉しいのか~前置き編~

batchiです。

早いものでALB(Application Load Balancer)が登場してから数ヶ月。
先輩のpinoco氏はALBが登場してすぐにブログに書いていたのですが、

ELB(Application Load Balancer)をおさわりする

当時の僕はパスベースとはなんぞや状態で、
いまいち「ALBならでは」の挙動を理解できておりませんでした。

ここにきてようやく理解が追いついてきたので、
数ヶ月前の自分に向けて噛み砕いた説明を記していきます。

まずはCLBとALBの違い

ALB(Application Load Balancer)が登場したことによって、
従来のLoad BalancerはCLB(Classic Load Balancer)と称されることになりました。

以下記事中の呼称はALB、CLBに統一します。

公式ドキュメントで両者の比較表が作られていますので確認しましょう。
http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html#elb-features

ALBとCLBの違い

[パスベースのルーティング]という行には、
ALBにのみチェックがついていることがわかります。

あとはまぁ、いろいろ違いますね。

いきなり脱線して日本語訳への不満

[スティッキーセッション (Cookie)]の行をご確認ください。
ALBの列に、「生成されたロードバランサー」と書いてあります。

ちょっと意味が分からないですね。

英語表記に切り替えると、
「load balancer generated」と記載されています。
「generated」によって「load balancer」が修飾されているという訳し方ですね。

正しくは「load balancer generated」が「cookies」を修飾していて、
「ロードバランサーが生成した(クッキー)(によるスティッキーセッション)」のはずです。

CLBであれば、
アプリケーション制御のcookieによるスティッキーセッションも、
ロードバランサー制御のスティッキーセッションも選択できるけど、
ALBでは後者しか使えません。という意味でした。

パスベースのパスとは

話は戻ってパスベースの話です。
パスベースにおけるパスとは何を指しているのかをきちんと理解するために、
URLの構成をおさらいしておきましょう。

https://www.cman.jp/network/term/url/
↑こちらのサイト様がわかりやすくまとまっていました。

簡単に言うとこういった構成になります。

http://<FQDN> <パス>

FQDNとは、「(ホスト名+)ドメイン」のことです。

弊社のHPのURLで見ると…
https://www.simpline.co.jp

ホスト名 www
ドメイン simpline.co.jp
パス なし

技術ブログの場合だと…
http://www.simpline.co.jp/tech/

ホスト名 www
ドメイン simpline.co.jp
パス /tech/

「パスベースのルーティング」には、
URLにおけるこの「パス」が関係してくるというわけです。

パスベースのルーティングが必要ないケース

ここで、弊社のサーバ構成をごく簡単にご説明します。

パスベースでないケース

簡単すぎますね。

EC2上でwebサーバを動かしており、
そのフロントにはCLBが立っています。

HPや技術ブログの他にも社員ブログ、代表ブログなど様々ありますが、
基本的に同じサーバの同じポート番号で動かしています。

クライアントはwww.simpline.co.jp <何がしかのパス>というURLにアクセスしてくるわけですが、
ここで<パス>が何であっても、
クライアント→hosted zone→CLB→80番ポートに至るまでの経路は全く同じです。

こういった構成においては、パスベースのルーティングは必要ありません。

では一体どういったケースで必要になってくるかというと…
肝心なところは次回に持ち越しです。

以上です。

AWS Certificate ManagerでSSL証明書を取得した話を読んで調べてみた話

batchiです。

前回はhm君がACMに関する記事を書いてくれたのですが、
見ている内になかなか面白そうだということになりまして、
自分でも調べてみることにしました。

AWS Certificate ManagerでSSL証明書を取得した話

基本的にはhm君が書いてくれたことに乗っかりつつ、
2016年12月現在日本語に対応していないドキュメントと、
http://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html

じゃあもうざっくりしたことはこちらで見ます!でおなじみのBlack Beltの資料をお供に、進めていきます。

ACMのさっくりとした特徴

■証明書取得は無料

 うれしいですね。証明書だけでなくACMというサービス自体が無料です。

■証明書の種類は「ドメイン検証済み証明書」

 ACMの「よくある質問」ではそういう言い回しになっていますが、
 一般的には「ドメイン認証証明書」ですね。
 https://aws.amazon.com/jp/certificate-manager/faqs/

 Black Beltのスライドの16ページに、証明書の種類が載っています。

■証明書の更新を自動で行ってくれる

 証明書の有効期間は13ヶ月で、
 早い場合期限切れの60日前から更新プロセスを実施してくれます。

■証明書のデプロイは、ELBかCloudFrontにのみ対応

 EC2やらオンプレで建てたWeb/APサーバに入れましょう、
 というのは(現在のところ)できませんということですね。

デュアルアクセスはできないが

証明書ベンダーによっては、
コモンネーム「www.hoge.co.jp」で証明書を取得すれば、
zoneapexである「hoge.co.jp」にも証明書が有効となったりします。

それをデュアルアクセスと呼ぶのだそうです。

ACMに置き換える前はデュアルアクセス対応の証明書だったので、
「じゃあACMではワイルドカードかなんかでまるっと有効にすればよろしんじゃないー」
なんて無責任に言っていたのですが、

ワイルドカード指定でプロテクトできるのは、
飽くまで「apexドメインのサブドメイン」までということでした。

つまり、「*.hoge.co.jp」と指定すれば、
www.hoge.co.jpもbatchi.hoge.co.jpも対象となりますが、
www.fuga.hoge.co.jpや、hoge.co.jpはプロテクトしてくれないのでした。

ただし

ACMでは1枚の証明書に複数ドメインを設定できるので、
今回はドメイン名「*.hoge.co.jp」で証明書を取得し、
そこに[追加の名前]として「hoge.co.jp」を指定することで、
やりたいことがひとまず実現されました。
(ワイルドカードでなくてwwwで良かったかもしれない)

↓そこらへんの仕様がつらつらと書いてあります。

http://docs.aws.amazon.com/acm/latest/userguide/acm-certificate.html

[Wildcard Names]
When you request a wildcard certificate, the asterisk (*) must be in the leftmost position of the domain name and can protect only one subdomain level. For example, *.example.com can protect login.example.com and test.example.com, but it cannot protect test.login.example.com. Also note that *.example.com protects only the subdomains of example.com, it does not protect the bare or apex domain (example.com). However, you can request a certificate that protects a bare or apex domain and its subdomains by specifying multiple domain names in your request. For example, you can request a certificate that protects example.com and *.example.com.

証明書にタグがつけられるが

ELBのリスナーにデプロイする選択画面では、
<ドメイン名>+<長ったらしい識別子>で表示されていました。残念。

証明書取得の事前準備

ドメイン認証証明書、というからには、
当然ドメインの管理者である必要があるわけで、
管理者あてに送られてくるメールを受け取れなければいけないわけです。

ではどこ宛にメールが送られてくるか、
というと、「whois情報に紐づく担当者」です。

正確に言うと、証明書リクエストに記載された各ドメイン名に対して WHOIS ルックアップが実行され、
そのドメインの連絡先情報に登録されている、
ドメインの登録者、管理者、および技術担当者の連絡先に送信されます、とのこと。

加えて、下記5つのアドレス。
administrator@your_domain
hostmaster@your_domain
postmaster@your_domain
webmaster@your_domain
admin@your_domain

whois情報とは何ぞや

このドメインはどこそこの誰が管理しているか、
というのは一般に公開されているものです。

「whois情報検索」なんかで検索すれば、
そういったサイトがいくつも出てきます。

試しに弊社のドメインのwhois情報を確認してみると…
あぁ。なるほど。

お名前.comなどでドメイン取得するケースが多いかと思いますが、
その際に登録する情報ですね。

whois代行みたいなオプションを有効にすれば、
この検索結果をお名前.comのものにしてくれると。

Validation Not Complete

上述のように、(可能性としては)たくさんの宛先に確認メールが送られるわけですが、
それを全部承認しなければ有効にならない、ということはありません。
(スライドの30Pの記述からそう判断した)

[ドメイン名]と[追加の名前]で証明書を取得したなら、
それぞれに(可能性としては複数の宛先に対して)承認メールが送られるので、
その両方で(1通以上のメールにおいて)承認を行えば、晴れてValidationがCompleteになります。
なるはずです。

http://docs.aws.amazon.com/acm/latest/userguide/troubleshooting.html#troubleshooting-incomplete

If your request includes more than one domain name in the certificate, then you must approve every domain name that you included.

2分くらい時間かかるそうです。

以上です。

AWS Certificate ManagerでSSL証明書を取得した話

こんにちは、hmです。

今回は、AWSのサービスであるAmazon Certificate managerで、
SSL証明書を取得し、現行のものと置き換えたお話です。

サービス利用の背景
現在、複数ドメインを取得・管理をしておりますが、
その中の一つが更新時期を迎えたので、この際見直しをすることになりました。

検討時、候補として挙がったのが、AWS Certificate managerで取得できる
SSL証明書でした。

ACMとは?

ACMは、ざっくりいうとSSL証明書を管理するサービスです。
AWSでも新規のSSL証明書を発行してもらえます。

下記は、サービスの特徴をさらにざっくりまとめました。

・証明書取得は、無料である。
・現在は、ドメイン検証済み証明書のみが取得可能。
・有効期間は1年間、更新は自動でOK!
・証明書発行は、CloudFrontとELBのみ対応

詳細は、こちら
今回の要件としては、ドメイン証明書レベルで大丈夫だったので、
早速実装いたしました。

実装編
1,今回要件として、www.XXXXXX.co.jpがSSL証明書取得対象

現行では、www.XXXXXX.co.jpでSSL証明書取得をすると、
zoneapexであるXXXXXX.co.jpにも効力が及んでいたが、
ACMでは分けて設定する必要があるようです。
なので、ワイルドカードで指定をします。

取得後のキャプチャはこちら。
2016-12-05 (2)
塗りつぶされてわからなくなってますが、
追加の部分にzoneapexで指定をしたものをいれています。

SSL証明書のリプレース

今回は、ロードバランサーにつけます。
20161206

矢印の部分がSSL証明書です。右側の変更ボタンを押して、
変更ができます。

変更ボタン後は下記のようになります。
ここで、選択肢の一番上を選び、取得したものをさらに選んで保存を押して終了。
2016-12-05 (3)

余談
SSL証明書取得時にAWSからユーザーへ承認のメールが届きます。
メールのあて先は、下記です。

administrator@your_domain
hostmaster@your_domain
postmaster@your_domain
webmaster@your_domain
admin@your_domain

今回は、上記のうち、2つに届いていて、
1つだけ承認をしましたが、承認していることにはなりませんでした。

どうやら確認ができる複数のアドレスに来ている場合、
すべてのドメインで承認が必要だという意味なのでしょうか。

念のため、ドキュメントを探していると、
2つ以上ドメインを指定するとすべて認証しなければならない。
Validation Not Complete の important
という記述を見つけましたが、よくわかりません。

簡単ですが、今回はここまで。

どうもありがとうございました。