Lambda Architecture vs. Container Architecture
ACM.300 Resolving errors caused by architecture mismatch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: Lambda | Container Security | Application Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In the last post I showed you how to enable CloudWatch logging for Lambda.
In the process I got the following error:
"errorType*: "Runtime.InvalidEntrypoint,
"errorMessage": "Requestld: [id] Error: fork/exec /entry.sh: exec format error"What’s that all about? I’m going to tell your up front that I think this error could be better. It seems like when running the Lambda AWS could determine the problem and present a better error message, but I figured it out based on the pain others have faced.
I got a clue from a comment on Twitter that I might have an architecture mismatch when I was trying to test a Lambda function with the Lambda Runtime Interface Emulator (RIE). Now I’m getting this error when deployed as a Lambda function and this post says basically the same thing:
Let’s take a look at what architectures we are using for the container and the Lambda function and see if they align.
Head over to the Lambda console where we deployed the Lambda function. On the Image tab you can see that the architecture is x86_64. Makes sense. If you recall the post where I created the CloudFormation template, I did not specify the architecture as that property is not required. The default is x86 (Intel hardware). That means AWS is executing this function on x86 hardware and that hardware and operating systems running on it need to interface in a certain way.
Take a look at our options for the CloudFormation property. We can use arm64 or x86_64 and the default is x86_64.
So I was sitting next to one of my AWS heroes at an event in Seattle, Ed Miller. He said he worked for Arm and I mistakenly thought he worked with Arm for AWS. I asked him which is better, Arm or x86 and he said, “You’re asking the Arm guy?” 😆 Oops. But he offered some insight anyway.
Basically from what I have read and been told, Intel may still have an edge and have better performance for some use cases at this time, but Arm is catching up fast. In many cases, Arm may be more cost-effective on AWS. It all depends on your use case so if you want to know which is really better or cheaper, you’ll have to do some performance testing and cost analysis for your particular architecture and application.
If you’re running a container or software on a particular platform, it has to be compatible with that platform. So on which architecture is the container that I built design to run? Recall that I pulled it from this blog post:
I built this image on my EC2 instance. Head over to the EC2 dashboard.
Click on the EC2 instance. Scroll down to AMI ID under the details.
Click on the AMI ID.
On the list of AMIs click on the AMI ID link again.
The Amazon Machine Image is essentially the definition of the EC2 instance configuration, including the EC2 instance architecture.
I built my docker container on an EC2 instance with the arm64 architecture, but I’m trying to run the container on a Lambda function with an x86_64 configuration.
If you built the docker file on your local laptop or some other machine, you would need to know if that machine is running x86_64 or arm64. There are also older 32 bit architectures but most machines are using 64 bit (the 64 in x86_64 and arm64.) I’ll leave it as an exercise to the reader to research the difference between 32 and 64 bit architectures. You might need to understand something about bits and the math I covered in these posts.
Anyway, let’s see if I can alter my template to specify the architecture and set it to arm64 and then test the Lambda function again.
For now I’m going to set the default to arm64 so I don’t have to go back and modify the deployment script.
Note the type is a list since you can create multiple architecture containers, but this container only supports arm. You can read about multiple-architecture containers here:
Reference the parameter.
Redeploy using the deploy script we created a few posts back for the dockertest Lambda function.
Verify the architecture is updated to arm64.
Test the Lambda as we did in the last post. Success. Kind of.
We have another error, but this error is inside the container.
In the next post I’ll fix that and explain why deploying with containers is even cooler than what I’ve covered so far — and has some risks of which developers and security teams need to be aware.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2024
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity for Executives in the Age of Cloud
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Appication Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresenationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Medium: Teri Radichel
❤️ Sign Up For Email
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab