Week 29, 2019 - Amazon EventBridge; EC2 Access Improvements; AWS CDK

By (4 minutes read)

Between EventBridge, new ways of connecting to your EC2 instances, and CDK going GA there’s a lot to cover this week.

Amazon EventBridge

Amazon EventBridge builds on CloudWatch Events in that it has much of the same underlying structure and way of working with it. The idea behind it is that, after it’s been setup, a 3rd-party service can trigger an event in your account. And just like with CloudWatch Events you can use this to cause actions to be taken.

Of course, many of the services for which this is useful will already have triggers that they can send. The big difference here is that it’s decoupled so you don’t need to have a service1 waiting for an event to come through. The event will just show up and in turn your automation starts running. If you’ve used CloudWatch Events you’ll be familiar with how you can set up triggers for certain events, while completely ignoring others.

In fact, even if EventBridge isn’t useful for you right now it might be useful to have a look at CloudWatch Events which does the same but for AWS notifications.

EC2 Access Improvements

As before, I remain convinced that you generally shouldn’t connect to your instances. If you really need to though, AWS has recently released several improvements to this. First, a couple of weeks ago they released EC2 Instance Connect. This allows you to use IAM credentials to upload a temporary SSH key to an instance, after which you have 60 seconds to SSH into it using your own key. It is also not limited to the default user. This has a couple of advantages: first, it’s a safer access pattern as you’re not sharing a single key anymore across multiple people2, secondly there is a trace of who logged in, and third because you can control who has access to what user it allows more fine-grained access control.

Last week more improvements came however as the System Manager Session Manager3 now also allows you to connect as a specified operating system user4. As with Instance Connect, access to certain users or roles can be restricted using IAM credentials. The other improvement is that you can now use the aws ssm start-session command as a proxy, enabling you to tunnel SSH (and SCP) sessions through the Session Manager. In short, this allows you to use your regular SSH client and preferred way of working with instances but in a more controlled and safe manner as you don’t need to have any ports open.


The AWS CDK is definitely worth of a full post all by itself, but that will have to wait for a bit5 so in the meantime this is mostly to let you know that it is now GA. I first wrote about it almost a year ago, when it only supported TypeScript and Java. Interestingly enough the GA release supports TypeScript and Python, the latter of which was only added fairly recently.

In case you’re not familiar with it, it is basically a way to automate writing your CloudFormation templates with a more holistic view. So, instead of focusing on purely the infrastructure the idea is that you build it from a view of your application. I think that my summary from last year still mostly stands, and while I’ve tried it out at various points during the preview I haven’t quite gotten my head around it yet. Or rather, I’m not convinced yet that it’s better than traditional DSLs6. I’ll probably try building something substantial with it soon and see how that goes.

Speaking at Container Camp

I’ve been going to the Container Camp conference since it first came to Australia 2 years ago and I’m very happy to say that I’ve been selected as a speaker for its third iteration here. Regular readers won’t be surprised to learn that my topic is related to serverless containers, so I can tell you that together with my friend Prateek Nayak I’ll be giving a talk titled “Keeping an eye on your serverless containers”. If you are interested in this talk, or any of the others on the schedule, you can use the code AWSMELB for a 20% discount on a ticket. And if you are coming, make sure to say hello.

  1. Or even an API Gateway in front of a Lambda function. [return]
  2. And thereby running the risk of that key being shared or stolen. [return]
  3. At least Instance Connect has a better name. [return]
  4. So only users with local accounts on the machine, this doesn’t work for Domain users if you’re connecting to a Windows machine. [return]
  5. My backlog of posts is growing as I’ve been very busy with preparing and giving presentations. [return]
  6. Which I no longer think are needed, as I explained in my article about Macros. [return]
comments powered by Disqus