Skip to content
ECS Task Kite - A simple ambassador container for inter-task communication on ECS -
Go Other
  1. Go 99.0%
  2. Other 1.0%
Branch: master
Clone or download
Type Name Latest commit message Commit time
Failed to load latest commit information.
examples/collect-instanceids Add missing closing p tag Jul 22, 2015
scripts/hack Add travis.yml Nov 3, 2016
Dockerfile Docs: Add IAM policy Sep 24, 2015
LICENSE Update LICENSE May 17, 2017
NOTICE Add licenses Godep stripped Sep 24, 2015 readme: Fix link to ambassador pattern Jun 23, 2017
ecs-task-kite.go Update ecsclient to use more interfaces Sep 24, 2015

ECS Task Kite

What is "ECS Task Kite"

You and your space-buddy are stowing away on a starship in a pair of corrugated tin containers. You know your best gal, Monday, is stowed away aboard another spaceship near the station. "Hey buddy, did you bring your Kite?" You knock on the container wall to get his attention, "I really need to flash a sig at my girl". "Yeah, my Kite's already out on the Sail, just give me her deets". Moments later, without Monday having a clue where you are, your buddy has used the reflected radiation (or lack thereof) on his Kite to find her and get your signal through. All would be well… if there weren't five girls named Monday and your buddy's Kite picked the wrong one at random.

Fortunately for you, the "Monday Quintuplets" are well designed and stateless so you can hardly tell the difference betwixt the lot of them.

No really, what is it?

ECS Task Kite is a proof of concept ambassador container using the ECS APIs. It's meant to be tiny in terms of memory and disk footprint and simple in terms of operation.

Unlike the ambassador pattern documented above, it is expected that this ambassador only be run on the consumer. It is also expected that the server is not identified by IP directly, but rather by ECS Task Family or by ECS Service Name. Furthermore, it is capable of proxying between multiple servers that meet the above criterion (randomly currently).

It is also expected that it be used via either container links or sharing the network namespace with the consumer. In the case of linking, it does not EXPOSE the appropriate ports (due to them being dynamically discovered at runtime), and thus will not work with the --icc option set to false. By default, --icc is set to true.


To use the Task Kite, simply add it to your task definition, link to it, and set the below options as appropriate.


  • Flag: -name=<containerName> set to the name of the container to proxy to within the referenced task or service.
  • Flag: -family=<taskFamily[:revision]> XOR -service=<serviceName>.


  • Flag: -public=<true|false>: Whether to proxy to the public IP of the EC2 instance(s); default false.
  • Flag: -cluster=<cluster>: The ECS cluster containing the above tasks or service; default "default".
  • Environment variable: AWS_REGION=<AWS Region> set to the region of the task(s) you will be ambassadoring; default current region.

The Task Kite will proxy to a task of the specified family or within the specified service at random when a connection is made to it on a valid port.

IAM Policy

The Task Kite makes a number of API calls which should be covered by a policy similar to the following:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": [
            "Resource": "*"

What is it not?

  • Production ready
  • Highly configurable (perhaps you want HAProxy?)
  • Usable outside of ECS (Have I mentioned HAProxy?)
  • Well tested


See the subdirectories of the examples directory.


Apache 2.0


Yes please!

You can’t perform that action at this time.