プロキシのフォワード/リバースを見分ける観点は、サービスの「利用者側/提供者側」でしょうか？

問題はECサイト運用会社側から見たWEB/APサーバーの構成において、APサーバーの通信を代理するWEBサーバーは〇〇プロキシである。

といった問題です
問題には出てこないインターネット先の会社員クライアント(例)まで想定すると、
・会社でこの利用者と他多数のクライアントの通信を代理しているフォワードプロキシ
・ECサイトに関するサーバーの通信を代理しているリバースプロキシ
が関わります。

このとき、２つのプロキシは細かく何を代理しているかは違うものの、やってる事は同じだと思ってます。
(ざっくり見るとどちらもプロキシにぶら下がってる沢山のホストの通信を代理をしている)

フォワード/リバースと呼び分けるのは、その機能ではなく、サービス提供側か利用者側か、立場の問題なのでしょうか？
(または立場に伴う設定の違い？)

プロキシサーバとはあくまでも代理するだけなので、フォワード/リバースのモードがあるわけではありません。

プロキシサーバの本来の流れをしっかり押さえるとわかりやすいかもしれないです。
プロキシサーバはだれのものでしょうか。この場合、もちろんサービス提供者です。
（おそらくプロキシサーバの管理者もサービス提供者です）

なので、サービス提供者側の人(会社員)がプロキシサーバを経由してインターネットへ通信するのがメインの流れになります。
これをフォワードプロキシと呼んでいます。

逆にECサイトの人がサービス提供者を利用するためには外部からプロキシサーバを経由して、Web/APサーバを利用することになります。
そのためこれをリバースプロキシ(反対のプロキシ)と呼んでいます。

プロキシサーバからインターネットへ出ていく通信なのか、インターネットからプロキシサーバへ向かってくる通信なのかを整理すると、フォワード/リバースが区別しやすいかもしれないです。

基本的にはクライアントへの代理応答という点で同じですが、違う点は以下の2つだと思います
1. HTTPSが使用された時の動作
 フォワードプロキシの場合：プロキシサーバはクライアントからのCONNECTメソッドを中継する役割のみ果たす。
 リバースプロキシの場合：プロキシサーバにて暗号化の解除を行うことがある。これによってHTTPヘッダの値を元に振り分け先を変えたりできる。

2. 通信フロー
 フォワードプロキシの場合：HTTP（S)のリクエストが行われる前に、プロキシのポート充てに通信が行われる。キャッシュで応答できるならキャッシュを応答してHTTP（S)のリクエストは行わない
 リバースプロキシの場合：いきなりHTTP（S)のパケットをやりとりし、サーバとの中継を行う

一発目の通信が違うので、フォワードプロキシを利用する端末は事前にプロキシサーバのアドレスを設定しておかないといけません。なので、管理範囲外（社外からのアプリの利用者など）からの通信は基本的にリバースプロキシが受けることになると思います。

ちなみにフォワードプロキシにも、NAPTで無理やり宛先アドレスとポート番号を変換してフォワードプロキシを通過させる透過プロキシみたいなものもあり、これをつかえば事前設定が不要になります。この場合は実質リバースプロキシ的な動作になります