diff --git a/_posts/2018-01-30-aws-lambda-ecs-runtask.md b/_posts/2018-01-30-aws-lambda-ecs-runtask.md
new file mode 100644
index 0000000..1673d00
--- /dev/null
+++ b/_posts/2018-01-30-aws-lambda-ecs-runtask.md
@@ -0,0 +1,49 @@
+---
+title: Launching Fargate instances from AWS Lambda
+slug: aws-lambda-ecs-runtask
+layout: post
+categories: aws serverless
+date: '2018-01-30 01:00:00 +0000'
+---
+
+Over the last few days, I've been experimenting with serverless web application development. This has included testing out [Fargate](https://aws.amazon.com/fargate/), Amazon's new managed container deployment service, and the more established [Lambda](https://aws.amazon.com/lambda/) and [API Gateway](https://aws.amazon.com/api-gateway/) services.
+
+The end result that I've been trying to achieve is to use Lambda to launch, via an API Gateway endpoint, a one-off asynchronous container execution on Fargate. So far, I've managed to put most of the jigsaw pieces together with only one major blocking experience.
+
+The problem was giving the Lambda execution role the requisite permissions to launch ECS instances (which can include Fargate instances) automatically. There are a couple of blog posts on the subject out there, and [one in particular](https://lobster1234.github.io/2017/12/03/run-tasks-with-aws-fargate-and-lambda/) that states that the Lambda role needs two policies: one that allows the `ecs:RunTask` action on the relevant resources, and another that adds the `iam:PassRole` that allows the `ecs:RunTask` role to be passed onto the task execution service itself.
+
+This seems reasonably clear, but several hours of trying to make the [Visual Editor](https://aws.amazon.com/blogs/security/use-the-new-visual-editor-to-create-and-modify-your-aws-iam-policies/) apply the policies correctly I was still receiving permissions errors when Lambda tried to launch the Fargate container.
+
+```
+User: arn:aws:sts::123456789012:assumed-role/my-lambda-func-role/myFunc is not authorized to perform: iam:PassRole on resource: arn:aws:iam::123456789012:role/ecsTaskExecutionRole
+```
+
+The solution ended up to be very simple. Switching to the JSON view in the Visual Editor showed that the generated JSON was pretty far away from what I was expecting it to be. Directly editing the JSON, and pasting in the following policies, resolved the issue immediately.
+
+{% highlight json %}
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Sid": "VisualEditor0",
+      "Effect": "Allow",
+      "Action": [
+        "ecs:RunTask"
+      ],
+      "Resource": [
+        "*"
+      ]
+    },
+    {
+      "Sid": "VisualEditor1",
+      "Effect": "Allow",
+      "Action": [
+        "iam:PassRole"
+      ],
+      "Resource": [
+        "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
+      ]
+    }
+  ]
+}
+{% endhighlight %}