Both types of signed URLs fulfill the same goal: provide a serverless-friendly and controlled way for users to upload files directly to S3 buckets. The process is also the same for both as the backend needs to sign the request after validating that the user is authorized then the browser sends the file directly to S3. And finally, both can be used from Javascript equally well.

POST signed URLs enable the same use case as PUT URLs: when you want a scalable and controlled way of letting users upload files directly to S3. The main difference is the technical implementation of how these URLs work. While PUT URLs provide a destination to upload files without any other required parts, POST URLs are made for forms that can send multiple fields.

For traditional applications when a client needs to upload a file it has to go through your backend. During the migration to the cloud, that usually means your backend uploads the same data to S3, doubling the bandwidth requirements. Signed upload URLs solve this problem. The clients upload data directly to S3 in a controlled and secure way, relieving your backend.

When you sign a URL with the global credentials (execution role for Lambda/ECS, instance profile for EC2, or IAM users) you get all the available permissions that come with it. If a user can trick your backend to sign a URL for a different bucket, for example, that could lead to security vulnerabilities. Using different sets of permissions for different purposes can help enforce the least privilege.