その設計、本当にクラウドがポイントですか？

何を優先するかがポイント

ポイントになるのは何を目的としたクラウドへの移行であるかであり、本来は性能や可用性、運用保守性などを考慮しつつ、品質・コスト・納期のバランスを考え設計するべきです。
「クラウドだから〇〇できないか」という気持ちはわかりますが、本来の目的・達成すべき目標・優先順位を見失っては本末転倒です。
「クラウドネイティブなシステムにしたい！」という思いを最優先するのであれば、製品Aを採用せずに、クラウドのマネジージドサービスをフル活用することをおすすめします。
しかし、今回の様に製品Aを前提としている場合はおおよそ以下いずれかのパターンなので、現実問題できることを考えることが建設的と考えます。

製品Aが必須となる要件がある。（システムとして不可欠な製品である、外部連携システムとの取り決め上製品Aが必須であるなど）
リスクを少なくするため、システムは大きく変えずにクラウドに移行したい。（いわゆるLift and Shift）
その他の事情（政治的な要因でクラウドが前提であるが知見がないなど）

では、製品Aを前提とした構成で考えるべき点は、果たして”クラウド特有”の検討事項なのでしょうか。

プラットフォームが変わっても考えるポイントは同じ

今回の例では、達成すべき要件は以下の通りです。

プラットフォームはAWSとする。
製品Aを導入したシステムである。（製品AはEC2への導入となる）
製品Aの冗長化を行う。

「AWS、EC2、冗長化」というキーワードが並ぶと、ELB（Classic ELB、ALB、NLB）を選択肢として考える気持ちはわかります。
しかし、製品Aの導入が必須となることを前提とする場合、冗長化という観点で以下の点を考えるべきかと思います。

製品Aは冗長化が可能な製品であるか。
製品Aが冗長化可能な場合、冗長化に必要な条件、選択肢（メリット/デメリット含め）が何であるか。
製品Aを導入するプラットフォーム（今回はAWS）により、選択肢として残るものは何か。

大事なのは①と②で、この２点はプラットフォームに依存していません。
特に②は、製品仕様によるところが大きく、製品仕様次第で冗長化の選択肢が限られてきます。
つまり、オンプレ／クラウドどちらであっても基本的な冗長化戦略は①および②の製品仕様が主軸であり、③のプラットフォームは製品Aの条件を満たせる環境か否かでしかありません。
製品Aを冗長化しようとする場合、プラットフォームを選ぶのは製品Aであり、プラットフォーム自体に製品Aの冗長化を決定付ける機能はないのです。

まとめ

オンプレよりクラウドが優れているのではなく、オンプレ／クラウド双方にメリット／デメリットがあり、システムの設計においてオンプレもクラウドも選択肢でしかありません。プロジェクトの目的・達成すべき目標・優先順位を常に意識し、最適なシステム構成を考えていくことが王道ではないでしょうか。

おまけ：製品Aをとにかく冗長化してみる

一例ですが、以下の様な仕組みとすることで製品A（製品にもよりますが）の冗長化をAWS上で実現可能です。本仕組みはオンプレでも可能な構成だと思いますが、私は未だかつてオンプレではお目にかかったことはありません。
製品AがWeb/APサーバ製品であれば一般的な構成なのですが、ファイル送受信やジョブ管理ソフトとなると構成および制御が複雑になるため、素直にクラスタ構成にすることをおすすめします。
（文章にしてみて、改めて「手作りクラスタ構成」であると私は感じました。）

AWSにてとにかく冗長化！

製品Aを導入したEC2を2台のMulti-AZ構成にする。
業務データはEFSに格納し、2台のEC2からアクセス可能とする。
EC2は必ず1台アクティブ1台スタンバイであることを前提とし、NLBに2台のEC2を紐づける。（もしくはNLBのターゲットをアクティブなEC2のみとなる様制御する）
2台のEC2のアクティブ/スタンバイおよび状態を監視・制御する仕組み（Lambdaなど）を実装する。

オンプレにてとにかく冗長化！

製品Aを導入した物理サーバを2台構成にする。
業務データはストレージ（NAS）に格納し、2台の物理サーバからアクセス可能とする。
物理サーバは必ず1台アクティブ1台スタンバイであることを前提とし、負荷分散装置に2台の物理サーバを負荷分散対象とする。（もしくは負荷分散先をアクティブな物理サーバのみとなる様制御する）
2台の物理サーバのアクティブ/スタンバイおよび状態を監視・制御する仕組み（shellなど）を実装する。