The marketing around Serverless likes to make it out like “spinning up” a function is a simple task with no other dependencies. However, Serverless functions have to be triggered somehow. And one of your options is to use AWS Lambda with an ALB.
But if you’ve just learned AWS Lambda and want to set it up with an ALB you’re about to run face first into a ton of new jargon: target groups, listeners, listener rules, ports etc. So if you’re not already familiar with AWS ALB and it’s various ideas you’re going to need to get up to speed.
By the end of this article you’ll understand the main concepts related to AWS ALB’s so that you can expose your Lambda function publically.
Recently I’ve been experimenting with Github Actions as a CI tool, specifically for setting up AWS Lambda on Github Actions.
Container based CI is awesome. And I’m really excited about the community that is building up around it. I hope with container based CI we spend less time fighting CI, and more time building apps.
But until we get there — I’ll try and make the CI fighting a little less painful by giving you a head start. And in this case, we’ll be pushing zipped artifacts for AWS Lambda on Github Actions.
AWS Lambda works by associating artifacts with the running Lambda exectuion. Therefore it’s quite common to zip our artifacts and upload them onto S3 to be used by Lambda. Today I’ll walk you through a quick three step method to upload zipped artifacts onto AWS for later use with AWS Lambda.
By the end of this article you’ll know the first step towards working with AWS Lambda on Github Actions and that means setting up pushing of zipped artifacts to S3.
AWS Access Keys are how you can programatically access the AWS cloud. AWS Access Keys can be used to provision, update — or even delete cloud resources. When it comes to your cloud account, personal or work you don’t want your account to be compromised — it could cost you at a minimum thousands of pounds. So keeping your AWS Access Keys safe is paramount.
Managing your AWS Access keys isn’t as scary as it first seems. With a little knowledge you can experiment and build software in the cloud, all whilst staying safe.
By the end of this article you should know what AWS keys are, why they’re important and five tips you can use to make sure you’re safe when using your access keys.
Have you ever been into the AWS console and been completely baffled about all the concepts and jargon? You’ve got: Security Groups, Inbound rules, VPC’s, Subnets, Internet Gateways, NAT, ENI’s and all of them are related to networking somehow. Put simply: there’s a lot to AWS networking. So if you’re going to break into it somehow you need to know what to focus on: the fundamentals.
Today we’re going to be going through the main networking components you should be familiar with in AWS. We’ll talk you through why you’d need the component, what it is and how you’d use it. Throughout the article we’ll be building up an example of running a web server in a public subnet as part of our own VPC.
By the end of this article you’ll understand the main networking concepts: Private IP’s, Virtual Private Cloud (VPC), Classless Inter Domain Routing (CIDR), Subnets, Internet Gateways and Security Groups and use these to implement a basic network design.
Avoid huge bills and getting locked out of your account
In 2016 hackers compromised my personal AWS setup. Within a matter of hours I received an AWS bill for $3000 dollars 😱😱.😱.😱.
When you’re a Cloud Native Engineer one of the best ways we can learn is through experimenting directly on cloud platforms, like AWS. But, doing so can be fraught with difficulties if you’re not careful when you setup and use your cloud account. An incorrectly setup account is vulnerable to hackers and you could even end up with a massive bill!
By the end of this article you’ll know all the steps to take before accessing your AWS cloud account so that you can experiment and learn about AWS.