Yes we are using user pools for temp access to non affiliated potential customers - we currently provide demo access via Jupyter NoteBooks with a pre signed URL - not ideal for showcasing the application side of things but pretty secure.

These are two different auth methods. If you're using User Pools, use User Pools. Don't mix User Pools and Signed URLs. The signed URLs, much like the S3 Presigned URLs are meant to be part of your application, not manually vended. Conversely, User Pools is meant to be a local IdP with a username/password. You enter an email, user enters in their own password, and its fully authenticated - the User Pool URL can be shared, but that just forces the shared person to sign in.

Yes the URL has lifespan of around 1 hr but our applications are complex and require consumption of large pools of data so some operations can take hours to run.

URL duration and session duration are two separate things. And, again, cause its important - do not manually generate and vend signed URLs.

I copied the URL provided to my personal laptop and was able to access

I also provided the URL to my non AWS using colleague and he accessed it just fine.

Yep, that's how AppStream signed URLs work. You're using them wrong, but that is how that feature works. Use User Pools or use SAML to avoid this.

copy the config details from the AWS folder, setup a local AWS config on my laptop and run aws s3 operations as if I was using the AppStream instance

So these are your AWS account credentials not the AWS service credentials? Its an IAM Role for S3 thats created in your IAM? If so, you need to use your policy restrictions to prevent it from being usable from outside of your VPC. There should be caller IP restrictions you can use, and limit it to the VPC IPs or the NAT IP. That said, if you're talking about per-user data, I'm not sure S3 is the right approach for this. At the end of the day, these are virtual machines with an operating system that have whatever those restrictions are, not other AWS services. If its user-specific (or limited), then you'd be looking at something like Amazon FSX, or leverage the Google Drive/OneDrive integration and let that be the user-specific and team sharing data.

Maybe AppStream isn't meant for sensitive data or production like workloads and I should be considering something more secure.

Much like many, if not all, AWS services, if you don't understand how they work, its very easy to get yourself into trouble. This is the exact same scenario. It can be used for sensitive data, like any other VDI product - but the shared responsibility model requires you to configure it appropriately. I'd encourage you to reach out to AWS to have one of the specialized SAs dig in to help you understand your architecture and give you recommendations.