We started to operate servers for our customers at AWS within one (root) account. Each customer environment is inside a separate VPC for maximum separation and ease of inter-instance access. Now with the second customer requiring a VPN connection I hit the wall with AWS the first time. You can’t have multiple VPC’s with VPN’s pointing to separate IP’s.
AWS support: “Unfortunately, due to routing restrictions in our regions we only allow a CGW IP to be used once per region.”
conflict among chosen gateway ip addresses
There is quite a number of discussions and threads around this, anyway without a straightforward technical solution (and installing software VPN is not suitable solution for me), I use a different workaround. I create additional accounts for every customer and link them back to our root account for consolidated billing. As nice side-effect, billings becomes more transparent for every account linked to one of our customers.
More info: http://docs.aws.amazon.com/awsaccountbilling/latest/about/consolidatedbilling.html
It was a matter of time until Amazon AWS would react to the recent price reduction by Google. With effect of April 1st they cut prices for EC2 and S3 massively again (up to 65% on S3 and 40% on EC2). For now the customer is the winner, lets observe how it develops on the long term.
I was offline for quite a while because shifting from one continent to another. But now regular posts should be rolling in again.
I am running a couple of instances in pre-production requirement mode and changed from a standard EBS volume to a IOPS volume for the DB instance or the volume with the DB files. I could not identify a reasonable increase of performance, maybe a misconception that IOPS volumes will boost performance, rather provide a defined and consistent random access I/O throughput. I must admit I did not use a value higher than 1000.
I decided to return to a standard ESB volume for my database as its performance did not benefit from the IOPS type (the DB is not overly busy too).
You cant change type and size of an EBS volume on the fly.
Using linux (Ubuntu) instances on Amazon EC2 is a quite safe thing to do, at least measured by the security provided by the platform (security groups, ACL, physical security,..). I recommend reading their security site here. At the end of the day the server is only as secure as you configure it, if you choose to open all ports running services with their default configurations and password settings, Amazon can’t help you.
When connecting to a Ubuntu server with ssh you need to provide the keyfile (somekeyfile.pem) that you can download when creating the key pair.
This 2048 bit key is required to login as regular ubuntu user. What I dislike is the fact that this user can sudo all, so once someone manage to get into you user account, he has root access too. I recommend to set a password for the ubuntu user and change the sudoers configuration.
Change the password for user ubuntu
Open the sudoers include file
sudo vi /etc/suderos.d/90-cloudimg-ubuntu or sudo vi /etc/sudoers
Finally this feature is available and easy as the click of a button. While it was previously almost impossible and last year through snapshots only you can select any AMI and copy to another region. It makes my life much easier and I stop maintaining reference images for every region but can make use of one image only ! More info here.
Today Amazon announced the EBS Snapshot Copy Feature (across regions). The intention is certainly to allow easy migration of data to another region, as you can copy the snapshot, create a volume and attach it to an instance. I was curious to try if I can migrate my Ubuntu instance to another region and it worked. You can use both command-line as well the AWS web admin.
Create a snapshot of a volume in your source region
To say it upfront: Usually there is no need to run an Ubuntu server with a desktop in the cloud. Whatever you do on the desktop you can do in a terminal too (assuming you dont want to use GIMP in the cloud). Here a little summary to get you started with a Precise Pangolin desktop running in the cloud.
Security: We will not use VNC, but NX. VNC is not secure (though can be tunnelled through SSH) and it works by sending compressed bitmaps of the screen, which is slower and less accurate than a NX server (X Server calls, Unix/Linux only)
Requirements: Amazon AWS account
Log into your AWS account
Optional: Create a security group with port 22 inbound only