Links

Daily workflow

Substrate is not here to dictate all aspects of your daily workflow, nor is Substrate in the business of influencing or limiting your tool choices. Substrate is all about removing all the hassles that come with having lots of AWS accounts, the one true unit of isolation in AWS, so that you can reap all the security, reliability, and compliance benefits of isolating your workloads in their own AWS accounts.
As such, Substrate introduces some extra tools to your daily workflow, mostly concerning accessing AWS and moving between AWS accounts.

Get AWS credentials from your Credential Factory

At the beginning of each working day, you'll want to refresh your AWS credentials, since each set only lasts 12 hours:
eval $(substrate credentials)

Assume roles to move between AWS accounts

Learn what AWS accounts exist in your organization and how they're tagged by looking in substrate.accounts.txt or running substrate accounts.
You can run a one-off command in one of those accounts (and of course the one-off command doesn't have to be aws ec2 describe-instances):
substrate assume-role -domain <domain> -environment <environment> -quality <quality> aws ec2 describe-instances
(Domains, environments, and qualities are how Substrate organizes AWS accounts.)
Or you can move your whole terminal session into another account:
eval $(substrate assume-role -domain <domain> -environment <environment> -quality <quality>)
And return from whence you came when you've wrapped up your work in that service account:
unassume-role
In all of these situations, the account boundary serves as a critical isolating safety feature, ensuring exploratory changes in development can't impact production or emergency operational changes to one production service can't impact others.

Create AWS accounts and IAM roles

In a Substrate-managed AWS organization you'll create and recreate and recreate accounts and IAM roles (always confident that Substrate will find them if they already exist).
When you create (or recreate) an account, Substrate will ensure the account and its basic IAM roles are in good working order and then run the various Terraform root modules associated with the account (one for global resources and another for each region; see global and regional Terraform modules for more).
Try it for yourself, using the domain, environment, and quality from a service account you find listed in substrate.accounts.txt:
substrate create-account -domain <domain> -environment <environment> -quality <quality>
Substrate manages an all-powerful Administrator role and a limited read-only Auditor role by default. But you're probably going to want to create custom IAM roles to complement the isolation you create by having lots of AWS accounts. Substrate manages IAM roles for cross-account access better than anything else around.
substrate create-role -role <RoleName> [account selection flags] [assume-role policy flags [policy attachment flags]
There are a lot of options, though, so consult the documentation on adding custom IAM roles for humans or services to get the complete picture.

Plan and apply Terraform changes

Substrate gives you production-ready Terraform infrastructure for all your AWS accounts with a module structure that enhances the isolation provided by your many AWS accounts and locked, remote state files. It strives to make writing Terraform code a straightforward exercise free of yak-shaving.
And while substrate create-account does in fact plan and/or apply Terraform changes in all an account's root modules in a predictable order, iterating on your works-in-progress deserve a faster feedback loop:
terraform -chdir=root-modules/<domain>/<environment>/<quality>/<region> plan
terraform -chdir=root-modules/<domain>/<environment>/<quality>/<region> apply

Launch an EC2 instance

In addition to brokering AWS credentials via your identity provider, your Intranet also includes the Instance Factory that can provision personal, temporary EC2 instances in your admin account for use as jump boxen or development environments.
To provision your own, visit your Intranet in your web browser, click Instance Factory, choose a region, and choose an instance type.