
AWS Partner Centralのファンドリクエストで「ACCESS allocation is required」エラーが出た際の原因と対策
コンバンハ、千葉(幸)です。
AWS Partner CentralはAWSパートナーがAWSとの協業を管理するためのハブです。共同販売、AWS Marketplaceでの製品/ソリューション販売、MDF(マーケティング開発資金)等プログラム特典申請などの機能を提供しています。
今回はファンドプログラムに関するところで、AWS Partner Centralからファンドリクエストを提出しようとした際に見慣れぬエラーが出ました。
ACCESS allocation is required to submit benefit application.
エラーの原因と、その対応方法をご紹介します。
事象の整理
- 一度差し戻しされた申請をresumeして出し直す際に発生した
- 1度目の申請と2度目の申請(出し直し)では月を跨ぎ、一週間程度の期間が空いていた
- 2度目の申請の最後の段階で提出ボタンをクリックすると画面の上部にエラーが表示された

事象の原因として推測されるもの
- 申請が紐づいているBenefitのACCESS allocationがINACTIVE になっていた
事象の対応方法
- ACCESS allocation がACTIVEな別のBenefitに紐づける形で新たな申請として作り直す
事象のイメージ
事象について理解するため、関連するリソースの用語を先に整理しておきます。
| リソースタイプ | 説明 | ID形式 |
|---|---|---|
| Benefit | ファンドプログラムの種類 | ben- + 小文字英数字14文字 |
| BenefitApplication | ファンドリクエスト | benappl- + 小文字英数字14文字 |
| BenefitAllocation | BenefitやBenefitApplicationに関連づく「枠」 | benalloc- + 小文字英数字14文字 |

まず大きな括りとしてBenefitというリソースがあります。申請時に選択するプログラムに相当するものです。プログラムごとの個々の申請は、BenefitApplication(以降、Application)として扱われます。
それとは別にBenefitAllocation(以降、Allocation)というリソースもあります。これは直感的には理解しづらく、AWSマネジメントコンソールで操作する際にはあまり意識しないものかもしれません。
Allocationは大きく分けると下記のように分類できます。
- Benefitに直接関連づくもの
- Benefit全体の
CASHもしくはCREDITSの割当額を管理するもの - Benefitに対する
ACCESS可否を管理するもの
- Benefit全体の
- 個別の申請(Application)に関連づくもの
- 個別の申請の額やステータスを管理するもの
- 申請が承認された段階で作成され、関連付けられる
- 個別の申請の額やステータスを管理するもの
今回の事象に関連する内容を補足し、番号を振りました。

- ①特定のプログラム(Benefit)を指定して②CASHの申請(Application)を作成した
- 申請は9月に作成して一度差し戻しされ、10月に入ってから再申請を試みた
- ①のBenefitに関連づいたAllocationとして下記等がある
- ③
ACCESSを管理する枠 - ④
CASHを管理する枠(プログラム全体としての枠)
- ③
- ②の申請の関連リソースとして、④のAllocationが確認できる
- ②の申請が承認されると⑤個別のAllcationが作成され関連づけられるが、今回のケースではまだ作成されていない
- ②の申請が属する①のBenefitのACCESSを管理する枠(③)が10月にINACTIVEとなった
- 併せて④のAllocationが期限切れを迎えている
- ②の申請を10月に入ってから再提出しようとした際に、③ACCESS枠が有効でないとエラーになった
-
ACCESS allocation is required to submit benefit application.
-
10月に入ってから新規に申請(Applcation)を作成しようとする際には、①のBenefitはそもそも選択肢に現れてきません。今回は、すでに作成済みだったApplicationの再申請を試みたため、「BenefitにACCESS allocationが無い」とエラーが発生しました。
あまり多く発生する事象ではないと思いますが、今回のような「再申請」や、下書きとして保存していたものを申請し直しする際に、ACCESS allocation(今回の③相当)がINACTIVEとなるタイミングを跨いでいると、同様のエラーが生じると考えられます。
AWS Partner CentralのBenefit関連リソースをAWS CLIで確認する
AWSマネジメントコンソールからだけではリソースを意識しづらいので、AWS CLIで実際の値を確認してみました。
使用するコマンドは下記のとおりです。
- get-benefit-application — AWS CLI 2.37.13 Command Reference
- get-benefit — AWS CLI 2.37.13 Command Reference
- list-benefit-allocations — AWS CLI 2.37.13 Command Reference
- get-benefit-allocation — AWS CLI 2.37.13 Command Reference
- list-benefits — AWS CLI 2.37.13 Command Reference
これらのコマンドを実行する際には共通して下記を指定します。
--catalog AWS \
--region us-east-1
--catalogにはテスト環境を表すSandboxを指定することもできます。リージョンは明示的にus-east-1を指定します。
②Applicationの詳細を見る get-benefit-application
まずは②相当の申請(Apploication)を確認します。
aws partnercentral-benefits get-benefit-application \
--catalog AWS \
--identifier benappl-xxxxxxxxxxxxxx \
--region us-east-1
一部抜粋した結果は下記のとおりです。
{
"Id": "benappl-xxxxxxxxxxxxxx",
"BenefitId": "ben-xxxxxxxxxxxxxx",
"FulfillmentTypes": [
"CASH"
],
"Programs": [
"PROGRAM_A"
],
"Status": "ACTION_REQUIRED",
"CreatedAt": "2026-09-25T10:38:53.241142+00:00",
"AssociatedResources": [
"arn:aws:partnercentral:us-east-1:111111111111:catalog/AWS/opportunity/O00000000",
"arn:aws:partnercentral:us-east-1:111111111111:catalog/AWS/benefit-allocation/benalloc-xxxxxxxxxxxxxx"
],
...
}
結果より、下記が確認できます。
BenefitIdから、どのBenefit(①)に紐づく申請なのかAssociatedResourcesから、関連するAllocation(④)
④の他にAssociatedResourcesに表示されているopportunityは、申請の際に指定したOpportunity(機会)を表します。
このコマンドの結果からはACCESS Allocation(③)が確認できないほか、申請が承認された際に作成される個別のAllocation(⑤相当)も確認できません。(今回はそもそもまだ⑤が作成されていないが、仮に作成されてもこのコマンドからでは辿れない。)
①Benefitの詳細を見る get-benefit
②のBenefitIdが指しているBenefitの詳細を取得します。
aws partnercentral-benefits get-benefit \
--catalog AWS \
--identifier ben-xxxxxxxxxxxxxx \
--region us-east-1
一部抜粋した結果は下記のとおり。名称はサンプルのものに差し替えています。
{
"Id": "ben-xxxxxxxxxxxxxx",
"Catalog": "AWS",
"Arn": "arn:aws:partnercentral:us-east-1::catalog/AWS/benefit/ben-xxxxxxxxxxxxxx",
"Name": "Sample Program",
"Description": "Sample Program",
"Programs": [
"PROGRAM_A"
],
"FulfillmentTypes": [
"CREDITS",
"CASH"
],
"BenefitRequestSchema": {
...
},
"Status": "ACTIVE"
}
BenefitRequestSchemaには申請のフォーマットが載っており、実際の表示はかなりの量になります。
このコマンドから配下の各種リソースを確認することはできないことがわかりました。また、①自体のStatusはACTIVEとなっているのが印象的です。
①に関連づくAllocationを探す list-benefit-allocations
①に関連づくAllocationを確認します。list-benefit-allocationsで下記条件を指定して絞り込みます。
BenefitIdが①のもの- 下記の名称から始まる含むものを除く(⑤相当の、個別の申請に関連付くAllocationを除外する)
Cash Benefit Allocation forCredit Benefit Allocation for
aws partnercentral-benefits list-benefit-allocations \
--catalog AWS \
--region us-east-1 \
--query "BenefitAllocationSummaries[?BenefitId=='ben-xxxxxxxxxxxxxx' && !starts_with(Name,'Cash Benefit Allocation for') && !starts_with(Name,'Credit Benefit Allocation for')].[Id,FulfillmentTypes[0],Status,ExpiresAt,Name]" \
--output text
今回のBenefitでは、下記の結果が得られました。
- FulfillmentTypeが
CASHとCREDITSのAllocationはそれぞれ同じ名前のものが複数あり、期限はすべて2026年9月中 ACCESSは1件だけで、StatusがINACTIVE
このINACTIVEのACCESSが③です。
③のACCESS Allocationを見る get-benefit-allocation
③の詳細を確認します。
aws partnercentral-benefits get-benefit-allocation \
--catalog AWS \
--identifier benalloc-xxxxxxxxxxxxxx \
--region us-east-1
実行結果は下記のとおり。
{
"Id": "benalloc-xxxxxxxxxxxxxx",
"Catalog": "AWS",
"Arn": "arn:aws:partnercentral:us-east-1:111111111111:catalog/AWS/benefit-allocation/benalloc-xxxxxxxxxxxxxx",
"Name": "Access to Funding Benefit",
"Description": "Access to Funding Benefit",
"Status": "INACTIVE",
"BenefitId": "ben-xxxxxxxxxxxxxx",
"FulfillmentType": "ACCESS",
"ApplicableBenefitIds": [],
"FulfillmentDetail": {
"AccessDetails": {
"Description": "Access to Funding Benefit"
}
},
"CreatedAt": "2026-07-06T22:09:59.035295+00:00",
"UpdatedAt": "2026-10-01T16:34:08.151487+00:00",
"StartsAt": "2026-07-06T22:09:59.019807+00:00",
"ExpiresAt": "2028-07-05T22:09:59.019823+00:00"
}
見るポイントは3つです。
FulfillmentTypeがACCESSで、StatusがINACTIVEUpdatedAtが2026-10-01で、この日に無効化されたようであるExpiresAtは2028年で、期限切れではない
ACCESS allocation is required to submit benefit application. というメッセージは③がINACTIVEである(そして他にACTIVEなACCESS allocationが存在しない)状態のことを表していると合点がいきました。AWSマネジメントコンソールだとこのAllocationというリソースはほぼ意識できないので、なかなか難しいポイントでした。
④のCASHのAllocationを見る get-benefit-allocation
④のAllocationを改めて確認します。①BenefitのCASHに関する全体の枠を表すものです。
aws partnercentral-benefits get-benefit-allocation \
--catalog AWS \
--identifier benalloc-xxxxxxxxxxxxxx \
--region us-east-1
一部を省略した結果が下記のとおり。
{
"Id": "benalloc-xxxxxxxxxxxxxx",
"Catalog": "AWS",
"Arn": "arn:aws:partnercentral:us-east-1:111111111111:catalog/AWS/benefit-allocation/benalloc-xxxxxxxxxxxxxx",
"Name": "Sample Program-Cash",
"Status": "ACTIVE",
"BenefitId": "ben-xxxxxxxxxxxxxx",
"FulfillmentType": "CASH",
"ApplicableBenefitIds": [
"ben-xxxxxxxxxxxxxx"
],
"FulfillmentDetail": {
"ConsumableDetails": {
...
}
},
"CreatedAt": "2026-07-06T22:09:57.349698+00:00",
"UpdatedAt": "2026-09-30T00:38:57.339389+00:00",
"StartsAt": "2026-07-01T07:00:00+00:00",
"ExpiresAt": "2026-09-29T07:00:00+00:00"
}
こちらはStatusがACTIVEのままですが、ExpiresAtは2026-09-29で、確認した時点ではすでに過ぎていました。③のAllocationのStatusとこのあたりが連動しているかどうかは気になるところです。
①の代替となるBenefitを探す list-benefits
①のBenefitでは申請が行えそうにないため、代替となるBenefitを探します。
aws partnercentral-benefits list-benefits \
--catalog AWS \
--region us-east-1 \
--query "BenefitSummaries[*].[Id,Name,join(',',FulfillmentTypes),join(',',Programs),Status]" \
--output text
このコマンドにより、下記の列を持つBenefits一覧が出力されます。
- Benefit ID
- 名前
- 対応タイプ(CASH/CREDITS/ACCESS)
- プログラムタイプ
- ステータス
今回の事象では、下記のBenefitが見つかりました。
- ①のBenefitと同じ名称である
- ①のBenefitと異なるプログラムタイプである
- ACCESSタイプのAllocationが2つ属しており、ひとつが
INACTIVE、もうひとつがACTIVEである
プログラムタイプが異なるものの、同じ名称でACTIVEなACCESS Allocationを持つBenefitが見つかったというわけです。こちらのBenefitを指定して申請(Application)を作成したところ、申請の提出までは問題なく行えました。
なお、Benefitが異なるため、AWSマネジメントコンソールから申請する際の選択内容はところどころで①の場合と異なっていました。
事象のまとめ
今回の事象のイメージを再掲します。

- ①Benefitとしてはステータスが
ACTIVE - ①Benefitに属する
ACCESSのAllocation(③)はステータスがINACTIVEで期限切れなし - ①Benefitに属する
CASHのAllocation(④)はステータスがACTIVEで期限切れ
という状況でした。ACCESS Allocationという概念を押さえておくと役立つ時が来るかもしれません。
終わりに
「ACCESS allocation is required to submit benefit application.」というエラーが出た際の原因と対応についてのご紹介でした。
AWSマネジメントコンソールから触っているだけでは裏側のリソースをなかなか意識できないので、いいきっかけとなりました。
同じエラーに当たる方が世界中に何人いるか分かりませんが、何らか参考になれば幸いです。
以上、チバユキ (@batchicchi)がお送りしました。









