“GovCloud” is a relatively new, and still rather ambiguous, term on the web. One might assume “the Cloud for Government”, and in a sense you’d be right, but what exactly does that mean? In this post, we will explore how the term is being used, and what it refers to.
The GovCloud paradigm focuses on the highly regulated needs of public organizations, using those regulations to ensure secure and successful deployments to the cloud, along with a consolidation and phased deprecation of outdated processes.
Within both contexts, the GovCloud paradigm aims to focus on standardized approaches to adopting and securing cloud solutions. Or as FedRAMP puts it, “facilitating the shift from insecure, tethered, tedious IT to secure, mobile, nimble, and quick IT”.
There are significant cost savings and value propositions in moving or expanding IT operations to cloud infrastructure, and government organizations around the world know this too. To organize these transitions, Governing bodies are working to define and adopt frameworks and guidelines for running government-managed or controlled IT operations on cloud providers with GovCloud products.
Collectively, “GovCloud” refers to this global initiative. While the specifics differ by jurisdiction, these government-specific frameworks provide guidelines for deploying and operating infrastructure on the cloud. For example, “FedRAMP” in the US is the “Federal Risk and Authorization Management Program” that provides an assessment and authorization process to ensure proper security and usability of cloud computing products and services. Under this program, approved FedRAMP cloud service providers (CSPs) can provide services for US government agencies and publicly regulated organizations.
Whether migrating from a cloud on an existing commercial stack, or from on-premises data centers, Government organizations are interested in the cloud for significant cost savings in infrastructure and reduction in operational overhead. But a transition to the cloud should ensure Government data and systems are not at risk, and therefore cloud providers are responding with solutions built specifically for Government organizations through GovCloud.
Pre-cloud network and application security looks a lot like a castle and moat. Generally speaking, there are clear boundaries, hardened safe zones with clear access points and explicit ingress/egress rules. Resources are collected together, and accessed by internal entities, or through explicit access rules from outside the moat.
For networks and applications running on cloud infrastructure, the terrain and risks differ significantly. There is no longer the ability to build a moat around a small physical location where the resources you need live and exist. As organizations adopt cloud-based services and deploy applications to shared infrastructure on the cloud, the boundaries we had grown familiar with have disappeared. Permissions and access controls are needed, and secrets sprawl.
Lastly, going to the cloud requires a shift in tooling and practices. Hosting platforms and deployment systems need to be built expecting certain types of failures. The methods for maintaining resilience in the face of failure differ from on prem deployments. Operations teams need to apply devops practices in full to leverage the best in testing, development process and modularizing and reusability of code. Some operations teams may have already begun to apply these practices in full, but for many, the move to the cloud includes those changes as well. Navigating this terrain can be overwhelming at best, and disastrous at worst.
GovCloud products differ from their commercial counterparts in several ways. The primary differences begin with regulation. GovCloud solutions focus on meeting the needs of IT as well as the strategic, financial and operational objectives of federal governments worldwide. Due to the unique requirements imposed on Government organizations, while transitioning to the cloud will bring significant cost savings, the high-security environment in GovCloud solutions present unique challenges that make the initial transition to could more difficult than expected.
In particular, GovCloud products are isolated from their commercial counterparts. This isolation translates to more costly and securely execution data migrations, and it requires operations teams own more of the stack. This comes in the form of additional work requiring expertise in both the systems being moved and the platform the systems will now run on.
A future post will cover more about what makes GovCloud difficult.
Amazon AWS and Microsoft Azure both provide isolated versions of their cloud environments specifically for Government entities. Known as their “GovCloud” product, these environments are segregated from the “commercial” regions used by the private sector (corporate enterprises and private organizations). In general, they are more restrictive in various ways, as compared to their “commercial” counterparts.
AWS refers to their offering as the GovCloud “Region”, though it is not just another region in AWS terminology.
AWS makes their services available within geographical zones known as “Regions”. Within the cloud provider account, regions are near the top of the object hierarchy, standing independently from one another. Partitions are one level up from regions, with a partition grouping one or more regions together, and generally for regulatory and management purposes.
Each partition includes its own authorization and authentication subsystems (IAM) isolated from the others. In addition the list of supported AWS services within each partition differs. AWS GovCloud is one of these “partitions” within AWS’ global cloud infrastructure, and GovCloud Regions are physically isolated from the regions in other partitions. This isolation manifests in different API endpoints and subsystems internal to AWS. The GovCloud regions do not share authentication or authorization systems with the commercial regions. A new account is used to gain access to GovCloud.
As of this writing, there are 2 regions in the public GovCloud partition, `us-gov-west-1` and `us-goveast-1`. Not all of AWS’ services are available in the GovCloud regions. In general, the more advanced managed services are not always available. Surprisingly, Route53 is not available. More subtly, due to the physical isolation of the partition, operations and deployment tooling that is typically run on the commercial regions often need updates to work with GovCloud.
Within the commercial partition, customers can share resources like database snapshots, or setup mirroring for S3 buckets across regions. Due to the partition and separate IAM subsystem within GovCloud, it’s not possible to directly “share” or configure resources across the commercial and GovCloud regions. This brings significant impact to service providers migrating their applications from commercial AWS accounts to a new account on GovCloud. Advanced methods and careful engineering are required to complete these migrations on time and with minimal disruption to your service. FP Complete has significant experience helping clients migrate services, and would be happy to support migrating your production services from commercial to GovCloud regions.
At FP Complete, we have applied our devops experiences to run client applications on GovCloud certified cloud providers. We have created new environments from the ground up and have migrated production systems with minimum downtime. FP Complete have secured applications and networks deployed to GovCloud environments. We have also optimized management tooling to improve the user experience and capabilities available to the engineers who operate these systems.
We have been successful in applying our engineering experience to GovCloud and would like to help you get there! Contact us today for free consultation.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
