I have purchased some elastic ips from aws which are mapped against some sub-domains.
e.g elastic ip mapped against xyz.domain.com.
I have an algorithm which creates ec2 Instances as per load on our website.
After successful start of that instance i associate that elastic ip to new instance using api.
it initiates my service to generate certificate using certbot, which makes my new instance setting complete and now i can use it in my existing architecture.
When load again goes back to normal i remove those new instances.
My problem is when load is fluctuating i sometimes hit rate limits in certbot e.g. and unable to function properly because without ssl certificate my whole system seems to collapse.
So what can i do to solve this problem?
Fixed parameters are -
10 elastic ips. All the domains are subdomain of a main domain
which are already mapped to elastic ips.
If you really want to use certbot then you need to store these certificates and reuse them when you start a new instance. You can use a parameter store securestring for example for each elasic IP and when you spin up the instance it checks this parameter first. If there is no certificate or it expires soon then get a new cert and overwrite the stored one. With this solution, a new instance does not mean a new certificate.
But this setup feels wrong. You can use the Application Load Balancer that integrates with ACM and Route53 so you can move the HTTPS termination to a single service then don't care about how instances are starting/stopping in the background.
Related
I followed all the steps given on the tutorial page of AWS to create a subdomain(https://aws.amazon.com/es/premiumsupport/knowledge-center/create-subdomain-route-53/) and I'm pretty sure I got everything right because the tutorial is pretty straight forward. For context, before this I setup a LAMP stack on the server linked with my main domain (example.com).
My question is how to upload and manage files on my subdomain (subdomain.example.com). I thought that all I needed to do was to create a new EC2 instance and link it with the "hosted zone" of my subdomain, and after that I could just upload files and it would work (like I did on my original instance of the main domain). But after many tries clearly I'm doing something wrong, because the page of my subdomain (subdomain.example.com) keeps appearing blank with just the text "This site can't be reached."
You say that you installed a LAMP stack on the instance, so presumably there is a web server listening on port 80.
To test this, first login to the instance via SSH, then try curl localhost to test the web server. If that fails, then there is a problem with your web server.
If it works, the you should check the Security Group associated with the Amazon EC2 instance. It should be allowing incoming traffic on port 80 from 0.0.0.0/0.
Next, obtain the Public IP address of the instance. In a browser on your own computer, try accessing the IP address, eg http://1.2.3.4. That should work if the Security Group has been correctly configured.
By the way, you should be using an Elastic IP address (EIP) for the EC2 instance, which is a 'static' IP address that does not change. You can create an EIP in the EC2 management console, then associate it with the instance. This prevents the Public IP address from changing if the instance is stopped.
Next, try accessing the instance via the domain name. If this does not work, then test the name resolution by using ping with your domain name. The Ping itself won't work, but it should display the IP address that is linked to that domain name. Make sure that the IP address matches the Public IP address you used in the previous step.
If no IP address is provided, then you are missing an A-Record in the hosted zone. You should create the A-Record in the hosted zone and provide it with the Public IP address of the instance.
I run a service on Fargate and my main objective is to keep the cost as low as possible. A minor downtime is not an issue which is helpful with the current approach. I have one instance of the task, running on Fargate (with spot provider). I have my domain under route53 and i'm using a lambda function for updating the A Record of www when a new container starts. Everything seems to be working fine. I need to enable HTTPS though and i'm stuck with this one - don't know if it's possible. I created a (free) certificate by AWS but i don't know how to make the service to listen on port 443 (allowed in SG). Using a Load Balancer is not an option as it will automatically increase the cost by ~15$.
Is this possible? Maybe i just need to modify the container (using apache)?
It's possible, but you will need to look into something like Let's Encrypt for an SSL certificate you can use directly inside the Fargate instance. ACM certificates cannot be used for that purpose.
Configure you webserver inside the container with cert and private key as normal to listen on 443 1. Container hosted on Fargate with public IP is not much different than an EC2 instance with public IP. You are already taking care of the update to A record if it changes.
Use Case
I'm working on an application that uses Presto, and for Presto, I have to set up HTTPS traffic internally (for security compliance reasons).
For this, I preferably need the nodes' FQDN to be in the same domain. E.g. myhost1.mydomain.com, myhost2.mydomain.com.
My Question
AWS automatically gives a FQDN like ip-10-20-30-40.ec2.internal. So, my question is:
Is there a way I can have a new node automatically be created with a FQDN like myhost1.mydomain.com? I know I can create internal "hosted zones" and DNS records for my hosts pretty easily, but I can't figure out how to make that the default domain for a new host.
Also, just FYI, I'm doing this for an auto-scale group; but I suspect that's irrelevant.
When the Amazon EC2 starts, it can run a script passed in via User Data.
You could code this script to create a CNAME record in Amazon Route 53 that points to the IP address of the instance.
I'm not sure how you'd necessarily determine the number within the name, so you could just create a random name. Also, it might be tricky to remove the CNAME entry when the instance is terminated. One way to both assign and remove the record would be to use Amazon EC2 Auto Scaling Lifecycle Hooks, which allows code to be triggered outside of the instance itself. It's more complex but would be fully effective.
I'm not familiar with Presto, but here's a couple of ideas.
First, if you are using an AWS managed load balancer, you can enable HTTPS between it and the instance using self-signed cert: the load balancer will NOT validate the cert, so your connection will be secure.
If that's not what you need, take a look at DHCP option sets for your VPC - I believe you can set your own domain name, rather than use the default ec2.internal.
Is it possible to upgrade EC2 instance without changing existing public IP address? My mobile application is live and unfortunately we didn't use elastic IP in web services. So if I upgrade current instance, it will generate new public IP and the old application users won't be able to use mobile application.
Is there any way to keep current IP as it is? Or any other way to upgrade it without loosing existing users? Please suggest.
Consider this a lesson as to why you should use a load balancer and a DNS entry, especially for anything public-facing. What were you going to do if you the instance failed? Or the availability zone went down?
Personally I would spin up a set new larger instances behind a load balancer, create a Route53 DNS entry that points to the load balancer, and then release an update to the client that points to the DNS entry. As clients update, traffic will gradually move to the load balancer. The undersized single instance's load will drop, so if it is overloaded it will eventually return to normal. Eventually you can kill the old instance when all/most clients have upgraded.
It depends on what sort of software you are running exactly
If you have an application that is sessionless then it would be simple to bring up another server on a different IP and then use route53 to switch over the traffic, with both servers running at the same time
If the application is stateful though and if it stores the sessions locally on the host then that's more of a problem
One possible approach is to bind an elastic ip to the running host, reconfigure your software to listen on all addresses ( a lot of configuration controls allow this with an address of 0.0.0.0 ) then change DNS and gradually see the traffic migrate to the elastic IP, while both addresses work
Once the new address is fully in use (depends on your TTL) it becomes much easier to switch to a new host by reassigning the EIP
Scenario:
I have an EC2 server which houses the api currently setup to accept connections from several iPads. I do not wish for network sniffers to see the JSON requests that are being exchanged between the servers and the devices. The idea is to have a secure protocol in place so that communication will be secured.
I have been told purchasing a SSL certificate is the way forward. The Amazon server instance I have running has an address in this format:
ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com/
this is where my web root is with all the appropriate web service files. My webservice urls look something similar to this:
ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com/Agent/Create
so on so forth. There is no hosting plan whatsoever (in the case that information is necessary).
I have been recommended to buy an SSL Cert from http://www.Godaddy.com and have thought about getting the up to 5 multiple domains SSL certificate package.
Question: 1
What things do I need to be made aware of in order to make sure nothing fails?
I have recently read that I may need to associate an elastic IP address to my instance, otherwise the IP of my instance will change on reboots? And if that is the case, that means that the SSL certificate that was used for this: ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com domain would no longer work since the ip address would have changed upon reboot and therefor me losing my secure domain?
Question: 2
If my thoughts in question 1 stands true, then my question would then be what is the most user friendly way or lets say, the way for beginners to create a dedicated url for my server instance (so that 1) the domain name doesnt randomly change upon server reboot (not sure when i would reboot anyway) and 2) does this mean I can have easier webservice urls that one can remember? such as.... www.pk.com/Agent/Create instead of the long ec2 ugly url?!
Any easy to follow tutorials would be very helpful. I have looked at a few articles that spoke about elastic ip address, SSL certificates, and other articles about renaming ec2 url, but I'm in a position where I dont actually know which one applies to me. lol
Hope someone can help. thanks
What you want to do is to get an elastic IP address. This lets you bind your instance to a particular IP address when you start it up. You can then register a hostname in DNS (Amazon don't help you with this part) and state that that hostname has the IP address that is the elastic IP address that you have registered.
The final piece is to get a server certificate (strictly, a keypair where the public part is the server certificate) that has the hostname in the CN field of its Distinguished Name, and to install that server keypair on the instance. (This is another part that Amazon don't help you with, and is in fact the same process as if you were hosting the hardware yourself.) Like that, the client
looks up the hostname and gets the elastic IP address,
connects and gets the server certificate, and
checks the server certificate and sees that the hostname it is for is the hostname that they expected. (There's a few other checks as well, such as whether the certificate was signed by a trusted certificate authority and whether the certificate is within its validity period.)
That allows the client to trust that who they have securely connected to is who they expected to securely connect to, which is a key part of establishing trust.
What you do not do is use the AWS machine names (internal or external) in the certificate you apply for. Those change and you really do not want to trust other people's VMs.
Donal's answer is the way to go. You need to explicitly register a domain and generate the SSL certificate containing the CN as that domain. Elastic IP addresses definitely are your friends in this issue. You will need them.
I added another answer in order to give another point of view: if you ever want to scale your backend solution, going that way will be more difficult. If you ever thought about adding more servers to host your web service, you should definitely set up an Elastic Load Balancer, add your instances to it, and point the domain you just registered to your Elastic Load Balancer. Then, you can purchase the SSL certificate and install it directly on your ELB, configuring SSL termination on the ELB. You will also configure the ELB so that connections arriving at port 443 will map to port 80 (or whatever port) on your servers. Don't worry, this is plain easy to set up.
Whenever you want to add more servers to your web service, it will just be a matter of setting up another EC2 instance (this process can - and should - be automated) and adding it to the ELB.
With this setup, you get rid of the need for Elastic IP addresses. All the connections go through the ELB.