ある時点で、AWS のすべてのお客様が、できるだけ早く将来に移行したいと言っています。モダナイゼーションの取り組みを簡素化し、成長を促進し、クラウドに適応すると同時に、コストも削減したいと考えています。これらの顧客は通常、組織のさまざまな部門が管理する多様なテクノロジースタック上で実行されている、オンプレミスで実行されている大規模なレガシーアプリケーションスイートを所有しています。さらに困難なことに、これらの組織は多くの場合、厳しいセキュリティとコンプライアンスの要件を満たさなければなりません。 共有の準

概要 クラウドインテグレーション部クラウドソリューション2課の川井です。 今回は、AWSの Sit-to-Site VPN（以降、AWS VPN）と VPNデバイスの FortiGateを使用して、IPsecVPNで 両サーバー間の接続をさせてみようと思います。 また、ネットワーク間の接続は動的ルーティングのBGPを使用します。 最後に、テスト検証として AWS側に仮想PCとしてWindowsサーバを立てて、そこから FortiGate内のInternalのIPアドレスにVPN経由で接続出来るか確認してい

G-gen の佐々木です。当記事では、GitHub Actions で GKE クラスタにリソースをデプロイする際に、 DNS エンドポイント を使用する方法を解説します。 DNS エンドポイントとは GitHub Actions を使用した GKE へのデプロイ 従来の方法 DNS エンドポイントを使用する方法（当記事で解説） DNS エンドポイントを使用する GKE クラスタの作成 シェル変数の設定 ネットワークリソースの作成 GKE クラスタの作成 Direct Workload Identity

G-gen の佐々木です。当記事では、GKE のコントロールプレーンにアクセスするための新しい方法として、 DNS ベースのエンドポイント （DNS エンドポイント）を紹介します。 はじめに GKE におけるコントロールプレーンへのアクセス方法 従来の方法 パブリックエンドポイント プライベートエンドポイント DNS エンドポイント IP ベースと DNS ベースの比較 使用方法 DNS エンドポイントの有効化 コントロールプレーンへのアクセス IP アドレスを使用した接続の無効化 はじめに Google

本ブログは 2024 年 4 月 24 日に公開されたBlog “ Using Protective DNS services with AWS workloads ” を翻訳したものです。 Protective DNS サービス (一般的に PDNS として知られています) は、インフラストラクチャのセキュリティを基礎から強化したい場合は最適なソリューションです。トラフィックのフィルタリングに、ソフトウェアベースのエージェントやデバイスを使用する従来の方法とは異なり、PDNS サービスは独自のアプローチ

SaaS プロバイダーにとって重要な課題は、テナントを特定し適切なリソースにリクエストをルーティングするための、セキュアで拡張性の高いテナントルーティング機構を設計することです。 効果的なテナントルーティングにより、分離性、拡張性、そしてセキュリティが確保されます。 この記事では、AWS 上のマルチテナント SaaS 環境における HTTP リクエストのルーティング戦略について、考慮事項、ベストプラクティス、そして例を交えて説明します。 トランスポート層でのルーティング戦略については、 SaaS 向け A

G-gen の山崎です。 当記事では Google マネージド SSL/TLS 証明書、ロードバランサ、Compute Engine 上の Apache HTTP Server という構成のシステムを構築したので、その手順を解説します。 システム構成 前提知識 Web サーバの構築 VM インスタンスの作成 Apache のインストール index.html の更新 Web サーバ接続確認 インスタンスグループの構築 Google マネージド SSL/TLS 証明書の作成 DNS 認証を作成する CNAM

はじめに

Azure では仮想ネットワーク (VNet) 内に配置されたリソースの名前解決を行う方法として、以下の 4 つの方法が用意されています。 Azure が提供する名前解決 プライベート DNS ゾーンによる名前解決 カスタム DNS サーバーによる名前解決 DNS Private Resolver による名前解決 本稿では、「 Azure が提供する名前解決 」の動作についてAzure 仮想マシン (VM) に注目して確認します。 同じ VNet に配置された VM を名前解決する 次の構成を用意して、同

はじめに こんにちは、クラウドエースの岸本です。 今回は、 Cloud Load Balancing から Cloud Run Functions へルーティングする手順を紹介します。 Cloud Load Bnlancing を用いることで、複数の Cloud Run Functions に対して負荷分散を行うことができるだけでなく、独自のドメインを使用してアクセスすることができます。 リクエスト先の Cloud Run Functions は簡単な Web ページを表示します。 ! 本記事は、前回の記

クラスターから直接ロードバランサーをプロビジョニングすることは、サービスを公開するための Kubernetes ネイティブの方法でしたが、場合によってはアプリケーションのアーキテクチャと合わないプロビジョニングプロセスになることがあります。そのため、別のメカニズムが必要とされます。この投稿で説明するユースケースでは、新しいロードバランサーをプロビジョニングせず、既存の Application Load Balancer (ALB)/ Network Load Balancer (NLB) のトラフィックを

こんにちは！イーゴリです。 DNSの脆弱性 DNSの通信は非暗号である DNSSECが守ってくれる攻撃パターン (キャッシュポイズニング攻撃) DNSSECとは DNSSEC導入のメリット DNSSEC導入のデメリット Amazon Route 53でDNSSECの有効化 DNSSECの有効化前の状態の確認 DNSSECを有効にする KSKのキーの作成 DSレコードの作成 Route 53 レジストラ 別のドメインレジストラ ZSKとKSKの鍵の責任分担 DNSSECの有効化後の状態の確認 考慮事項 課金

技術研究所開発室の山本(和)です。私は、同僚の日比野と一緒にDNSのフルリゾルバ(キャッシュサーバ)の実装を進めています。このフルリゾルバの名前は bowline と言います。結びの王様である「もやい...

本記事は 夏休みクラウド自由研究 8/17付の記事です 。 こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 昨日の寺内の記事 で、VPC環境に AWS CloudShell を作成し、ネットワークまわりのテストにも使用できそうだという話が出ていました。本記事では、ネットワークテストツールとしてCloudShellを利用できるのか、という観点でもう少し考察してみることにします。 VPC環境にCloudShellを作成する手順については、上記記事をご覧くだ

はじめに