I saw a video on YouTube about how to make your business card smart with a simple NFC sticker. The problem is that while you can program a vCard into a sticker, iOS devices don’t support them yet. The only way to get an iPhone to read an NFC vCard is to host the vCard file on the web. Then it hit me. Why not host the vCard on AWS using only free tier resources.

The obvious solution was Lambda and Lambda Function URLs since they are completely free. Plus, you can be sure that AWS will still be around in 5 or 10 years, so your digital business card will still be running.
Also, it’s very easy to update your information if something changes, you don’t have to buy a new one. Which is good for the environment too!

During development I ran into issues that required creating extra policies to make it work. Since I wanted to make it as simple as possible for everyone to use it I created a CloudFormation template that creates all the resources for you.
And when you no longer need it, CloudFormation can delete all the used resources. But why would you do that when it’s completely free.

The code is written in Node.js 18.x and produces a v. 3.0 vCard. You might ask why not v. 4.0 and the answer is simple. Apple doesn’t support it and I wanted to make it as compatible as possible.
The other problem I faced is that according to the vCard specifications you can link an image URL as your photo, but Apple devices don’t support that either. The photo should be Base64 encoded in your vCard.
That is why CloudFormation creates an S3 bucket where you can store your photo (avatar.jpeg) and the Lambda function will convert it to Base64 and include it in your card.

Not just Apple, AWS has some weird things too. For example, when you create a FunctionURL for your Lambda function, this URL is not defined in your Lambda environment variable. To get the FunctionURL, you need to grant the GetFunctionUrlConfig role to read your function URL. Since a vCard allows you to define the source of the vCard where you can always get the latest version, I had to create a policy and attach it to the Lambda role to include the FunctionURL in the vCard.

The other issue I faced is that while you can include your Lambda code in CloudFormation, it creates an index.js file instead of an index.mjs which is required for Node.js 18.x. There is a solution to include the code in an S3 bucket and CloudFormation will retrieve the code from there, but then you are stuck with the region where your S3 bucket is. So I created two CloudFormation templates.
If you want the easiest installation and don’t want to change your region, use the default template. This will run in US East (N. Virginia). If you want to host your business card in another region, use the template-with-code.yaml instead, but you will need to rename index.js to index.mjs for the code to work.

All the source code is available on GitHub under the Apache 2.0 license. See the GitHub page for detailed installation information.
Use template.yaml if you want the simplest installation.
If you want to specify the region in which the resources are created, use the template-with-code.yaml stack instead and rename the index.js source file to index.mjs.

I hope this little code is as useful as it was fun to write it.

A Free and easy DIY digital business card bejegyzés először Road to AWS-én jelent meg.

Creating the Lambda function

First, we create a Lambda function as in the previous post but instead of selecting Use a blueprint we now select Author from scratch. We give our function a name. Under Permissions we won’t create a new role for this function, we will select our existing role that has been created by our blueprint.

After clicking Create function our Lambda code is created and is ready to be linked with our API Gateway. For this, we go into the API Gateway service.

We would like to use this function as a new resource so we create a new resource and in that a new method. On the method settings, we select our new Lambda function as we did before. We now can see in our API flow diagram how our newly created Lambda function is executed.

Upon clicking on Test we can test our new API call and everything looks okay. Are we sure?!

Is everything okay?

Remember, that we selected to use an existing role for our new Lambda function. Does our role have all the required permissions?

If we go back to Lambda and check out the Monitor section we see no errors.

But upon clicking View logs in CloudWatch we get an error.

This means that logging doesn’t currently work on our new Lambda function. We have to manually create a log group and allow our role to write to this log.

In the CloudWatch console, we select Log groups and click on Create log group and name our log group exactly as in the error message. In our case: /aws/lambda/simple-api-auth

When the log group is created remember to note down its ARN because we will later need it.

Now, to allow our role to write to this log group, we have to go to IAM and modify our role. We see that the CloudWatch permissions are in the AWSLambdaBasicExecutionRole policy.

We now select this policy and click on Edit policy. Under the resources section, we click on Add ARN and add our newly created log groups ARN. Save the policy.

And we are done! We have added a new function to our API Gateway and set up the necessary permissions.

Takeaways:

• Keep your permissions maintained in IAM. Specify resources and only allow policies that are required.

A Adding a new Lambda function to an API Gateway bejegyzés először Road to AWS-én jelent meg.