I’m currently using cloudformation(JSON template) to manage different aws services.
The Aws services I use include S3, Lambda, API Gateway, Amplify, Dynamodb, IAM, Cognito.
The development phase is almost finished, now I'm finding ways to build UAT environments by using the existing cloudformation template.
Different ways come into my mind.
1.Create cloudformation stacks after switching to different countries
But some services like S3 are cross-country services.
If I create another S3 bucket with the same name, the bucket might not be successfully created.
2.Create new IAM User for creating cloudformation stacks
I am currently using the Root User account for the Service Management in the development stage(I know it's bad practise though). I can create a new IAM user(e.g. UAT_Admin) to create the UAT environment.
These are all methods I can think of. I need a method for the environment management for later creating UAT environments, and even the Production environment in the future.
Any comments or suggestions?
For greatest separation of different development environments (dev, testing, uat, prod) often different accounts are used. This provides greatest separation of resources without risking that someone from testing will accidentally delete/modify production services.
To make it easier to work with different accounts AWS provides AWS Organizations as well as AWS CloudFormation StackSets. The StackSets would enable you to use same template accorss different accounts.
Related
I like to create multiple environments in AWS Account rather than multiple accounts, how can this be done?
Use-case for this is each environment can have its own stack, so each environment will have DynamoDB, Lambda, services etc.
I could not find any documentation on how to create multiple environments in AWS Account
Currently, I am using these services in AWS:
EC2 instance
S3 bucket
SES for transactional mails
I access S3 and SES services in the backend using an AWS_ACCESS_KEY_ID, and an AWS_SECRET_ACCESS_KEY which basically means I cannot share those keys with the developers.
I would like to create a separate development environment that doesn't give access to those services in production.
I have made some research and I found-out that I can create a whole new account for development environment and then synchronize billing between the two especially that I have AWS credits.
Before investing time in that, I wonder if it's possible to achieve my goal with using a separate IAM identity.
I am using different accounts for environment management by cloudformation.
I am considering the best deployment procedure
There are 2 ways i think of.
1.serverless setup(lambda,dynamodb,s3 etc) in different account, but deployment for different environments(UAT,Prod) is done on the same master account.
E.g.account master_admin for deployment of all environment in amplify. dev_admin and uat_admin are used for serverless setup for dev and uat environment separately.
2.both serverless setup and deployment are done on the same account
E.g.dev_admin is used for serverless setup and amplify deployment in dev stage, while uat_admin is for uat env serverless setup and amplify deployment
I am not sure the pros and cons for these 2 ways and which one is better
Creating different accounts for each environment (PRODUCTION, Stage), provide separation between the environments, but operational tasks are challenges.
create IAM users, groups, and policies for each account.
sign in to each account separately.
And you may need to think on:
AWS Organizations and Consolidated Billing.
Federate identity.
One account for all environments simplifies managing users and permission but needs IAM Groups, user, roles, and policies in addition tp Resource level policies, for access control,
and aws resources need to be tagged to distinguish between the environments.
AWS Amplify and the "Applications" feature within AWS Lambda seem to have a few things in common:
Both seem to be a wrapper around several AWS resources
Both walk you through a guided setup to provision a working AWS stack
Both set up some CI/CD pipelines for you so that Git commits trigger a build and deploy
So what are the differences between these two services, and what are some scenarios where you might want to choose one over the other?
AWS Amplify is a toolchain for front-end developers to interact with AWS resources. It provides a cli program to manage resources and (JS/Android/iOS) libraries to integrate them into your front-end applications.
It doesn't 'wrap' resources, but is merely a convenience layer to manage them (it is somewhat similar to AWS SAM); Amplify generates CloudFormation templates, stores those locally, and uses aws-cli to provision them. Note that Amplify can also be used just as a front-end library to integrate resources that are already set up.
AWS Lambda Applications is an actual AWS service, or rather a feature of AWS Lambda. It groups related resources, so they can be managed and deployed as if it was a single resource.
... what are
some scenarios where you might want to choose one over the other?
Amplify is aimed at web- and mobile developers: it allows them to manage backend resources without much backend knowledge.
It is not a matter of 'using one over the other'; they can actually be used in conjunction with each other.
I am trying to clone my aws account(prod) to another account(test) with all resources and configuration I have set up on prod. Is there any best practice to replicate the aws account to another?
This is not possible.
Nor is there an easy way to list all resources in an AWS account.
Each AWS Service (eg EC2, S3, Lambda) have their own API calls to list resources and describe configurations. There is no universal way to request this information.
Best Practice is to only create resources using AWS CloudFormation templates, thereby having full documentation of resources created and the ability to deploy similar infrastructure in other AWS accounts or regions.
Some third-party services (eg https://www.hava.io/) can extract configuration information and automatically create AWS CloudFormation templates. However, these templates only record the configuration of AWS resources -- they do not replicate the content of storage on disks, Amazon S3 or databases.