aws-cloudformation-vpc
Provides AWS CloudFormation patterns for VPC foundations, including subnets, route tables, internet and NAT gateways, endpoints, and reusable outputs. Use when creating a new network baseline, segmenting public and private workloads, or preparing CloudFormation networking stacks for application deployments.
What this skill does
# AWS CloudFormation VPC Infrastructure
## Overview
Build a VPC foundation with CloudFormation that stays readable, reusable, and safe to evolve. Provides a clear subnet and routing model with predictable connectivity for public and private workloads, plus outputs that downstream stacks can consume without duplicating network logic.
Use the `references/` files for larger templates and extended service combinations.
## When to Use
- Creating a new VPC stack for an application or shared platform
- Adding public and private subnets across one or more Availability Zones
- Wiring internet access, NAT egress, or private endpoints
- Exporting VPC, subnet, route table, and security-group-adjacent identifiers for other stacks
- Preparing reusable infrastructure for ECS, EKS, Lambda, EC2, or RDS stacks
## Instructions
### 1. Start with the address plan
Before writing resources, define:
- VPC CIDR range
- Number of Availability Zones
- Public, private, and isolated subnet ranges
- Which workloads need internet ingress, NAT egress, or only private AWS service access
This prevents route-table sprawl and painful subnet replacement later.
### 2. Build the core network resources in layers
Create the stack in this order:
1. VPC and subnets
2. Internet Gateway for public ingress and egress
3. NAT gateways if private subnets need outbound internet access
4. Route tables and subnet associations
5. Optional VPC endpoints for private access to AWS services
Keep each layer easy to inspect in the template and avoid mixing unrelated application resources into the same stack.
### 3. Parameterize only the environment-dependent values
Useful parameters include:
- Environment name
- VPC CIDR and subnet CIDRs
- Number of AZs or explicit subnet IDs in nested-stack scenarios
- Flags for optional endpoints or NAT layout
Do not parameterize every route or tag unless it meaningfully changes between environments.
### 4. Export only what consumers really need
Typical outputs:
- VPC ID
- Public, private, and isolated subnet IDs
- Route table IDs when downstream stacks must attach routes
- Security boundaries or prefix-list references only when another stack consumes them
Stable outputs make application stacks easier to compose and migrate.
### 5. Validate before deployment
Run these commands to validate the template and verify routing:
```bash
# Validate CloudFormation template syntax
aws cloudformation validate-template --template-body file://vpc.yaml
# Review change set before applying
aws cloudformation create-change-set \
--stack-name my-vpc \
--template-body file://vpc.yaml \
--change-set-type CREATE
# Verify route table associations
aws ec2 describe-route-tables \
--filters "Name=vpc-id,Values=<vpc-id>"
# Check subnet to route table mappings
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=<subnet-id>"
# Verify internet gateway attachment
aws ec2 describe-internet-gateways \
--filters "Name=attachment.vpc-id,Values=<vpc-id>"
```
## Examples
### Example 1: Complete two-tier VPC with routing
This template creates a VPC with public and private subnets, internet gateway, NAT gateway, and properly configured route tables.
```yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: "Two-tier VPC with public and private subnets"
Resources:
# VPC
MainVpc:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
EnableDnsSupport: true
Tags:
- Key: Name
Value: !Sub "${AWS::StackName}-main"
# Internet Gateway
InternetGateway:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: !Sub "${AWS::StackName}-igw"
# Attach IGW to VPC
GatewayToInternet:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref MainVpc
InternetGatewayId: !Ref InternetGateway
# Public Subnet (AZ 1)
PublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MainVpc
CidrBlock: 10.0.1.0/24
AvailabilityZone: !Select [0, !GetAZs ""]
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: !Sub "${AWS::StackName}-public-a"
# Private Subnet (AZ 1)
PrivateSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MainVpc
CidrBlock: 10.0.11.0/24
AvailabilityZone: !Select [0, !GetAZs ""]
Tags:
- Key: Name
Value: !Sub "${AWS::StackName}-private-a"
# Elastic IP for NAT Gateway
NatEip:
Type: AWS::EC2::EIP
DependsOn: GatewayToInternet
Properties:
Domain: vpc
# NAT Gateway
NatGateway:
Type: AWS::EC2::NatGateway
Properties:
SubnetId: !Ref PublicSubnetA
AllocationId: !GetAtt NatEip.AllocationId
# Public Route Table
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref MainVpc
Tags:
- Key: Name
Value: !Sub "${AWS::StackName}-public-rt"
# Default route to IGW
PublicDefaultRoute:
Type: AWS::EC2::Route
DependsOn: GatewayToInternet
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
# Associate public subnet
PublicSubnetARouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnetA
RouteTableId: !Ref PublicRouteTable
# Private Route Table
PrivateRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref MainVpc
Tags:
- Key: Name
Value: !Sub "${AWS::StackName}-private-rt"
# Default route via NAT Gateway
PrivateDefaultRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref PrivateRouteTable
DestinationCidrBlock: 0.0.0.0/0
NatGatewayId: !Ref NatGateway
# Associate private subnet
PrivateSubnetARouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PrivateSubnetA
RouteTableId: !Ref PrivateRouteTable
Outputs:
VpcId:
Description: VPC ID
Value: !Ref MainVpc
Export:
Name: !Sub "${AWS::StackName}-VpcId"
PublicSubnetA:
Description: Public subnet AZ1
Value: !Ref PublicSubnetA
Export:
Name: !Sub "${AWS::StackName}-PublicSubnetA"
PrivateSubnetA:
Description: Private subnet AZ1
Value: !Ref PrivateSubnetA
Export:
Name: !Sub "${AWS::StackName}-PrivateSubnetA"
PublicRouteTableId:
Description: Public route table ID
Value: !Ref PublicRouteTable
Export:
Name: !Sub "${AWS::StackName}-PublicRouteTableId"
PrivateRouteTableId:
Description: Private route table ID
Value: !Ref PrivateRouteTable
Export:
Name: !Sub "${AWS::StackName}-PrivateRouteTableId"
```
### Example 2: VPC endpoint for private S3 access
```yaml
Resources:
# S3 VPC Endpoint
S3Endpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref MainVpc
ServiceName: !Sub "com.amazonaws.${AWS::Region}.s3"
RouteTableIds:
- !Ref PrivateRouteTable
VpcEndpointType: Gateway
```
## Best Practices
- Keep public, private, and isolated subnet purposes explicit in names and tags
- Prefer one NAT gateway per AZ for resilient production environments when budget allows
- Use VPC endpoints to reduce unnecessary NAT traffic for AWS service access
- Export VPC and subnet identifiers from the network stack instead of recreating network assumptions elsewhere
- Review network changes with dependency stacks because route and subnet changes can have broad blast radius
- Keep the root skill focused and move larger networking variants to `references/examples.md`
## Constraints and Warnings
- NAT gateways incur hourly costs and data transfer charges—consider VPC endpoints for AWS service access
- CIDR overlap blocks peering, transit, and future network expansion
- Route-table or subnet replacements can interrupt traffic even when the tempRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.