Creating subdomains for users using aws-route53

Question

Phew! Okay so what I want is - Let's say I am building one platform called devloper.com.

And one user is signing up - his username is tushar. What I want to do is - whenever user signs up - he should be redirected to his own subdomain named tushar.developer.com.

I know the basic idea that it can be done with aws-route53 service. Can you guys explain me how it can be done and elaborate on it?

I'm thinking of using pulumi to automate this task. Thoughts on that too.

I have done some research that aws-route53 can achieve this task,

Answer 1

In my experience, pulumi is absolutely NOT the best tool to do this. This answer assumes that you own developer.com in your was account already.

Pulumi way: Disclaimer, this is not typically how pulumi is used, so results my very.

The way that I would go about this is:

1. Import your hosted zone into pulumi, this is a very straight forward process. (https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/import/)
2. Then I would get that username into your pulumi code somehow. I think pulling a list of uses from an object database like aws dynomodb. But if you can get away with it, just update the pulumi config with a map of users.
3. In that map, whether it is in AWS or your pulumi config, you would need to include the username, and the AWS resources that is specific to their username. Then pulumi can create those records for you in a loop in the pulumi code and just pass in the root hosted zone.
4. Then you would invoke the pulumi command from your code using a local function call.

---

NOW: all that said, that is a way that you COULD do it using pulumi. This would not be good though. Managing the cloud state in that way and dynamically like that is asking for trouble, and it is layers of complexity with a ton of failure points.

The way I would actually go about this is if you are pointing that user to separate resources in aws that are not part of your site, in your registration code I would import the boto3 library. Then in your registration code I would use boto3 to create a record with the users name tied to the root hosted zone. When your user logs in that user object will contain all that information you need to do the redirect. Then from the front end code you can simply call a redirect to those specific hosts. That is only if that subdomain needs to point to a new resource in AWS.

If this is all INTERNAL routing in your application, eg. you are routing the user.developer.com to another file within your site, you can do all that in the front end code, no need for route53 at that point, anytime you see a subdomain pattern in your code you would just route it to the appropriate code. Nextjs is good tool for this I think. You would create a wild card domain *.developer.com and then you would look at the domain the user is coming from and handle the routing appropriately there.

If your user registration needs to create a bunch of resources in the cloud for that user, I would still use boto3 for that and not pulumi. Anything you can do in the console you can do using boto3.

I love pulumi, but it is more for managing static infrastructure. I would use pullumi to stand up all the infra that your application runs on. If that makes more sense.

Answer 2

To accomplish this, we can employ an event-driven architecture. The initial step involves generating a wildcard certificate for your domain, such as *.devloper.com. Additionally, there will be some modifications required at the code level. Let's consider the following scenarios:

When a user visits the platform, the system checks whether the user is logged in or not at the code level.

• If the user is logged in, then they are redirected to userName.developer.com.
• If the user is not logged in, then they remain on developer.com, functioning as a fallback domain.
• In the event of a user sign-up, a lambda function is triggered, enabling the addition of a DNS entry. This entry includes userName.developer.com and its corresponding value in R53.

The advantage of utilizing a wildcard certificate is that you won't need to repeatedly issue certificates for each individual user. Instead, you can utilize the same certificate across the platform.

Hope this helps.