I have no idea of why AWS keeps popping up for you.
It doesn’t for me, so perhaps in there lies the issue.
Ensure you installed it properly, and ofc, reboot at least on ce to make sure all the bells and whistles come up.
You’ll also want to run the monitor at least once, and in super-user mode, so to edit groups, pools and so on (even if you only have the one machine.), before submitting the first job.
The AWS entry is just in the Deadline/Assets panel. It was actually checked so I unchecked it.
I installed exactly as per your links and process description. Rebooted.
I ran a teapot job to check stuff was working before trying the large scene, and that worked as I’d expect it to, so it is definitely linked to the large scene and its bitmaps.
I cut down the scene to include only 360 bitmaps out of the total 260k and that will submit just fine.
So my conclusion is that Deadline simply cannot deal with that amount of bitmap data, as part of the process is to look for and reference all 260k frames in order to begin rendering, which seems a bit silly.
So unless there is a way to override that and simply do what Backburner does, which is to open the scene and render it, then I am stumped.
This looks like a ‘similar’ issue and one that has no solution as yet, if I read it correctly https://forums.thinkboxsoftware.com/t/slow-submission-of-max-scene-with-many-assets/14043/2
If that is the case then it is of course ridiculous that it works like this.
While on some other task, i took the time to benchmark the loading times of four 8k Tiff textures, versus their .TX counterparts.
This was done opening and closing the compact material editor, populated with shaders, ensuring that the files were reloaded each time (i.e. not cached.).
The time not spent loading the files was measured opening and closing the matEditor when the maps were loaded (the slack will include both the UI redraw, and the rendering of the samples proper.).
All files were loaded off an SSD with no other process accessing it (variations are due to the first cpu core being hammered, ofc.), so in a way they make .Tx look worse than it is, as the tiff files load as quickly as they possibly can (unlike, f.e., in production.).
Still, the .tx files are about *five times* quicker to load, and the speed is maintained for all and any material editor interaction (tiff: sluggish; .tx: lightning quick.).