AWS ELB with EC2 instances in different regions - amazon-ec2

AWS ElasticLoadBalancer (ELB) can distribute the traffic between multiple EC2 instances that are in the different availability zones of the same region.
Is it possible to back AWS ELB with EC2 instances from different regions?

Is it possible to back AWS ELB with EC2 instances from different regions?
To my understanding ELB can't do that.
Note that there is a good reason - introduced latency across regions as opposed to AZ latency. However, you could mimic something like that using Route53 or any other DNS that supports GSLB (Global Server Load Balancing) or similar approach.

Related

What it means when AWS Lambda is configured with VPC?

Even after going through the AWS documentation and various blogs, I still don't understand how AWS lambda would behave when it is configured with VPC.
When AWS lambda configured with VPC, does that mean all instances of lambda would get the IP address from the specified subnet of that VPC?
How the ENI plays the role in AWS Lambda-VPC configuration?
The formula for ENI capacity from AWS doc -
Projected peak concurrent executions * (Memory in GB / 3GB)
Does it means AWS lambda’s running instance used to have 3 GB memory? And when that exceeds another ENI would get attached?
Most the AWS Lambda-VPC configuration related architecture diagrams shows Lambda inside VPC. Does that means Lambda would run inside VPC?
Here, I’m sure I’m missing a few pieces of information. Any pointers would be helpful.
When you configure a Lambda function to run in the VPC it uses an ENI that is created with and IP address in one of the subnets you select. Based on the formula of expected ENIs needed it seems that ENIs can be shared between lambdas.
There are only two reasons that I know of for running your lambda in a VPC.
It needs to access resources inside your VPC that do not have a public endpoint, e.g. Redis/Memcached caching clusters (Elasticache) or an RDS/Redshift cluster that doesn't have a public ip (good idea to not have public ip's on databases). When you lambda runs inside the VPC it uses a private ip and can connect to the private resources in your VPC
If you need to have your lambda's have a consistent IP address (perhaps a service that only allows whitelisting of IPs for authentication). This is achieved by using a NAT gateway.
Lambda functions cannot received inbound connections in any case.
Disadvantages of putting your lambda in a VPC are
Slower cold start times since a ENI might need to be provisioned.
You need a NAT gateway (or VPC endpoint) to access external resources
Needing to manage concurrency and available ip addresses more closely.

Autoscaling EC2 instances running Nginx-based web service behind ELB

Looking for advice on the recommended way of setting up autoscaling for a pair of EC2 instances running a Nginx-based web service behind an ELB.
I understand that I'll need to use CloudWatch to monitor my EC2 instances - is it sufficient to save my EC2 instance as an AMI image and then have CloudWatch fire up new instances using that image (with ELB automatically routing requests in round-robin fashion to available instances)?
You can attach your load balancer to your Auto Scaling Group (ASG). When attached, the load balancer automatically registers the newly launched instances in the group and distributes the traffic across them. For adding health checks to the ASG with a load balancer attached to it, you need to:
Go to EC2 console
Choose Auto Scaling Group under Auto Scaling
Select your group and click Actions and then Edit
Select ELB for Health Check Type and set the period (e.g. 300)
Save
Note that an ASG with EC2 health check type will not automatically replace the unhealthy instances. Read more here.

Should I use Amazon VPC in Amazon EC2 when I have multiple servers

I am planning to have a multi server architecture in amazon EC2 where the servers need to talk to each other. These servers need to be located in different amazon regions (different datacenters). Can I just use the internal network of the amazon ec2? What are the security issues? Should I mandatorily use Amazon VPC in this setup.
Jam ,
If you are planning to create instances on different regions then go for VPC ,because VPC gives you more security .You can restrict these machines for limited external access also .
As security part , VPC is better than classic EC2 instances ,as you can even only allow VPC to VPC connections also .

Amazon EC2 autoscaling instances with elastic IPs

Is there any way to make new instances added to an autoscaling group associate with an elastic IP? I have a use case where the instances in my autoscale group need to be whitelisted on remote servers, so they need to have predictable IPs.
I realize there are ways to do this programmatically using the API, but I'm wondering if there's any other way. It seems like CloudFormation may be able to do this.
You can associate an Elastic IP to ASG instances using manual or scripted API calls just as you would any other instance -- however, there is no automated way to do this. ASG instances are designed to be ephemeral/disposable, and Elastic IP association goes against this philosophy.
To solve your problem re: whitelisting, you have a few options:
If the system that requires predictable source IPs is on EC2 and under your control, you can disable IP restrictions and use EC2 security groups to secure traffic instead
If the system is not under your control, you can set up a proxy server with an Elastic IP and have your ASG instances use the proxy for outbound traffic
You can use http://aws.amazon.com/vpc/ to gain complete control over instance addressing, including network egress IPs -- though this can be time consuming
There are 3 approaches I could find to doing this. Cloud Formation will just automate it but you need to understand what's going on first.
1.-As #gabrtv mentioned use VPC, this lends itself to two options.
1.1-Within a VPC use a NAT Gateway to route all traffic in and out of the Gateway. The Gateway will have an Elastic IP and internet traffic then whitelist the NAT Gateway on your server side. Look for NAT gateway on AWS documentation.
1.2-Create a Virtual Private Gateway/VPN connection to your backend servers in your datacenter and route traffic through that.
1.2.a-Create your instances within a DEDICATED private subnet.
1.2.b-Whitelist the entire subnet on your side, any request from that subnet will be allowed in.
1.2.c Make sure your routes in the Subnet are correct.
(I'm skipping 2 on purpose since that is 1.2)
3.-The LAZY way:
Utilize AWS Opsworks to do two things:
1st: Allocate a RESOURCE Pool of Elastic IPs.
2nd: Start LOAD instances on demand and AUTO assign them one elastic ip from the Pool.
For the second part you will need to have the 24/7 instances be your minimum and the Load instances be your MAX. AWS Opsworks now allows Cloud Watch alarms to trigger instance startup so it is very similar to ASG.
The only disadvantage of Opsworks is that instances aren't terminated but stopped instead when the load goes down and that you must "create" instances beforehand. Also you depend on Chef solo to initiate your instances but is the only way to get auto assigning EIPs to your newly created instances that I could find.
Cheers!

Can EC2 instances in different regions communicate over their private IP addresses?

I have two EC2 instances from an Ubuntu image, they are located in different regions.
I just want to ask, whether they can communicate over the private IP addresses?
I have opened the required ports with a security group. I use netcat to test the communication, but it only works, when I use the public IP addresses.
It is not possible to communicate between Amazon EC2 regions via the private IP addresses (except if you setup a VPN and respective routing for this, see section VPN Solution below), traffic between regions is in fact passing the public internet and is not distinguishable from any other internet traffic, see e.g. the following FAQs from the Region and Availability Zone FAQ:
Can instances use group-based firewall rules across Regions? - No. Group-based firewall rules only work within a Region. If you need instances to communicate with each other across Regions, you should use CIDR based firewall rules. [...]
What is the cost for data transfer between Regions? - Data transferred from one Region to another is charged at both sides at the Internet data transfer rate.
This applies to an Amazon VPC as well, see e.g. the FAQ Can Amazon EC2 instances within a VPC in one region communicate with Amazon EC2 instances within a VPC in another region?:
Yes, as long as all communication takes place over the Internet
Gateway of each VPC and uses the Elastic IP addresses assigned to the
instances in each VPC. Please note: security groups cannot span
regions. All traffic filtering between instances in one VPC and
instances in another VPC must use the Elastic IP addresses as the
specified source or destination address. [emphasis mine]
VPN Solution
AWS has meanwhile released two walkthroughs describing a solution for Connecting Multiple VPCs with EC2 Instances based on either IPsec or OpenVPN:
Connecting Multiple VPCs with EC2 Instances (IPSec)
please note that this tutorial facilitates Openswan, but you can achieve the same with strongSwan (or even the Linux IPsec stack built in as of kernel 2.6+, see e.g. IPsec L2TP VPN server)
Connecting Multiple VPCs with EC2 Instances (SSL)
Now you can do it with AWS VPC peer connection.
It enables the resources in two VPCs that are in different regions, even in different accounts, to be able to communicate with the private IP address, just like in the same LAN.
One thing you need to know is the CIDR blocks you choose for your both VPCs, they must not be in conflict. Otherwise, the peer connection can't be made successfully.
See the official doc about VPC peer connection.

Resources