Accelerate deployments on AWS with effective governance
AWS Architecture BlogAccelerate deployments on AWS with effective governanceby Rostislav Markov, Justin Kuskowski, and Nathan Scott | on12 AUG 2022| inAmazon EC2,Architecture,AWS CodeCommit,AWS CodePipeline,AWS Fargate,AWS Service Catalog|Permalink|ShareAmazon Web Services (AWS) users ask how to accelerate their teams’ deployments on AWS while maintaining compliance with security controls. In this blog post, we describe common governance models introduced in mature organizations to manage their teams’ AWS deployments. These models are best used to increase the maturity of your cloud infrastructure deployments.Governance models for AWS deploymentsWe distinguish three common models used by mature cloud adopters to manage their infrastructure deployments on AWS. The models differ in what they control: the infrastructure code, deployment toolchain, or provisioned AWS resources. We define the models as follows:Central pattern library, which offers a repository of curated deployment templates that application teams can re-use with their deployments.Continuous Integration/Continuous Delivery (CI/CD) as a service, which offers a toolchain standard to be re-used by application teams.Centrally managed infrastructure, which allows application teams to deploy AWS resources managed by central operations teams.The decision of how much responsibility you shift to application teams depends on their autonomy, operating model, application type, and rate of change. The three models can be used in tandem to address different use cases and maximize impact. Typically, organizations start by gathering pre-approved deployment templates in a central pattern library.Model 1: Central pattern libraryWith this model, cloud platform engineers publish a central pattern library from which teams can reference infrastructure as code templates. Application teams reuse the templates byforkingthe central repository or by copying the templates into their own repository. Application teams can also manage their own deployment AWS account and pipeline withAWS CodePipeline), as well as the resource-provisioning process, while reusing templates from the central pattern library with a service likeAWS CodeCommit. Figure 1 provides an overview of this governance model.Figure 1. Deployment governance with central pattern libraryThe central pattern library represents the least intrusive form of enablement via reusable assets. Application teams appreciate the central pattern library model, as it allows them to maintain autonomy over their deployment process and toolchain. Reusing existing templates speeds up the creation of your teams’ first infrastructure templates and eases policy adherence, such as tagging policies and security controls.After the reusable templates are in the application team’s repository, incremental updates can be pulled from the central library when the template has been enhanced. This allows teams to pull when they see fit. Changes to the team’s repository will trigger the pipeline to deploy the associated infrastructure code.With the central pattern library model, application teams need to manage resource configuration and CI/CD toolchain on their own in order to gain the benefits of automated deployments. Model 2 addresses this.Model 2: CI/CD as a serviceIn Model 2, application teams launch a governed deployment pipeline fromAWS Service Catalog. This includes the infrastructure code needed to run the application and“hello world”source code to show the end-to-end deployment flow.Cloud platform engineers develop the service catalog portfolio (in this case the CI/CD toolchain). Then, application teams can launch AWS Service Catalog products, which deploy an instance of the pipeline code and populated Git repository (Figure 2).The pipeline is initiated immediately after the repository is populated, which results in the “hello world” application being deployed to the first environment. The infrastructure code (for example,Amazon Elastic Compute Cloud [Amazon EC2]and AWSFargate)will be located in the application team’s repository. Incremental updates can be pulled by launching a product update from AWS Service Catalog. This allows application teams to pull when they see fit.Figure 2. Deployment governance with CI/CD as a serviceThis governance model is particularly suitable for mature developer organizations with full-stack responsibility or platform projects, as it provides end-to-end deployment automation to provision resources across multiple teams and AWS accounts. This model also adds security controls over the deployment process.Since there is little room for teams to adapt the toolchain standard, the model can be perceived as very opinionated. The model expects application teams to manage their own infrastructure. Model 3 addresses this.Model 3: Centrally managed infrastructureThis model allows application teams to provision resources managed by a central operations team as self-service. Cloud platform engineers publish infrastructure portfolios to AWS Service Catalog with pre-approved configuration by central teams (Figure 3). These portfolios can be shared with all AWS accounts used by application engineers.Provisioning AWS resources viaAWS Service Catalogproducts ensures resource configuration fulfills central operations requirements. Compared with Model 2, the pre-populated infrastructure templates launch AWS Service Catalog products, as opposed to directly referencing the API of the corresponding AWS service (for example Amazon EC2). This locks down how infrastructure is configured and provisioned.Figure 3. Deployment governance with centrally managed infrastructureIn our experience, it is essential to manage the variety of AWS Service Catalog products. This avoids proliferation of products with many templates differing slightly. Centrally managed infrastructure propagates an “on-premises” mindset so it should be used only in cases where application teams cannot own the full stack.Models 2 and 3 can be combined for application engineers to launch both deployment toolchain and resources as AWS Service Catalog products (Figure 4), while also maintaining the opportunity to provision from pre-populated infrastructure templates in the team repository. After the code is in their repository, incremental updates can be pulled by running an update from the provisioned AWS Service Catalog product. This allows the application team to pull an update as needed while avoiding manual deployments of service catalog products.Figure 4. Using AWS Service Catalog to automate CI/CD and infrastructure resource provisioningComparing modelsThe three governance models differ along the following aspects (see Table 1):Governance level:What component is managed centrally by cloud platform engineers?Role of application engineers:What is the responsibility split and operating model?Use case:When is each model applicable?Table 1. Governance models for managing infrastructure deploymentsModel 1: Central pattern libraryModel 2: CI/CD as a serviceModel 3: Centrally managed infrastructureGovernance levelCentrally defined infrastructure templatesCentrally defined deployment toolchainCentrally defined provisioning and management of AWS resourcesRole of cloud platform engineersManage pattern library and policy checksManage deployment toolchain and stage checksManage resource provisioning (including CI/CD)Role of application teamsManage deployment toolchain and resource provisioningManage resource provisioningManage application integrationUse caseFederated governance with application teams maintaining autonomy over application and infrastructurePlatform projects or development organizations with strong preference for pre-defined deployment standards including toolchainApplications without development teams (e.g., “commercial-off-the-shelf”) or with separation of duty (e.g., infrastructure operations teams)ConclusionIn this blog post, we distinguished three common governance models to manage the deployment of AWS resources. The three models can be used in tandem to address different use cases and maximize impact in your organization. The decision of how much responsibility is shifted to application teams depends on your organizational setup and use case.Want to learn more?Why Deployment Requirements are Important When Making Architectural ChoicesMaking Effective Decisions for Your V1 AWS DesignIntroduction to DevOps on AWSPracticing Continuous Integration and Continuous Delivery on AWSRostislav MarkovRostislav Markov is principal architect with AWS Professional Services. As technical leader in Strategic Industries, he works with AWS customers and partners on their cloud transformation programs. Outside of work, he enjoys spending time with his family outdoors and exploring New York City culture.Justin KuskowskiJustin Kuskowski is a Principal DevOps Consultant at Amazon Web Services. He works directly with AWS customers to provide guidance and technical assistance around improving their value stream which ultimately reduces product time to market and leads to a better customer experience. Outside of work, Justin enjoys traveling the country to watch his two kids play soccer and spending time with his family and friends wakesurfing on the lakes in Michigan.Nathan ScottNathan Scott is a principal architect with AWS Professional Services, where he helps global enterprise customers with strategic initiatives. He has a passion for operational excellence and supported customers in successful cloud adoption, mass migration, transformation, security, infrastructure architecture, and automation.
Amazon Web Services (AWS) users ask how to accelerate their teams’ deployments on AWS while maintaining compliance with security controls. In this blog post, we describe common governance models introduced in mature organizations to manage their teams’ AWS deployments. These models are best used to increase the maturity of your cloud infrastructure deployments. Governance models […]
Rostislav Markov
Amazon EC2 Architecture AWS CodeCommit AWS CodePipeline AWS Fargate AWS Service Catalog