Les Hazlewood's questions

Let's assume that I have 20 running EC2 instances and 10 active Reserved Instance reservations.

Using the AWS Console or AWS CLI, what is the fastest way to determine which of the running EC2 instances are not 'covered' by a Reserved Instance reservation?

To give more clarity on the desired result, consider the following (not possible in the AWS console that I'm aware of):

1. Get a list of all running instances in a region. You can do this in the AWS console today and via the AWS CLI.
2. Get a list of all active Reserved Instance reservations in the same region. you can do this in the AWS console today and via the AWS CLI.
3. Cross-check the two lists: Every time you see a running instance of size X in zone Y, and there is a Reserved Instance reservation of size X in zone Y, remove it from the running list.
4. The remainder of instances in the modified running list are all those that are not covered by a Reserved Instance reservation.

I'm looking for a way to get #4 without having to manually copy the two lists available in the AWS console to Excel and manually crossing off running instances as I see a corresponding RI reservations. I could write a script that uses the CLI to do this too, but I was assuming that there might be something that already exists since this is an obvious way of analyzing cost efficiency.

I have a cloud-based (Amazon AWS, Rackspace, whatever) multi-tenant SaaS application, and I need to support HTTPS communications for multiple unrelated tenant domains.

As an illustrative example, let's say our SaaS is available at:

https://foo.com

Tenants can access their tenant-specific UI and service endpoints via:

https://tenantA.foo.com
https://tenantB.foo.com
...

This is easy to support today with one wildcard SSL certificate.

However, with our SaaS, our tenants may wish to expose our UI (but branded for them) directly to their own users.

This causes a problem: let's say John Smith is an existing customer of tenantA (and has no knowledge of foo.com). If John Smith is directed to https://tenantA.foo.com, they could easily become confused (e.g. 'who the heck is foo.com? Why am I here? Am I being hacked? Aahhh!').

To avoid this problem, our tenants would set up a subdomain like:

https://foo.tenantA.com

This avoids a lot of end-user confusion: tenantA's users can see a URL they recognize as owned by tenantA and will more readily use the app. But tenantA wants us to host everything about the app, which means foo.com's infrastructure needs to serve the SSL connection.

To that end, we want to support the following:

1. A tenant uploads to us an SSL cert+key for foo.tenantA.com.
2. We take that SSL cert and dynamically install it into a highly available Load Balancing cluster (2 or more LB nodes) that load balances requests to our SaaS application web endpoints.
3. The tenant updates their DNS to have foo.tenantA.com be a CNAME redirect to tenantA.foo.com.

This way our Load Balancer pool will serve/terminate all HTTPS communications to foo.tenantA.com and all requests are load balanced to our SaaS web server cluster.

This means SSL certs should be able to be added and removed from the LB pool at runtime. Changes cannot interrupt the ability to service existing or new HTTPS requests.

Also, as we'll deploy on virtualized hardware (e.g. EC2) with Linux, we don't have access to the hardware/data center. This must be a software-based solution that can run in Linux. It must also be highly-available (2 or more LB 'nodes').

Does anyone know of a concrete solution? For example, can Nginx, HAProxy or Squid (or anything else) be set up to support this? Is there a 'recipe' or existing solution that is documented and suitable?

P.S. Amazon's Elastic Load Balancer (at the time of writing) cannot pragmatically satisfy this need - it would require an Amazon ELB for each tenant domain. Since every ELB needs to 'ping' the web servers, if you had 500 tenants, you'd have 500 ELBs pinging the SaaS web service endpoints - a non-negligible negative performance hit.