一、背景
现有数据库某字段保存有大量文本，现在需要对多条数据进行全文检索，以确定哪些条数据包含关键字。此时可使用MySQL全文检索。在搜索之前，需要为响应的字段增加索引，这一步会产生较大的系统资源消耗，请谨慎操作。
使用方法如下文。
一、背景
CORS的全称是Cross-Origin Resource Sharing，是浏览器跨站访问的技术规范。在使用S3静态托管时候，如果网页中的调用使用了CORS，那么需要为S3和CloudFront增加对应策略，才可以正常加载内容。
本文介绍了搭建一个纯静态网站过程中，如何使用S3非公开桶提供存储，使用CloudFront+OAI对外发布，并使用CloudFront Function进行默认页跳转。
一、背景-使用S3直接提供静态网站的挑战
S3提供静态网站Hosting的方式，是官方使用S3提供网站托管的推荐主要方式，此时是直接对外暴露S3存储桶的，也就是必须将S3存储桶设置为Public可见。如果本AWS账户内仅有一个S3存储并配置为公开，可能问题不大。但是对于大部分企业用户，尤其是混合多种业务数据管理的场景、一个账号内有许多存储桶，将存储桶设置为Public会遇到安全挑战的问题。
一、背景
Amazon Bedrock Inference Profile功能是2024年底推出的一项功能，在诞生之初，主要用于实现跨Region推理，而通过给Profile增加Tag的方式，即可实现费用追踪。
一、背景
在配置邮件客户端的过程中，连接邮箱时除了输入域名、用户名、密码之外，通常需要手工填写收发邮件的服务器地址。此时如果打开了Auto Discover也就是自动发现功能，就能无需手工输入，邮件客户端将自动识别服务器地址，大大简化了配置过程。目前电脑上在用的邮件客户端、手机上的邮件客户端都具备自动发现功能。
当使用Amazon Workmail提供邮箱服务的时候，默认是不开启Auto Discover功能的，需要手工配置。本文介绍如何配置。
本文介绍如何为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 对多用户并行开发的权限管理方式之一，是可以与企业现有单点认证系统对接，然后每个企业目录的用户就可以直接对应到一个SageMaker Studio内的Notebook。在这种对接方式下，SageMaker Studio首先与IAM Identity Center（IdC）集成，然后使用 External Source 连接外部的Identity Source，即可实现第三方SSO对接。
在一些信息系统审计中，可能会被要求提交“S3存储是一个被动式系统”、“S3不会主动向外发起网络连接”、“S3不会执行存储的可执行文件”等证明资料。建议通过S3合规性最佳实践进行系统的解答。
本文展示了一个MCP Server和Client的运行交互过程，通过Step-by-step的打印日志，帮助理解MCP是如何工作的。本文引用的代码参考文中的Github链接。
一、背景
在上一篇博客 使用VPC Traffic Mirror功能进行流量审计 中，我们介绍了使用VPC Traffic Mirror采集7层访问日志，不过采集架构局限在单VPC、单EC2。
那么如何构建一个跨VPC、多VPC、跨账号专门的日志采集架构？本文解答这一需求的设计。
一、背景
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）将客户的数据重新加密，
使用户无法正常访问，并向要求受害者在七天内支付赎金，
否则将永久删除所有加密文件。
这篇文章对整个攻击事件过程描述的比较模糊，文中提到“勒索组织首先获取了受害者的亚马逊账户凭证”，但转而又提到“此次攻击没有利用任何系统漏洞，而是利用了亚马逊云服务本身的安全机制”。这两句前后矛盾的表述让许多人感到困惑，并担心自身系统安全。
为此，AWS官方也有一篇博客针对类似攻击事件给出了一些信息，英文原文在这里。基于这两篇文章，本文介绍下类似勒索攻击的由来，以及类似的防护方法。
一、背景
在一些对数据安全有较高要求的场景中，需要对S3上的数据进行加密。有时候可能会遇到以下需求：
- 合规要求，必须加密
- 强度要高，例如AES256
- 加密要简单，最好是对称密钥，加密和解密都是同一个密码
- 与IDC、多云等兼容性问题，不能使用AWS KMS服务来管理密钥，用户自管理密钥
- 不希望编写加密代码
- 不希望应用层承担加密运算的开销
在以上情况下，可使用S3服务的SSE-C功能来满足以上加密需求。
此时可能有同学有疑问，在创建S3存储桶界面上选择加密算法的位置，并没有SSE-C加密方式的选项，那么它是如何运作的？这要从S3的几种加密方式说起。
注：由于Amazon Bedrock服务已经提供了完全托管的Serverless Bedrock模型，因此您无须再通过导入模型的方式运行DeepSeek R1模型了。
如果您希望了解导入自定义模型的操作过程和方式，那么您可以继续阅读本篇。
一、背景
1、什么是Ollama
Ollama是一个在本地运行大语言模型（LLM）的开源框架，提供了针对Windows、Linux、MacOS预先封装好的一系列模型，可一键方式在开发者本地（例如笔记本）运行大模型，大大简化了体验和开发的过程。Ollma将不同模型封装到自定义的容器架构内，并针对不同硬件架构做好了适配，可在包括Apple M1处理器在内的多种机型上运行。
一、背景
在使用AWS Config服务开启内置规则、对本账号进行诊断的时候，可能会发现有一条规则是提示S3存储桶的Bucket Key功能没有打开，这会带来成本影响。这个选项是什么意思呢？本文讲解如何启用这个选项。
S3存储桶的加密方式有SSE-S3、KMS、Dual Layer KMS三种。在这三种加密机制使用场景下，有一个名为Bucket Key的功能，与加密场景密切相关。当不使用Bucket Key时候，每次对S3存储桶的读写调用都需要访问KMS，这样带来KMS的大量请求费用。当开启Bucket Key的功能后，由S3服务管理一个短期有效的密钥并在S3服务层面缓存，日常调用存储桶的读写，将不需要访问KMS，而是使用这个Bucket key。当Bucket Key过期后，自动与KMS服务交互重新生成新的Key。由此，即可节约99%的KMS费用。
在创建S3存储桶时候，页面会询问存储加密类型，以及是否打开Bucket Key。如果本账号已经有大量的存储桶，且分别使用了不同的加密规则，但是一些存储桶创建时候没有打开Bucket Key功能，那么如何快速为所有存储桶打开Bucket Key？在AWS控制台上一个个点击存储桶的过程会非常麻烦没有效率，因此推荐编写Python脚本完成这个配置。
另外在编写脚本的过程中可发现，这几个加密选项在AWS控制台上以及API上看上去的名字是不同的，API层面的标签如下：
- 控制台网页上的SSE-S3: 在API层面的标签是
AES256，也就是默认使用的加密算法 - 控制台网页上的SSE-KMS：在API层面的标签是
aws:kms，表示密钥由KMS管理 - 控制台网页上的Dual-Layer SSE-KMS：在在API层面的标签是
aws:kms:dsse，表示双层KMS级别的加密
这样就可以把本存储桶的加密类型和API调用类型对应起来了。
一、背景
Python语言被广泛使用，在数据处理、机器学习等领域有统治地位。Python作为解释型语言，其主要优势就是跨平台、代码简洁，然而这也带来负面的影响，那就是解释型语言的运行效率低。因此，针对Python语言的编译运行有很多解决方案，其中一种是Cython。Cython可以将Python代码转换为C语言并编译为动态链接库，然后Python代码中可直接调用这些动态链接库。如此虽然提升了速度，但也带来一系列问题。一是编译后的动态链接库失去了跨平台特性，每个硬件架构平台（如X86_64和ARM）、不同操作系统版本（Glibc版本差异）的动态链接库是不通用的，都需要重新编译。二是要达到和C相近的性能，Python代码需要做优化才可以完全按C语言编译执行，由此带来代码改动的工作量，即需要在代码中按照Cython语言的要求对变量添加类型声明。如果不做这些优化，那么使用Cython比直接运行原Python效率提升有限，有提升但没有上升一个数量级，远不及C的运行速度。
虽然有着这两点缺点，不过使用Cython还有一个额外的收获，那就是编译后的动态链接库可封装代码，在一定程度上起到保护源代码的作用，让原始代码不再直接可读。由于反编译C代码动态链接库的门槛较高，因此这个方式在一定程度上提升了获取源代码的难度，实现了比较初步的源代码保护。因此本文不探讨Cython编译后的加速效果，而是介绍编译后保护代码明文的效果。
本文即讲述这种场景。准备一个访问存储桶的代码作为示例，假设这个业务场景需要列存储桶目录，并进行了一定的业务逻辑处理例如过滤特定文件并显示，然后将其命名为file_access.py，其中包含函数list_my_file。假设这个程序需要被保护，稍后将被编译为file_access.so。在运行环境中，只需要import引用这个动态链接库，即可调用其中的函数。现在开始。
ASR的全称是Automated Speech Recognition，通俗的说就是语音输入识别。TTS的全称是Text to Speech，也就是从文本到语音的人工合成。在AWS这两个场景分别对应的是Amazon Transcribe服务，以及Amazon Polly服务。
本文的Demo演示ASR功能本机mic输入，以及TTS通过本机扬声器播放合成的语音。
注意：Cloud9宣布了将在2024年7月之后不再为新账号提供服务，原有AWS账号可继续使用。请参考本文末尾的官网说明。
一、背景
使用Cloud9时候经常遇到一个问题，创建Cloud9开发环境的是另外的IAM User或者是联合登陆的IAM Role，在环境创建好之后使用另外的账户去操作Cloud9，在本Region的Cloud9界面下的My environment下是看不到别人创建的Cloud9的。由此必须切换到创建Cloud9的身份重新登陆AWS控制台。这样使用非常不便。另外，如果创建Cloud9的是一个IAM Role，可能无法直接登陆。
此时，可以通过CLI为现有的Cloud9增加新的权限，即可让其他人有权限使用。
本文基于Github上作者jief123的方案编写。Github官方文档方案采用CDK形式部署，而本文是描述如何手工部署。
一、背景
Bedrock服务提供的多种大模型使用中需要遵循各模型原厂的合规要求。为了实现网络加速，可在全球统一配置一个Bedrock流量入口，为全球多地区的应用加速。
整个架构的主要步骤如下：
- Bedrock的模型调用选择us-west-2区域
- 配置CloudFront加速加速点，仅使用北美和欧洲的POP节点
- 在CloudFront特定的us-east-1区域的Lambda控制台配置Lambda@Edge，然后关联到CloudFront
- 修改代码重定向流量到CloudFront发布点