Tags: awslabs/aws-saas-boost
Tags
Fix onboarding new tenants with EFS (#513) * Fix onboarding new tenants with EFS (#513) * Revert removal of CreateTags (#513) --------- Co-authored-by: Ulrich Hinze <[email protected]> Co-authored-by: brtrvn <[email protected]>
Update saas-boost.yaml reflect the new S3 policy (#508) * Add Tier to tag setting * added the Tier tag to the resources * To pass the Tier tag as a parameter to the tenant-onboarding-app.yaml CloudFormation stack through handleOnboardingBaseProvisioned * Fargate Service Quota check logic change from Task based quota to vCPU based quota * Add logic for Fargate Spot vCPU resource count check * Add logic for Fargate Spot vCPU resource count check * Modify logic for Fargate Spot vCPU resource count check * Update saas-boost.yaml Changed the way log storage permissions are granted to buckets for writing S3 Access logs from ACLs to IAM policies. New policy practices of S3 https://aws.amazon.com/about-aws/whats-new/2023/04/amazon-s3-two-security-best-practices-buckets-default/ --------- Co-authored-by: Kim <[email protected]> Co-authored-by: PoeppingT <[email protected]>
Update scripts must not fail if Lambda function does not already exis… …t. (#480) * Update scripts must not fail if Lambda function does not already exist. When updating from older versions of SaaS Boost to newer ones, we rely on each Lambda function's update.sh script to build the code and update any relevant Lambda functions in the AWS account. If any of these update.sh scripts fail, an entire SaaS Boost update will fail, since it assumes something has gone wrong with building or uploading that code. However, in the case we add a new Lambda function, the existing Lambda function may not already exist until the CloudFormation stack is updated, which is something the Installer executes after running each update.sh script. This change makes these update scripts not fail in that case. * Switch to using lambda list --------- Co-authored-by: PoeppingT <[email protected]>
Fix signout in admin web app. (#439) This commit also includes a large-scale cleanup of unnecessary JS in the admin web app, deleting files that are unused in an effort to simplify the JS application. Fixes #432 Co-authored-by: PoeppingT <[email protected]> Co-authored-by: brtrvn <[email protected]>
Fix bug attaching multiple CapacityProviders in multiple EC2 services. ( #359) * Fix bug attaching multiple CapacityProviders in multiple EC2 services. When launching multiple EC2 services the current tenant-onboarding-app CloudFormation stack tries to create a ClusterCapacityAssociations CloudFormation resource for each service. However because attaching CapacityProviders to ECS Clusters is non-atomic only the first ClusterCapacityAssociations will actually succeed. This commit adds a CustomResource which on CapacityProvider create and delete will attach or detach that CapacityProvider to the existing ECSCluster. Because this attachment is a non-atomic operation (i.e. it involves first getting the existing capacityProviders for the ECS cluster before then overwriting with a new set of capacityProviders) this commit also includes using the existing Onboarding DynamoDB table as a locking mechanism to prevent against illogical overwrites between multiple stacks operating on the same ECS Cluster. Fixes #356. * Fix null pointer in cloudformation-utils Co-authored-by: PoeppingT <[email protected]> Co-authored-by: brtrvn <[email protected]>
Installer update enhancements (#288) * Rename and fix all update scripts. * Add caching to AwsClientBuilderFactory * Fix build script indexing bug for sample app * Update enhancements: intelligent updating, improved architecture, more tests. * Address PR comments Co-authored-by: PoeppingT <[email protected]>
Fixing EC2 launch type and Windows provisioning. Upgrading to use EC2… … Launch Templates and also support EC2 for Linux workloads (still hard coded to use Fargate for Linux).
PreviousNext