Announcing Fugue Team 2017.01.20

Michael Marcialis


We are a pleased to announce a new version of Fugue called Fugue Team. Fugue Team allows customers to manage multiple AWS accounts from a single Conductor and control who can access and operate resources with Fugue. With the introduction of Fugue Team we are continuing to offer a Free Edition of Fugue that allows users to manage a single AWS account with a single root user. 

Fugue Team: Multiple AWS Account Management

  • With Fugue Team you can now manage more than one AWS account from a single Fugue Conductor. Customers add the accounts they want Fugue to manage via the Fugue CLI and when they run a Composition they simply indicate the account they want to run it in via the account flag in the fugue run command. Cross account IAM Roles are used by the Conductor to build and manage AWS infrastructure in the AWS accounts that users added to it. Please refer to the Fugue Documentation site for more information (

Fugue Team: Declarative Role Based Access Control (RBAC)

  • In addition to Multiple AWS account management, Fugue Team also gives customers the ability to control who can access and perform specific operations on their Fugue Conductor. The role based access control feature allows customers to declare a user policy for their Fugue Conductor. In this policy they can declare the users they want and the specific actions each user is authorized to perform. A set of Fugue CLI commands are provided to attach policies to the Conductor and retrieve user credentials. Please refer to the Fugue Documentation site for more information (

Fugue CLI Features and Improvements

  • CLI Updates
    • We added a --force flag to the fugue upgrade command. In some circumstances this flag allows you to recover a failed upgrade.
    • We added a command that allows you to release a process from the Conductor. This command is important if you are removing an AWS account from the Conductor and still have processes running in that account. See

AWS Service Coverage

AWS service coverage included in this release is described in terms of the services' constituent resources. For details on any of this service coverage, refer to the Fugue Standard Library Reference (

  • IAM

    • Managed Policies
    • Groups
    • Roles
      • Extended existing coverage
    • Users
      • Extended existing coverage including adding Login Profiles
  • VPC

    • Network Interfaces
    • Internet Gateway
      • Extended existing coverage
    • Subnet
      • Extended existing coverage
    • NAT Gateway
      • Extended existing coverage
    • DhcpOptions
      • Extended existing coverage
  • EC2

    • Instance
      • Extended existing coverage
      • Note: If you currently have an instance(s) managed by Fugue you need to make sure you perform the correct upgrade steps when upgrading to the latest release. Please see the upgrade notice at the top of these release notes.
  • Auto Scaling

    • ScalingPolicy
      • Extended existing coverage
    • Launch Configuration
      • Extended existing coverage including allowing optional user provided Launch Configuration names
    • Auto Scaling Group
      • Extended existing coverage including allowing optional user provided Auto Scaling Group names
  • RDS

    • DB Subnet Group
      • Extended existing coverage
    • DBSubnetGroup field is now mutable for RDS Database Instances
  • R53

    • Resource Record Set
      • Extended existing coverage
  • SNS

    • SNS Subscriptions
  • Lambda

    • Event Source Mapping

General Updates to Fugue Libraries

  • The new AWS Ohio region (us-east-2) is now a supported region for running Fugue processes.
  • There is a new library validation which checks to make sure ELB Secure Listeners have a SSLCertificateId specified.
  • Cloudformation is now supported in the fugue-aws standard library.
  • The VPC field in the Core library for Internet Gateways is now optional and conforms to AWS semantics.
  • Lambda Functions can now be referenced as types rather than externals when declaring a S3 bucket notification.

Ludwig Improvements

  • The default Ludwig backend has been changed from simple to null. This means that when compilation is complete and the compiler enters the backend (output) phase, you will now get just a carriage return instead of a large amount of structured JSON. To turn on a specific Ludwig backend you can provide the following Compiler flag:
         -s,--semantics {null | tree | graph | proto | simple | snapshot}
  • Fixed an issue where the Compiler was not properly pattern matching on nested case statements.
  • Ludwig compiler errors can now be output in JSON format by specifying the
         --error-format json
    compiler flag.
  • Ludwig validations can now be written using the output of the compiler Node Stream. This improvement allows users to write validations for complex infrastructure configurations.
  • Ludwig now allows users to iterate over collections using list comprehensions.
  • We improved compiler error messages which involve large type definitions.
  • Fixed an issue where Ludwig was showing a scope checking error instead of a parsing error.