Route53フェイルオーバでSorryページをELB固定レスポンス表示させる | DevelopersIO
こんにちは、久住です。 Sorryページ表示を検証する機会があったので、２回に分けてまとめて書かせていただきます。 インターネットVPN経由での通信だったので、Route53フェイルオーバ＋ELBの方式で検討しました。 ※検証のためパブリックIPでの接続で試してますが、インターネットVPNで接続する場合はInternalELBで設定する必要があります。 はじめに 今回はRoute53フェイルオーバでELBの固定レスポンスを返す構成を試します。 Route53フェイルオーバは「ターゲットの正常性評価」を利用します。 Amazon Route53の新機能 ELBをHealth Checkのターゲットにしてみた 設定 Route53設定 ホストゾーンの設定 アクセス用のドメインのホストゾーンを作成します。 レコードセットの設定 レコードセットを２つ作成します。 ルーティングポリシーをプライマリ、
AmazonのDNSトラフィック乗っ取り 仕組みについて解説 - orangeitems’s diary
Route53のトラフィック乗っ取り AmazonのRoute53がトラフィック乗っ取りの被害に遭った、と聞くとぎょっとした人が多いのではないでしょうか。AWSの利用者は多いですからね。攻撃の仕組みについて解説します。 www.itmedia.co.jp AWSのクラウドベースのDNSサービスである「Route 53」のDNSトラフィックが何者かに乗っ取られ、「MyEtherWallet.com」のユーザーが仮想通貨を盗まれる事件が発生した。 解説 まず、この問題に関して利用された攻撃手法は「BGPハイジャック」という名前であることをおぼえてください。BGPとはネットワークの中で、ルーティング情報（経路情報）を交換するためのプロトコルです。BGPにて世界中のルーターが会話をすることによって、世界中どんなところにでも、インターネットがつながっていればパケットを届けることができるのです。例えば
オンプレからAWSのDNSを引く高可用性な構成 | DevelopersIO
コンニチハ、千葉です。 オンプレ+AWSのハイブリッドな構成で、AWS側のDNS引きたいということがあります。 例えば、ELBやRDSです。オンプレ側がインターネット接続可能でパブリックなDNSを引く場合はあまり問題になりません。が、オンプレ側がパブリックDNSを引けない場合は困りますね。 この場合、AWSのDNSをを利用したくなるのですが残念ながらオンプレからAWSのDNSを直接引くことはできません。 構成 そこで、直接引くのではなくAWS上にDNSフォワーダーを立て、オンプレのサーバではこちらを参照するように構成します。 自前で立てるのではなく、AWS Directory Serviceを使えばマネージドなので運用が楽になります。参考 ただ、今回はオンプレからDirect Connect(またはVPC、以下略)経由にてS3をアクセスする構成を考えており、今回立てるDNSフォワーダー上に
それは僕たちのドメイン・DNS運用 - YAPC::Asia Tokyo 2015
はじめまして、こんにちは！jigyakkumaです！！！！！１ Infrastructure as Codeが叫ばれる昨今、ドメインやDNS管理・運用にもその波が押し寄せておりますが皆様いかがお過ごしでしょうか。 私が所属している組織では取り扱うドメイン・DNSの数が比較的多く、管理・運用でのベストプラクティスを日夜模索しながら改善を行っている状況です。 運用や管理といった分野は各社のエンジニアや担当者がそれぞれ構築した仕組みやルールで運用を行ってはいるが、ノウハウの共有や知見を得る機会があまりないと感じております。 会社で所有しているドメインやDNSについて運用の手間やトラブルなどでお困りの方も、もしかすると多いのではないでしょうか。 本トークではドメイン登録代行サービスを使用した人力による運用を経てAWS Route53にドメイン・DNSを集約するまでの背景やメリット、注意点を中心に会
Account Suspended
Account Suspended This Account has been suspended. Contact your hosting provider for more information.
Amazon Route 53 を既存ドメインの DNS サービスとして使用する - Amazon Route 53
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon Route 53 を既存ドメインの DNS サービスとして使用する 1 つまたは複数のドメイン登録を Route 53 に移管していて、現在有料の DNS サービスを提供していないドメインレジストラを使用している場合は、ドメインを移行する前に DNS サービスを移行する必要があります。そうしないと、レジストラはドメインの移行時に DNS サービスの提供を停止し、関連するウェブサイトやウェブアプリケーションはインターネット上で使用できなくなります。(現在のレジストラから別の DNS サービスプロバイダーに DNS サービスを移管することもできます。 Route 53 に登録されているドメインの DNS サービスプロバイダとして、Route 53 の使用は
Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード - Amazon Route 53
作成したパブリックホストゾーンごとに、Amazon Route 53 はネームサーバー (NS) レコードと Start of Authority (SOA) レコードを自動的に作成します。これらのレコードを変更する必要はほとんどありません。 ネームサーバー (NS) レコード Amazon Route 53 によって、ホストゾーンと同じ名前のネームサーバー (NS) レコードが自動的に作成されます。これには、ホストゾーンの 4 つの正式なネームサーバーがリストされます。まれな状況を除き、このレコードのネームサーバーを追加、変更、または削除しないことをお勧めします。 次の例に、Route 53 ネームサーバーの名前の形式を示します (これらはサンプルとして提供されています。レジストラのネームサーバーレコードを更新する際には、これらを使用しないでください)。
route53をAWS CLIで切り替える～マネジメントコンソールも使えないこんな世の中じゃ～ | Engineer's Blog
12/23（月） 16時前にただならぬアラートが来だした。 影響ドメイン等からcloudfrontの可能性を疑い、twitterで検索すると、やはりそうらしい。 急いで家に帰り、キャッシュのパージ等を試してみるも、復旧しない。 nslookupをすると、結果が返ってきたり、返ってこなかったり、遅かったり。 どうやら、cloudfrontのドメインがroute53で引けなくなっているようだ。 上司に相談し、cloudfront経由のドメインをオリジンサーバへ向けることにした。 しかし、AWSのマネジメントコンソールもcloudfrontを使っているらしく、死んでいる。画面が真っ白だ。 自分の頭も一瞬真っ白になった。 すこしうろたえたが、AWS CLIで切り替えればいいかと思いついた。 ちょうど自分のサーバにインストールしてあるし。 備忘も兼ね、簡単な使い方を残しておく。 ゾーンIDの確認
AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む） | DevelopersIO
独自ドメインSSLだとCloudFront使えないから横綱無理だよねー、という話がありました。うん、確かにそうでした、執筆時点では…！ 本日2013/06/12、CloudFrontの独自ドメインSSL対応が発表（英語・日本語）されましたので、みなさん揃って横綱になればいいと思います。 よく訓練されたアップル信者、都元です。AWSを利用して構築した環境から、クライアント（モバイルやブラウザ等）に対してHTTPを使って静的なコンテンツを配信したいケースって、多いですよね。多いというか、むしろどんなシステムにも多かれ少なかれ、静的なコンテンツ配信があると思います。 スケーラビリティ・柔軟性・可用性・パフォーマンス・コスト 静的なコンテンツというのは、コンテンツをリクエストに応じて生成したりせず、完成品としてのファイルが手元にある状態です。例えば、多くのWebシステムにおいて、ほとんどの画像やJ
AWS News Blog
Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples At AWS re:Invent 2022, we previewed Amazon SageMaker geospatial capabilities, allowing data scientists and machine learning (ML) engineers to build, train, and deploy ML models using geospatial data. Geospatial ML with Amazon SageMaker supports access to readily available geospatial dat
AWS: JavaのDNSキャッシュ ( TTL )について - aws memo
AWSのサービスではDNSを用いて可用性を向上する仕組みを用いている。 各種APIのエンドポイント RDSのエンドポイント ELBのエンドポイント ElastiCacheのエンドポイント CloudSearchのエンドポイント Redshiftのエンドポイント などなど。AWSが提供するエンドポイントのFQDNを、自分のアプリケーションから参照するように設定したり、一旦DNSでCNAME設定することも多い。 ただし、これらのエンドポイントFQDNで設定されているIPアドレスは、運用中に変更される可能性がある（ノード障害、フェイルオーバー等によるIPアドレス変更、スケーリングによるIPアドレス増減、等）。そのため、アプリケーション側はエンドポイントのIPアドレス変更に追随する必要がある。（追随しないと、古いIPアドレスにアクセス試行しつづけて、結果としてシステム障害になってしまう） ここで問
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Route53のフェイルオーバー機能とS3を使ってバックアップサイトを作成する | 夢中生活＠美雲屋（鈴木商店）
Awsをちゃんと使ってみた
conma.me