Tasks for AWS 2.15 Release Notes

30 Januar 2018

The Utoolity team is pleased to present Tasks for AWS 2.15 – this release catches up on several serverless announcements from 'AWS re:Invent 2017': It adds support for the AWS Fargate launch type in Amazon ECS, and adds support for traffic shifting, concurrency limits, and the C# .NET Core 2.0 and Go 1.x runtimes in AWS Lambda.

You can now run your Docker containers as an Amazon ECS Task or Amazon ECS Service without managing servers and clusters, and exercise more control over the deployment and concurrent execution of an AWS Lambda Function, which can now also use the C# .NET Core 2.0 and Go 1.x runtimes.

If you are using Bamboo remote agents, please review the Tasks for AWS 2.15 Upgrade Notes for important information on this release.

Learn more and try it for free in:

Bamboo

On this page:

1 Highlights
2 Resolved issues
- 2.1 Release 2.15.5
- 2.2 Release 2.15.4
- 2.3 Release 2.15.3
- 2.4 Release 2.15.2
- 2.5 Release 2.15.1
- 2.6 Release 2.15.0

Highlights

Use AWS Fargate to run Docker containers on Amazon ECS without managing infrastructure

You can now use the AWS Fargate launch type to run Docker containers with the Amazon ECS Task task or the Amazon ECS Service task without managing servers or clusters – refer to the resp. introductory blog posts for more details:

Introducing AWS Fargate – Run Containers without Managing Infrastructure

AWS Fargate is an easy way to deploy your containers on AWS. To put it simply, Fargate is like EC2, but instead of giving you a virtual machine you get a container. It’s a technology that allows you to use containers as a fundamental compute primitive without having to manage the underlying instances. All you need to do is build your container image, specify the CPU and memory requirements, define your networking and IAM policies, and launch. With Fargate, you have flexible configuration options to closely match your application needs and you’re billed with per-second granularity. [...]

AWS Fargate: A Product Overview

Perform gradual deployments of AWS Lambda functions

You can now gradually deploy your Lambda function by shifting traffic between two function versions with the AWS Lambda Function task – refer to the resp. introductory blog post for more details:

Implementing Canary Deployments of AWS Lambda Functions with Alias Traffic Shifting

Before the release of traffic shifting for Lambda aliases, deployments of a Lambda function could only be performed in a single “flip” by updating function code for version $LATEST, or by updating an alias to target a different function version. After the update propagates, typically within a few seconds, 100% of function invocations execute the new version. Implementing canary deployments with this model required the development of an additional routing layer, further adding development time, complexity, and invocation latency. While rolling back a bad deployment of a Lambda function is a trivial operation and takes effect near instantaneously, deployments of new versions for critical functions can still be a potentially nerve-racking experience.
With the introduction of alias traffic shifting, it is now possible to trivially implement canary deployments of Lambda functions. By updating additional version weights on an alias, invocation traffic is routed to the new function versions based on the weight specified. [...]

Limit concurrent executions of AWS Lambda functions

You can now limit the concurrent execution impact of your Lambda functions by setting a function specific concurrency limit with the AWS Lambda Function task – refer to the resp. introductory blog post for more details:

Managing AWS Lambda Function Concurrency

You can now set a concurrency limit on individual Lambda functions in an account. The concurrency limit that you set reserves a portion of your account level concurrency for a given function. All of your functions’ concurrent executions count against this account-level limit by default.
If you set a concurrency limit for a specific function, then that function’s concurrency limit allocation is deducted from the shared pool and assigned to that specific function. AWS also reserves 100 units of concurrency for all functions that don’t have a specified concurrency limit set. This helps to make sure that future functions have capacity to be consumed. [...]

Circuit Breaker / Emergency Kill Switch

The Lambda function concurrent execution limit can also be used as a circuit breaker or emergency kill switch by setting the reserved concurrency to zero so that a function cannot be invoked anymore until the concurrency limit is raised again.

Use the C# .NET Core 2.0 and Go 1.x runtimes for AWS Lambda functions

You can now use the C# .NET Core 2.0 and Go 1.x runtimes in the AWS Lambda Function task – refer to the resp. introductory blog posts for more details: