F5とAWS：クラウドにおける高度なアプリケーションデリバリサービス
はじめに
Amazon Web Services（AWS）は、パブリッククラウドのInfrastructure-as-a-Service（IaaS）において、最大規模かつ最も広く普及しているプロバイダーとなっています。組織は、オンプレミスインフラストラクチャを購入または再構成することなく、アプリケーションスタック全体を構築、テスト、デプロイできるようになりました。本番アプリケーションでは、Webアプリケーションファイアウォール（WAF）、SSLアクセラレーション、コンテンツベースルーティング、負荷分散、DDoS緩和、アイデンティティおよびアクセス管理、プロトコルアジリティなどの高度なアプリケーションデリバリサービスを活用できます。これにより、重要なアプリケーションの高速化、高機能化、安全性の向上が可能になります。クラウドネイティブなAWS環境へのデプロイでは、F5ソリューションにより、これらのアプリケーションサービスをAWSクラウド環境へシンプルかつ容易に提供できます。
Amazon Web Servicesとは
IaaSプロバイダーであるAmazon Web Services（AWS）は、アプリケーションの開発に十分なコンピューティングインフラストラクチャを従量制で提供しています。設備投資や保守に費用をかけることなく、包括的なアプリケーションスイートを開発し、デプロイできます。AWSは、オンプレミスと同様のコンピューティングインフラストラクチャに加え、アプリケーションサービス、インフラストラクチャの自動スケーリング、複数のロケーションでのアプリケーションホスティングも提供します。こうした追加機能があるため、AWSのベストプラクティスは従来型データセンターのベストプラクティスとは異なります。AWSと従来型データセンターの違いをより深く理解するには、AWSがサービスを提供する仕組みを把握することが重要です。
インフラストラクチャサービス
AWSを最大限に活用するために、地理的分散、コンピューティングインスタンス、ネットワーク、ストレージの概念など、AWSのIaaSサービスにおける重要な特性をいくつか見ていきましょう。
地理的分布
AWSを理解するには、まずリソースが物理的にどのように分散されているかを把握する必要があります。最上位の単位として、AWSには複数のリージョンがあり、それぞれが米国東部などの広い地理的範囲をカバーしています。各リージョンには複数のアベイラビリティゾーンが含まれています。アベイラビリティゾーンは、相互に障害の影響を受けないよう分離して設計されていることから、このように呼ばれます。あるアベイラビリティゾーン（AZ）で発生した障害が、同じリージョン内の別のAZに波及することはありません。各AZは分離されていますが、同じリージョン内のAZ間は低レイテンシーのネットワークリンクで接続されています。可用性を確保するため、リージョン内の複数のAZにまたがって機能を冗長化する設計パターンが用意されています。
コンピューティング
コンピューティングインスタンスは、Amazon Machine Image（AMI）と呼ばれるソフトウェアディスクイメージを基に作成されます。各AMIは不変であり、それを使用するコンピューターからは読み取り専用です。AMIを使用してコンピューティングインスタンスを起動すると、クラウド上で仮想マシンが稼働します。コンピューティングインスタンスの仮想ハードウェア特性は、インスタンスで利用可能なCPU数やRAM容量など、さまざまに設定できます。
ネットワーク
各コンピューティングインスタンスはVirtual Private Cloud（VPC）内に存在します。VPCは、物理環境におけるLANにほぼ相当します。各VPCは論理的に分離されています。VPCは複数のサブネットで構成でき、サブネット間では暗黙的にルーティングされます。パブリックサブネットはインターネットからルーティング可能ですが、プライベートサブネットは内部からのみ利用できます。完全なアプリケーションをデプロイするには、1つ以上のコンピューティングインスタンスをVPC内にデプロイします。コンピューティングインスタンスまたはロードバランサーにDNSエントリが割り当てられている場合、VPC間で通信できます。
ストレージ
前述のとおり、各AMIは、それを使用するインスタンスから変更することはできません。永続ストレージ向けに、AWSはさまざまなソリューションを提供しており、主なものにSimple Storage Service（S3）とElastic Block Storage（EBS）があります。S3は、オブジェクトを名前で保存し、アクセスできるオブジェクトストレージサービスです。オブジェクトのサイズは0バイト～5 TBです。実際、各AMIは暗黙的にS3オブジェクトとして扱われます。オブジェクトは変更できず、作成と削除のみが可能なため、写真や仮想マシンイメージなど、比較的静的なコンテンツに適しています。
EBSは、従来型のストレージに近い機能を提供します。EBSに接続されたコンピューティングインスタンスからは、EBSが従来型のハードディスクとして認識されます。EBSボリュームに同時に接続できる実行中のインスタンスは1つだけであるため、EBSを共有ストレージとして使用することはできません。
サービスのスケーリング
AWSは、主要なインフラストラクチャコンポーネントに加え、アプリケーションのスケーリングを可能にする各種サービスも提供しています。AWSではインフラストラクチャリソースを迅速にプロビジョニングできるため、Amazonはそれらのリソースの自動スケーリングと負荷分散を可能にするソリューションを開発しました。
負荷分散
AWSは、Elastic Load Balancing（ELB）サービスを提供しています。当初、ELBはレイヤー4で動作するシンプルなロードバランサーを指し、プール内の複数の正常なノードにトラフィックを分散していました。プールは複数のアベイラビリティーゾーンにまたがって構成できるため、1つのアベイラビリティーゾーンで障害が発生した場合にも自動的に冗長性が確保されます。このロードバランサーは基本的なネットワークレイヤー7機能も一部備えていますが、主にレイヤー4で動作し、TCPトラフィックをラウンドロビン方式でプール内のノードにルーティングします。ヘルスチェックによって利用可能なノードが判定され、そのノードがトラフィックの転送先候補となります。現在、AWSでは、この初期のロードバランサーを新しいApplication Load Balancer（ALB）と区別するため、Classic Load Balancerと呼んでいます。
自動スケーリング
AWSではスタンバイ容量を利用できるため、プール内のノードをスケーリングするオプションを提供できます。AWS CloudWatchサービスは、プール内の各ノードのパフォーマンス指標を監視します。CPU使用率が5分間にわたって60%を超える場合など、事前定義されたしきい値を超えると、別のノードがプロビジョニングされます。反対に、下限のしきい値を下回ると、ノードが削除されます。設計者は、プール内のノードの最大数と最小数、およびノードの作成や削除をトリガーするしきい値を指定できます。ロードバランサーの背後で自動スケーリングを使用すると、負荷に応じて必要な分だけノードプールを拡張または縮小できます。
F5アプリケーションデリバリサービス
アプリケーションはビジネスルールやロジックを処理しますが、大規模な本番環境での展開、管理、運用に必要な堅牢性が不足していることが少なくありません。F5ソリューションは、以下の表に示す高度なアプリケーションデリバリサービスを提供することで、アプリケーションの高速化、高機能化、セキュリティ強化を実現します。
F5の高度なアプリケーションデリバリサービス
アプリケーションレベルの監視
- 高度なアプリケーションヘルスチェック（複数ステップのモニターを使用）
- マルチレベルのヘルスチェック（データベースとアプリケーションの両方が利用可能かどうかの確認など）
- 非HTTPヘルスチェック（SIP、Microsoft Windows SQL Server、FTPなど）
- 高度なアルゴリズムにより、最も良好に稼働しているサーバーへトラフィックを効率的に分散
グローバルな可用性
- 異なるクラウドプロバイダーやデータセンターが混在する環境全体でのアプリケーション可用性
- BIG-IPの高度なモニターとの統合
- DNSSecのサポート
高速化
ネットワークとトランスポートの最適化
- WANおよびセルラーネットワーク経由の配信に最適化できる、構成可能なTCPスタック
- バックエンドインフラストラクチャを変更することなく、追加の圧縮とリクエスト多重化のメリットをもたらすHTTP/2ゲートウェイ
アプリケーションとデータの最適化
- 検出されたネットワークまたはクライアントの特性に応じた、画像の選択的なオンザフライ最適化
- 適応型圧縮とTCP最適化によるSSL暗号化トンネル経由のWAN高速化
よりスマート
データパスのプログラマビリティ
- アプリケーションデータのあらゆる側面を読み取り、書き込み、検査する機能を含め、アプリケーショントラフィックをプログラムで完全に制御
- イベント駆動型の包括的な言語
コントロールプレーンのプログラマビリティ
- サーバー負荷、アプリケーションの動作、インフラストラクチャの変化などのイベントに応じて構成を変更する機能
- 完全自律型または外部API駆動型のトリガー
より安全
高度なネットワークファイアウォールサービス
- 地理的位置やエンドポイントのレピュテーションなど、単なるIP:port:protocol以外の基準に基づくトラフィック制御の判断
- HTTPプロトコルの検証
- 曜日と時刻のスケジュール
Web Application Firewallサービス
- Webアプリケーションの脅威を特定し、悪意のあるトラフィックをブロックする包括的なツール
- 送信データの損失防止（DLP）サービス
アクセスおよびアイデンティティサービス
- 2要素認証トークン、CAPTCHA、地理的制限などの高度な認証サービス
- クライアント証明書の確認とエンドポイントの検査
- SAMLサービスプロバイダー（SP）およびアイデンティティプロバイダー（IdP）サービス
サービス拒否（DoS）攻撃の緩和
- プロアクティブなボット対策
- レイヤー7 DoSの検知と緩和
SSLと暗号化
- SSL復号、トラフィック検査、再暗号化
- コンピュートノードのリソースからSSLワークロードをオフロード
高度なアプリケーションデリバリサービスにより、アプリケーションの可用性とセキュリティを高めながら、より高いパフォーマンスを実現できます。これらのサービスは、各アプリケーションから独立した戦略的な制御ポイントに配置できます。サービスをアプリケーションのビジネスロジックから分離することで、開発チームにインフラストラクチャ、管理、パフォーマンスに関する負担をかけることなく、アプリケーションがビジネスニーズに対応できるようになります。また、戦略的な制御ポイントを設けることで、ガバナンス上の課題を各アプリケーションから独立して一貫した方法で処理できます。
すべてを統合：F5とAWS
F5は、AWSインフラストラクチャとのクラウドネイティブな統合を提供することで、組織がAWS環境を最大限に活用し、アプリケーションのパフォーマンス、可用性、セキュリティを向上できるよう支援します。次のセクションでは、AWSとF5がどのように連携するかを説明します。
ブートストラップ
サーバーインスタンスを汎用イメージから起動する場合、ホスト名やIPアドレスなどのパラメーターを変更したり、構成を設定したりすることが適切な場合がよくあります。クライアントマシンでは、これらのパラメーターはDHCPを介して設定されますが、サーバーのパラメーターをDHCPで設定すると、問題が発生することが少なくありません。また、ネットワーク設定に加えて、特定のインスタンスで特定のソフトウェアパッケージやソフトウェア構成が必要になる場合もあります。
BIG-IPを導入する場合、管理者は、BIG-IP Local Traffic Manager (LTM)の仮想サーバーやプールの構成、BIG-IP Application Security Managerの特定のWAF構成、BIG-IP Advanced Firewall Managerのファイアウォール設定など、各モジュールの構成を自動化したいと考えることがあります。サーバーインスタンスをインストールする際にも同様の課題があり、正しく機能させるにはベースイメージに追加の構成が必要です。
AWSでは、インスタンスを構成する主な方法として、新しいAMIを作成する方法と、cloud-initを使用して起動プロセス中にサーバーを変更する方法の2つが用意されています。新しいAMIの作成は、複数のインスタンスに共通し、頻繁に更新される可能性が低い変更に適しています。一方、cloud-initは、影響するインスタンスが少なく、存続期間が短い変更に適しています。
AMI
長期間維持することが見込まれる変更や、複数のインスタンスに共通する変更には、目的の構成に近いAMIからマシンを起動し、新しいAMIを作成する方法が適しています。管理者が実行中のインスタンスに必要な変更を加えた後、そのインスタンスを停止し、新しいAMIを生成してAWSに登録します。以後、このAMIから起動するすべてのインスタンスには、変更が適用済みの状態になります。この方法では変更が実質的に永続化され、また新しいAMIの生成には時間がかかる場合があるため、通常、AMIに組み込むのは、長期間使用し、複数のインスタンスで利用できる変更です。また、一部のcloud-initプロセスには時間がかかる場合があるため、AMIを使用すると起動時間を短縮できるという利点もあります。
Cloud-init
新しいAMIへの組み込みに適さない必要な変更には、インスタンスの起動時に毎回スタートアップスクリプトを実行できるcloud-initが適しています。cloud-initを使用すると、簡単な変更やインスタンス固有の変更をインスタンスに組み込めます。
cloud-initのデメリットとして、パッケージのインストールなどの構成変更を起動時に実行する必要があるため、起動に時間がかかることが挙げられます。起動時間が長くなると、オートスケーリングが有効に機能しなくなる可能性があり、オートスケーリングを使用するシナリオに実質的な影響を及ぼします。そのため、時間のかかる変更はcloud-initで行わず、新しいAMIに組み込む必要があります。
変更を複数のインスタンスに適用できるものの、すべてのインスタンスには適用できない場合、構成管理が煩雑になることもあります。たとえば、特定の仮想サーバー構成を持つBIG-IP環境を、ある自動スケーリンググループで使用するとします。そのグループ内のマシンには1つのAMIを使用し、別の自動スケーリンググループにある他のBIG-IPマシンには別のAMIを使用できます。自動スケーリンググループごとに1つのAMIを使用することで、cloud-initプロセスでは各ホスト固有の変更のみが必要になります。グループに共通する変更はAMIに組み込めます。この方法の欠点は、すべてのマシンに共通する変更を行うたびに、AMIを更新する必要があることです。
自動スケーリング
アプリケーションは通常、複数のユーザーに機能を同時に提供します。アプリケーションの利用が拡大すると、実行環境であるコンピューターの処理能力を超える場合があります。アプリケーションの要件がコンピューターの処理能力を上回った場合は、処理能力を増強する方法を検討する必要があります。スケーリングには、スケールアップ、パイプライン化、スケールアウトという3つの一般的なアプローチがあります。
スケールアップ
スケールアップは、既存のコンピューターをより高速なものに置き換えるだけで済むため、容量を増やす最も簡単な方法です。より高速なコンピューターを導入すれば、アプリケーションやインフラストラクチャを変更することなく、アプリケーションのあらゆる処理と、そのコンピューター上で稼働するその他のサービスを高速化できます。スケールアップの欠点は、パフォーマンスの向上に伴ってコストが指数関数的に増加する傾向があり、やがて費用対効果が低下する点です。一定のしきい値を超えると、スケールアップにかかるコストは現実的ではなくなります。
パイプライン処理
パイプライン処理は、組立ラインのようにワークロードを一連のステップに分解することで実現します。各ステップを異なるコンピューターがそれぞれ独立して処理できれば、全体のスループットを向上できます。ただし、パイプライン処理で向上するのはスループットのみであり、多くの場合、レイテンシーが犠牲になります。言い換えると、パイプライン処理は全体的なパフォーマンスを向上できる一方で、単一ユーザーまたは単一リクエストのパフォーマンスを低下させる可能性があります。もう1つの欠点は、分解可能なワークフローを深く理解し、その理解に合わせてインフラストラクチャを構成する必要があることです。その結果、インフラストラクチャに関する意思決定がビジネスロジックと密接に結び付きます。これは、多くの組織が目指している方向とは正反対です。
スケールアウト
スケールアウトでは、アプリケーションやコンピューター自体には手を加えず、サーバープール全体にリクエストを均等に分散します。一般に、アプリケーションは複数の独立したリクエストを同時に処理するため、同一構成のアプリケーションサーバーで構成されるプール全体にリクエストを安全に分散できます。また、スケールアウトには冗長性が向上するという利点があり、プールメンバーのいずれかに障害が発生しても、アプリケーション全体が停止することはありません。一方、プール内の各ノードにリクエストを均等に分散するには、アプリケーション外部で複雑なオーケストレーションが必要になるという欠点があります。
AWS auto scale
AWS auto scaleでは、必要とするアプリケーションの容量をスケールアウト方式で拡張します。CloudWatchサービスは、プール内のノードを監視します。ノードが事前定義されたしきい値を超えると、CloudWatchは必要に応じて新しいノードを自動的に起動するか、プール内のノードを停止します。BIG-IPプラットフォームでは、このプロセスを2つの方法のいずれかで実行できます。BIG-IPインスタンスの数を変更する方法と、単一のBIG-IPインスタンスの背後にあるプール内のノード数を変更する方法です。この2つの方法の違いは、スケーリングの対象がBIG-IPインスタンスかプールかという点にあります。
最初のシナリオでは、BIG-IPプールを2つのELBデバイスの間に配置します。1つ目のELBデバイスはBIG-IPメンバーのインスタンス化と終了を制御し、2つ目のELBデバイスは各BIG-IPインスタンスのサーバープールにおける唯一のエントリとなります。このアプローチは、BIG-IPインスタンスがSSL終端やWebアプリケーションファイアウォールなどの高度なアプリケーションデリバリサービスを提供する場合に適しています。1つ目のELBデバイスは負荷分散を実行すると同時に、必要に応じてプールを拡大または縮小します。
2つ目のシナリオでは、CloudWatchを介してバックエンドプールのメンバー数が増減しますが、負荷分散はBIG-IPインスタンスが実行します。BIG-IPインスタンスはAWSと通信し、プールに追加またはプールから削除されるノードを検出します。このアプローチは、iRulesスクリプト言語などの高度な負荷分散機能を使用する場合や、URLまたはコンテンツに基づいてリクエストを振り分ける場合に適しています。このような場合、バックエンドプール内のサーバー負荷を管理するには、1つのBIG-IPインスタンスで十分です。
セキュリティとIAM
BIG-IPインスタンスは、少なくとも2つのシナリオでAWSインフラストラクチャと連携する必要があります。1つ目は、複数のゾーンにまたがるAWSデプロイメントで、AWS Elastic IPに関連付けられたIPアドレスを変更する場合です。2つ目は、プール内のサーバー数を増減するAWS CloudWatchサービスによって追加または削除されたプールメンバーを、BIG-IPインスタンスが認識する必要がある場合です。インフラストラクチャとの各連携はAPI呼び出しを介して行われます。API呼び出しを行う他のソフトウェアと同様に、BIG-IPインスタンスもAWSに対して認証を行う必要があります。一般に、AWSへの認証方法には、認証情報を使用する方法とIAMロールを使用する方法の2つがあります。
認証情報
最も簡単な認証方法は、API呼び出しに適切な認証情報を含めることです。AWSの認証情報はアクセスキーとシークレットキーで構成され、それぞれユーザー名とパスワードにほぼ相当します。管理者が認証情報を生成し、開発者がそれをアプリケーションに組み込みます。これにより、アプリケーションは適切なAPI呼び出しにアクセスできるようになります。
認証情報をアプリケーションに埋め込む方法は簡単ですが、セキュリティ上のリスクがあります。開発者がアプリケーション内の認証情報を保護しない限り、第三者や他のソフトウェアに認証情報を取得され、悪用される可能性があります。また、この方法では、ソフトウェアを変更せずに認証情報だけを変更することが困難です。認証情報の使用は簡単なテストには妥当な方法ですが、本番環境のソリューションでは別の認証方法を使用する必要があります。そのため、AWSのベストプラクティスでは、保存された認証情報をアプリケーションで使用しないことを推奨しています。
アイデンティティおよびアクセス管理
API呼び出しの認証には、IAMロールを使用することでセキュリティをさらに強化できます。AWS Identity and Access Management（IAM）を使用すると、AWSインフラストラクチャへのアクセスを管理できます。BIG-IPマシンなどの任意のコンピューティングインスタンスには、特定の機能セットを許可するIAMロールを割り当てることができます。インスタンスの起動時に、IAMはそのインスタンス用の一時的な認証情報を生成します。この認証情報はインスタンスの稼働中のみ有効で、指定されたAPI機能だけを使用できます。IAMロールを設定したBIG-IPインスタンスは認証情報を保存せず、必要なインフラストラクチャAPIにのみアクセスできるため、認証情報に基づく認証よりもセキュリティが向上します。
マルチゾーン可用性
前述のとおり、AWSのデータセンターは地理的なリージョンに配置され、各データセンターはアベイラビリティゾーン（AZ）に属します。リージョン内の各AZは、電源、ネットワーク、建物を含め、他のAZとリソースを共有していません。実際、各AZは同じリージョン内の他のAZから地理的に分離されています。このようにゾーンが分離されているため、AWS利用者は、あるAZに影響する事象が別のAZには影響しないと考えることができます。つまり、原則として、ある時点で利用できなくなる可能性があるのは、リージョン内の最大1つのAZです。そのため、2つ以上のアベイラビリティゾーンにまたがってデプロイされたサービスは、継続的に利用できることになります。
BIG-IPプラットフォームは、コンピューティングインスタンスに本質的に関連付けられていないIPアドレスであるAWS Elastic IPを使用して、AWSのAZ間で高可用性をサポートします。このIPアドレスは、稼働中のコンピューティングインスタンスのプライベートIPアドレスに動的に転送できます。複数のゾーンにまたがる高可用性を実現するため、同一構成のBIG-IPインスタンスとアプリケーションサーバーのセットを、それぞれ別のAZに配置します。最初に、Elastic IPをいずれかのBIG-IPインスタンスに割り当てます。各クライアントはElastic IPに接続し、その接続は、いずれかのBIG-IPインスタンスのプライベートIPアドレスに転送されます。障害が発生した場合、もう一方のBIG-IPインスタンスがAWSへのAPI呼び出しを行い、Elastic IPアドレスの転送先を自身に変更するよう要求して、その役割を引き継ぎます。
Elastic Load Balancer
ELBと連携することで、BIG-IPプラットフォームは、複数のAZやBIG-IPノードの自動スケーリングなどのAWS機能とシームレスに連携するアプリケーションサービスを提供できます。
BIG-IPインスタンスの前段にELBを配置すると、複数のAZにまたがるデプロイが簡素化されます。これは、BIG-IPインスタンスがアプリケーションサービスを提供する各AZ内の個々のアプリケーションスタックに対して、ELBがシームレスにトラフィックを分散できるためです。このアプローチにより、複数のAZにまたがる負荷分散が簡素化されます。
BIG-IPインスタンスに伸縮性が必要な場合、自動スケーリング機能を備えたELBにより、BIG-IP仮想アプライアンスのプールを自動的にスケールアウト／スケールインし、Webアプリケーションファイアウォール、アイデンティティ管理、SSL終端などのアプリケーションサービスを提供できます。ELBサンドイッチ構成では、トラフィックは最初のELBにルーティングされ、BIG-IPインスタンスのプールに対して負荷分散と自動スケーリングが行われます。BIG-IPプール全体の構成を簡素化するため、各BIG-IPインスタンスのサーバープールには単一のELBアドレスを設定します。その後、2番目のELBがトラフィックを下流のサーバープールにルーティングします。
ELBとBIG-IPのトポロジーをさまざまに組み合わせることで、いずれか一方だけでは実現できない自動スケーリング、可用性、アプリケーションサービスを提供できます。ELBとBIG-IPプラットフォーム双方の利点を活用することで、アーキテクトは個々の導入環境に必要なレベルのサービスを提供できます。
Cloud Formationテンプレート
反復可能なスクリプト化されたデプロイを実現するため、AWSはCloud Formation Templates（CFT）を提供しています。これにより、デプロイと継続的な管理の両方が簡素化されます。目的のサービスまたはアプリケーションアーキテクチャ向けにCFTを作成すると、AWSはそれを使用してアプリケーションを迅速かつ確実にプロビジョニングできます。CFTはDevOps環境で特に有用であり、テストおよび本番環境へのデプロイに向けた反復可能なプロセスをチームが容易に構築できます。
F5は、CFTを使用したBIG-IPインスタンスのデプロイをサポートするだけでなく、一般的なBIG-IPデプロイ向けのリファレンスCFTファイルも複数提供しています。
リファレンスCFTファイルのパラメーターを調整することで、BIG-IPインスタンスやその背後にあるバックエンドサーバーの自動スケーリングをはじめ、より複雑なシナリオを含むさまざまなシナリオに応じて、BIG-IPソリューションをスクリプトでデプロイできます。CFTとF5ソリューションを使用して、AWS内で繰り返し実行するデプロイを自動化することで、複雑なアプリケーション環境を迅速かつ少ない作業でデプロイできます。
ドキュメント
もちろん、テクノロジーは十分に活用できなければ、ほとんど役に立ちません。そのため、F5では充実したドキュメントを提供しています。BIG-IPプラットフォーム全般に関するドキュメントに加え、AWS内のBIG-IPインスタンスに固有の情報もご用意しています。ご不明な点がある場合は、まずAsk F5をご覧ください。
ドキュメントタブでは、特定のBIG-IPモジュールに関する情報に加え、AWS連携に関するセクション全体を参照できます。AWSポータルには、入門情報から複雑な導入シナリオまで、ドキュメント、記事、コミュニティ、各種リソースを検索できるインターフェースが用意されています。
ドキュメントで解決できないご質問については、F5 DevCentralコミュニティが回答とサポートを提供します。
まとめ
パブリッククラウド導入の流れは、もはや一過性のブームではなく、ITにおける持続的なトレンドとなっています。世界最大規模かつ最も包括的なパブリッククラウドサービスプロバイダーであるAmazon Web Servicesを利用することで、組織はオンプレミス機器を使用せずにアプリケーションを構築、テスト、デプロイできます。F5は、高度なアプリケーションデリバリーサービスをAWSエコシステムの一部として提供し、AWSクラウド環境でアプリケーションの高速化、スマート化、セキュリティ強化を支援できるよう構成しています。
2017年3月14日公開