What is a worX pattern?
worX patterns are self-contained packages of Terraform and other supporting files that can be used to provision and manage everything from simple VMs, all the way to highly complex global transit networks, on AWS and all using a low-code approach that supports customization using a single simple configuration file.
Pattern types
There are several pattern types in worX; Unit, Workload, Fabric and Control patterns, each of which can be customized using simple configuration files that use YAML syntax.
Unit patterns
These more foundational building block resources are often provisioned in combination with supporting resources to improve capacity, performance or security.
A good example of a Unit pattern is the Stateful VM, which provisions EC2 VMs and has features that support; adding more storage, clustering enhancements, customizing the VM as it's boots and much more!
Each Unit pattern can support managing one or more resource of the same type, all from the same YAML config file.
# Just the one
enterprise_stateful_vm:
all-in-one-demo-server:
instance_ami: "redhat8"
instance_type: "t2.micro"
tags:
Name: "all-in-one-demo-server"
Function: 'All in one demo server for re:Invent'
# More than one
enterprise_stateful_vm:
# 1st one
demo-web-01:
instance_ami: "amazonlinux2"
instance_type: "t2.micro"
tags:
Name: "demo-web-01"
Function: 'Web services demo server for re:Invent'
# 2nd one
demo-app-01:
instance_ami: "redhat8"
instance_type: "t2.micro"
tags:
Name: "demo-app-01"
Function: 'All in one demo server for re:Invent'
# ..and on we go
Workload patterns
Can be used to provision a collection of different AWS resources to host full applications and services. We have Workload patterns for traditional 3-Tier applications, virtual appliances, Kubernetes clusters and much more.
A good example of a Workload pattern is the Atlassian Data Center Service, which provisions several VMs for hosting applications, network storage for shared assets, replicated databases, traffic management load balancers and bastion host for secure remote access
Each Workload pattern can support managing only one more complex logical resource collection, from the same YAML config file.
# Just the one!
workload_atlassian_service:
num_atlassian_instances: 5
ec2_atlassian_vms:
instance_type: "t2.xlarge"
names:
- JIRA-SVR-101
- JIRA-SVR-102
- JIRA-SVR-103
- JIRA-SVR-104
- JIRA-SVR-105
efs_mount_point: "/efs"
rds_db_port: 5432
efs_atlassian:
disable_efs_lifecycle_policies: false
performance_mode: "generalPurpose"
throughput_mode: "bursting"
provisioned_throughput_in_mibps: null
transition_to_ia: "AFTER_30_DAYS"
transition_to_primary_storage_class: "AFTER_1_ACCESS"
backup_policy: "ENABLED"
# ALB Configuration
lb_atlassian:
https_ssl_policy: "ELBSecurityPolicy-2016-08"
stickiness_enabled: true
stickiness_duration: 600
atlassian_hostname: "atlassian.example.com"
atlassianapi_hostname: "atlassianapi.example.com"
enable_self_signed_cert: false
# Weights per Jira HTTPS target group, defaults to [1,1,1,1,...]
atlassian_az_tg_weights: [4, 4, 1]
# Whether or not to provision a VM as a secure bastion host
enable_jump_host: true
# Whether or not to provision a VM as a log ingestion endpoint
enable_heavy_forwarder: true
# These CIDRs represent the private network addresses that should be allowed to connect
# and will be used for Security Group provisioning
org_network_cidrs:
- "10.0.0.0/8"
Fabric patterns
Resource collections that provide platform, networking and traffic management capabilities for AWS.
A good example of a Fabric pattern is the Standalone VPC, which provisions a VPC with up to 3 layers of subnets, Security Groups, VPC Endpoints, Flow logging and much more!
The Standalone VPC pattern can handle all of the IP address management, partition your VPC so that you can enable additional layers or availability zones without disrupting your existing hosted workloads
Each Fabric pattern can support managing only one more complex logical resource collection, from the same YAML config file.
# Just the one!
enterprise_spoke_vpc-workload:
vpc_cidr_block: "10.11.0.0/23"
num_availability_zones: 2
enable_edge_subnets: true
dns_suffix: "spoke.cloud.something.org"
Control patterns
Resource collections that provide management, access and governance guardrails to help ensure your AWS accounts comply with modern best practice.
A good example of a Control pattern is the Managed Account, which provides password policy control, identity provider control, root user login detection and audit trail setup
Each Control pattern can support managing only one more complex logical resource collection, from the same YAML config file.
# Just the one!
hestio_enterprise_managed_org_account:
pattern_features:
cloud_trail:
enabled: true
cloudwatch_log_retention_in_days: 14
managed_identity_source:
enabled: true
identity_source: saml-idp
root_login_detection:
enabled: true
sns_notification_target:
- "[email protected]"
- "[email protected]"
tag_default_resources:
enabled: false
managed_access_roles:
cloud_database_administrator:
enabled: true
include_default_deny: false
cloud_network_administrator:
enabled: true
include_default_deny: true
cloud_administrator:
enabled: true
include_default_deny: true
cloud_financial:
enabled: true
include_default_deny: true
So, now that we know the basic concept of a worX pattern, let's take a look at how we can use and customize the patterns in the library.
