We host our clients' infrastructure. We are looking at AWS for some services. However, our business model is to provide the hosting included in our fee so to that end we need to be the account holder. We therefore need to have one account which is billed but clear delineation between different separate client infrastructure. Ideally with a separate console etc. Is this possible? Thanks.
You should take a look at consolidated billing, as it sounds like it will meet your needs:
http://docs.aws.amazon.com/awsaccountbilling/latest/about/consolidatedbilling.html
This would enable you to set up unique "linked accounts" per customer, each fully separate and independent of each other (separate console logins, separate security configurations, etc.).
Related
I have two EC2 instances in a single AWS account. Both are running for different application services. Now, I want to make billing separate for that particular account. So, I can get the exact spent and charges for the applications and can manage my account as per that for separate accounting purposes.
Is it possible? If not, then can anyone suggest me a better way to achieve this?
I'm planning to handle the different AWS accounts for both services. But, it will be hard to manage so, I can't prefer that option.
For more, In Google Cloud, they're providing to handle different billing accounts within the same google cloud account. So, I think this concept might be available on AWS also.
Thanks in advance for any little bit of help or suggestion.
You can't get separate bills for different sets of resources within the same AWS account. However, you can filter out the costs for different sets of resources using tags. By using a distinct tag (or set of tags) in the resources you allocate to each application, you can get a breakdown of the cost for each application in billing reports and cost explorer. See the documentation for details and steps on how to set it up - https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
I believe it's the same with Google Cloud as well - although you can have multiple billing accounts within your google account (the hierarchy in GC is different to AWS, and an AWS account is more similar to a GC project than a GC account), a project within your account must have one billing account and does not support multiples.
By this -
Now, I want to make billing separate for that particular account.
do you mean you already have 2 different AWS accounts? If yes, you can get billing details as per account if they become part of same Organization. Check AWS Organizations docs for more info.
With Orgs, you can view bills of different accounts from one account itself if it is part of org. Also your accounts get discounts for services.
I'm working on a project for a web app where each enterprise customer will have separate resources independent to themselves (i.e. users and user data unique to a single paying customer, content unique for each paying customer, etc). It's somewhat similar to a normal CRM. We're building on AWS and planning to use RDS for the database. Given the fact that each customer does not share data across any different region, would it be most effective to:
Upon enterprise customer sign up, a new VPC is created with new RDS and EC2 instances, so that each customer has siloed databased and services
Have a single VPC with RDS and EC2 instances shared across all customers and use an indicator field in the database to determine what data belongs to each customer
We don't anticipate having over 10000 users for any given enterprise customer, and right now the project is small with only a single enterprise customer.
This answer all depends on how you anticipate your application growth (not just in terms of number of customers but also performance), however personally I would say if you have a single enterprise customer at the moment create a single VPC.
Perhaps separate out a seperate database on the RDS for each customer initially assuming that cost would become a concern, with a seperate db user for each customer to limit exposure.
If the financials allow then you would look at separating out to a seperate RDS database where the performance demands (maybe you have tiers for SLAs etc).
If you get larger customers (who may have bespoke needs, or stringent requirements such as no multi tenant hosts) I would suggest you look at an organizations setup with a account per large customer to separate out the resources and a single account for any shared or multi-customer resources.
The key is plan ahead for how you would want to but if you're still in the early midst of onboarding clients then do not over complicate your setup yet.
I would like to know a system by which I can keep track of multiple aws accounts, somewhere around 130+ accounts with each account containing around 200+ servers.
I wanna know methods to keep track of machine failure, service failure etc.
I also wanna know methods by which I can automatically turn up a machine if the underlying hardware failed or the machine terminated while on spot.
I'm open to all solutions including chef/terraform automation, healing scripts etc.
You guys will be saving me a lot of sleepless nights :)
Thanks in advance!!
This is purely my take on implementing your problem statement.
1) Well.. for managing and keeping track of multiple aws accounts you can use AWS Organization. This will help you manage centrally with one root account all the other 130+ accounts. You can enable consolidated billing as well.
2) As far as keeping track of failures... you may need to customize this according to your requirements. For example: You can build a micro service on top of docker containers or ecs whose sole purpose is to keep track of failures, generate a report and push to s3 on a daily basis.You can further create a dashboard using AWS quicksight out of this reports in S3.
There can be another micro service which will rectify the failures. It just depends on how exhaustive and fine grained you want your implementation to be.
3) For spawning instances when spot instances are terminated, it can be achieved through you simple autoscaling configurations. Here are some of the articles you may want to go through which will give you some ideas:
Using Spot Instances with On-Demand instances
Optimizing Spot Fleet+Docker with High Availability
AWS Organisations are useful for management. You can also look at multiple account billing strategy and security strategy. A shared services account with your IAM users will make things easier.
Regarding tracking failures you can set up automatic instance recovery using CloudWatch. CloudWatch can also have alerts defined that will email you when something happens you don't expect, though setting them up individually could be time consuming. At your scale I think you should look into third party tools.
I would want to have different environments in AWS. At first I thought of differentiating environments by Tags, tags on AWS Resources. But then I cannot restrict users to change Tags of the machine. What that means is, if I allow them ec2:CreateTags, they can not only create tag, but also change tag of any of the resources, since cannot apply a condition on it - say for example if it belongs to a particular VPC or subnet. If I don't allow them the previlege to create tag, then they can launch an instance but their tags are not applied and hence any further operation on the instance is not permitted.
If I want to distinguish between environments by VPC-ID, then for operations such as ec2:StartInstance cannot apply a condition to allow the operation only in a specific VPC-ID, but can conditionally allow based on Resource Tag which for reasons in previous paragraph is not convincing.
On AWS documentation it mentions
One approach to maintaining this separation was discussed in the Working with AWS Access Credentials, that is, to use different accounts for development and production resources.
So it is possible to have one Paying Account for several other accounts which themselves are Paying Accounts? I still don't think multiple accounts for just different environments is a good idea.
How do you generally differentiate among environments for enforcing policies?
Thanks.
Different accounts is the way to go. There are so many places you'll want to create isolation that you'll make yourself crazy trying to do it within one account. Think about it - there's network controls, all the IAM permissions for all the services, access control lists, tags that have the limitations you describe, and on and on. Real isolation comes from putting things in different accounts for now.
The last thing you want is some weakness in your dev environment to pivot into your production environment - end of story. Consider also the productivity benefit of separating prod and dev accounts... you'll never break a prod system from a mistake or experiment in development.
Consolidated billing is the answer to paying for it all. Easy to setup and track. If you need more reporting, look into CloudAbility.
Where this gets really interesting is in the space of multiple production and multiple dev environments. There are a lot of opinions on isolation there. Some people combine all prod and dev into two accounts, and some put every prod and dev into their own. It all depends on your risk profile. Just don't end up like CloudSpaces.
It is possible to do consolidated billing, where one account is billed for its own usage + the AWS usage for any other linked account. However, you can not split that bill (e.g. have the master account only pay for EC2 services on a linked account, while having the linked account pay for it's other usage like S3, etc.).
As for differentiating between environments, I've used different security groups for each one (dev, staging, production) as an alternative to tags, but there are limitations when it comes to enforcing policies. The best option to have full policy control is to use different accounts.
I would suggest go with with one VPC and use Security Groups for isolation. As your AWS infra grows, you will need Directory Services (Name Servers, User Directory, VM Directory, Lookup services etc.). If you have two VPCs, sharing the Directory Services will not be easy. Also if you need Code Repository (e.g. GitHub) or Build tools (e.g. Jenkins) having three separate VPCs for DEV, Staging and Production will make things really complicated.
I am working for two separate employers, on a project with similar goals. Both use Amazon EC2 for their servers, and both gave me an account to access their instances, with different userid and password pair, is it possible to have these 2 accounts be a subset of another account? So i can switch easily from one account to another from that main account?
No, not unless you want the superset account to also assume billing responsibility for the sub-accounts. I'm pretty sure neither you nor either of your two employers would appreciate being billed for the composite EC2 usage of both...
From a working-practices viewpoint, however, you can configure ElasticFox with any number of different account configurations and switch between them at the click of a dropdown.