Amazon Route 53をやさしくおさらいする会 https://minorun365.connpass.com/event/294692/
![Amazon Route 53をやさしくおさらい](https://cdn-ak-scissors.b.st-hatena.com/image/square/b79cb8799e165251c67ed798466468272cad0f9e/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5dcac812057c4a9abf7d984b59c72585%2Fslide_0.jpg%3F27073195)
Amazon Route 53をやさしくおさらいする会 https://minorun365.connpass.com/event/294692/
技術部プラットフォームグループのエンジニア、shibatchです。 最近カラーミーショップのDNSのサーバ引っ越し作業をおこないました。引っ越し先はAWSを利用したのですが、Route53ではなくあえてEC2+Auroraという構成にチャレンジしたのでご紹介します。なお、途中経過は以前GMOペパボエンジニア Advent Calendar 2020内のAWSでDNSをRoute53を使わずに構築するとして公開しました。無事完了したのでこの記事は最終的な構成について加筆・再構成したものになります。 まとめ(結果、どうなったか) 権威DNSサーバをプライベートクラウド内のBINDサーバからAWSのPowerDNS(on EC2)+Auroraへ再構成しました PowerDNSのRESTful APIを活用することで、バッチ処理でのZONE更新を廃止し、システムのデータベースに依存しない、シンプ
ベルリンのしがひです。COVID-19渦はヨーロッパにも広がり、いくつかの自治体で地域封鎖などの緊急防疫が実施されています。 日本では通勤時の混雑と密集がハイリスクであること、また安倍首相が今週からの学校閉鎖を要請するという発表を行ったことで会社員の在宅勤務の必要性がますます高まり、Slack、Zoomといったリモートワークツールへ注目が集まっています。 しかしながらリモートワークはコミュニケーションに使用するツールのみで事足りるものではなく、業務システムやドキュメントへのアクセスが安全に確保されていることが必要で、実際のところ、全社員にこういったリモートアクセス環境を用意することへのハードルが高いのではないでしょうか。 今回はオンプレ、クラウドにあるシステムへのリモートアクセスを即興で構築する方法を実践します。差し迫ったリモートワーク対応のヒントになればと思います。 VPNを構築している
ども、ゲストブロガーの大瀧です。 クラスメソッド在籍中の2018年2月頃社内向けにDNS勉強会を全4回で開催したことがあり、そのときの資料がひょこっと見つかったので公開してみます。(正確には第3回は聖剛さん担当だったので一緒に公開してもらいました、感謝。) 第1回 DNS入門 : DNSのしくみ、キャッシュ 第2回 DNSコンテンツサーバー : DNSサーバーの分散構成とゾーンの委任 第3回 DNSセキュリティ : DNS関連の攻撃手法とDNSSEC 第4回 AWSのDNSサービス : Route 53とAmazon DNS DNSについての理解を深める一助にしていただければと思います。現職(SORACOM)でももちろん超重要な技術です! 第1回 DNS入門 スライド共有サービス終了に伴い、公開終了 第2回 DNSコンテンツサーバー スライド共有サービス終了に伴い、公開終了 第3回 DNS
AWS EC2環境でのDNS Rebindingについて検証したので紹介します。 まずは、「前回までのおさらい」です。先日以下の記事でSSRF攻撃およびSSRF脆弱性について紹介しました。 SSRF(Server Side Request Forgery)徹底入門 この記事の中で、以下のように紹介しました。 ホスト名からIPアドレスを求める際にも以下の問題が発生します。 DNSサーバーが複数のIPアドレスを返す場合の処理の漏れ IPアドレスの表記の多様性(参考記事) IPアドレスチェックとHTTPリクエストのタイミングの差を悪用した攻撃(TOCTOU脆弱性) リクエスト先のWebサーバーが、攻撃対象サーバーにリダイレクトする 上記のTOCTOU(Time of check to time of use)問題は、DNSの名前解決の文脈ではDNS Rebindingとも呼ばれます。 DNS R
タイトルの通りです。 キャッシュしないCloudFrontなんて何に使うの?って感じなんですが、最近 AWS WAF がリリースされたりして、ELBのように前段に挟むだけでも意味があると思っています。 動的コンテンツが多いと恩恵は受けにくいのですが、それでも静的なファイルのみを指定してキャッシュを配信したり、DDoS対策したり…これから新たにウェブサービスのアーキテクティングする際はとりあえず間に噛ませておく、というのが良いと感じています。 ディストリビューションの設定 デフォルトの設定から変更するべき箇所を列挙します。 Create Distribution の画面で入力、変更する箇所を列挙します。 Origin Settings Origin Domain Name: クリックしてELB一覧からオリジンとなるサーバーを選択 Origin ID: 任意で(ELB設定時にデフォルトで付与さ
タイトル長いですが、今回新しくドメインとってやったことの流れです。 1. ドメイン取得 最大手のお名前.com さんでしょう、ということでドメインを取得しました。9/17 19時までキャンペーンらしいです。 始めての利用の場合は取得するドメインを入力してからアカウントを作成します。クレジットカードかコンビニ払いだと入金確認後すぐにドメインを取得、利用が開始できます。 お名前.com でDNSレコードを設定する場合はそのままドメインNAVI に入ればいいのですが、今回は違うのでいったん置いておきます。 2. Amazon Route53 を設定する Amazon Route53 は可用性・拡張性の高いDNSサーバーをサービスとして使えます。個人で使う用途としては、お名前.com などのネームサーバーをそのまま使っても問題ないと思います。今回はどちらかというと勉強用途で利用を決めました。 料金
日に2回もブログを書くなんて人生初かもしれないonagataniです。こちらにちわ。という事で今回もRoute53の小ネタを。 皆さんRoute53利用されてますか!利用していない方は今すぐに利用しましょうとても便利です。 とはいえ、Route53に全部移設するのは無理だよー、wwwやwwwなしドメインは管理部署が違うので・・・という事もあるかと思います。 そんなときに便利なのが「サブドメインのDNSをRoute53に委任する」です。DNSの基本的な機能なのですが知らない人もいるかと思いますので紹介させて頂きます。 DNSの委任についてはこちらの記事が参考になるかと思います AWSのマニュアル読めば理解できる方はこちらをどうぞ。 つまり「example.jp」というドメインがあるとして、www.example.jpやexample.jpについてはDNSは今のままで sub.example.
はじめに 以前、お名前.comで購入したドメインがあって、そのドメインをどうにかしてAWS(特にELB)で使用したいと思い、いろいろ調べたのでその結果を書きます。 Agenda お名前.comのドメインをRoute53に移管する お名前.comにRoute53のDNSを登録してサブドメインを委任する お名前.comのレコードに直接AWSサービスのFQDNをCNAMEで設定する Route53でドメインを購入し、お名前.comのドメインからCNAMEで参照する 前提条件 お名前.comでドメイン取得済み AWSアカウント作成済み 1.お名前.comのドメインをRoute53に移管する ドメインをRoute53に移管するには以下の制約をクリアしなくてはいけない。 お名前.comで購入したドメインが購入から60日以上経過していること 移管対象のドメインがRoute53に登録できるドメインであるこ
The document discusses Amazon FSx for Lustre, a fully managed file system for high-performance computing workloads. It provides fast parallel access to data stored in Amazon S3. The presentation covers how FSx for Lustre delivers scalable throughput and IOPS using Lustre and SSDs. It also discusses how FSx for Lustre can be used to access data stored in S3 for compute workloads run on EC2, with da
ウィスキー、シガー、パイプをこよなく愛する大栗です。 本日DirectoryのマネージドサービスであるAWS Directory Serviceが発表されました。 早速機能を試してみます。 2014年11月4日追記 DNSは個別のインスタンスで設定しない方が良いとの情報がありました。 DNSはVPCのDHPC Optionで設定しましょう。 AWS Directory Service? 一言で言うと、AWSがマネージとしてくれるActive Directoryです。AWS上にドメインを作成する事も出来ますし、オンプレミスのActive Directoryと連携する事も出来ます。また、WorkSpacesやZocaloとの連携も行えます。 なお、AWS Directory ServiceはSambaをベースにしているそうです。 Directoryを作成する AWS Directory Ser
ども、大瀧です。 本日、AWSのマネージドDNSサービスRoute 53にTraffic Flowという機能が追加されました。 早速試してみたのでレポートします。 Route 53 Traffic Flowとは Route 53には、純粋なDNSレコードにルーティングポリシーというRoute 53独自の設定を付与することができます。 ルーティングポリシーについてはAWS再入門のRoute 53の回で説明があると思うので、ここでは割愛します。ルーティングポリシーを適用すると、↓のスクリーンショットのように1つのDNS名に対して複数のレコードが定義されます。 さらに複数のルーティングポリシーを組み合わせることもできるのですが、だんだんと同じDNS名を持つレコードが増えてきて、依存関係や評価ルールを見るのが辛くなってきます。それを解決するのが今回のTraffic Flowです。Traffic F
このブログのドメインをお名前.com から Amazon Route 53 に移管しました。 移管手順はクラスメソッドさんのブログが参考になります。自分の場合、約 6 時間で完了しました。 お名前.com から Amazon Route 53 へドメインを移管する Route 53 のドメイン料金は他社と比べて安いわけではありません(ドメイン登録は Gandi というレジストラを通じて行われます)。人気の gTLD (.com / .net / .org) が 10 〜 12 ドルなので、料金だけ見ればお名前.com の方が安いです。 ではなぜ移管したかと言うと、一番の理由はセキュリティです。 国内レジストラの残念な現状 控えめに言っても、国内レジストラはセキュリティに対して積極的に投資しているようには見えません。 多くの Web サービスが 2 段階認証に対応していく中、国内レジストラは
Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http
こんにちは、虎塚です。 Amazon Route 53でドメインが管理できるようになって数ヶ月がたちました。Route 53では、Amazon Route 53でドメインを購入する | Developers.IOにあるように、ドメインを新規に取得することができます。さらに、別のドメインレジストラで登録していたドメインを、移管して管理することもできます。 そこで今日は、他のドメインレジストラに登録しているドメインをRoute 53へ移管する手順を紹介します。例として、 お名前.comで管理しているドメインを想定して説明します。 ちなみに、移管手続きからAmazon側での処理完了までの所要時間は、移管元の事業者によって異なります(移管元が何も応答しなかった場合、5〜7日間かかるとのことです)。今回は約6時間でした。 はじめに この記事の内容は、AWSの公式ドキュメントをスクリーンショット入りで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く