Currently, I have built an application on EC2 instances in multiple regions. The problems are when one instance per region need to patch/maintain, and we need more effort to handle if something fails.
I decide to use Lambda#Edge instead of EC2 and question is:
Lambda#Edge is better than these EC2 instances?
Need to make sure that Lambda#Edge would be reachable with the same latency or better than EC2. Have any official docs to prove this?
Thanks
If the issue you're facing is one of patching and maintenance of instances then yes, Lambda or Lambda#Edge will absolutely remove that issue.
If the issue is latency and you want to keep your instances you could create an Amazon Cloudfront Distribution that would go in front of your instances and serve cached content to your users - that might be the easiest way to start out.
Lambda#Edge would have the same latency as Cloudfront. Lambda functions that are deployed to CloudFront edge locations have a couple of limitations.
Related
I am having long cold start times on our Lambda functions. We have tried "pinging" the Lambdas to keep them warm but that can get costly and seems like a poor way to keep performance up. We also have an EC2 instance running 24/7. I could theoretically "mirror" all of our Lambda functions to our EC2 instance to respond with the same data for our API call. Our Lambdas are on https://api.mysite.com and our EC2 is https://dev.mysite.com.
My question is could we "load balance?" traffic between the two. (Create a new subdomain to do the following) To have our dev subdomain (EC2) respond to all requests up until a certain "requests per minute" is hit. Then start to route traffic to our dev subdomain (Lambda) since we have enough traffic coming in to keep the Lambdas hot. Once traffic slows down, we move the traffic back over to our EC2.. Is this possible?
No, you can not do that with AWS Load balancer. What you can do is setup cloudwatch trigger to the lambda function which will map api.mysite.com to the lambda load balancer dns. Similarly, you can add trigger for low traffic which will redo dns entry.
If you are aware of rise in traffic, you can scheduled instances. Else you can also try AWS Fargate.
Hope this helps you.
Cloudwatch allows you to choose the number of triggers you wanna set for a lambda i.e. whenever an API is called, cloudwatch will trigger those many of the lambdas. This is one way you could achieve it. There's no way yet, to load balance between lambdas and instances.
You can configure your API to use Step functions which will orchestrate your lambda.
We are checking the feasibility of migrating one of our application to Amazon Web Services (AWS) . We decide to use AWS API Gateway to expose the services and AWS Lambda (java) for back end data processing. The lambda function has to fetch a large amount of data from our database.
Currently using Cassandra for data storage, which has been set up with in an EC2 instance and it has no public ip.
Can anyone suggest a way to access Cassandra(EC2) from AWS Lambda using the private Ip ( 10.0.x.x)?
Is it a right choice to use AWS Lambda for large scale applications?
Since your Cassandra instance is using private IP, you will need to configure your AWS lambda Network to use a VPC. It could be the VPC you are running Cassandra in, or a VPC you create for the purpose of your lambdas, and that you VPC-peer to your cassandra VPC. A few things to note from the documentation :
when your lambda runs in a VPC, it doesn't have internet access by default, you will need to configure a NAT for that.
There is an additional latency due to the configuration of the ENI (you only pay that penalty on cold start)
You need to make sure your lambda has the right permission to manage the ENI, you should use this role: AWSLambdaVPCAccessExecutionRole
Your plan to use API / AWS lambda has at least 3 potential issues which you need to consider carefully:
Cost. API gateway per request cost is higher than AWS lambda per request cost. Make sure you are familiar with the cost.
cold start. When AWS start an underlying container to execute your lambda, you pay a cold start latency (which get worse when using VPC due to the management of the ENI). If you execute your lambda concurrently, there will be multiple underlying containers. Each of them will have this cold start the first time. AWS tends to keep the underlying containers ready for a warm start, for a few minutes (users report 5 to 40 minutes). You might try to keep your container warm by pinging your aws lambda, obviously if you have multiple container in parallel, it is getting tricky.
Cassandra session. You will probably want to avoid creating and destroying your Cassandra session each time you invoke your lambda (costly). I haven't tried yet, but there are reports of keeping the session alive in a warm container, you might want to check this SO answer.
Having say all that, currently the biggest limitation in using AWS lambda is concurrent execution and cold start latency. For data processing, that's usually fine. For user-facing usage, the percentage of slow cold start might affect your user experience.
I have a basic docker image containing a python script that comes in under 100mb. I'm not sure what distro I'm going to use but preferably one that results in the smallest file size as possible.
The goal is to deploy a docker image on t2.nano ec2 instance but it must meet the following conditions:
from the time a customer requests access via URL, it should respond as quickly as possible, preferably under a few seconds.
the latency between the customer and newly deployed docker ec2 instance should be as small as possible, meaning ec2 on the closest availability region.
Is this possible?
It's not possible to deploy an EC2 instance in under a few seconds, especially not t2.nano type instances. EC2 instances follow the same rules as physical compute resources, thus larger instance types boot faster, and t2.nano is currently the smallest/least powerful/slowest instance size. That said, even the fastest instances would take a minute or so to be provisioned and fully booted.
It sounds like you should look into using AWS Lambda. It's their proprietary, managed, containerized compute resource service, and designed for the kind of workflow you are describing. You don't manage the containers themselves, but deploy the code (of which Python is a supported language) and its dependent libraries to the service, and it handles launching it in a container on demand, with overhead in the sub-second range.
Note that it is not designed for hosting "websites" directly, if that's your intention. Lambda functions are invoked by other AWS services, one of which is API Gateway, which would be the best route in providing a public interface to your Lambda functions. This could be used in conjunction with something like S3 static website hosting to provide the building blocks for a "serverless" web application.
As for your second question, Route 53 does support latency based routing, but I don't believe it supports API Gateway endpoints as targets yet. So if global latency is a big concern, your best bet may be to deploy a few full-time EC2 instances around the world and use latency based routing. If it's mainly static assets you're worried about, CloudFront can cache these at edge locations, as an alternative.
I have website (EC2, RDS, VPC, S3) located in EU (Ireland) and I want to make it more accessible for users from America and Asia.
Should I create new instances (EC2, RDS, VPC, S3) in new regions? Or there is another way how to do that?
If I will have more EC2 instances, how should I deploy updates for every instance?
What is the best way to make AWS website light and accessible with small latency from every corner of the world?
Should I create new instances (EC2, RDS, VPC, S3) in new regions?
If you take budget considerations out of the picture then creating instances in each AZ around the world and spreading geographic traffic to them would be a great consideration.
Or there is another way how to do that?
Perhaps the easiest way both from implementation and maintainability as well as budget considerations would be to implement a geographic edge cache like Akamai, CloudFlare, etc.
Akamai is horrendously expensive, but CloudFlare has some free and very cheap plans.
Using an edge cache means that static cached content can be served to your clients from the nearest global edge points to them, without requiring your AWS infrastructure to be optimised for regions.
For example - if you request your home page from Ireland, it may be served from an Irish edge cache location, whereas if I request it from New Zealand, it may be served from an Australasian edge cache location - this doesn't add any complexity to your AWS set up.
In the scenario where a cached version of your page doesn't exist in CloudFlare (for example), it will hit your AWS origin server for the result. This will result in geographic performance variation, but you trade that off against the cost of implementing EC2 instances in each region and the reduced number of hits that actually reach your infrastructure with the cache in place.
If I will have more EC2 instances, how should I deploy updates for every instance?
This largely depends on the complexity of your web application.
For more simple applications you can use Elastic Beanstalk to easily deploy updates to all of your EC2 instances and manage your auto-scaling.
For more complex arrangements you might choose to use a combination of CodeCommit, CodePipeline and CodeDeploy to achieve the same thing.
Thirdly, there's always the option that you could construct your own deployment tool using a combination of custom scripts and AWS API calls. Or use a tool that has already been created for this purpose.
What is the best way to make AWS website light and accessible with small latency from every corner of the world?
This is a pretty broad and complicated question.
My suggestions would be to make use of lazy loading wherever possible, cache everything wherever you can, tweak your web server configuration within an inch of its life (and use things like Varnish if you're on nginx), optimise all your media assets as much as possible, etc.
For media assets you could use a CDN (like S3 or CloudFront) to serve requests instead of storing them on EC2 instances.
By far the most important thing you could do for this though would be to put in an edge cache (discussed earlier). If you do this, your AWS performance is much less of a concern.
Im developing global mobile service communicating with back end server ( S3 - file server , EC2 - application server)
But i don't know how many s3 and ec2 are needed and where i should launch these.
So i'd like to know about below
Im planning to mount S3 in Oregon. As you know, CloudFront is the good solution for getting image quickly but the problem i wanna solve is uploading. I thought 2 solutions. The first solution it that using Put method to CloudFront, upload file to S3 through CloudFront. The second solution is mounting several S3 in different regions. Which is the better solution?
Now i am developing application server in only one EC2. I might have to mount several EC2s for global service. but i don't know how to make end users to connect to specific ec2 of several EC2s. Can you explain me?
thanks
I think your understanding of S3, is slightly off.
You wouldn't and shouldn't need to create "Geo"-specific S3 buckets for the purposes you are describing.
If you are using the service for image delivery over pure HTTP, then you can create the bucket anywhere, and then use a Amazon Cloudfront Distribution as the "frontend" whihc will give you approximately 40 edge locations around the world for your Geo-optimizations.
The more relevant edge location will be used for each user around the world, and they will then request the image from your S3 bucket and store it based on your meta settings. (Typically, from my experience, it's about every 24 hours for low serving traffic websites even when you set an Expire age of months/years.
You also don't "mount" S3. You just create a bucket, and you shouldn't ever want to create multiple buckets which store the same data.
.........
For your sercond question, regarding creating a "global service" for EC2, what are you hopeing to actually achieve.
The web is naturally global. Are your users going to be frett over an additional 200ms latency?
You haven't really descrived what your service will do, but one approach, would be to do all of your computing in Oregon, and then just create cache servers, such as Varnish in different regions. You can use Route53 for the routing, and you can also take advantage of ELB.
My recommendation would be to stop what you are doing, and launch everything from Oregon. The "web" is already "global" and I don't think you are going to need to worry about issues such as this until you hit scale. At which point, I'm going to assume you can just hire someone to solve this problem for you. It sounds like you have the budget for it...