Endpoint target type 'DomainName' is not allowed for this profile - azure-traffic-manager

I am trying to create a new traffic manager profile of either Performance or Weight configuration but I keep getting stuck when trying to add an Azure Endpoint.
I have a two public IP inside of Azure, one with an optional DNS name, one with out.
When I try to add either of these as an endpoint, I get the following error message:
The one with a dns name on it:
Failed to save configuration changes to Traffic Manager profile 'profilename'. Error: Endpoint target type, 'DomainName', is not allowed for this profile. Valid values are: IPv4Address.
The one without a dns name:
No DNS name is configured.
If i choose External Endpoint and add the IPv4 directly it will work.
I tried with several different Traffice Manager profiles.. Is there a secret that I am missing out on? I am stuck..

Usually, There are three types of endpoint supported by Traffic Manager:
Azure endpoints are used for services hosted in Azure.
External endpoints are used for IPv4/IPv6 addresses, FQDNs, or for services hosted outside Azure that can either be on-premises or
with a different hosting provider.
Nested endpoints are used to combine Traffic Manager profiles to create more flexible traffic-routing schemes to support the needs
of larger, more complex deployments.
...
Azure endpoints are used for Azure-based services in Traffic Manager.
The following Azure resource types are supported:
PaaS cloud services. Web Apps Web App Slots PublicIPAddress resources
(which can be connected to VMs either directly or via an Azure Load
Balancer). The publicIpAddress must have a DNS name assigned to be
used in a Traffic Manager profile.
In this case, when you add a public IP address in the same subscription as an Azure endpoint, it will grey out if no DNS name configured in the Azure portal. You could add it when the public IP address configured with Azure provided DNS name like somedns.westus2.cloudapp.azure.com, this works on my side.
For example, there is a public IP address with the DNS name used for an Azure load balancer frontend.

Related

AWS ECS Fargate without Load Balancer for internal services

I am trying to load some rest services using cloudformation as ECS Service with Fargate.
I don't want a public domain name for these services. I will access them internally from my AWS Lambda functions.
I realized AWS Fargate needs load balancing and Load balancer needs certificate and certificates needs a domain name.
Probably I am missing something but I tried to load AWS Fargate without a load balancer and I was unable to access it from Lambdas.
The question is; how do I run my services on ECS with Fargate without Load Balancer?
Use ECS Service Discovery to set up private DNS records that allow your application to discover service endpoints without using a load balancer or having to create public DNS records. Service Discovery works by creating private DNS records in Route 53 that are queryable from within your VPC, so that you can find the IP addresses for all of the tasks running in a service. If you're running multiple tasks you will get multiple A records back, one per task, so you will need to do client-side load balancing by picking a random record in the returned set.
The documentation linked above is a little vague so here are some more specific instructions: When creating your service in the console, in Step 2: Configure Network, check the Enable service discovery integration checkbox. Then specify "create new private namespace" and supply a name for your namespace, such as foo.app. Then select the "Create new discover service" radio button, and specify a name for your service (such as service1). Leave the rest of the settings in the Service discovery (optional) section as default.
Now from within your VPC, you'll be able to look up service1.foo.app and get back A records with the IP addresses of all of the tasks running in the service.
This medium article also has a good summary of how to set up service discovery.

How to use Azure Traffic Manager with a custom domain, if the DNS settings don't allow for forwarding

I have an Azure web app up and running, using a custom domain purchased outside of Azure... and that all runs fine. So I have https://myappname.azurewebsites.net/ loading fine with my domain name URL https://www.myappname.com
I'm trying to upgrade the web app, though using Azure Traffic Manager. I've cloned the app a few times, each on its own app service plan, and I have the traffic manager all up and running fine. I can successfully hit different versions of my cloned website based on the traffic manager configuration profile... so no issues there.
The only issue is that I can only access the "traffic managed" version of my website via the standard azure URL -> myappname.trafficmanager.net.
All examples I've seen say all I really need to do now, is go into my DNS Management screen, and add domain forwarding, however, my online DNS management tool does not offer this option.
I can't really change my A record in the DNS management screen, because I don't know the IP address of myappname.trafficmanager.net
Every place I've tried to change the name of the current/working Azure URL (like in awverify text files, www cnames, etc.) does nothing. The DNS still points to the single instance which remains in the IP address od the DNS managers A record.
Also, since my live/single instance is linked to the domain name (along with the SSL binding), I can't add those properties to the clones, which makes sense....only one version can be live. However I could unbind that when I make the switch from the single instance web app to the traffic managed set of clones, but I fear I can only bind that to one of the clones. I can't seem to bind it to the myappname.trafficmanager.net version, which might cascade down to all of its endpoints. Is there a way to bind my domain name and SSL cert to more than one version of my web app?
Thanks!
Is there a way to bind my domain name and SSL cert to more than one
version of my web app?
I don't think you can do that unless you have two different domains or subdomains with each own SSL cert. Each web app hostname is unique globally and each SSL binding is attached with the web app domain name.
If you have a purchased domain and just keep the default xxx.azurewebsites.net as each hostname. Then you could configure the two Azure app serves as the endpoint of TM.
By default, Azure provided a wildcard cert for this domain *azurewebsites.net, so you can automatically access this hostname with HTTPS without any extra cert. Then use a CNAME record www in the domain domain.com in your DNS provider to point to the traffic manager hostname myappname.trafficmanager.net. Since Traffic Manager works as DNS level, it does not validate the server and client SSL, you could safely ignore the SSL warning when accessing with traffic manager hostname.
Feel free to let me know if you have any question.

Automatic Failover between Azure Internal Load Balancers

We are moving a workflow of our business to Azure. I currently have two VMs as an HA pair behind an internal load balancer in the North Central US Region as my production environment. I have mirrored this architecture in the South Central US Region for disaster recovery purposes. A vendor recommended I place an Azure Traffic Manager in front of the ILBs for automatic failover, but it appears that I cannot spec ILBs as endpoints for ATM. (For clarity, all connections to these ILBs are through VPNs.)
Our current plan is to put the IPs for both ILBs in a custom-built appliance placed on-prem, and the failover would happen on that appliance. However, it would greatly simplify things if we could present a single IP to that appliance, and let the failover happen in Azure instead.
Is there an Azure product or service, or perhaps more appropriate architecture that would allow for a single IP to be presented to the customer, but allow for automatic failover across regions?
It seems that you could configure an application gateway with an internal load balancer (ILB) endpoint. In this case, you will have a private frontend IP configuration for an Application Gateway. The APPGW will be deployed in a dedicated subnet, it will exist on the same VNet with your internal backend VMs. Please note in this case you can directly add the private VMs as the backends instead of internal load balancer frontend IP address because of private APPGW itself is an internal load balancer.
Moreover, APPGW also could configure a public frontend IP configuration, if so, you can configure the APPGW public frontend IP as the endpoints of the Azure traffic manager.
Hope this could help you.

Setting up internal custom domain in AWS EC2 instance

Please help on the below use-case.
We have an AWS EC2 instance with public IP or load balancer DNS --> public.ip or application.lb.amazonaws.com (where we have a custom web apps running as target)
We have another VM instance (e.g.: private.ip) within our Data Center (DC) (where the same web apps is running as source).
We need to have a web based communication between these 2 instances but currently its happening through HTTP. We have already handled all connectivity issues and we are able to now communicate between 2 instances.
We're accessing the source & target URL's as http://public.ip:31415 or application.lb.amazonaws.com:31416
Now we need to convert HTTP URL's in (4) to HTTPS along with a custom domain name. This domain name will not be PUBLIC & it will be resolved only within our office network. E.g Domain name: test.source.apps & test.target.apps
We would be making an entry in our local machine /etc/hosts (similar to below) to have this name resolution in (5) works for now in test & for other environments we planned to make an entry in our internal office DNS servers for this name resolution.
Example /etc/hosts:
Target:
test.target.app public.ip.ec2.server
(or) test.target.app application.lb.amazonaws.com
Source:
test.source.app data.center.ip
We don’t want any paid mode of SSL (like CA or public domain) due to the fact that this URL will be used only by 2 -3 developers and within the office network only. But as part of the security compliance we need to definitely make this a HTTPS URL.
Web apps are running in Jetty web server. We've planned to do it using LetsEncrypt + Custom domain.
Can anyone suggest if this possible in AWS & any steps on how to make this change (i.e. creating subdomain that is internal to our host/network &
using LetsEncrypt SSL)?

HTTPS setup in Amazon EC2

How do we enable HTTPS in Amazon EC2? Our site is working on HTTP.
First, you need to open HTTPS port (443). To do that, you go to https://console.aws.amazon.com/ec2/ and click on the Security Groups link on the left, then create a new security group with also HTTPS available.
Then, just update the security group of a running instance or create a new instance using that group.
After these steps, your EC2 work is finished, and it's all an application problem.
This answer is focused to someone that buy a domain in another site (as GoDaddy) and want to use the Amazon free certificate with Certificate Manager
This answer uses Amazon Classic Load Balancer (paid) see the pricing before using it
Step 1 - Request a certificate with Certificate Manager
Go to Certificate Manager > Request Certificate > Request a public certificate
On Domain name you will add myprojectdomainname.com and *.myprojectdomainname.com and go on Next
Chose Email validation and Confirm and Request
Open the email that you have received (on the email account that you have buyed the domain) and aprove the request
After this, check if the validation status of myprojectdomainname.com and *.myprojectdomainname.com is sucess, if is sucess you can continue to Step 2
Step 2 - Create a Security Group to a Load Balancer
On EC2 go to Security Groups > and Create a Security Group and add the http and https inbound
It will be something like:
Step 3 - Create the Load Balancer
EC2 > Load Balancer > Create Load Balancer > Classic Load Balancer (Third option)
Create LB inside - the vpc of your project
On Load Balancer Protocol add Http and Https
Next > Select exiting security group
Choose the security group that you have create in the previous step
Next > Choose certificate from ACM
Select the certificate of the step 1
Next >
on Health check i've used the ping path / (one slash instead of /index.html)
Step 4 - Associate your instance with the security group of load balancer
EC2 > Instances > click on your project > Actions > Networking > Change Security Groups
Add the Security Group of your Load Balancer
Step 5
EC2 > Load Balancer > Click on the load balancer that you have created > copy the DNS Name (A Record), it will be something like myproject-2021611191.us-east-1.elb.amazonaws.com
Go to Route 53 > Routes Zones > click on the domain name > Go to Records Sets
(If you are don't have your domain here, create a hosted zone with Domain Name: myprojectdomainname.com and Type: Public Hosted Zone)
Check if you have a record type A (probably not), create/edit record set with name empty, type A, alias Yes and Target the dns that you have copied
Create also a new Record Set of type A, name *.myprojectdomainname.com, alias Yes and Target your domain (myprojectdomainname.com). This will make possible access your site with www.myprojectdomainname.com and subsite.myprojectdomainname.com. Note: You will need to configure your reverse proxy (Nginx/Apache) to do so.
On NS copy the 4 Name Servers values to use on the next Step, it will be something like:
ns-362.awsdns-45.com
ns-1558.awsdns-02.co.uk
ns-737.awsdns-28.net
ns-1522.awsdns-62.org
Go to EC2 > Instances > And copy the IPv4 Public IP too
Step 6
On the domain register site that you have buyed the domain (in my case GoDaddy)
Change the routing to http : <Your IPv4 Public IP Number> and select Forward with masking
Change the Name Servers (NS) to the 4 NS that you have copied, this can take 48 hours to make effect
Amazon EC2 instances are just virtual machines so you would setup SSL the same way you would set it up on any server.
You don't mention what platform you are on, so it difficult to give any more information.
An old question but worth mentioning another option in the answers.
In case the DNS system of your domain has been defined in Amazon Route 53, you can use Amazon CloudFront service in front of your EC2 and attach a free Amazon SSL certificate to it. This way you will benefit from both having a CDN for a faster content delivery and also securing you domain with HTTPS protocol.
You can also use Amazon API Gateway. Put your application behind API Gateway. Please check this FAQ
There must be also an answer for people who want a hassle free https on ec2 for mainly demo and testing purposes, one way they can achieve that very fast is:
With my answer here which describes How you can achieve https for testing purposes in minutes with EC2 without the hassle of creating certificates
One of the best resources I found was using let's encrypt, you do not need ELB nor cloudfront for your EC2 instance to have HTTPS, just follow the following simple instructions:
let's encrypt
Login to your server and follow the steps in the link.
It is also important as mentioned by others that you have port 443 opened by editing your security groups
You can view your certificate or any other website's by changing the site name in this link
Please do not forget that it is only valid for 90 days
Use Elastic Load Balacing, it supports SSL termination at the Load Balancer, including offloading SSL decryption from application instances and providing centralized management of SSL certificates.
You need to register a domain(on GoDaddy for example) and put a load balancer in front of your ec2 instance - as DigaoParceiro said in his answer.
The issue is that domains generated by amazon on your ec2 instances are ephemeral. Today the domain is belonging to you, tomorrow it may not.
For that reason, let's encrypt throws an error when you try to register a certificate on amazon generated domain that states:
The ACME server refuses to issue a certificate for this domain name, because it is forbidden by policy
More details about this here:
https://community.letsencrypt.org/t/policy-forbids-issuing-for-name-on-amazon-ec2-domain/12692/4
You need to create a security group for HTTPS and assign it to your webserver:
Open the Amazon EC2 console.
Choose Security Groups in the navigation pane.
Choose Create Security Group.
For Create Security Group, do the following:
For the Security group name, type a name for the security group that you are creating.
(Optional) Type a description of the security group that you are creating.
For VPC, choose the VPC that contains your web server Amazon EC2 instance.
Choose Add Rule. For Type, choose HTTPS.
Choose Create.
In the navigation pane, choose Instances.
Select the check box next to your web server instance. Then choose Actions, Networking, and Change Security Groups.
Select the check box next to the security group that you created for HTTPS. Then choose Assign Security Groups.
To verify SSL/TLS offload with a web browser
Use a web browser to connect to your web server using the public DNS name or IP address of the server.
Ensure that the URL in the address bar begins with https://.
For example, https://ec2-52-14-212-67.us-east-2.compute.amazonaws.com/.

Resources