‹ 首页

aws-cloudformation-elasticache

@giuseppe-trisciuoglio · 收录于 1 周前

Provides AWS CloudFormation patterns for ElastiCache Redis or Memcached infrastructure, including subnet groups, parameter groups, security controls, and cross-stack outputs. Use when designing cache tiers, high-availability replication groups, encryption settings, or reusable CloudFormation templates for application caching.

适合你,如果正在用CloudFormation管理AWS缓存基础设施

/ 下载安装
aws-cloudformation-elasticache.skill双击,或拖进 Claude 桌面版 / Cowork,即完成安装↓ .skill↓ .zip
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code~/.claude/skills/(项目级 .claude/skills/)
Codex CLI~/.codex/skills/
Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add giuseppe-trisciuoglio/developer-kit/aws-cloudformation-elasticache
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- giuseppe-trisciuoglio/developer-kit/aws-cloudformation-elasticache
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify giuseppe-trisciuoglio/developer-kit/aws-cloudformation-elasticache
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
303GitHub stars
~1K最小装载
~8.7K含声明引用
~8.7K文本包总量
镜像托管

怎么用

技能原文 SKILL.md作者撰写 · MIT · 306f428

AWS CloudFormation ElastiCache

Overview

Use this skill to model ElastiCache infrastructure with CloudFormation without turning SKILL.md into a full service manual.

Focus on the delivery decisions that matter most:

  • choosing the right cache topology
  • placing the cache safely inside a VPC
  • configuring availability, encryption, and exports for downstream stacks

Use the bundled references/ documents for larger production templates and service-specific detail.

When to Use

Use this skill when:

  • creating a Redis or Memcached cache tier with CloudFormation
  • deciding between AWS::ElastiCache::CacheCluster and AWS::ElastiCache::ReplicationGroup
  • configuring subnet groups, parameter groups, and security groups for application access
  • adding snapshots, maintenance windows, encryption, and Multi-AZ behavior
  • exporting cache endpoints to application or platform stacks
  • reviewing cache changes for replacement risk, downtime, or operational cost

Typical trigger phrases include cloudformation elasticache, redis replication group, memcached cluster, cache subnet group, and export redis endpoint.

Instructions
1. Choose the cache topology first

Use:

  • ReplicationGroup for production Redis-style deployments that need failover, replicas, or sharding
  • CacheCluster for Memcached or simple single-node cache scenarios

Do not start with resource YAML before deciding whether the application needs durability, read replicas, cluster mode, or just an ephemeral cache.

2. Model the network boundary explicitly

Create and wire:

  • a subnet group with private application subnets
  • a security group that allows access only from the application tier
  • parameter groups only when default engine settings are insufficient

Keep the cache private unless there is a very unusual and well-reviewed reason not to.

3. Configure durability and security based on environment

For production-style Redis deployments, decide on:

  • automatic failover and Multi-AZ
  • at-rest and in-transit encryption
  • snapshot retention and maintenance windows
  • authentication or auth token strategy where supported

For lower environments, document when a cheaper single-node configuration is acceptable.

4. Add reusable parameters and outputs

Parameterize only the settings that truly vary between environments, such as node type, subnet IDs, or snapshot retention.

Export outputs that other stacks need, typically:

  • primary or configuration endpoint
  • reader endpoint when applicable
  • security group or subnet group identifiers only if downstream stacks genuinely depend on them
5. Validate the stack change before rollout

Before deployment:

  • run template validation
  • inspect whether changes replace the cluster or replication group
  • review security group exposure and encryption settings
  • confirm maintenance, backup, and scaling choices match the application's recovery expectations
Examples
Example 1: Redis replication group with private networking
Parameters:
  CacheNodeType:
    Type: String
    Default: cache.t4g.small

Resources:
  CacheSubnetGroup:
    Type: AWS::ElastiCache::SubnetGroup
    Properties:
      Description: Private subnets for the cache tier
      SubnetIds: !Ref PrivateSubnetIds

  CacheSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Application access to Redis
      VpcId: !Ref VpcId

  RedisReplicationGroup:
    Type: AWS::ElastiCache::ReplicationGroup
    Properties:
      ReplicationGroupDescription: Application Redis cluster
      Engine: redis
      CacheNodeType: !Ref CacheNodeType
      NumNodeGroups: 1
      ReplicasPerNodeGroup: 1
      AutomaticFailoverEnabled: true
      MultiAZEnabled: true
      CacheSubnetGroupName: !Ref CacheSubnetGroup
      SecurityGroupIds:
        - !Ref CacheSecurityGroup
      TransitEncryptionEnabled: true
      AtRestEncryptionEnabled: true
Example 2: Export an endpoint for another stack
Outputs:
  RedisPrimaryEndpoint:
    Description: Primary endpoint used by the application stack
    Value: !GetAtt RedisReplicationGroup.PrimaryEndPoint.Address
    Export:
      Name: !Sub "${AWS::StackName}-RedisPrimaryEndpoint"

Keep outputs small and stable so consumer stacks do not break unnecessarily.

Best Practices
  • Prefer replication groups over single-node Redis for production systems.
  • Put caches in private subnets and restrict ingress to known application security groups.
  • Turn on encryption and snapshots unless there is a documented reason not to.
  • Review replacement risk before changing engine version, cluster mode, or subnet design.
  • Use parameters for environment-specific sizing, not for every possible knob.
  • Keep deep template variants in references/examples.md instead of expanding the root skill endlessly.
Constraints and Warnings
  • Some ElastiCache changes cause replacement or data loss if applied carelessly.
  • NAT, subnet, and routing mistakes can make the cache unreachable even when the stack succeeds.
  • Multi-AZ, replicas, and larger node types can change cost significantly.
  • Cache endpoints, encryption support, and auth features vary by engine and version.
  • Snapshot and maintenance windows must align with the application's recovery and deployment practices.
References
  • references/examples.md
  • references/reference.md
Related Skills
  • aws-cloudformation-vpc
  • aws-cloudformation-security
  • aws-cloudformation-ecs
  • aws-cloudformation-lambda
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。