aws-deployment-framework
aws-deployment-framework copied to clipboard
awslabs
The AWS Deployment Framework (ADF) is an extensive and flexible framework to manage and deploy resources across multiple AWS accounts and regions based on AWS Organizations.
When deploying the ADF into an existing organization, it might be nice to have more control over which OUs should be bootstrapped, as another process (eg Landing Zone / Control...
I have this deployment map: ``` ipelines: - name: vpc-pipeline default_providers: source: provider: codecommit properties: account_id: 11223344556677 deploy: provider: cloudformation properties: action: replace_on_failure stack_name: ipam-vpc template_filename: packaged.yml params: restart_execution_on_update: True...
## What and Why This is partly inspired by: https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments But also working towards a solution to Issue #250 The proposal is that we add the concept of a "Wave"...
ADF Version: 3.0.1 ` - account_full_name: "some-random-account" -- | organizational_unit_path: /existing/new-ou | email: [email protected] | allow_billing: True | delete_default_vpc: False | alias: some-random-account | tags: | - managed_by_adf: True `...
Why not use Resource Type Providers (Python [here](https://github.com/aws-cloudformation/cloudformation-cli-python-plugin/)) instead of custom resources? If the resource types are split into smaller parts, other deployment frameworks (like [CDK](https://docs.aws.amazon.com/cdk/api/latest/), [Terraform](https://www.terraform.io/docs/providers/aws/index.html), [Pulumi](https://www.pulumi.com/docs/), [OrgFormation](https://github.com/OlafConijn/AwsOrganizationFormation)) could...
There’s a new CDK feature called CDK Pipelines: https://aws.amazon.com/blogs/developer/cdk-pipelines-continuous-delivery-for-aws-cdk-applications/ Should ADF adopt that as the way of dealing with new pipelines, using the deployment-map declarations?
Control Tower uses a 14-day retention policy for it's CloudWatch Logs. Seems reasonable to introduce as a default for ADF as well - or - to preserve backwards compatibility -...
As it says. Right now the name of the deployment OU is not configurable. Since Control Tower (for better or worse) is now the default account factory and introduces capitalised...
Integration with CT/ALZ will provide a lesser administrative effort and a more secure management.
Given the new features announced for CodeSuite [here](https://aws.amazon.com/about-aws/whats-new/2020/04/receive-notifications-for-aws-codebuild-codecommit-codedeploy-codepipeline-in-slack/), I believe it would be a good idea to replace the Slack integration method to this new one. Thoughts?