3. プライバシー保護 今回は個人用ドメインなのでプライバシー保護が必須でした。 Route 53、Cloudflareともにプライバシー保護に関する機能は存在するのですが、その内容は両者で異なります。 Route 53 Route 53には名前通り「プライバシー保護」機能がありドメインの連絡先情報を「レジストラの情報に置き替え」または「REDACTED FOR PRIVACYで置き替え」してくれます。 どちらの方法で置き換えられるのかはAWSにより自動的に決められます。 ドメインの連絡先情報のプライバシー保護の有効化/無効化 ただし、保護される内容はTLDにより異なるため都度ドキュメントで確認する必要があります。 今回の.techドメインでは 組織名を除くすべての情報が非表示になります。 .tech という扱いでした。 Cloudflare Cloudflareではデフォルトでプライバシ
ども、大瀧です。 先ほど佐々木よりCloudFrontがEDNS-Client-Subnetをサポートしたので試してみたというエントリーが投下されましたが、同じエッジロケーションでサービスされるAmazon Route 53も動くのでは?と思い試してみました。 Route 53レイテンシーベースルーティングの設定 Route 53には、最寄りのリージョンのレコードを返すレイテンシーベースルーティング(LBR)という機能があります。以下のような感じで設定してみました。 動作確認 では、弊社(日本国内)のISPのリゾルバとGoogle DNS(8.8.8.8)でどうなるかと米国リージョンのEC2からAWSのリゾルバ、Google DNSでの実行結果を比較してみます。 日本からのアクセス ikkomon:~ ryuta$ host -t cname about.otaki.classmethod
本日（現地時間 8/21）、Route 53 が CAA レコードに対応しました。 Amazon Route 53 now supports CAA records CAA Format - Supported DNS Record Types - Amazon Route 53 さっそくマネジメントコンソールから設定できるようになっているわけですが、その前に CAA レコードについて少し解説します。 CAA (Certification Authority Authorization) レコード ひとことで言うと、 「このドメインに関する証明書(SSL, TLS)を発行できる認証局(CA) を指定する」ためのレコードです。 例えばこのレコードに「認証局 A しか発行してはならない」と記述した場合は、認証局 B はたとえリクエストがあったとしても証明書を発行しません。 勝手に他人のドメイン
大栗です。 Route 53で新機能がリリースされたので調査してみました。 Amazon Route 53 announces support for multivalue answers in response to DNS queries Values for Multivalue Answer Resource Record Sets マルチバリューの回答とは？ Route 53ではロードバランサと異なる仕組みで負荷分散をするために1つのFQDNに対して複数のIPアドレスを回答することができました。Route 53の1つのレコードに対して複数のIPアドレスを入力します。最大で8個のレコードを登録できます。 今回のアップデートでは、IPアドレス毎に別のレコードとして登録する事ができます。 しかし、通常では今までのDNSの回答とマルチバリューの回答は同様となります。 $ dig sing
CDNをAkamaiに切り替えた - Glide Note
2ヶ月くらい前にCDNをAkamaiに切り替えたので、知見を公開。 (追記 2015年8月18日 私個人の認識不足で用語の使い方に問題があったので一部修正しました s/SLA 100%/高可用性構成/g) TL;DR Kaizen Platform, Inc.で利用しているCDNをAkamaiに切り替えた Akamaiはスタートアップでも利用出来るコスト感 高可用性構成のAkamaiを利用することでCDNの可用性というインフラエンジニア的に頭の痛い問題が減った CDN第一世代 AWS CloudFront CDN (-2015年1月) CDNにCloudFrontを利用 サービスで利用しているインフラのほとんどがAWSで稼働しており、 その関係でCDNもCloudFrontを選択。 CDN第二世代 CloudFront + CDN77 (2015年1月-5月) AWS CloudFront
こんばんは、三井田です。 今回は、Elastic Load Balancing (ELB)とRoute 53のヘルスチェックの仕様の違いについて簡単にまとめてみたいと思います。 ELBのヘルスチェックはご存知のとおり、ロードバランサがどのバックエンドインスタンスにトラフィックをルーティングするかを判断するために用いられます。 一方、Route 53のヘルスチェックは、重み付けラウンドロビンやDNSフェールオーバーで、どのIPアドレスを回答に含めるかを判断するために用いられます。 ヘルスチェック仕様早見表 まずは、以下の表にご覧下さい。 サービス ELB Route 53 ヘルスチェック元 （Health Checker）
Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to EC2編） 本記事はAmazon Route 53のDNSフェイルオーバーに関する下記記事の続き記事です。 ・AWS：Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） https://dev.classmethod.jp/cloud/route-53-dns-failover-s3/ プライマリサイト（EC2）からセカンダリサイト（EC2）へのDNSフェイルオーバー Route 53に追加されたDNSフェイルオーバー機能ですが、前回はフェイルオーバー先のサイトとしてS3の静的なサイトを採用した場合の構成を試してみました。 今回はフェイルオーバー先のサイトもEC2ベースで構成された場合を試してみま
Route 53 に EC2 インスタンスの Public DNS を CNAME で登録して、それを EC2 インスタンス間での通信でも利用するという話です。 1. 前提 EC2-Classic 環境 EC2 インスタンスの接続情報（FQDN なり IP なり）は、AWS のメンテナンスによる再起動などで変更される。 アプリケーションやミドルウェアで、別インスタンスに接続している場合、AWS から割り当てられる Public DNS や IP を設定ファイルなどに記述していると、変更の度に修正が必要になる。 DNSサーバを立てようとしたが、そこまで変更の頻度は多くない（日常的にインスタンス数が増減するわけではない）ので、正直わざわざ立てるほどでも無い。また、DNS サーバの面倒も見たくない。 2. やりたいこと Route 53 で各ホストの接続情報を管理すれば、一元管理できるし、修正も
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
