How default route works in AWS instance - amazon-ec2

I have EC2 instance with 10.0.250.0/24, and it has default route by default pointing to 10.0.250.1. How this ip is assigned, is that my all traffic passing through this IP ?
I have firewall in same subnet which is 20.0.250.108, I need all my traffic should go through 10.0.250.108. What i need to do for this? Instead of configuring static route configuring from EC2 instance. Is that anything possible through AWS-routeTable

Related

Amazon aws route53, redirect subdomain to ec2 app running under specific port

I have a domain name mydomain.com registered on amazon route 53.
I have an EC2 instance in which I installed a docker portainer image under 9000 port.
My docker image run perfectly under ec2 public ip address:
http://xxx.xxx.xxx.xxx:9000
What I want now is to create a subdomain: portainer.mydomain.com and pointed it to my EC2 portainer instance.
When I try to create a new record set portainer.mydomaon.com and point it to my docker image instance I can't specify the port value.
I know I miss something, I'm on my beginning on DNS domains.
Route 53 is a DNS resolver. Its job is to resolve domain to ip address. It has nothing to do with port.
But there are some alternatives:
Add a secondary ip to the instance to host multiple websites and bind them to port 80. You add an additional ip by attaching elastic network interface (ENI).
Add Application Load Balancer with host based routing (you will get much more control, you can even do path based routing as well). See: Listeners for Your Application Load Balancers - Elastic Load Balancing
S3 redirection (Route 53 Record Set on Different Port)

Making non-default port accesible on public network in EC2 AWS instance

I want to use my EC2 instance on public IP for multiple applications(as a staging server). By default, port 80(or 443 for https) is publicly accessible for HTTP. But, I want to use other ports as well. For example,
http://my-aws-public-url.com:4050
I have already provided access to port 4050 using security group, but it is still not working. Can you please provide me what I am missing.
To make a port publicly accessible, you need to follow all the below steps.
Add custom rule in the security group to allow the custom port, i.e, 4050 in the example above.
Add an elastic IP to the EC2 instance
Your instance should be publicly accessible(defined using VPC, network ACL and subnet). This step can be verified if the default port is publicly accessbile.
Lastly, the port should be enabled in windows firewall(Go to windows firewall -> Inbound Rules -> New Rule -> Port -> Select TCP and specify local port(e.g. 4050)).

Amazon - can't connect to instance behind VPC

For testing purposes, I set up a VPC on Amazon and created an instance within the VPC. I've added a gateway for the 0.0.0.0/0 address to the attached routing table, and given the instance an elastic IP address. I'm unable to ssh or ping it, even when I set the security group to allow all traffic. I must be missing something obvious. What am I doing wrong?
It turns out that when I created the instance, I accepted the default security group, which only allows access from a specific IP address. When I added another instance, I created it with a security group which allowed all traffic, and I was able to ping it.

ec2 cli api not usable within vpc?

I have some instances with an EC2 VPC (using only ip addresses from RFC 1918) that need to use some services of EC2 via CLI interface (ec2-describe-instances, ec2-run-instances, etc)
I can't get it to work : my understanding is that the service point of the CLI interface is located somewhere in AWS cloud and my requests originating from an RFC1918 address are not routable in the AWS cloud between EC2 service point and my instance.
Is that correct ?
Is my only solution to install a NAT instance within my VPC (I would like to avoid it) ? Or could I get a way to remap this Ec2 service point within my VPC on a RFC1918 address
Any help welcome !
Thanks in advance
didier
You can give the instance an elastic IP address and get outbound access to other publicIPs, like the EC2 API endpoint. Make sure your security group doesn't allow any inbound traffic from the Internet.
Alternatively, if you don't want to use an EIP, you can launch an instance in a VPC with a publicIP address. more here: http://aws.typepad.com/aws/2013/08/additional-ip-address-flexibility-in-the-virtual-private-cloud.html

Amazon ELB in VPC

We're using Amazon EC2, and we want to put an ELB (load balancer) to 2 instances on a private subnet. If we just add the private subnet to the ELB, it will not get any connections, if we attach both subnets to the ELB then it can access the instances, but it often will get time-outs. Has anyone successfully implemented an ELB within the private subnet of their VPC? If so, could you perhaps explain the procedure to me?
Thanks
My teammate and I just have implemented ELB in a VPC with 2 private subnets in different availability zones. The reason you get timeouts is that for each subnet you add to the load balancer, it gets one external IP address. (try 'dig elb-dns-name-here' and you will see several IP addresses). If one of these IP address maps a private subnet, it will timeout. The IP that maps into your public subnet will work. Because DNS may give you any one of the IP addresses, sometimes it works, sometimes it times out.
After some back and forth with amazon, we discovered that the ELB should only be placed in 'public' subnets, that is subnets that have a route out to the Internet Gateway. We wanted to keep our web servers in our private subnets but allow the ELB to talk to them. To solve this, we had to ensure that we had a corresponding public subnet for each availability zone in which we had private subnets. We then added to the ELB, the public subnets for each availability zone.
At first, this didn't seem to work, but after trying everything, we recreated the ELB and everything worked as it should. I think this is a bug, or the ELB was just in an odd state from so many changes.
Here is more or less what we did:
WebServer-1 is running in PrivateSubnet-1 in availability zone us-east-1b with security group called web-server.
WebServer-2 is running in PrivateSubnet-2 in availability zone us-east-1c with security group called web-server.
Created a public subnet in zone us-east-1b, we'll call it PublicSubnet-1. We ensured that we associated the routing table that includes the route to the Internet Gateway (ig-xxxxx) with this new subnet. (If you used the wizard to create a public/private VPC, this route already exists.)
Created a public subnet in zone us-east-1c, we'll call it PublicSubnet-2. We ensured that we associated the routing table that includes the route to the Internet Gateway (ig-xxxxx) with this new subnet. (If you used the wizard to create a public/private VPC, this route already exists.)
Created a new ELB, adding to it PublicSubnet-1 and PublicSubnet-2 (not the PrivateSubnet-X). Also, picked the instances to run in the ELB, in this case WebServer-1 and WebServer-2. Made sure to assign a security group that allows incoming port 80 and 443. Lets call this group elb-group.
In the web-server group, allow traffic from port 80 and 443 from the elb-group.
The key here is understanding, that you are not "Adding subnets/availability zones" to ELB, but rather specifying what subnets to put ELB instances into.
Yes, ELB is a software load balancer and when you create ELB object, a custom loadbalancing EC2 instance is put into the all subnets that you specified. So for the ELB (its instances) to be accessible, they have to be put into the subnets that have default route configured via IGW (most likely you classified these subnets as public).
So as already was answered above, you have to specify "public" networks for ELB, and those networks should be from the AZs where your EC2 instances are running. In this case ELB instances will be able to reach your EC2 instances (as long as security groups are configured correctly)
We've implemented ELB in a private subnet so the statement that all ELB's need to be public isn't completely true. You do need a NAT. Create a private subnet for the private ELB's, turn on VPC DNS and then make sure the private routing table is configured to go through the NAT. The subnet security groups also need to be setup to allow traffic between ELB and App, and App to DB subnets.
Beanstalk health checks won't work as they can't reach the load balancer, but for services that need to be outside of the public reach this is a good compromise.
Suggested reading to get your VPC architecture started: http://blog.controlgroup.com/2013/10/14/guided-creation-of-cloudformation-templates-for-vpc/.
You must add the following settings.
Public subnet zone b = Server NAT
Private subnet zone c = Server Web
Public subnet zone c = ELB
The trick is routing:
The router to NAT is attach with gateway A.
The router to Server Web is attach to NAT.
The router to Public subnet is attach with gateway A.
ELB details:
1.Zone: Public subnet zone c
2.Instance: Server Web
3.Security Groups: enable ports
http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html
Adding a diagram to Nathan's answer. Full medium post here: https://nav7neeet.medium.com/load-balance-traffic-to-private-ec2-instances-cb07058549fd

Resources