HashiCorp at re:Invent ‘19: Terraform Supports Newly Announced AWS Services

HashiCorp is a gold sponsor of this year’s AWS re:Invent, happening December 2-6 in Las Vegas, NV. At our booth on the expo floor (Booth #2434), we have experts to explain how each of our products supports and works with AWS services and can help facilitate application deployments in the cloud.

At last year’s AWS re:Invent, we announced HashiCorp Terraform support for a number of new AWS services and a HashiCorp Consul integration with AWS Cloud Map highlighting our continued partnership with AWS. This year, we are introducing a number of enhancements to the AWS Terraform provider to enable launch-day support for several of the newly announced AWS services. In this blog, we’ll explore those service enhancements.

»AWS BranchConnect

Today at re:Invent, AWS announced enhancements to Amazon Virtual Private Cloud (Amazon VPC) with the introduction of Amazon VPC Ingress Routing, a service that helps customers simplify the integration of network and security appliances within their network topology. With Amazon VPC Ingress Routing, customers can define routing rules at the Internet Gateway (IGW) and Virtual Private Gateway (VGW) to redirect ingress traffic to third-party appliances, before it reaches the final destination. This makes it easier for customers to deploy production-grade applications with the networking and security services they require within their Amazon VPC. This blog explains how to use Terraform to take advantage of these enhancements to VPC ingress routing.

In order to enable Amazon VPC Ingress Routing in a VPC, operators supply an attribute to an Amazon Elastic Compute Cloud (Amazon EC2) Route Table Association that points to an Internet or Virtual Private Gateway ID that will be used for Ingress Routing. Here is a sample configuration of an Amazon EC2 Route Table Association that has enhanced ingress routing enabled:

resource "aws_route_table_association" "example" {
    gateway_id = aws_internet_gateway.example.id
    route_table_id = aws_route_table.example.id
}

As shown in this example, operators declare that this Amazon EC2 instance will enable enhanced ingress routing rules. The rules will be enabled once a terraform apply is run without any additional changes to this instance. For users looking to learn more about Amazon VPC Ingress Routing, please visit the AWS blog.

»Amazon EKS Managed Node Groups

At KubeCon North America in San Diego, AWS announced the release of Managed Node Groups for Amazon EKS. We are proud to announce we provided launch-day support for this feature in Terraform. The Managed Node Groups functionality allows automated management of Kubernetes worker nodes by creating, updating, and deleting an Auto Scaling Group (ASG) with EKS-compatible Kubernetes software and configuration pre-installed on nodes. Previously, worker nodes and any updates would need to be configured and performed manually.

Available in version 2.38.0 of the Terraform AWS Provider, a new aws_eks_node_group resource can manage this new functionality. The resource documentation can be found on the Terraform website. EKS and the new Terraform resource support in-place updates for EKS Amazon Machine Image (AMI) updates, which can automatically be deployed across nodes while respecting Kubernetes Pod Disruption Budgets.

EKS Node Groups require an IAM Role to provide permissions for the infrastructure management and EC2 Subnets for the worker nodes to reside. An example Terraform configuration, given an existing VPC and EKS Cluster, is provided below:

# Example IAM Role for EKS Node Group

resource "aws_iam_role" "example" {
  name = "eks-node-group-example"
  
  assume_role_policy = jsonencode({
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
    Version = "2012-10-17"
  })
}

resource "aws_iam_role_policy_attachment" "example-AmazonEKSWorkerNodePolicy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
  role       = aws_iam_role.example.name
}

resource "aws_iam_role_policy_attachment" "example-AmazonEKS_CNI_Policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
  role       = aws_iam_role.example.name
}

resource "aws_iam_role_policy_attachment" "example-AmazonEC2ContainerRegistryReadOnly" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
  role       = aws_iam_role.example.name
}

# Example Subnets for EKS Node Group

data "aws_availability_zones" "available" {
  state = "available"
}

resource "aws_subnet" "example" {
  count = 3

  availability_zone = data.aws_availability_zones.available.names[count.index]
  cidr_block        = cidrsubnet(aws_vpc.example.cidr_block, 8, count.index)
  vpc_id            = aws_vpc.example.id

  tags = {
    "kubernetes.io/cluster/${aws_eks_cluster.example.name}" = "shared"
  }
}

# Example EKS Node Group

resource "aws_eks_node_group" "example" {
  cluster_name    = aws_eks_cluster.example.name
  node_group_name = "example"
  node_role_arn   = aws_iam_role.example.arn
  subnet_ids      = aws_subnet.example[*].id

  scaling_config {
    desired_size = 1
    max_size     = 1
    min_size     = 1
  }
}

»Amazon EKS for AWS Fargate

In addition to Managed Node Groups, AWS also introduced the ability for Amazon EKS clusters to run workloads with Fargate worker nodes at re:Invent. This enhancement to Fargate provides EKS users the same capabilities previously available only for Amazon ECS containers. Users relying on EKS for alleviating some of the challenges of managing Kubernetes within AWS environments can now also leverage Fargate for managing the underlying infrastructure of these clusters. To support this new functionality, we’ve added an additional resource to the Terraform AWS provider, aws_eks_fargate_profile. By adding this resource, new or existing Kubernetes Pod deployments that match the configured selectors will launch within Fargate. Here is an example of that configuration:

resource "aws_eks_fargate_profile" {
  cluster_name           = aws_eks_cluster.example.name           
  name                   = "example_fargate_profile"                   
  pod_execution_role_arn = aws_iam_role.example.arn 
  subnet_ids             = aws_subnet.example[*].id          
  tags = {
    TagKey1 = “TagValue1”
  }                   

  selectors { 
    labels = {
      LabelKey1 = “LabelValue1”
    }    
    namespace = "example-namespace" 
  }
}

To learn more about this resource, read this blog.

»AWS Lambda Provisioned Concurrency

AWS Lambda is an event-driven serverless computing platform that helps users run code on compute resources it manages. Today at re:Invent, AWS announced that users will be able to set expected concurrency on Lambda functions or aliases. After the initial setup, users will not experience burst throttles or cold starts for their Lambda functions or aliases.

Now, users can leverage Terraform for managing the expected concurrency of their Lambda functions and aliases. Terraform introduces a new resource aws_lambda_provisioned_concurrency_config that will allow users to configure the expected concurrency of an AWS Lambda function or alias as shown in the example below:

resource "aws_lambda_alias" "example" {
  function_name    = aws_lambda_function.example.function_name
  function_version = aws_lambda_function.example.version
  name             = "example"
}

resource "aws_lambda_provisioned_concurrency_config" "example" {
  function_name                     = aws_lambda_alias.example.function_name
  provisioned_concurrent_executions = 100
  qualifier                         = aws_lambda_alias.example.name
}

»Conclusion

Our collaboration with AWS enables us to continue providing new AWS service support at launch for Terraform users. As AWS continues to expand their container and serverless offerings, our goal is to make sure that users are able to incorporate these services into their existing Terraform workflows. If you are attending AWS re:Invent and have questions about any of these services, please come to booth #2434 on the expo hall floor. For more information about Terraform, visit our product page.