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およびレコードセットに関する権限が必要です。 設定手順 現時点で
Route53 で CloudFront、ELB、S3 をエイリアス設定した場合の TTL - Qiita
Route53 でエイリアスレコードを設定する場合の TTL についてまとめました。 CloudFront、ELB、S3 を設定する Choosing Between Alias and Non-Alias Resource Record Sets If an alias resource record set points to a CloudFront distribution, an ELB load balancer, or an Amazon S3 bucket, you cannot set the time to live (TTL); Amazon Route 53 uses the CloudFront, Elastic Load Balancing, or Amazon S3 TTLs. CloudFront、ELB、S3 をエイリアスレコードで設定する場合は Rout
Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 - Amazon Route 53
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 example.com を対象とした 2 つ以上のウェブサーバーなど、同じ機能を実行する 2 つ以上のリソースがある場合、次のヘルスチェック機能を使用して、正常なリソースにのみトラフィックをルーティングできます。 EC2 インスタンスおよびその他のリソース (非エイリアスレコード) の正常性をチェックする エイリアスレコードを作成できないリソース (EC2 インスタンスなど) にトラフィックをルーティングする場合は、各リソースのレコードとヘルスチェックを作成します。次に、各ヘルスチェックを該当するレコードに関連付けます。ヘルスチェックは、対応するリソースの正常性を定期的にチェックし、Route
お名前.comからAmazon Route 53へドメインを移管する | DevelopersIO
こんにちは、虎塚です。 Amazon Route 53でドメインが管理できるようになって数ヶ月がたちました。Route 53では、Amazon Route 53でドメインを購入する ｜ Developers.IOにあるように、ドメインを新規に取得することができます。さらに、別のドメインレジストラで登録していたドメインを、移管して管理することもできます。 そこで今日は、他のドメインレジストラに登録しているドメインをRoute 53へ移管する手順を紹介します。例として、 お名前.comで管理しているドメインを想定して説明します。 ちなみに、移管手続きからAmazon側での処理完了までの所要時間は、移管元の事業者によって異なります（移管元が何も応答しなかった場合、5〜7日間かかるとのことです）。今回は約6時間でした。 はじめに この記事の内容は、AWSの公式ドキュメントをスクリーンショット入りで
Route53のレコードをRoadworkerとCircleCIを使ってPull Requestベースで管理する
手元でRoute53のレコードを管理したいんだけど、Roadworkerを使ってRoutefileがPull Requestでマージされたときに自動で行われるようになれば、コメント付きの履歴がとれつつ実際の状態とリポジトリ上のファイルとの一貫性がとれていいのかなと思ってやってみた。 必要なもの CircleCIのアカウント Travis CIでも同様のことはできると思う。ただ今回プライベートリポジトリを扱いたかったので、無料で1枠使えるCircleCIで試してみた。 Route53のfull access権限のあるIAMユーザのAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEY RoadworkerのRoutefile 現在の状態をroadworker -e -o RoutefileコマンドでRoutefileに書きだす 前述のRoute53の鍵を~/.aws/
Route 53のPrivate DNS対応を試してみた | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 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コマンドで確認すると、以下の様に表示され
Amazon Route53管理ツール Roadworkerの設定(Routefile)レシピ | DevelopersIO
ども、大瀧です。 Route 53の管理ツールRoadworker、便利ですね〜。え、どんなツールなのか知らない?そんな方は植木の紹介記事をどうぞ！(宣伝) 早速、弊社案件でもちょこちょこ活用しています。 触っていて気になったのが、Roadworkerの設定ファイルRoutefileの書き方です。RoutefileはRoute 53のゾーン情報をRubyのDSLで記述するので、Rubyのいろいろな文法が使えるんじゃないかと思い立ち、試してみました。 Routefileの例 zone_apex = "example.com" servers = [{ name: "mail", record: "192.168.1.20" },{ name: "app", record: "192.168.1.30" }] hosted_zone zone_apex do rrset zone_apex,
【AWS】Route53をgitで管理する「Roadworker」を早速試してみました | DevelopersIO
はじめに こんにちは植木和樹です。8月23日にcloudpackさん主催のcloudpack night #7に参加してきました。夜8時すぎから始まった懇親会では、AWSを利用している各社の気合の入ったライトニングトークを聞くことができました。その中で「Roadworker」というツールをクックパッド株式会社の菅原さんが紹介されていました。 「cloudpack Night #7で発表しました / Roadworkerというツールを作りました」 このツールは一言でいうとRoute53（DNS）のレコードをChefやPuppetのようにコードで管理できる（もちろん冪等性も！）というものです。素晴らしいですね。動作デモの様子が上記ページにあるYoutubeの動画で紹介されていますが、とても簡単にDNSレコードをコードで管理できる様子がわかります。 それでは早速試してみましょう！ 準備するもの
Route53の新機能によって解決したELBの大きな問題 | TecTec Cloud
AmazonRoute53のβがとれ、正式版になったららしいです。これに伴い、AWSエヴァンジェリストである玉川氏のブログでさらっと紹介されている「新しいエイリアス機能、Zone Apex対応」の文章を読みました。 これ、ELBを利用している人にとっては相当衝撃だったのではないでしょうか。 少なくとも、私にとっては衝撃でした。ビビりました。AmazonEC2最大の弱点（だと個人的に思っていた）ELBのある問題を見事に解決しているからです。あまりに衝撃的だったので、さっそく本ブログで検証してみました。 これまで何が問題だったのか。 実は、AmazonEC2でELBを利用している場合、http://ttcloud.netのような、ドメインルートなURLを利用することができませんでした。http://www.ttcloud.netのような、ホスト名指定のURLにする必要があったのです。サイト
【試してみた】Amazon Route 53にドメインを移動してみた。 | Pocketstudio.jp log3
AWS 上の DNS 環境である Amazon Route 53 に、 DNS を移してみました。これは、その記録。 Amazon Route 53 http://aws.amazon.com/jp/route53/ 一般的に DNS といえば、Linux 系の方であれば BIND や unbound を思い出される方が多いのではないでしょうか。BIND であれば、named.conf にゾーンのエントリを追加したり、セカンダリDNSサーバを登録したりと、ゾーン転送したり。…これが手作業だと、結構面倒だったりしますよね。ウッカリ Serial を更新し忘れて、一日中延々と悩んだり、レコードに「.」をつけ忘れて www.example.jp.example.jp のような情報ががが、とか。 一方、Amazon Route 53 は、ブラウザで画面をポチポチするだけでドメインを管理出来てしまう
AWSブログを3行でまとめる試み : Route53 にDNSフェイルオーバー機能が追加 - naoyaのはてなダイアリー
DNSフロントエンドサービスのRoute53でフェイルオーバー機能が使えるようになったぞ Route53に参照先へのHTTP/TCPヘルスチェックがついて、ダウンしたとき用のレコードを登録できるぞ S3 で静的ページ作ってバックアップサイトにしとくといいかもね。ヘルスチェックの詳細は Route 53 Developer Guide をチェケラッ cf: http://aws.typepad.com/aws_japan/2013/02/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting-.html コメント ヘルスチェックもついてるので EC2 インスタンスを2台作って冗長性を持たせるというのにも使えるだろうけど、それなら ELB を使えば良いので、解説にもある通り S3 で静的ページが現実的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Route53(DNS)をTerraformで操作 - Qiita
Route53でドメインが購入できるようになった - UNIX的なアレ
Gitを使ったRoute53の管理