CLI command to register instances to a classic load balancer is:
aws elb register-instances-with-load-balancer --load-balancer-name my-load-balancer --instances i-d6f6fae3
Can we use classic ELB's ARN in --load-balancer-name parameter? If yes, how do we get the classic ELB's ARN and does the command change in any way?
We cannot use ELB's ARN in --load-balancer-name parameter. ARNs are usually long strings, mostly exceeding 32 characters. --load-balancer-name accepts only strings <32 characters. That's one way to find out ARNs cannot be used for that parameter.
Related
What is the best way (considering both security and template re-use) to provide secrets like a host/port and external service username/password when the consumer doesn't expect or support a ValueProvider? By consumer I mean what is typically an IO class, such as MongoDbIO, ElasticsearchIO, etc.
I've already seen and successfully used this method: https://henrysuryawirawan.com/posts/dataflow-secret-manager/ but in that example, and some apache-provided IOs, the IO accepts the parameters in a ValueProvider. The apache ElasticsearchIO does not, neither does the MongoDbIO. The RedisIO does (via the RedisConnectionConfiguration). SpannerIO does.
So if the IO we want to use does not, is providing the config statically at template compile time the only option, and how is this typically done? Providing them dynamically seems safer security-wise, especially through something like Secret Manager.
Yes, SecretManager / KMS are likely the best ways to deal here. But unfortunately, your options are limited if ValueProviders are not allowed.
You may use Flex Templates to work around the need of ValueProviders.
We have a probably useful example in DataflowTemplates: KMSUtils.java, which expands options using KMS during runtime.
I'm new to AWS.
I started learning about ALB and NLB. I know ALB working in Layer 7 protocols and NLB working in layer 4 protocols.
Can anyone please explain the real time example of ALB and NLB?? When to use ALB and NLB??
Even though all the web application will use TCP protocols for making connection between server and client.
So Is ALB use the TCP (layer 4) protocols??
Then what is the different between them? Can anyone please explain briefly???
In summary: an NLB only knows about TCP, while an ALB knows everything about the request.
An NLB can only route a request based on IP addresses and other TCP-package info.
An ALB can route a request by looking at the content of it: what protocol is it using (HTTP, HTTPS)? What path is it trying to query (/api/v1, /api/v2)? What content-type is it requesting?
So, if you want requests for the v1 API endpoint to be routed to an autoscaling group of EC2 instances and requests for the v2 API endpoint routed to another group of instances, then your best option is the ALB because it allows you to configure rules that make your desired routing possible.
On the other hand, if you just want that clients coming from Germany are routed to one autoscaling group and clients from the USA to another group, the NLB should be sufficient because you can set up rules that match the IP addresses of those countries.
TL;DR To load balance HTTP requests, use an ALB. For TCP/UDP load balancing, use an NLB.
An ALB (Application Load Balancer) understands HTTP. If you need to do HTTP-based routing (e.g., routing to different targets depending on the request path) you need to use an ALB.
Unique features of ALBs include:
HTTP path-based routing
HTTP header-based routing
Redirects
Lambda functions as targets
An NLB (Network Load Balancer) operates at the transport level (TCP/UDP). NLBs are more performant than ALBs because they don't need to parse HTTP messages.
NLBs support some unique features too:
Static IP
Elastic IP addresses
Preserving the source IP
You can see a full comparison of features on the Elastic load balancing features page.
Lets say I use DNS to configure ftp.mysite.com to my site's IP, I want to give clients the credentials to use the ftp site. Can I give them the URL (ftp.mysite.com) OR should I give then the IP directly (even though the URL points to that IP).
Am I risking compatibility issues of some sort?
Do not use an IP address, always use a domain name. A domain name is less likely to change and carries more information than an IP address.
While a domain name is indeed just an alias to an IP address, a single IP address can be used for multiple domains. This is common with virtual hostings.
In this case, an IP address may not carry enough information. This more common with HTTP, where a domain name, that is otherwise lost in domain-to-IP resolution, is provided to an HTTP server using Host: HTTP header.
FTP protocol has a similar mechanics, the HOST command. But as that command was introduced relatively recently, it is actually quite rare that an FTP server relies on this. Even on shared hostings, a domain is usually included in an FTP username to allow even FTP clients, that do not (yet) support the HOST command.
See also Do the SSH or FTP protocols tell the server to which domain I am trying to connect?
there is no deference. you can give either you IP or your domain name. once people have the domain, they can get your IP very easy.
the domain can be better choice in case the IP is going to be changed.
Most FTP servers are hosted on port 21 (or 22 for SFTP).
ftp.mysite.com usually points to localhost:21 or localhost:22
So there is no difference, except for the ports.
I have a complex web app at example-app.com, hosting fully on AWS using ELB and Route 53 for DNS. It's a Rails app.
I'm running an experiment that I'm using in the rails app, at example-app.com/test. I want to set up new-domain-app.com, to point at example-app.com/test, and have the URL cloacked to always be new-domain-app.com. It's a single page site, so it shouldn't require any navigation.
I'm having a lot of trouble figuring out how to set up my DNS on Route 53 to accomplish this. Does anyone have good ideas on what this Route 53 configuration should look like?
AWS offers a very simple way to implement this -- with CloudFront. Forget about the fact that it's marketed as a CDN. It's also a reverse proxy that can prepend a fixed value onto the path, and send a different hostname to the back-end server than the one typed into the browser, which sounds like what you need.
Create a CloudFront web distribution.
Configure the new domain name as an alternate domain name for the distribution.
For the origin server, put your existing hostname.
For the origin path, put /test -- or whatever string you want prefixed onto the path sent by the browser.
Configure the cache behavior as needed -- enable forwarding of the query string or cookies if needed and any headers your app wants to see, but not Host.
Point your new domain name at CloudFront... But before you do that, note that your CloudFront distribution has a dxxxexample.cloudfront.net hostname. After the distribution finishes setting up (the "In Progress" status goes away, usually in 5 to 20 minutes) your site should be accessible at the cloudfront.net hostname.
How this works: When you type http://example.com into the browser, CloudFront will add the origin path onto the path the browser sends, so GET / HTTP/1.1 becomes GET /test/ HTTP/1.1. This configuration just prefixes every request's path with the string you specified as the origin path, and sends it on to the server. The browser address bar does not change, because this is not a redirect. The host header sent by the browser is replaced with the hostname of the origin server when the request is sent to the origin.
What you are trying to do is not possible. Route53 is a DNS system, and you can not configure a hostname (e.g. new-domain-app.com) to point to URL (e.g. http://example-app.com/test) using DNS.
However, you are probably using a wrong tool for the job. If example-app.com/test is indeed a simple, static, single page site, then you do not need to host it inside Rails app. Instead, you can host it on AWS S3 bucket, and then you can point new-domain-app.com to that bucket using Route53.
See the following for details:
http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html
DNS knows about Domains, not url's. DNS simply converts names to IP addresses.
You can't do what you are asking for just using DNS and ELB, however, what you can do is have a seperate VHOST for new-domain-app.com that points to your example-app.com site and accomplishes what you want using some sort of redirection rule that only fires for new-domain-app.com.
I'm not sure that this qualifies as an SO question, and more likely is a serverfault question. Specifics about your webserver and OS platform would be helpful in getting more specific advice.
So here's some details:
You already have example-app.com setup and working
You create a CNAME entry pointing new-domain-app.com to example-app.com or you can make an A record pointing to the same IP. If you already have example-app.com pointing to a different IP address, then use a subdomain (test.example-app.com) to isolate it.
Setup a new vhost on your server that basically duplicates the existing vhost for new-domain-app.com. The only thing you need to change is the server name configuration.
Why does this work? Because HTTP 1.1 included the HOST header that browsers send along, and web servers use in vhosting to determine which virtual host to route an incoming request to. When it sees that the client browser wanted "example-app.com" it routes the request to the appropriate vhost.
Rather than having to do some fancy proxying, which certainly can be used to get to a similar result, you can just add a redirection rule that looks for requests for the host example-app.com and redirects those to example-app.com. In apache that uses mod_rewrite which people often utilize by putting rules in the ubiquitous .htacess file, but can also be done in nginx and other common web servers. The specifics are slightly different for each.
I am working on an AWS EC2 instance, I installed an apache server.
Is it possible to set a url to my server?
I would like to write on my browser:
http://myServiceWebSite
instead of
http://23.26.31.178
Can I hide the ip of my server by a face name?
Thank you.
You can set a DNS using a domain registrar such as Go Daddy
You can use FREE domain names such as co.nr though I think that 13$ a year for a .com is a descent price.
As ajay wrote, Amazon Does provide a default DNS but it is "ugly" and you will probably not use it.
By default, every time you restart a machine it will probably assign a different IP address, and the DNS name is ugly because it is based on IP, and it is released on instance shutdown.
If your server is used by the public internet you might have at least 3 choices:
Make the IP address static by using Elastic IP option from EC2 console and register this IP using some DNS Service such as Go Daddy.
Leave your IP assigned dynamically and use a dynamic DNS service such as DynDns.
If need to use an Elastic Load Balancer use the AWS Route 53 DNS Service, and instead of creating an A Resource Record pointing to a static IP address, you could use an Alias Resource Record pointing to your Elastic Load Balancer, I think this would be the best option if you have more than 1 server.
If you want a quick and dirty solution, you could use a url shortener and use the url it generates from your default AWS DNS. This is not a long term solution, but just something to use if, for example, you want to deploy a prototype quickly and display it for someone temporarily without handing them an IP address.