I have to assign a policy on a particular user, so that he could be able to create only particular type of ec2 instance, in a particular region. Say a developer x could be able to perform all action in us -east region's ec2 service on high memory instance type only. He should not be able to create or perform action on any other instance type.
Please let me know if there is a way to assign such policy.
Thanks in advance.
Thanks & Regards
Manu Misra
Unfortunately not - policies for ec2 are only at the action level. You can't restrict them to particular instances or instance types. I don't even think you could restrict them to a single region.
Related
I am a beginner in AWS development and I had a question regarding accessing amazon aurora from lambda.
I have read that all instances of Amazon Aurora needs to be created inside a VPC. However, it seems that Lambda will incure massive latency for setting up elastic network interface (ENI) everytime it tried to access resources which is inside a VPC
https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-latency-killer-5408323278dd
Since this could increase the cold start time by around 10s , is there a way to avoid this ENI setup latency while using Lambda to access Amazon RDS?
No. There is currently no "good" way to reliably prevent the coldstart.
(1) Yes, keeping the lambda function warm can help reduce the problem, but it will still be present.
(2) The only way would be if you run your rds "outside" a VPC (i.e. make it publicly available) and secure it using security groups. But this is a really bad idea for a lot of reasons (lambda ip addresses change so you need to leave the rds instance wide open for any attacker, violates aws best practices, etc).
AWS lambda + rds is currently not suitable if you need responsiveness. That's why Amazon is pushing the use of dynamodb with lambda so much (since that uses https).
Tldr if you need responsiveness + security stay away from lambda + rds.
What you need to do is make sure your lambda role has the AWSLambdaVPCAccessExecutionRole policy attached to it.
Your ENI is created on cold start. Avoid the cold start by creating another lambda to invoke your current lambda on a schedule to keep it warm.
Im hoping to move an application to AWS.
I would like to use the AutoScaling so not all my EC2 instances are in use when the application use is quiet.
My problem is.....
I have one service account used for all communication between the various components of the application and the servers in that environment
We have a security exception with my company which allows us to use the service account to perform its actions on each individual server.
Every time we introduce a new server to the environment, we have to request that the security team update our exception list to allow the new server in as well.
There is no automatic method for doing this. We have to submit a request to the security team asking for the new server to be added to the exception.
So while AutoScaling would be prefect how can it work in this case if each time a server is added the security team needs to be notified so they can add the new server to the exception list?
Thanks
You can get notifications when your autoscale group scales either up or down. SNS can send a variety of things, including SMS (text) messages to a cell phone.
While this would work, it is incredibly manual. The goal of an autoscale group is to let the environment expand and contract without human intervention. I personally would not implement this as, depending on the availability of your security team they may be a bottle neck to scaling up. If for some reason they miss the scale up event that signals them to do something then you've got orphan machines that you're paying for that are doing nothing.
Additionally, there are also ways to script the provisioning of a new machine. Perhaps there is a way to add what you want automatically. AWS calls this userdata - you can learn a bit more about it from the AWS EC2 docs.
But ultimately I'd really take a step back and look at your architecture. If you can't script the machine provisioning then autoscaling is not very worthwhile - it's just plain "have devops add another machine if needed and hope they remember to take it down when it's not needed".
I am planning to use AWS to host a global website that have customers all around the world. We will have a website and app, and we will use serverless architecture. I will also consider multi-region DynamoDB to allow users closer to the region to access the closest database instance.
My question regarding the best design to implement a solution that is not locked down to one particular region, and we are a borderless implementation. I am also looking at high traffic and high number of users across different countries.
I am looking at this https://aws.amazon.com/getting-started/serverless-web-app/module-1/ but it requires me to choose a region. I almost need a router in front of this with multiple S3 buckets, but don't know how. For example, how do users access a copy of the landing page closest to their region?, how do mobile app users call up lambda functions in their region?
If you could point me to a posting or article or simply your response, I would be most grateful.
Note: would be interested if Google Cloud Platform is also an option?
thank you!
S3
Instead of setting up an S3 bucket per-region, you could set up a CloudFront distribution to serve the contents of a single bucket at all edge locations.
During the Create Distribution process, select the S3 bucket in the Origin Domain Name dropdown.
Caveat: when you update the bucket contents, you need to invalidate the CloudFront cache so that the updated contents get distributed. This isn't such a big deal.
API Gateway
Setting up an API Gateway gives you the choice of Edge-Optimized or Regional.
In the Edge-Optimized case, AWS automatically serves your API via the edge network, but requests are all routed back to your original API Gateway instance in its home region. This is the easy option.
In the Regional case, you would need to deploy multiple instances of your API, one per region. From there, you could do a latency-based routing setup in Route 53. This is the harder option, but more flexible.
Refer to this SO answer for more detail
Note: you can always start developing in an Edge-Optimized configuration, and then later on redeploy to a Regional configuration.
DynamoDB / Lambda
DynamoDB and Lambda are regional services, but you could deploy instances to multiple regions.
In the case of DynamoDB, you could set up cross-region replication using stream functions.
Though I have never implemented it, AWS provides documentation on how to set up replication
Note: Like with Edge-Optimized API Gateway, you can start developing DynamoDB tables and Lambda functions in a single region and then later scale out to a multi-regional deployment.
Update
As noted in the comments, DynamoDB has a feature called Global Tables, which handles the cross-regional replication for you. Appears to be fairly simple -- create a table, and then manage its cross-region replication from the Global Tables tab (from that tab, enable streams, and then add additional regions).
For more info, here are the AWS Docs
At the time of writing, this feature is only supported in the following regions: US West (Oregon), US East (Ohio), US East (N. Virginia), EU (Frankfurt), EU West (Ireland). I imagine when enough customers request this feature in other regions it would become available.
Also noted, you can run Lambda#Edge functions to respond to CloudFront events.
The lambda function can inspect the AWS_REGION environment variable at runtime and then invoke (and forward the request details) a region-appropriate service (e.g. API Gateway). This means you could also use Lambda#Edge as an API Gateway replacement by inspecting the query string yourself (YMMV).
I have one account on amazon aws services and Elastic IP associated with an instance on it. Can I re-associate the Elastic IP with an instance on another account?
To my understanding it is not possible to associate Elastic IP with instance on another account. I am an AWS user and I have also just researched the question in the AWS forums at:
http://forums.aws.amazon.com
Options that you MAY have available are workarounds, which might include things like:
If you are using a domain name, then get a new AWS account with a new EIP (Elastic IP) established, then switch the DNS of the domain name to point to the new EIP.
If you are referring to the original EIP in code, set up the new account with the new EIP, and change the code that is referring to to the EIP to refer to the new one.
You might establish a subnet between the two EC2 instances, similar to what is being done at this link http://fortycloud.com/interconnecting-two-aws-vpc-regions/ though it could be harder to do this when the EC2 instances are in two different accounts. But this line of thinking may get you somewhere depending on your scenario.
Please let me know your scenario, and I will be glad to suggest other workarounds. What is the kind of task you are trying to accomplish? A few calls? Passing some data back and forth? Or running a full website? If your scenario were known, then it might be possible to suggest a more appropriate approach. Thanks and good luck with your project!
You can open two cases from both accounts and then support team will create lock on EIP for destination account and then you can release EIP from source account and allocate it in the destination account using AWS CLI command :
Example:
aws ec2 allocate-address --domain vpc --address 203.0.x.x
In short, Lock ensures that EIP will not be allocated to public address space for other customers to allocate it.
So, please make sure you ask for an EIP locking and two cases required for security verification from source and destination.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-eip-recovering
Regards,
Dinesh Rathee
LinkedIn : https://www.linkedin.com/in/​dineshrathee12
It's possible, you will need to open a support case and they will do it for you after confirming ownership and approval with the two accounts involved.
The ec2-describe-instances command is not very helpful in distinguishing the instances.
Are there command line tools that give a better overview?
Perhaps somewhat like http://github.com/newbamboo/manec2 but with support for different regions etc.
Amazon recently has added a feature to 'tag' your EC2 instances.
You can use security group to identify your instance. See http://www.shlomoswidler.com/2009/06/tagging-ec2-instances-using-security_30.html
You can add an empty security_group to each instance to be able to communicate with each other.
I'm using http://github.com/cocoy/mr.awsome to provision and name instance via security groups. This way I can identify each instance whether I'm using Elasticfox, AWS console, or the same tool mr.awsome.
See also: http://www.capsunlock.net/2010/05/five-easy-steps-to-tag-ec2-instance-using-mr-awsome.html
Cheers,
Rodney
http://www.capunlock.net
I think Rodney's method of using securty groups is the most comprehensive, but if you just want a way to assign a free-form tag to your instances, you can do that if you set up a free account at RightScale and use it to launch your instances. Warning - you'll have to put up with occasional emails from RightScale asking if you want to use their paid services.
This isn't a command-line solution, and it's far from perfect, but my company currently maintains a shared Word document in a Dropbox folder that maintains the role/name -> instance id mapping for all of our active instances.
Using a Word document also allows us to keep track of some more information that is nice to have available at a glance:
The "environment" the instance is a part of.
The RDP shortcut to the instance for simple access.
The AMI the instance was launched from.
Any additional attached volumes.
The region the instance is in.
etc.