# Infrastructure as code
A fundamental principle of DevOps is to treat infrastructure the same way developers treat code. Application code has a defined format and syntax. If the code is not written according to the rules of the programming language, applications cannot be created. Code is stored in a version management or source control system that logs a history of code development, changes, and bug fixes. When code is compiled or built into applications, we expect a consistent application to be created, and the build is repeatable and reliable.
Practicing *infrastructure as code* means applying the same rigor of application code development to infrastructure provisioning. All configurations should be defined in a declarative way and stored in a source control system such as [AWS CodeCommit](https://aws.amazon.com/codecommit), the same as application code. Infrastructure provisioning, orchestration, and deployment should also support the use of the infrastructure as code.
Infrastructure was traditionally provisioned using a combination of scripts and manual processes. Sometimes these scripts were stored in version control systems or documented step by step in text files or run-books. Often the person writing the run books is not the same person executing these scripts or following through the run-books. If these scripts or runbooks are not updated frequently, they can potentially become a show-stopper in deployments. This results in the creation of new environments not always being repeatable, reliable, or consistent.
In contrast, AWS provides a DevOps-focused way of creating and maintaining infrastructure. Similar to the way software developers write application code, AWS provides services that enable the creation, deployment and maintenance of infrastructure in a programmatic, descriptive, and declarative way. These services provide rigor, clarity, and reliability. The AWS services discussed in this paper are core to a DevOps methodology and form the underpinnings of numerous higher-level AWS DevOps principles and practices.
AWS offers the following services to define infrastructure as code.
**Topics**
+ [CloudFormation](aws-cloudformation.md)
+ [AWS Serverless Application Model](aws-serverless-application-model.md)
+ [AWS Cloud Development Kit (AWS CDK)](aws-cdk.md)
+ [AWS Cloud Development Kit for Kubernetes](aws-cdk-for-kubernetes.md)
+ [AWS Cloud Development Kit for Terraform](aws-cdk-for-terraform.md)
+ [AWS Cloud Control API](aws-cloud-control-api.md)
# CloudFormation
AWS CloudFormation is a service that enables developers to create AWS resources in an orderly and predictable fashion. Resources are written in text files using JSON or YAML format. The templates require a specific syntax and structure that depends on the types of resources being created and managed. You author your resources in JSON or YAML with any code editor such as [AWS Cloud9](https://aws.amazon.com/cloud9/), check it into a version control system, and then CloudFormation builds the specified services in safe, repeatable manner.
A CloudFormation template is deployed into the AWS environment as a stack. You can manage stacks through the AWS Management Console, AWS Command Line Interface, or CloudFormation APIs. If you need to make changes to the running resources in a stack you update the stack. Before making changes to your resources, you can generate a change set, which is a summary of your proposed changes. Change sets enable you to see how your changes might impact your running resources, especially for critical resources, before implementing them.
![\[A diagram depicting AWS CloudFormation creating an entire environment (stack) from one template\]](http://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/images/figure-1.png)
You can use a single template to create and update an entire environment, or separate templates to manage multiple layers within an environment. This enables templates to be modularized, and also provides a layer of governance that is important to many organizations.
When you create or update a stack in the CloudFormation console, events are displayed, showing the status of the configuration. If an error occurs, by default the stack is rolled back to its previous state. Amazon SNS provides notifications on events. For example, you can use Amazon SNS to track stack creation and deletion progress using email and integrate with other processes programmatically.
AWS CloudFormation makes it easy to organize and deploy a collection of AWS resources, and lets you describe any dependencies or pass in special parameters when the stack is configured.
With CloudFormation templates, you can work with a broad set of AWS services, such as Amazon S3, Auto Scaling, Amazon CloudFront, Amazon DynamoDB, Amazon EC2, Amazon ElastiCache, AWS Elastic Beanstalk, Elastic Load Balancing, IAM, AWS OpsWorks, and Amazon VPC. For the most recent list of supported resources, refer to [AWS resource and property types reference](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html).
# AWS Serverless Application Model
The [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) (AWS SAM) is an open-source framework that you can use to build [serverless applications](https://aws.amazon.com/serverless/) on AWS.
AWS SAM integrates with other AWS services, so creating serverless applications with AWS SAM provides the following benefits:
+ **Single-deployment configuration** — AWS SAM makes it easy to organize related components and resources, and operate on a single stack. You can use AWS SAM to share configuration (such as memory and timeouts) between resources, and deploy all related resources together as a single, versioned entity.
+ **Extension of CloudFormation** — Because AWS SAM is an extension of CloudFormation, you get the reliable deployment capabilities of CloudFormation. You can define resources by using CloudFormation in your AWS SAM template.
+ **Built-in best practices** — You can use AWS SAM to define and deploy your IaC. This makes it possible for you to use and enforce best practices such as code reviews.
# AWS Cloud Development Kit (AWS CDK)
The [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk) is an open source software development framework to model and provision your cloud application resources using familiar programming languages. AWS CDK enables you to model application infrastructure using TypeScript, Python, Java, and .NET. Developers can leverage their existing Integrated Development Environment (IDE), using tools such as autocomplete and in-line documentation to accelerate development of infrastructure.
AWS CDK utilizes CloudFormation in the background to provision resources in a safe, repeatable manner. Constructs are the basic building blocks of CDK code. A construct represents a cloud component and encapsulates everything CloudFormation needs to create the component. The AWS CDK includes the [AWS Construct Library](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html), containing constructs representing many AWS services. By combining constructs together, you can quickly and easily create complex architectures for deployment in AWS.
# AWS Cloud Development Kit for Kubernetes
[AWS Cloud Development Kit for Kubernetes](https://aws.amazon.com/blogs/containers/introducing-cdk-for-kubernetes) is an open-source software development framework for defining Kubernetes applications using general-purpose programming languages.
Once you have defined your application in a programming language (as of the date of this publication, only Python and TypeScript are supported), cdk8s will convert your application description in to pre-Kubernetes YAML. This YAML file can then be consumed by any Kubernetes cluster running anywhere. Because the structure is defined in a programming language, you can use the rich features provided by the programming language. You can use the abstraction feature of the programming language to create your own boilerplate code, and reuse it across all of the deployments.
# AWS Cloud Development Kit for Terraform
Built on top of the open source [JSII library](https://aws.github.io/jsii/), [CDK for Terraform](https://developer.hashicorp.com/terraform/cdktf) (CDKTF) allows you to write Terraform configurations in your choice of C\$1, Python, TypeScript, Java, or Go and still benefit from the full ecosystem of Terraform providers and modules. You can import any existing provider or module from the Terraform Registry into your application, and CDKTF will generate resource classes for you to interact with in your target programming language.
With CDKTF, developers can set up their IaC without context switching from their familiar programming language, using the same tooling and syntax to provision infrastructure resources similar to the application business logic. Teams can collaborate in familiar syntax, while still using the power of the Terraform ecosystem and deploying their infrastructure configurations via established Terraform deployment pipelines.
# AWS Cloud Control API
[AWS Cloud Control API](https://aws.amazon.com/cloudcontrolapi/) is a new AWS capability that introduces a common set of Create, Read, Update, Delete, and List (CRUDL) APIs to help developers manage their cloud infrastructure in an easy and consistent way. The Cloud Control API common APIs allow developers to uniformly manage the lifecycle of AWS and third-party services.
As a developer, you might prefer to simplify the way you manage the lifecycle of all your resources. You can use Cloud Control API's uniform resource configuration model with a pre-defined format to standardize your cloud resource configuration. In addition, you will benefit from uniform API behavior (response elements and errors) while managing your resources.
For example, you will find it simple to debug errors during CRUDL operations through uniform error codes surfaced by Cloud Control API that are independent of the resources you operate on. Using Cloud Control API, you will also find it simple to configure cross-resource dependencies. You will also no longer require to author and maintain custom code across multiple vendor tools and APIs to use AWS and third-party resources together.