PCMAN的技术博客 – 2025 仰望星空，脚踏实地 – 本站是个人兴趣学习笔记而非AWS官方博客，如用于商业生产环境请自行判断风险、谨慎把握

使用Amazon Bedrock Inference Profile结合Tag实现模型调用费用分拆

一、背景

Amazon Bedrock Inference Profile功能是2024年底推出的一项功能，在诞生之初，主要用于实现跨Region推理，而通过给Profile增加Tag的方式，即可实现费用追踪。

过去，在应用程序代码中调用模型，通常是直接指定模型的版本，例如anthropic.claude-3-5-sonnet-20240620-v1:0:200k。这样的模型调用没将只发送到当前目标Region（单一Region）。如果此时并发过大，本Region的Token Limit遇到上限，那么将触发限流。使用Inference Profile功能即可解决这一问题。Inference Profile预定义了一组模型推理节点，例如使用US Anthropic Claude 3.5 Sonnet这个Profile的话，将包含一组2个推理Region，即us-east-1 and us-west-2。同样，使用以EU开头的Profile，就是在欧洲的几个Region之间分配推理流量。这样，就通过多个Region的GPU容量，显著提升了推理能力。这一过程对用户而言是透明的，应用程序无需调整，只需要使用Inference Profile即可。

Inference Profile除了用于多Region推理外，还可以实现成本分配。Inference Profile有两种类型，分别是用于多Region推理的系统类型即默认的Profile，还有自定义的名为应用程序类型。使用时，为不同的应用程序创建自己专有的应用程序类型的Inference Profile，创建时候需要以某个系统类型的Profile为基准，然后创建自定义类型。创建成功后，在Inference Profile上绑定不同的Tag标签，这样即可实现Inference Profile与应用的映射关系。

为Amazon Workmail配置自动发现Auto Discover

一、背景

在配置邮件客户端的过程中，连接邮箱时除了输入域名、用户名、密码之外，通常需要手工填写收发邮件的服务器地址。此时如果打开了Auto Discover也就是自动发现功能，就能无需手工输入，邮件客户端将自动识别服务器地址，大大简化了配置过程。目前电脑上在用的邮件客户端、手机上的邮件客户端都具备自动发现功能。

当使用Amazon Workmail提供邮箱服务的时候，默认是不开启Auto Discover功能的，需要手工配置。本文介绍如何配置。

如何为Amazon Workmail启用MFA双因素认证

本文介绍如何为Amazon Workmail启用IAM Identity Center并开启MFA多因素认证。

一、背景

Amazon Workmail邮件系统自身有内部的目录服务，可用于用户数量较少的快速部署和使用。在此时登录界面上是不支持配置MFA的。即便点击Workmail的设置图标，在其中也无法找到开启MFA的选项。这是由于Amazon Workmail内置的目录认证服务是不支持MFA的。

为了开启MFA，需要将Amazon Workmail配置为使用IAM Identity Center服务（以前叫做AWS Single Sign-On即SSO，以下简称IdC服务），并在IdC服务中管理用户和分组。此时在IdC服务中，可以设置用户第一次登录时候必须强制绑定MFA，即可满足安全合规要求。IdC服务支持主流的软件MFA，例如Microsoft Authenticator，Google Authenticator等手机APP，也支持硬件形式的USB Token。

下面开始配置。

SageMaker Studio SSO 效果演示

SageMaker Studio 对多用户并行开发的权限管理方式之一，是可以与企业现有单点认证系统对接，然后每个企业目录的用户就可以直接对应到一个SageMaker Studio内的Notebook。在这种对接方式下，SageMaker Studio首先与IAM Identity Center（IdC）集成，然后使用 External Source 连接外部的Identity Source，即可实现第三方SSO对接。

关于S3系统是否满足“被动式”系统以及无法运行可执行文件的合规性问题描述

在一些信息系统审计中，可能会被要求提交“S3存储是一个被动式系统”、“S3不会主动向外发起网络连接”、“S3不会执行存储的可执行文件”等证明资料。建议通过S3合规性最佳实践进行系统的解答。

MCP系列：启动你的第一个MCP Server并与之交互

本文展示了一个MCP Server和Client的运行交互过程，通过Step-by-step的打印日志，帮助理解MCP是如何工作的。本文引用的代码参考文中的Github链接。

一、背景

1、为何出现了MCP

MCP的全程是Model Context Protocol (MCP)，是由Anthropic公司发起的开源项目，旨在为大模型和第三方工具调用定义一个规范的、标准的接口，便于更多开发者编写的工具代码能够兼容通用。

使用NLB或GWLB搭建多VPC的Traffic Mirror流量采集架构

一、背景

在上一篇博客《使用VPC Traffic Mirror功能进行流量审计》中，我们介绍了使用VPC Traffic Mirror采集7层访问日志，不过采集架构局限在单VPC、单EC2。

那么如何构建一个跨VPC、多VPC、跨账号专门的日志采集架构？本文解答这一需求的设计。

使用VPC Traffic Mirror功能进行流量审计

一、背景

1、使用Traffic Mirror的场景

对于简单的网络流量采集需求，可以使用VPC Flowlog功能，之前这篇博客介绍了VPC Flowlog的使用。不过VPC Flowlog也有局限，主要是仅记录OSI模型的第四层的日志信息，也就是所谓的“五元组”，即源地址、源端口、目标地址、目标端口、协议这五要素，很多时候不能满足日志需求。

如果需求进一步增加要求如下日志能力：

7层流量采集，记录域名、HTTP header等
旁路方式，不影响流量
相对低成本
不希望使用复杂的Network Firewall或者第三方NGFW+Gateway Load Balancer方案

以上需求场景，适合使用VPC Traffic Mirror实现。

针对S3存储的勒索攻击的防护以及关闭SSE-C的方法

一、针对S3存储的勒索攻击事件背景

近期有一片文章《亚马逊安全机制被用于勒索攻击，全球数千家机构已成为攻击目标》，原文在这里。引用部分文字如下：

据报道，勒索组织已经开始加密全球数千家机构在亚马逊云存储的数据。
与传统的勒索软件攻击不同，此次攻击没有利用任何系统漏洞，
而是利用了亚马逊云服务本身的安全机制，制造了一个几乎无法破解的困境，
迫使受害者不得不选择支付赎金。

勒索组织首先获取了受害者的亚马逊账户凭证，
这些凭证具有读取存储数据和写入加密工具的权限。
随后，他们利用亚马逊的服务器端加密工具（SSE-C）将客户的数据重新加密，
使用户无法正常访问，并向要求受害者在七天内支付赎金，
否则将永久删除所有加密文件。

这篇文章对整个攻击事件过程描述的比较模糊，文中提到“勒索组织首先获取了受害者的亚马逊账户凭证”，但转而又提到“此次攻击没有利用任何系统漏洞，而是利用了亚马逊云服务本身的安全机制”。这两句前后矛盾的表述让许多人感到困惑，并担心自身系统安全。

为此，AWS官方也有一篇博客针对类似攻击事件给出了一些信息，英文原文在这里。基于这两篇文章，本文介绍下类似勒索攻击的由来，以及类似的防护方法。

使用S3存储的SSE-C方式加密数据

一、背景

在一些对数据安全有较高要求的场景中，需要对S3上的数据进行加密。有时候可能会遇到以下需求：

合规要求，必须加密
强度要高，例如AES256
加密要简单，最好是对称密钥，加密和解密都是同一个密码
与IDC、多云等兼容性问题，不能使用AWS KMS服务来管理密钥，用户自管理密钥
不希望编写加密代码
不希望应用层承担加密运算的开销

在以上情况下，可使用S3服务的SSE-C功能来满足以上加密需求。

此时可能有同学有疑问，在创建S3存储桶界面上选择加密算法的位置，并没有SSE-C加密方式的选项，那么它是如何运作的？这要从S3的几种加密方式说起。

在Bedrock上以导入自定义模型的方式部署DeepSeek R1模型蒸馏的Llama70b模型

本文基于亚马逊云开发者微信公众号这篇文章的内容编写，对相关服务增加了介绍，操作过程做了截图，并汇总了冷启动、费用等问题。有疑问请参考原文。

一、背景

在前一篇博客中介绍了使用Ollama在MacOS本机或者EC2 G系列实例上快速启动DeepSeek R1蒸馏后的1.5b模型/32b（均基于Qwen蒸馏而来）。在生产环境中，单机部署只能解决时效性要求不高的批量离线推理，对于在线的实时推理场景，单机部署是不能满足高可靠要求和并发要求的，一但单机遇到故障，整个应用就无法访问了。因此此时就需要在Bedrock上托管的方式部署。

Bedrock支持自定义模型导入功能。截至2025年1月Bedrock导入自定义模型仅支持Llama架构、不支持Qwen架构，因此导入DeepSeek R1模型蒸馏的一组模型时候，无法选择基于Qwen架构的32B参数的版本。可用的将是8B和70B参数的版本（基于Llama）。本文选择70B参数的版本，通过Custom Model Import功能在Bedrock上部署。

使用Ollama在MacOS本机和AWS EC2 G系列机型上运行DeepSeek R1蒸馏模型

一、背景

1、什么是Ollama

Ollama是一个在本地运行大语言模型（LLM）的开源框架，提供了针对Windows、Linux、MacOS预先封装好的一系列模型，可一键方式在开发者本地（例如笔记本）运行大模型，大大简化了体验和开发的过程。Ollma将不同模型封装到自定义的容器架构内，并针对不同硬件架构做好了适配，可在包括Apple M1处理器在内的多种机型上运行。

通过Python脚本设置S3存储桶的Bucket Key

一、背景

在使用AWS Config服务开启内置规则、对本账号进行诊断的时候，可能会发现有一条规则是提示S3存储桶的Bucket Key功能没有打开，这会带来成本影响。这个选项是什么意思呢？本文讲解如何启用这个选项。

使用Cython编译运行保护Python源代码

一、背景

Python语言被广泛使用，在数据处理、机器学习等领域有统治地位。Python作为解释型语言，其主要优势就是跨平台、代码简洁，然而这也带来负面的影响，那就是解释型语言的运行效率低。因此，针对Python语言的编译运行有很多解决方案，其中一种是Cython。Cython可以将Python代码转换为C语言并编译为动态链接库，然后Python代码中可直接调用这些动态链接库。如此虽然提升了速度，但也带来一系列问题。一是编译后的动态链接库失去了跨平台特性，每个硬件架构平台（如X86_64和ARM）、不同操作系统版本（Glibc版本差异）的动态链接库是不通用的，都需要重新编译。二是要达到和C相近的性能，Python代码需要做优化才可以完全按C语言编译执行，由此带来代码改动的工作量，即需要在代码中按照Cython语言的要求对变量添加类型声明。如果不做这些优化，那么使用Cython比直接运行原Python效率提升有限，有提升但没有上升一个数量级，远不及C的运行速度。

虽然有着这两点缺点，不过使用Cython还有一个额外的收获，那就是编译后的动态链接库可封装代码，在一定程度上起到保护源代码的作用，让原始代码不再直接可读。由于反编译C代码动态链接库的门槛较高，因此这个方式在一定程度上提升了获取源代码的难度，实现了比较初步的源代码保护。因此本文不探讨Cython编译后的加速效果，而是介绍编译后保护代码明文的效果。

使用AWS平台上的ASR（Transcribe）和TTS（Polly）服务

ASR的全称是Automated Speech Recognition，通俗的说就是语音输入识别。TTS的全称是Text to Speech，也就是从文本到语音的人工合成。在AWS这两个场景分别对应的是Amazon Transcribe服务，以及Amazon Polly服务。

本文的Demo演示ASR功能本机mic输入，以及TTS通过本机扬声器播放合成的语音。

S	M	T	W	T	F	S
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31