翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# でのネットワークアクセスのアンチパターン AWS クラウド
<a name="anti-patterns"></a>

*アンチパターン*とは、繰り返し起こる問題に対して頻繁に用いられる解決策で、その解決策が逆効果であったり、効果がなかったり、代替案よりも効果が低かったりするものです。このセクションで説明する設計オプションは通常機能しますが、大きな欠点があります。可能な場合は、より良い代替手段が利用できるため、避ける必要があります。

**Topics**
+ [アベイラビリティーゾーンの との不一致 AWS PrivateLink](#anti-patterns-az-mismatch)
+ [AWS Site-to-Site VPN 間の接続 AWS アカウント](#anti-patterns-vpn-connection)

## アベイラビリティーゾーンの との不一致 AWS PrivateLink
<a name="anti-patterns-az-mismatch"></a>

を介してアプリケーションへのアクセスを提供する場合 AWS PrivateLink、SaaS コンシューマーは、アプリケーションがデプロイされているアベイラビリティーゾーンでのみインターフェイス VPC エンドポイントを作成できます。たとえば、アプリケーションが `use1-az1`と にデプロイされている場合`use1-az2`、コンシューマーは に VPC エンドポイントをデプロイできません`use1-az3`。SaaS サービスをすべてのアベイラビリティーゾーンにデプロイすることをお勧めします。の大部分 AWS リージョン には 3 つのアベイラビリティーゾーンがありますが、それ以上のアベイラビリティーゾーンもあります。包括的なリストについては、[「リージョンとアベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)」を参照してください。を選択するときは、アベイラビリティーゾーンの数を考慮してください AWS リージョン。

**注記**  
アベイラビリティーゾーン名はアベイラビリティーゾーン IDs。詳細については、[「 AWS リソースのアベイラビリティーゾーン IDs](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)」を参照してください。

SaaS プロバイダーがすべてのアベイラビリティーゾーンにデプロイしないことを選択した場合、いくつかの結果があります。SaaS サービスが `use1-az1`と にデプロイされているが`use1-az2`、コンシューマーが を含む 3 つのアベイラビリティーゾーンすべてを使用しているとします`use1-az3`。インターフェイス VPC エンドポイントは `use1-az1`と のコンシューマー側にデプロイされ`use1-az2`、 のアプリケーションはこれらのエンドポイントのいずれかにアクセス`use1-az3`する必要があります。まず、一致しないアベイラビリティーゾーンのサブネットからそれぞれの VPC エンドポイントへのトラフィックを許可する必要があります。コンシューマーは、リージョン AWS PrivateLink DNS 名を使用することを決定できます。これにより、VPC エンドポイントのいずれかに解決され、2 つのエンドポイント間でトラフィックが均等に分散されます。または、コンシューマーは、 などのエンドポイントにトラフィックを直接送信することを選択できます`use1-az2`。これにより、トラフィックの 67% が でプロバイダー側に到着`use1-az2`し、33% が に到着します`use1-az1`。次の図は、このシナリオを示しています。

![トラフィックはアベイラビリティーゾーンに均等に分散されません。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-network-access-options/images/antipattern-az-mismatch.png)


大量のコンシューマーとトラフィックの不均等な分散により、ワークロードが 1 つのアベイラビリティーゾーンで容量の問題が発生し、別のアベイラビリティーゾーンで容量不足になる可能性があります。この問題に対処するために、SaaS プロバイダーは Network Load Balancer で[クロスゾーン負荷分散を有効にすることで、トラフィックを均等に負荷分散](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#cross-zone-load-balancing)することを決定できます。これには追加料金が発生します。

サービスプロバイダーが一致するアベイラビリティーゾーンが 1 つしかない場合、すべてのトラフィックは 1 つのエンドポイント経由で入ります。これにより、不均衡がさらに大きくなります。その結果、SaaS サービスはコンシューマーにとって高可用性ではなくなりました。コンシューマーが使用していない追加のアベイラビリティーゾーンでアプリケーションを提供するかどうかは関係ありません。最悪の場合、SaaS プロバイダーは、同じアベイラビリティーゾーンを使用しないコンシューマーにサービスを提供できない可能性があります。

まれに、SaaS プロバイダーがすべてのアベイラビリティーゾーンにアプリケーションをプロビジョニングする実行可能なオプションがない場合、欠落しているアベイラビリティーゾーンにのみサブネットを作成し、それらの空のアベイラビリティーゾーンにサービスを拡張することもできます。その後、クロスゾーン負荷分散は、着信トラフィックを他のアベイラビリティーゾーンの実際のアプリケーションエンドポイントに分散できます。

## AWS Site-to-Site VPN 間の接続 AWS アカウント
<a name="anti-patterns-vpn-connection"></a>

オンプレミス環境からクラウドに移行する企業は、ネットワーク全体をリフトアンドシフトしようとすることがあります。これは、オンプレミスとクラウドのネットワーキングプラクティスに大きな違いがあるため、問題を引き起こす可能性があります。この考え方の移行が行われない場合、ある VPC AWS Site-to-Site VPN から別の VPC への接続などが発生する可能性があります。このアプローチでは、 の専用ネットワーキングサービスを活用できないため AWS クラウド、管理が簡素化され、パフォーマンスが向上します。クラウドネイティブ設計に適応することで、運用上のオーバーヘッドが軽減され、VPCs 間の信頼性とスケーラビリティが向上します。

この接続オプションを SaaS プロバイダーとして提供することを検討している場合は、自分またはコンシューマーにその理由を尋ね AWS Site-to-Site VPN てください。次に、これらの要件から逆算して、より良い接続オプションを見つけます。このガイドのサービス[機能の比較](services.md#services-capabilities)セクションには、オプションの特定に役立つマトリックスが含まれています。次に、このガイドの関連セクションを参照して、ユースケースに対応するアーキテクチャアプローチを見つけることができます。