# IS cloud-aws ready for Long Resource ID **URL:** \ **Category:** Elasticsearch\ **Created:** [October 12, 2016, 12:29pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805 "2016-10-12T12:29:42Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Amit\_Dunsky](https://avatars.discourse-cdn.com/v4/letter/a/6bbea6/32.png) [@Amit\_Dunsky](https://discuss.elastic.co/u/Amit_Dunsky)\ **Post date:** [October 12, 2016, 12:29pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/1 "2016-10-12T12:29:42Z")
Starting end of Dec. 2016, AWS will begin using a Long Resource ID format for EC2 Instances, EBS, RI and Snapshots. According to AWS, previously created resources which still uses the short id format will retain its ID and will not be required to make any change. Given that, many AWS accounts (us included) will most probably hold mixed id formats resources, and my question is: How ready the cloud-aws plugin is (Ver. 2.4.1)? Will it support both formats? Is it ready for the soon coming change? Thank you! ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 12, 2016, 12:34pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/2 "2016-10-12T12:34:31Z")
In short: I have no idea! I believe that is totally transparent and managed by the AWS SDK itself. I mean that we never explicitly define whatever ID in discovery-ec2 or repository-s3 plugins. If there is anything to do, my guess is that we might have to upgrade the AWS SDK? Do you have any link to what you described? ---
**Author:** ![Amit\_Dunsky](https://avatars.discourse-cdn.com/v4/letter/a/6bbea6/32.png) [@Amit\_Dunsky](https://discuss.elastic.co/u/Amit_Dunsky)\ **Post date:** [October 12, 2016, 12:49pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/3 "2016-10-12T12:49:45Z")
Well, the main problem might be - as the suggests - with the length of the resource ID being expanded. We had experience with code using too-short of a datatype, which as a result could not parse the resource ID correctly. That is my main worry... ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 12, 2016, 1:02pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/4 "2016-10-12T13:02:41Z")
Sure. But we don't use that "ID" field in our code AFAIK. The AWS SDK probably does and I hope they are using the right datatype for that already. I did not read yet anything related to that in the release notes. Again, if you have any pointer, I'll be happy to read. ---
**Author:** ![Amit\_Dunsky](https://avatars.discourse-cdn.com/v4/letter/a/6bbea6/32.png) [@Amit\_Dunsky](https://discuss.elastic.co/u/Amit_Dunsky)\ **Post date:** [October 12, 2016, 1:28pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/5 "2016-10-12T13:28:06Z")
Since the plugin requires "ec2:DescribeInstances" permissions, I figured it must be getting the resource ID as well, hence this change might affect it. AWS documentation regarding the change is available here: [http://zik.link/longid](http://zik.link/longid) ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 12, 2016, 1:43pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/6 "2016-10-12T13:43:41Z")
According to the doc you linked to, JAVA SDK is compatible. > The following SDKs are fully compatible with longer IDs and do not need to be upgraded: PHP v1, Boto v1, Boto v2, Ruby v1, Ruby v2, JavaScript, **Java** , .NET, AWS Tools for Windows PowerShell, and Go. We should be safe then. But thanks for opening this thread! ---
**Author:** ![Amit\_Dunsky](https://avatars.discourse-cdn.com/v4/letter/a/6bbea6/32.png) [@Amit\_Dunsky](https://discuss.elastic.co/u/Amit_Dunsky)\ **Post date:** [October 12, 2016, 3:08pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/7 "2016-10-12T15:08:20Z")
So the SDK is ready. How about the code? Are you not parsing the Instance ID? Maybe keeping it in a variable? Are you sure its long enough? ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 12, 2016, 3:29pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/8 "2016-10-12T15:29:34Z")
> [@Amit\_Dunsky](#): > > How about the code? > Are you not parsing the Instance ID? No. > [@Amit\_Dunsky](#): > > Maybe keeping it in a variable? No. The only IDs I have seen in our code are not related to instances and are using a java `String`. ---
**Author:** ![Amit\_Dunsky](https://avatars.discourse-cdn.com/v4/letter/a/6bbea6/32.png) [@Amit\_Dunsky](https://discuss.elastic.co/u/Amit_Dunsky)\ **Post date:** [October 12, 2016, 3:39pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/9 "2016-10-12T15:39:59Z")
Great! So, can we trust the cloud-aws plugin is ready for the longer resource ID format? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:12pm UTC](https://discuss.elastic.co/t/is-cloud-aws-ready-for-long-resource-id/62805/10 "2017-07-05T22:12:59Z")