Amazon Route 53 Auto Namingでサービスディスカバリを実現する | DevelopersIO
ども、大瀧です。 先日Amazon Route 53 Auto Namingがリリースされ、Route 53のDNS基盤によるマイクロサービスの切り替えやサービスディスカバリが利用できるようになりました。 試してみた様子をレポートします。 Route 53 Auto Namingとは Route 53はSLA 100%を誇る高い可用性とスケーラビリティを備えたマネージドDNSサービスです。Auto Namingはサービスディスカバリ向けに、特定のDNS名へのレコード追加、削除のための専用APIを持ちます。サービスディスカバリ機能として提供されるのは従来からあるRoute 53のマルチバリューレコードとその個別ヘルスチェックなので、IAMとしてはAuto Naming APIの権限に加えてRoute 53 Hosted Zoneおよびレコードセットに関する権限が必要です。 設定手順 現時点で
いつの間にかTLS1.3 Readyな世界でTLS1.3を調べている途中に出会ったDNS CAAAmazon Route 53 now supports CAA recordsによるとRoute 53ででもCAAがサポートされたと言うことなので実際入れてみる。 DNS CAAとはによると ドメインの管理者がDNSのCAA (Certification Authority Authorization) レコードを利用し、ドメイン名とサブドメインに対して証明書を発行できる認証局 (CA) を指定できます。 ドメイン管理者(DNSの変更する権限のある人)がどこの証明書を使えと明示的に宣言できるという認識です。 2017年9月から証明書発行時に確認されるようになるなんていう話もあるのでDNS側としては対応しておいた方がいいんでしょうね。 現状CAAは普及していないっぽい。ざっとドメインを調べたけど
このブログに限らず、私は基本的に Amazon Route53 を DNS サービスとして愛用しています。Google Cloud DNS のほうが安かったりとか、いつまでβなんだろうという Azure DNS – サービスとしてのクラウド DNS | Microsoft Azure がありますが、Route53 が好きです。 今回は、 ようやく DNS Query Test Tool が Route53 でサポートされたので、嬉しくて記事を書いてみます。 目次 目次 Amazon Route53 が好きな理由 ドメイン購入も含めた統合 Private DNS の管理 との統合 扱えるレコードタイプの種別 Aレコードエイリアス (Alias) ルーティングポリシー DNS クエリテスト まとめ Amazon Route53 が好きな理由 お名前.com .... はおいておいて、Azure
Amazon AWS Route 53 http://aws.amazon.com/jp/route53/ 0.50USD / Zone / Month 0.40USD / 1,000,000 クエリ クラウドDNSサービスとしては最古参、管理コンソールのWeb画面から設定可能。 各種言語が用意されたAWS SDKからプログラマブルな操作も可能。 レイテンシベースルーティングクエリ、GeoDNSクエリといった通信状況を鑑みて払い出すIPを決定する機構の他、ドメイン名と同一のホスト名( apex レコード、est.co.jp など )をエイリアスとして設定可能といった他には見られない重要な機能もあり。 Microsoft Azure Azure DNS (プレビュー) https://azure.microsoft.com/ja-jp/services/dns/ 25.50JPY / Zon
route53のネガティブキャッシュについて
DNS にはネガティブキャッシュの仕組みがあり、存在しないドメイン(NXDOMAIN)を問い合わせた時は、そのドメインが存在しないということを一定期間キャッシュしてくれる。 ドメイン追加前にうっかりフライングで新規ドメインを名前解決しようとするとネガティブキャッシュされていまい、ドメイン追加してもキャッシュが expire されるまでは名前解決できなくなってしまう。 一般的な DNS サービスでは、SOA の minimum 値がネガティブキャッシュ期間となる。 Amazon の DNS サービス route 53 はネガティブキャッシュ期間を次のルールで決定している。 The minimum time to live (TTL). This value helps define the length of time that an NXDOMAIN result, which indic
Route53のヘルスチェックは文句なしに良いサービスです。これを使ってCloudFrontのようなCDNサービスが正常に動いているか、ゆるくチェックしてもらいます。 概要 CloudFrontはCDNです。１つのオリジンをいろんなエッジロケーションから配信するのですが、すべてのリージョンから動作確認するには、AWSや他のクラウドベンダーのサービスを使って、世界各国からアクセスする方法があります。ガチでやるなら、各リージョンのEC2を建ててやることになりますが、そこまででも無いならRoute53のヘルスチェックにまかせてしまうという話。 Route53のヘルスチェックについて 四の五の言うより下の図を見てください。 ちなみにこの図は下が切れてます。全部で15箇所からチェックをかけてます。こいつらが本当に各リージョンに散らばっているかは dig -x ipアドレス で調べてください。確かに各
ウィスキー、シガー、パイプをこよなく愛する大栗です。 DNSサービスであるRoute 53がVPC内のPrivate DNSをサポートしたので試してみました。 Route 53の設定 Route 53でHosted Zoneを作成します。今まで見慣れないTypeとVPC Idが出てきます。TypeでPublic DNSかPrivate DNSを選択します。 ドメイン名を"maroon1st.local"としてドメインを作成して、Typeを"Private Hosted Zone for Amazon VPC"に設定して、対象のVPCを関連付けます。 作成したHosted Zoneでレコードを作成します。ここではRDSのエンドポイントにCNAMEを設定しました。 この後、既存のDNSキャッシュが消えるまで待ちます。(DNSは「浸透」しませんよ) digコマンドで確認すると、以下の様に表示され
ども、大瀧です。 先日のRoute 53のアップデートでできるようになった新機能、Geo DNSを実現するGeo Routingをご紹介します。 Geo Routing(Geo DNS)とは Geo DNSは、地理データベースと接続元IPアドレスを照合しクライアントに地域ごとの異なるレコードを返すDNSの構成です。Route 53では、Geo DNS相当の仕組みとして、Geo Routing機能を設定することが出来ます。 従来、Route 53にはLatency Routingというクライアント最寄りのリージョンのレコードを返す機能がありましたが、今回のGeo Routingはインターネットのネットワーク構成に拠らない、精度の高いレコードの区分けが特徴です。また、Latency Routingはリージョン単位での振り分けでしたが、Geo Routingは国や州などより細かい振り分けが可能で
The key function of our log management service is to process massive amounts of log data from a wide variety of sources, parsing and indexing it to make it ready for analysis and monitoring in near real-time. The first entry point to Loggly’s big data ingestion pipeline is what we call our collectors. (You can learn more about the whole pipeline in this recent post.) Loggly Collectors Perform One
こんばんは、三井田です。 今回は、Elastic Load Balancing (ELB)とRoute 53のヘルスチェックの仕様の違いについて簡単にまとめてみたいと思います。 ELBのヘルスチェックはご存知のとおり、ロードバランサがどのバックエンドインスタンスにトラフィックをルーティングするかを判断するために用いられます。 一方、Route 53のヘルスチェックは、重み付けラウンドロビンやDNSフェールオーバーで、どのIPアドレスを回答に含めるかを判断するために用いられます。 ヘルスチェック仕様早見表 まずは、以下の表にご覧下さい。 サービス ELB Route 53 ヘルスチェック元 （Health Checker）
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 はじめに Sensu をプロダクション環境で運用しようとすると、その中核となる RabbitMQ はどう見ても SPOF になるんでは？という疑問から HA Proxy や Route 53 を使って HA 構成がとれないか検証してみた。 下記のように Sensu クライアント及び Sensu サーバーが Route 53 に定義されたドメイン名に対してアクセスするような構成を構築して検証する。 尚、今回は ElastiCache for Redis は用いずに Sensu サーバー上に構築した Redis サーバーを利用した。 Route53 による Health Check の設定 参考 Route53のDNSフェイルオーバー機能を使ってみた 設定の条件 RabbitMQ ノードのグロー
New – Amazon EC2 R7a Instances Powered By 4th Gen AMD EPYC Processors for Memory Optimized Workloads We launched the memory optimized Amazon EC2 R6a instances in July 2022 powered by 3rd Gen AMD EPYC (Milan) processors, running at frequencies up to 3.6 GHz. Many customers who run workloads that are dependent on x86 instructions, such as SAP, are looking for ways to optimize their cloud utilization
6. Route53で困ってたこと API操作→即反映 ● 事前に検証できない ● 変更履歴が残らない R53 FoxにImport/Export機能をつけた ● dry runができない ● テストが手動（GUIなので） →ExportしたJSONをgitに保存する運用… 8. 設定ファイル hosted_zone "winebarrel.jp." do rrset "winebarrel.jp.", "A" do ttl 300 resource_records( "127.0.0.1", "127.0.0.2" ) end rrset "winebarrel.jp.", "MX" do ttl 300 resource_records( "10 mx.winebarrel.jp" ) end end hosted_zone "info.winebarrel.jp." do rrset
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
