I was looking for a solution that was open source and that anyone could contribute to it. While discussing this issue with María Encinar (EMEA Community Programs Manager
– AWS), it turned out that other European countries are facing similar problems and there is also a trend on these conference websites. She recommended me this GitHub repository.
As far as I could track it down it all started with Android Study Group, which created a GitHub Page for Android conferences. Spain, Portugal, Italy and even Canada soon followed. I realized right away that I am on the right track. The source code is open source, hosted on GitHub and anyone can contribute to it with a simple Pull request. This was a great foundation, but I knew I wanted more.

Hungarian translation

The main problem we face here in Hungary is that while there are a lot of events happening here, some are primarily in English. For someone who is just starting with AWS, this could be an extra challenge that they might not take. That is why my first improvement was to translate the interface into Hungarian. I didn’t want to exclude English speakers as well, so I made the interface bilingual. This way everyone can feel comfortable on the website.

The other improvement I made is that I clearly highlighted the language of the conference. This way I can help people who prefer content in their native language.

Deployment on AWS

I cannot ignore the fact that I am an AWS Community Builder, so it was a no-brainer that I would implement this on AWS. Registering a domain and setting it up on Route 53 was the first step. Then I looked at the possibilities of hosting. The site is written in Jeklly and each page is generated separately. Using GitHub Actions, I can regenerate the static pages every time there is a new commit.
Hosting a static website on AWS isn’t rocket science. S3 static file hosting is a cheap and easy way. I just needed to find a way how to publish my files to S3. Jake Jarvis created a GitHub Action that can sync your files to S3. All you have to do is to create the appropriate IAM permissions and your files will be pushed to the S3 bucket of your choice. From there, AWS will do the rest. I have created a CloudFront distribution to get HTTPS and fast access from Hungary. Currently, there is no AWS region in Hungary, but there is an edge location in Budapest, so serving the site from there gives fast access to Hungarian users.

The outcome

The result is techconf.hu, a community-curated list of tech conferences around Hungary. I sincerely hope that this project will benefit the Hungarian AWS community, and perhaps other countries facing similar issues will follow. Happy Conferencing!

A Bringing together Hungarian technology conferences bejegyzés először Road to AWS-én jelent meg.

The basics: S3 static website hosting

Hosting your static website has never been easier. With Amazon S3 static hosting, you can serve your static pages by simply uploading it to an S3 bucket and enabling public access (be sure to name your bucket as your domain name). You can find a lot of articles on the web that explain how to set up S3 static hosting, which is why I am not going to go into any further details here.

But there are limitations: S3 static hosting doesn’t support HTTPS, the de-facto-minimum for website hosting. To use HTTPS, you need to set up Amazon CloudFront. This comes with a lot of extra features like GeoIP restrictions, caching and a free SSL certificate. Not to mention, you can finally disable your S3 public access (which could be a security risk) and give limited access to CloudFront only (with a bucket policy).

Pro tip: Give CloudFront ListBucket permissions in your S3 bucket policy, otherwise the client will not receive HTTP status codes, including a 404 when trying to access non-existent content:

Mishi

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::roadtoaws.com",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        },
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::roadtoaws.com/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        }
    ]
}

Because of the caching involved with CloudFront, this is not ideal for development. You either have to test your code locally or without HTTPS enabled.  This is the main reason why I would still like to see HTTPS support in S3 in the future.

Make it dynamic

Static websites are a thing of the past. You will most likely need some kind of dynamic content. While there are a lot of services that provide functionality, like E-mail sending, Comments, that you could include in your static code to make it dynamic, you’d most likely have to write your own code. This is where Lambda Function URLs come in handy. With a simple Lambda function, you can execute code or use other AWS resources that you can invoke with a simple HTTP request in your browser. But how do you restrict it to a specific IP, domain, or CloudFront?

AWS recommends authenticating through IAM, and while this is really a secure way, it makes development challenging.  The first thing you see is CORS where you can set your origin to a domain. Unfortunately, this didn’t work for me the way I wanted it to. This doesn’t restrict your Lambda from being called from any IP. You can also set an X-Custom header here, but that doesn’t really limit external access.

Then you look for matching IAM permissions that you can attach to Lambda functions. In the available Policies you can find InvokeFunctionUrl where you can add an IP address to limit the invocation to a specific IP. This sounds great! You create a policy and attach it to your Lambda Role. Unfortunately, this does not restrict your Lambda access either.

So what was my solution?

1. Restrict in code

The first obvious solution is to check the source IP with your Lambda function. Here is a sample code in Node.js (you can find a similar code for other languages online):

const ipAddress = event.identity.sourceIP;

if (ipAddress === '52.84.106.111') {
  const error = {
      statusCode: 403,
      body: JSON.stringify('Access denied'),
  };
  
  return error;
} else {
  const hello = {
      statusCode: 200,
      body: JSON.stringify('Hello World!'),
  };
  
  return hello;
}

While this obviously works, you’re adding extra code to a Lambda function that’s primary role is to do something else. Not to mention that this will increase the runtime and the resources used by Lambda. Most importantly, how can you be sure that the IP you get in the sourceIP variable is really the IP the client comes from.

My biggest concern with this solution was that I not only wanted to restrict my functions to one specific IP but to the whole CloudFront distribution – so that I can be sure that it is called from one of my static pages –. With this method, it would be a hassle to maintain an up-to-date list of all CloudFront servers.

2. reCAPTCHA

Yes, you heard it right, Google reCAPTCHA. This may sound strange at first, but this is the solution I have implemented in my work and provides the solutions to the above challenges.

Embeding the reCAPTCHA code in your static web pages is a good idea. In fact, Google recommends that you include the code in all of your pages – not just the ones that you need it, such as form validations – because that way the algorithm can more effectively detect fraudulent use. Within the lambda function, I can now validate whether or not the user really invoked my Lambda function URL from my static web page. Here is the code I use to verify the reCAPTCHA request:

const gRecaptchaResponse = event.queryStringParameters["g-recaptcha-response"];
    
    var verificationUrl = "https://www.google.com/recaptcha/api/siteverify?secret=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&response=" + gRecaptchaResponse;
    const recaptchaResult = await getRequest(verificationUrl);
    
    if (false == recaptchaResult.success || 0.5 > recaptchaResult.score) {
      return error;
    }

In conclusion

S3 static website hosting is the easiest way to start with your serverless journey. While there are obstacles ahead you can always find a serverless solution.

A Restricting AWS Lambda Function URLs to CloudFront bejegyzés először Road to AWS-én jelent meg.