Discussion Forums Welcome, Guest Login Forums Help Back to Discussion Forum

Announcement: Amazon CloudFront announces deprecation of older API versions Posted By: George-AWS Created in: Forum: Amazon CloudFront Status: Expired Posted on: Apr 21, 2019 8:54 PM Please note that we posted an update to the announcement below on April 21, 2019. Please refer to the updated announcement here link



On Thursday, June 6, 2019, CloudFront will deprecate the oldest versions of the CloudFront API, specifically those dated prior to 2016. As CloudFront has evolved, new features and concepts (such as origin groups and support for SNI certificates) have been introduced that can't be represented in the older APIs. To improve overall support and consistency for CloudFront developers we're reducing the number of API versions we need to maintain.



Beginning on June 6, 2019 the listed versions of the CloudFront APIs will stop working and will instead return a “410: Gone” response code. To prevent disruption to any calling applications, we recommend that you upgrade applications that invoke these APIs as quickly as possible. We are providing 60+ days of advance notice of the impending deprecation date to allow sufficient time to perform these actions. If you have questions about this notice, please contact AWS Support.



For information about the current CloudFront API, see the CloudFront API Reference:



Full list of versions to be deprecated on 6/6/2019:

2008-06-30, 2009-04-02, 2009-09-09, 2009-12-01, 2010-03-01, 2010-05-01, 2010-06-01, 2010-07-15, 2010-08-01, 2010-11-01, 2012-03-15, 2012-05-05, 2012-07-01, 2013-05-12, 2013-08-26, 2013-09-27, 2013-11-11, 2013-11-22, 2014-01-31, 2014-05-31, 2014-08-31, 2014-10-21, 2014-11-06, 2015-04-17, 2015-07-27, 2015-09-17, 2015-12-22



Additional FAQs



Q: I saw the announcement about upcoming API deprecation. What is happening on 6/6/2019?

On June 6, 2019, CloudFront will deprecate all API versions prior to 2016. These API's will cease functioning on that date.



Q: Why is CloudFront deprecating these APIs?

To date, CloudFront has never deprecated an API version. While we strive to maintain backward-compatibility of API calls, newer features can not always be implemented in older APIs without breaking changes. Further, maintaining these older APIs introduces technical complexity and opportunity for untested regression errors to be introduced. In order to continue the pace of feature evolution that customers expect and to ensure the best developer experience, it is necessary to consolidate our supported APIs.



Q: How do I determine if I'm using the affected API versions?

In any application making calls to CloudFront APIs, you should see syntax like this in the calling HTTP Request:



PUT /2010-11-01/distribution/Id/config HTTP/1.1 <?xml version="1.0" encoding="UTF-8"?> <DistributionConfig xmlns="http://cloudfront.amazonaws.com/doc/2010-11-01/">

...additional BODY contents...



Your specific HTTP Method (“PUT”), version (“2010-11-01”), and API endpoint name (“/distribution/Id”) will vary based on the operation being performed, but it is the version component of the API call and the xmlns value that indicate which API version you are using.



In addition to the above inspection of your code, you can use CloudTrail logging and Athena to mine AWS API call data for the affected versions. That process is described in a Support Knowledge base Article here:

https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-api-version-check/



Q: What do I need to do to ensure that my workflows don't break?

In order to avoid calling applications from receiving a 410: Gone response beginning on 6/6/2019, you should modify those applications to call a newer, supported version. The full list of APIs and the XSD schemas can be found here:



Using the same example above:



PUT /2010-11-01/distribution/Id/config HTTP/1.1 <?xml version="1.0" encoding="UTF-8"?> <DistributionConfig xmlns="http://cloudfront.amazonaws.com/doc/2010-11-01/">

...additional BODY contents...



You will need to select the most appropriate API version for your needs (the latest version is likely the best choice unless there are specific considerations for your application), incorporate the XSD schema associated with the version you select, and ensure that your GET/POST/PUT calls reference the appropriate API version in the two <version> locations in the invocation (the version portion of the PATH in the HTTP request, and the version field in the xmlns parameter). For example,



PUT /2018-11-05/distribution/Id/config HTTP/1.1 <?xml version="1.0" encoding="UTF-8"?> <DistributionConfig xmlns="http://cloudfront.amazonaws.com/doc/2018-11-05/">

...additional BODY contents...



You will also have to update the rest of the BODY of your API call to ensure that all the parameters, names, and values are supplied as defined in the API .XSD, keeping in mind that as functions have been added and updated, parameters may have been added, changed or removed. So, some diligence is required to ensure that your API calls that retrieve, create, or update configuration values reflect the specification/contract of the selected newer API.



Q: Does this affect my traffic served by Amazon CloudFront?

No, but you should take the recommended corrective action. These APIs are configuration APIs and deal with the creation and configuration of CloudFront distributions. This deprecation does not affect features or traffic flowing through CloudFront or requests/responses that CloudFront is serving. Your user-facing applications should require no changes, and no disruptions to these applications should occur. The effects would be seen in configuration, deployment or other CI/CD types of operations that invoke these configuration APIs. If you have automation around your CloudFront configuration actions, you should examine these tools to ensure that they are upgraded to call one of the newer (2016 or later) API versions to avoid disruption or errors. While CloudFront will go on serving your traffic in it's current configuration after this deprecation, if you do not upgrade to a newer API version, any configuration changes you attempt using a deprecated version of the API will fail, so you will have to update at that time or use the console instead. On Thursday, June 6, 2019, CloudFront will deprecate the oldest versions of the CloudFront API, specifically those dated prior to 2016. As CloudFront has evolved, new features and concepts (such as origin groups and support for SNI certificates) have been introduced that can't be represented in the older APIs. To improve overall support and consistency for CloudFront developers we're reducing the number of API versions we need to maintain.Beginning on June 6, 2019 the listed versions of the CloudFront APIs will stop working and will instead return a “410: Gone” response code. To prevent disruption to any calling applications, we recommend that you upgrade applications that invoke these APIs as quickly as possible. We are providing 60+ days of advance notice of the impending deprecation date to allow sufficient time to perform these actions. If you have questions about this notice, please contact AWS Support.For information about the current CloudFront API, see the CloudFront API Reference: CloudFront API Reference Full list of versions to be deprecated on 6/6/2019:2008-06-30, 2009-04-02, 2009-09-09, 2009-12-01, 2010-03-01, 2010-05-01, 2010-06-01, 2010-07-15, 2010-08-01, 2010-11-01, 2012-03-15, 2012-05-05, 2012-07-01, 2013-05-12, 2013-08-26, 2013-09-27, 2013-11-11, 2013-11-22, 2014-01-31, 2014-05-31, 2014-08-31, 2014-10-21, 2014-11-06, 2015-04-17, 2015-07-27, 2015-09-17, 2015-12-22On June 6, 2019, CloudFront will deprecate all API versions prior to 2016. These API's will cease functioning on that date.To date, CloudFront has never deprecated an API version. While we strive to maintain backward-compatibility of API calls, newer features can not always be implemented in older APIs without breaking changes. Further, maintaining these older APIs introduces technical complexity and opportunity for untested regression errors to be introduced. In order to continue the pace of feature evolution that customers expect and to ensure the best developer experience, it is necessary to consolidate our supported APIs.In any application making calls to CloudFront APIs, you should see syntax like this in the calling HTTP Request:PUT /2010-11-01/distribution/Id/config HTTP/1.1 ...additional BODY contents...Your specific HTTP Method (“PUT”), version (“2010-11-01”), and API endpoint name (“/distribution/Id”) will vary based on the operation being performed, but it is the version component of the API call and the xmlns value that indicate which API version you are using.In addition to the above inspection of your code, you can use CloudTrail logging and Athena to mine AWS API call data for the affected versions. That process is described in a Support Knowledge base Article here:In order to avoid calling applications from receiving a 410: Gone response beginning on 6/6/2019, you should modify those applications to call a newer, supported version. The full list of APIs and the XSD schemas can be found here: CloudFront API Version Index Using the same example above:PUT /2010-11-01/distribution/Id/config HTTP/1.1 ...additional BODY contents...You will need to select the most appropriate API version for your needs (the latest version is likely the best choice unless there are specific considerations for your application), incorporate the XSD schema associated with the version you select, and ensure that your GET/POST/PUT calls reference the appropriate API version in the two locations in the invocation (the version portion of the PATH in the HTTP request, and the version field in the xmlns parameter). For example,PUT /2018-11-05/distribution/Id/config HTTP/1.1 ...additional BODY contents...You will also have to update the rest of the BODY of your API call to ensure that all the parameters, names, and values are supplied as defined in the API .XSD, keeping in mind that as functions have been added and updated, parameters may have been added, changed or removed. So, some diligence is required to ensure that your API calls that retrieve, create, or update configuration values reflect the specification/contract of the selected newer API.No, but you should take the recommended corrective action. These APIs are configuration APIs and deal with the creation and configuration of CloudFront distributions. This deprecation does not affect features or traffic flowing through CloudFront or requests/responses that CloudFront is serving. Your user-facing applications should require no changes, and no disruptions to these applications should occur. The effects would be seen in configuration, deployment or other CI/CD types of operations that invoke these configuration APIs. If you have automation around your CloudFront configuration actions, you should examine these tools to ensure that they are upgraded to call one of the newer (2016 or later) API versions to avoid disruption or errors. While CloudFront will go on serving your traffic in it's current configuration after this deprecation, if you do not upgrade to a newer API version, any configuration changes you attempt using a deprecated version of the API will fail, so you will have to update at that time or use the console instead.



