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.
Related
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".
They don't want to give me their Amazon username and password because it has their complete purchase history.
Is there anyway for them to authorize me as a user?
Amazon has AWS Identity and Access Management, that should help with what your asking. http://aws.amazon.com/iam/
It's easy enough to create new accounts on Amazon, and it's also reasonable to keep corporate and personal accounts separate for expense purposes. I'd recommend doing that for simplicity, but I understand that it could be a concern regarding potential misuse on the rest of the Amazon site.
The use of access keys (as suggested by #KristianGlass) may be adequate, as well, allowing you to create and kill instances, but not allowing you access to the main AWS console. Elasticfox also works with the EC2 keys, so you could use that as a surrogate for the console.
Depending on what you're looking for, they might just be able to create you an Access Key and have you use that.
If they look under "Security Credentials" in their Account page (this should be a link to it) they can easily "Create a new Access Key" (they will of course need to give you both the Access Key ID and the Secret Access Key).
To paraphrase Amazon's documentation about Access Keys, you can use them for making requests to REST or Query APIs - specifically this includes EC2.
So I'm trying to figure out what's involved with doing the following using EC2:
I've got a desktop application that sometimes has to do cpu-intensive operations. What I need to do is offload these tasks to a cloud server which will run a version of the app specifically to handle the running of that task and return the results.
There will be situations where multiple instances of the desktop app are being run by different users and several might request offloading of tasks concurrently.
My question: Can the desktop app establish its own new EC2 instance to do the work and, if so, does is there a single ip address that it connects to to start the instance creation? When the instance is created, does it get its own IP address?
As you can see by my question I'm misunderstanding some key part of the EC2 system. Some clarification would be much appreciated
Amazon has an EC2 API that can be used to create, modify, or delete instances. This API is available in many of the popular programming languages so your desktop app should be able able to stat an EC2 instance and offload the work automatically.
http://www.programmableweb.com/api/amazon-ec2/links
Each new EC2 instance has its own unique public IP address which can be retrieved via the APIs mentioned above.
Amazon EC2 has a free usage tier that allows you to run one micro instance at a time, free for a year. So go ahead and try it out, even if you run more than one instance at a time, its super cheap. At least use the free micro instance to become farmiliar with how EC2 works.
In your code
Detect need to offload computation
Use EC2 API to create another instance of a saved virtual machine state you previously
setup
Use the API to get the IP address of the new instance
Connect to the IP address of the instance you just started and tell it what work to do
I have just installed a fedora linux AMI on amazon EC2, from the amazon collection. I plan to connect it to EBS storage. Assuming I have done nothing more than the most basic steps, no password changed, nothing extra has been done at this stage other than the above.
Now, from this point, what steps should I take to stop the hackers and secure my instance/EBS?
Actually there is nothing different here from securing any other Linux server.
At some point you need to create your own image (AMI). The reason for doing this is that the changes you will make in an existing AMI will be lost if your instance goes down (which could easily happen as Amazon doesn't guarantee that an instance will stay active indefinitely). Even if you do use EBS for data storage, you will need to do the same mundane tasks configuring the OS every time the instance goes down. You may also want to stop and restart your instance in certain periods or in case of peak traffic start more than one of them.
You can read some instructions for creating your image in the documentation. Regarding security you need to be careful not to expose your certification files and keys. If you fail on doing this, then a cracker could use them to start new instances that will be charged for. Thankfully the process is very safe and you should only pay attention in a couple of points:
Start from an image you trust. Users are allowed to create public images to be used by everyone and they could either by mistake or in purpose have left a security hole in them that could allow someone to steal your identifiers. Starting from an official Amazon AMI, even if it lacks some of the features you require, is always a wise solution.
In the process of creating an image, you will need to upload your certificates in a running instance. Upload them in a location that isn't bundled in the image (/mnt or /tmp). Leaving them in the image is insecure, since you may need to share your image in the future. Even if you are never planning to do so, a cracker could exploit a security fault in the software your using (OS, web server, framework) to gain access in your running instance and steal your credentials.
If you are planning to create a public image, make sure that you leave no trace of your keys/identifies in it (in the command history of the shell for example).
What we did at work is we made sure that servers could be accessed only with a private key, no passwords. We also disabled ping so that anyone out there pinging for servers would be less likely to find ours. Additionally, we blocked port 22 from anything outside our network IP, wit the exception of a few IT personnel who might need access from home on the weekends. All other non-essential ports were blocked.
If you have more than one EC2 instance, I would recommend finding a way to ensure that intercommunication between servers is secure. For instance, you don't want server B to get hacked too just because server A was compromised. There may be a way to block SSH access from one server to another, but I have not personally done this.
What makes securing an EC2 instance more challenging than an in-house server is the lack of your corporate firewall. Instead, you rely solely on the tools Amazon provides you. When our servers were in-house, some weren't even exposed to the Internet and were only accessible within the network because the server just didn't have a public IP address.
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.