こんにちは、菊池です。 今回紹介するのは、先日東京リージョンでも使えるようになったばかりの、AWS Client VPNについてです。 [AWS]踏み台をワンチャンなくせる!?VPC接続にClient VPNを使ってみよう AWS Client VPNでは、上記記事にて紹介した相互認証のほか、Active Directory認証が利用可能です。Windowsクライアントからの、Active Directory認証による接続方法を試してみました。 Active Directory認証によるClient VPN 先の、相互認証との違いは、以下の2点のみです。 あらかじめDirectory Serviceを作成しておく 認証方式にActive Directory認証を選択 まずはDirectory Serviceの立ち上げです。今回はSimple ADを立ち上げました。 続いて、Client V
こんにちは、菊池です。 AWS Client VPNを検証していますが、いよいよ、このサービスの真骨頂とも言える、VPCを経由したインターネットアクセスを試します。 従来からある、Site to Site VPNやDirectConnectといった外部との接続サービスに対して、Client VPNだけがもつ最大の特徴が、VPC外へのアクセスが公式にサポートされているという点です。 AWS Client VPN の詳細 上記のドキュメントにも記載の通り、Client VPNでは、VPC内のリソースだけではなく VGWを経由したオンプレミスリソース VPC Peeringを経由した他のVPC VPCエンドポイント IGWを経由したインターネットアクセス が可能になっています。 Client VPN からのインターネットアクセス それではやってみます。あらかじめ、Client VPN エンドポイ
社内勉強会でAWSのSite to Site VPN/DirectConnectのBGPについて紹介する機会がありました。その延長として、具体的なユースケースを実機を使ってどのように動作するか紹介します。 こんにちは、菊池です。 AWSとオンプレミスの拠点を接続するSite to Site VPNやDirectConnectでは、経路情報を交換/制御するために動的ルーティングプロトコルのBGPを使用します。このBGPの経路交換ですが、経験がないとなかなかイメージがつかみにくく、また、オンプレ側の機器も必要なので検証も気軽にやりにくいところがあります。今回は、BGP経路情報がどのように広報され、経路制御されるのか、Site to Site VPNのいくつかのパターンで実際に試してみましたので、紹介します。 基本的な仕様 具体的な設定の前に、基本的な仕様の確認です。Site to Site V
こんにちは、菊池です。 Route53を使って管理しているドメインで、サブドメイン発行して別のHosted Zoneに権限を委譲する方法を紹介します。 ユースケース 例えば、以下のようなケースでは組織Aが管理しているexample.comから、サブドメインjp.exampleを組織Bに権限委譲しています。 組織A(委譲元) 管理ドメイン:example.com 組織B(委譲先) 管理ドメイン:jp.example.com このように、権限を委譲されることで組織Bでは自由にjp.exampleを利用することができるようになります。 AWSのマネージドDNSサービスであるRoute53で発行・運用しているドメインでも、上記のようにサブドメインを委譲することができます。企業で保有しているトップドメインを、サービスの単位などで適切に委譲していくことで、運用を分離させることができます。 やってみた
こんにちは、菊池です。 衝撃の新機能です。VPCに割り当てるCIDRが拡張可能になりました! Amazon Virtual Private Cloud (VPC) now allows customers to expand their existing VPCs 「一度作成したVPCのCIDRは変更できない」という常識は過去のものになりました。この新機能によりVPCがスケール可能になりますので、EC2、RDS、ELBといったVPC内リソースが想定以上に拡張していくケースにも対応できます。また、あらかじめ作成時に巨大なCIDRを確保する、といったことも必要なくなることでしょう。 VPC CIDRの拡張 VPC作成時に割り当てるCIDRブロックがプライマリCIDRとなり、あとからセカンダリCIDRを追加可能になりました。 Associating a Secondary IPv4 CIDR B
こんにちは、菊池です。 AWSで最も基本的なサービスの1つともいえるEC2ですが、その設定の中で"拡張ネットワーキング"と"プレイスメントグループ"というのがあるのをご存知でしょうか? 目新しい機能ではありませんし、意識して設定しなくても不都合が発生するものでもありませんのでデフォルト状態で利用されている方もいるのではないでしょうか。 Linux の拡張ネットワーキング 拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。 プレイスメントグループ プレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。サポートされているインスタンスタイプとともにプレイスメントグループを使用すると、アプリケーションが低レイテンシーの 10 Gbps (ギガビット/秒)
こんにちは、菊池です。 CloudFormationは、テンプレートを利用することでAWSの環境を簡単にプロビジョニングできるサービスです。先日のアップデートで、複数のAWSアカウント、リージョンに対しCloudFormationのスタックを作成できる新機能、StackSetsがリリースされました。 AWS CloudFormation Supports Multiple Account and Region Provisioning with StackSet サンプルテンプレートを使ってStackSetsを利用してみましたので紹介します。 CloudFormation StackSets CloudFormation StackSetsを使うことで、1つのテンプレートから複数のAWSアカウント、リージョンに対しStackを作成することが可能です。 Working with AWS Cl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く