- Newest
- Most votes
- Most comments
After a month and a half of back and forth with AWS support we have a solution.
It seems that when an S3 bucket has a '.' in the name AppStream now silently fails to download files from S3 due to known limitations with TLS and SSL certificates. Support send us this link to a blog post where the AWS team has discussed S3 path deprecation and the limitations of the virtual host style of accessing buckets. They claimed to be working on a solution but apparently they do not have one as of yet.
https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/
We have suggested that AWS should implement a warning in the AWS Console UI when a user creates a bucket with a '.' in the name or uses a pre-exsiting bucket with a '.' in the name with an AppBlock to help avoid any one else running into this problem in the future.
TLDR; Do not use a '.' in the name of buckets you intend to use with AppBlocks with an Elastic Fleet in AppStream.
Hi -
Can you confirm the streaming instance has access to S3 from your VPC? The easiest way to test it is to assign your app block/application to an Elastic fleet with desktop mode enabled. You can then use FireFox with a S3 presigned URL for the VHD/executable file to see if it downloads. If it doesn't download, look into your VPC configuration to ensure you have either an internet route to S3, or an S3 VPC endpoint. If it does download, you'll need an AWS support case to resolve.
Does your application resource have a launch parameter that includes quotes? I ran into an issue where an invalid quote character in the launch params caused an issue - basically ” failed, while " worked.
We found this post (https://repost.aws/questions/QUovIEbdOSQMuqI1n11TW9kg/custom-appstream-2-0-elastic-application-wont-mount-vhd-and-start) and tried the presigned S3 URL already and were able to download the EXE and the VHD from S3 from inside the instance in desktop mode.
We tried this application without any launch parameters at all and the result was the same.
Gotcha - one other thing to validate is that the AppStream 2.0 service has the appropriate trust relationship to download the file. If you followed the directions on this page (https://docs.aws.amazon.com/appstream2/latest/developerguide/store-s3-bucket.html) to provide the service access to the S3 bucket, you'll need to submit an AWS Support ticket to look at what's going on.
Our bucket is public. We use the following policy: { "Version": "2008-10-17", "Statement": [ { "Sid": "AddPerm", "Effect": "Allow", "Principal": "", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::<bucket_name>/" } ] }
As we understand it this should work right (and it was working yesterday)?
"As we understand it this should work right (and it was working yesterday)?" => Ah, I totally missed this point in your original post - sorry about that. AWS Support is going to be the best bet to dive in to understand what (if anything) changed to break it at this point.
Relevant content
- asked 10 days ago
AWS OFFICIALUpdated 10 months ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 months ago
After wasting most of a day on this, I found your post which fixed my issue. It is really unforgivable that AWS has not either fixed the bug or documented it.