cloud.gov news

Background: We announced on February 26 that cloud.gov would remove support for the cflinuxfs2 stack (the operating system image for applications). This was the default stack for cloud.gov applications deployed before April 15. On April 15 we set the default stack for new applications to cflinuxfs3.

An OS upgrade, cross-IaaS services, R Shiny apps, and more!

Here’s the latest on how we’ve been trying to make cloud.gov simpler and more secure. (If you find yourself needing to explain cloud.gov to coworkers or leadership, take a look at our new two-pager!)

In the past, we’ve had issues with users being notified of a sandbox purge even though the sandbox didn’t actually get cleared. So in order to provide a more seamless experience, cloud.gov now offers S3 service plans for sandboxes that automatically clear your S3 contents whenever your sandbox is cleared.

For custom domain support, cloud.gov provides a CDN service that uses AWS CloudFront. AWS CloudFront is outside the AWS FedRAMP P-ATO boundary, so we’ve updated the CDN service documentation to explain the compliance impact of using this service more clearly.

Upcoming breaking change

• We will remove support for TLS 1.0 and 1.1 connections to all applications on cloud.gov on March 30, so that all connections must use TLS 1.2. TLS 1.0 and 1.1 are outdated versions of the encryption protocol for HTTPS connections, and federal standards require federal systems to stop using them (see FedRAMP TLS Requirements). After this change, your applications will be inaccessible for anyone using a client device that requires TLS 1.1 or lower. We estimate this change will block less than 1 percent of traffic that reaches applications hosted on cloud.gov today. It’s probably required for your applications by your own agency as well, but if you have any concerns or questions, please contact us.

Announcements

On Tuesday January 9 from 17:09 EST to approximately 23:42 EST (6 hours and 33 minutes), the cloud.gov platform and customer applications were unavailable. This was the longest and most significant outage in the history of our platform. No data was lost.