user_data not working in request_spot_instances (base64 encoding)
See original GitHub issueWhen attempting to spin up a spot instance, I get as far as pending evaluation, and once that completes I get a bad-parameters error, related to the user_data not being base64-encoded:
error message:
<fault>
<code>Client.InvalidParameterValue</code>
<message>Invalid BASE64 encoding of user data (400 response code)</message>
</fault>
If I leave out the user_data, it fulfills the spot request, and I get a spot instance with no issues.
Also, this same user_data string works fine when running create_instances (on-demand).
request_spot_instance call:
ec2.meta.client.request_spot_instances(
SpotPrice=max_spot_price,
InstanceCount=int(instance_count),
LaunchSpecification={
'InstanceType': instance_type,
'ImageId': ami_id,
'KeyName': key_name,
'SecurityGroupIds': security_groups,
'UserData': user_data,
'SubnetId': subnet_id,
'IamInstanceProfile': {
'Name': instance_profile_name
},
'Monitoring': {
'Enabled': True
}
}
)
create_instance call:
ec2.create_instances(
ImageId=ami_id,
SubnetId=subnet_id,
KeyName=key_name,
InstanceType=instance_type,
SecurityGroupIds=security_groups,
MinCount=int(instance_count),
MaxCount=int(instance_count),
IamInstanceProfile={
'Name': instance_profile_name
},
Monitoring={'Enabled': True},
UserData=user_data
)
Full Error Message:
...
<item>
<spotInstanceRequestId>sir-********</spotInstanceRequestId>
<spotPrice>1.504000</spotPrice>
<type>one-time</type>
<state>failed</state>
<fault>
<code>Client.InvalidParameterValue</code>
<message>Invalid BASE64 encoding of user data (400 response code)</message>
</fault>
<status>
<code>bad-parameters</code>
<updateTime>2015-11-16T14:45:27.000Z</updateTime>
<message>Your Spot request failed due to bad parameters.</message>
</status>
<launchSpecification>
<imageId>ami-********</imageId>
<keyName>********</keyName>
<groupSet>
<item>
<groupId>sg-41ba1326</groupId>
<groupName>aolp-dev-us-east-1-PrivateNetworkSG-X9G897DEU9FD</groupName>
</item>
</groupSet>
<instanceType>c3.4xlarge</instanceType>
<placement>
<availabilityZone>us-east-1a</availabilityZone>
</placement>
<monitoring>
<enabled>true</enabled>
</monitoring>
<subnetId>subnet-637b4e14</subnetId>
<iamInstanceProfile>
<name>********</name>
</iamInstanceProfile>
</launchSpecification>
<createTime>2015-11-16T14:43:03.000Z</createTime>
<productDescription>Windows</productDescription>
</item>
...
Any help would be greatly appreciated.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:1
- Comments:7 (2 by maintainers)
Top Results From Across the Web
request_spot_instance API is not accepting user data in file ...
So when I pass base64 encoded data of my file , then the API works correctly. file = open("my_script0.txt", 'r') encoded_data = base64....
Read more >Better documentation for UserData in request-spot-instances
Using file://xxx as UserData in launch-specification doesn't seem to work. AWS console gives me "Bad base64 encoding" error.
Read more >Solved: AWS Spot instance create failed with Invalid BASE6...
We starting to hit Spot Instance create failure with Invalid BASE64 encoding of user data since 2AM Nov 5th 2019 GMT time.
Read more >Which type of base64 encoding of userdata to use for API?
python has at least 4 different kinds of base64 encoding it can do. i tested 3 of them and ran instances encoding user...
Read more >UserData - Amazon Elastic Compute Cloud
Describes the user data for an instance. ... If you are using an AWS SDK or command line tool, Base64-encoding is performed for...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
For the record, that’s a way to do this:
Ah, I see, one issue has been hit often enough to get its own pullout to make it apparent, the other has not.