AppStream AppBlock Does Not Download From S3 On Instance Launch

0

We have an application in AppStream using an AppBlock with an Elastic Fleet. The application is an executable file hosted in a public S3 bucket (< 1 MB). When the instance launches there is no sign of the EXE having been downloaded to the usual folder (C:\AppStream<AppBlockName\MyApp.exe). This was working yesterday as of 6:30 PM EDT.

We have also tried a similar approach using a VHD (approx. 100MB) instead of an executable file with the same result.

Finally we have tried new App Blocks, new Applications, and new Fleets to rule out any potential issues with the existing ones and the result has been the same each time.

We are wondering if there is any place where a log file is stored / available to determine why this is failing or if there is an operational issue with AppStream in the ca-central-1 region?

asked 7 months ago138 views
2 Answers
0
Accepted Answer

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.

answered 6 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.

0

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.

EXPERT
answered 7 months ago
  • 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.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions