I tried applying VPC Encryption Controls across the entire Organization at once using declarative policies
This page has been translated by machine translation. View original
Introduction
On July 6, 2026, AWS Organizations Declarative Policies became capable of bulk-applying VPC Encryption Controls. Application at the Organization/OU/account level is supported.
The main changes are as follows.
| Item | Before | This time |
|---|---|---|
| Configuration unit | Individual per VPC | Bulk at Organization/OU/account level |
| Management method | VPC owner makes individual API calls | Applied via declarative policy from management account |
| Application to new VPCs | Manually enabled each time | Automatically applied to VPCs within policy scope |
| Change permissions | VPC owner can change freely | Owner changes not allowed under declarative policy management |
This time, we created and attached a declarative policy from the management account, and verified bulk transition to enforce, blocking of changes by VPC owners, rejection of creation of unsupported resources, exclusion settings, and rollback after policy detachment.
Verification Details
Verification Environment
This is a configuration where a declarative policy is created from the management account in an AWS Organizations environment and attached to a member account.
VPC Encryption Controls incurs charges per VPC. In the Tokyo region (ap-northeast-1) used this time, it is $0.21/hour per non-empty VPC (VPC with network interfaces) with monitor or enforce mode enabled. This amounts to approximately $151.20/VPC per month on a 30-day basis. There are no additional charges for the declarative policy itself.
Verification began with the following VPCs existing in the member account.
vpc-0aa1111111111111a(192.168.0.0/18, Name: ec2-warp-unified, with IPv6, with Egress Only Internet Gateway)vpc-0bb2222222222222b(172.31.0.0/16, default VPC)
Creating and Applying Declarative Policy
First, enable the DECLARATIVE_POLICY_EC2 policy type in the management account.
aws organizations enable-policy-type \
--policy-type DECLARATIVE_POLICY_EC2 \
--root-id r-xxxx
Create a declarative policy that applies VPC Encryption Controls in attempt_enforce mode. This specification causes VPCs that meet the conditions to transition to enforce mode. The excluded resources are Internet Gateway and NAT Gateway.
aws organizations create-policy \
--name "VPCEncryptionEnforce" \
--type DECLARATIVE_POLICY_EC2 \
--content '{
"ec2_attributes": {
"vpc_encryption_control": {
"mode": {
"@@assign": "attempt_enforce"
},
"exclusions": {
"@@assign": ["internet_gateway", "nat_gateway"]
}
}
}
}'
Attach the created policy (p-abc1234567) to the member account.
aws organizations attach-policy \
--policy-id p-abc1234567 \
--target-id 111122223333
Checking Status After Application
Immediately after attaching the policy, we checked the account-level status of the member account.
aws ec2 describe-account-vpc-encryption-control
{
"AccountVpcEncryptionControl": {
"State": "transitions-in-progress",
"Mode": "attempt-enforce",
"Exclusions": {
"InternetGateway": "enabled",
"NatGateway": "enabled",
"EgressOnlyInternetGateway": "disabled",
"VirtualPrivateGateway": "disabled",
"VpcPeering": "disabled",
"Lambda": "disabled",
"VpcLattice": "disabled",
"ElasticFileSystem": "disabled"
},
"ManagedBy": "declarative-policy",
"LastUpdateTimestamp": "2026-07-10T16:13:07.009000+00:00"
}
}
ManagedBy has changed to declarative-policy, and the specified exclusion settings (InternetGateway, NatGateway) are reflected. The State is transitions-in-progress, indicating that the transition of existing VPCs to enforce state is in progress.
Checking the VPC-level status revealed different states for the two VPCs.
vpc-0bb2222222222222b(default VPC):enforce-in-progress— Although an Internet Gateway exists, it is included in the exclusion settings, so transitioning to enforcevpc-0aa1111111111111a(ec2-warp-unified):enforce-failed— Cannot transition because Egress Only Internet Gateway is not included in the exclusion settings
Verifying Encryption Enforcement Behavior
The following tests use a newly created VPC (vpc-0cc3333333333333c).
Automatic Application to New VPCs
When a new VPC was created, enforce mode was already applied at the time of the creation response.
aws ec2 create-vpc --cidr-block 10.99.0.0/24
You can confirm in the EncryptionControl field of the creation response that the State is available.
Response when creating a new VPC (EncryptionControl section)
{
"EncryptionControl": {
"VpcId": "vpc-0cc3333333333333c",
"VpcEncryptionControlId": "vpcec-0ee5555555555555e",
"Mode": "enforce",
"State": "available",
"StateMessage": "succeeded",
"ResourceExclusions": {
"InternetGateway": {"State": "enabled", "StateMessage": "succeeded"},
"NatGateway": {"State": "enabled", "StateMessage": "succeeded"},
"EgressOnlyInternetGateway": {"State": "disabled"},
"VirtualPrivateGateway": {"State": "disabled"},
"VpcPeering": {"State": "disabled"},
"Lambda": {"State": "disabled"},
"VpcLattice": {"State": "disabled"},
"ElasticFileSystem": {"State": "disabled"}
}
}
}
While transitioning existing VPCs to enforce took more than 10 minutes, new VPCs returned State: available at creation time, with enforce immediately active.
Blocking Changes to Encryption Control by VPC Owner
Under declarative policy management, any attempt by the VPC owner to delete or change the mode of Encryption Control is rejected with OperationNotPermitted.
Deletion attempt:
aws ec2 delete-vpc-encryption-control \
--vpc-encryption-control-id vpcec-0ee5555555555555e
An error occurred (OperationNotPermitted) when calling the DeleteVpcEncryptionControl operation:
Configuring encryption-control is not allowed. VPC encryption controls is currently managed at the declarative-policy level.
Mode change attempt:
aws ec2 modify-vpc-encryption-control \
--vpc-encryption-control-id vpcec-0ee5555555555555e \
--mode monitor
Similarly rejected with OperationNotPermitted.
Blocking of Encryption-Unsupported Resources (Egress Only Internet Gateway)
When attempting to create an Egress Only Internet Gateway in a VPC in enforce mode, an error is returned immediately.
aws ec2 create-egress-only-internet-gateway \
--vpc-id vpc-0cc3333333333333c
An error occurred (DisallowedByVpcEncryptionControl) when calling the CreateEgressOnlyInternetGateway operation:
egress-only internet gateway cannot be created when VPC encryption is enforced
Creation was synchronously blocked with a dedicated error code DisallowedByVpcEncryptionControl.
Blocking of Encryption-Unsupported Resources (VPC Peering)
In this configuration, VPC Peering, unlike Egress Only Internet Gateway, did not result in a synchronous error; instead, it transitioned asynchronously to failed after creation.
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-0cc3333333333333c \
--peer-vpc-id vpc-0bb2222222222222b
The request itself was accepted and the Peering Connection (pcx-0dd4444444444444d) was created. However, checking the status showed it had automatically transitioned to failed.
{
"Status": {
"Code": "failed",
"Message": "Failed due to incorrect VPC-ID, Account ID, overlapping CIDR range, or VPC Encryption Control posture"
}
}
The two blocking patterns are summarized as follows.
| Resource | Failure timing | Error code/state |
|---|---|---|
| Egress Only IGW | Synchronous (immediate API error) | DisallowedByVpcEncryptionControl |
| VPC Peering (this configuration) | Asynchronous (failed transition after creation) | Status: failed |
Note that the VPC Peering failed message is a generic one that lists multiple failure causes. Since there were no issues with the VPC ID, account ID, or CIDR in this case, Encryption Control posture was determined to be the cause. If VPC Peering creation is automated, status verification after creation is necessary.
Verifying Exclusion Settings Behavior (Internet Gateway)
aws ec2 create-internet-gateway
# → igw-0aa8888888888888a
aws ec2 attach-internet-gateway \
--internet-gateway-id igw-0aa8888888888888a \
--vpc-id vpc-0cc3333333333333c
Both creation and attachment of the Internet Gateway succeeded.
Rollback After Policy Detachment
When the policy is detached, the account-level settings are rolled back to the state before application. In this verification, VPC-level Encryption Controls were not automatically deleted; deleting them required per-VPC operations.
aws organizations detach-policy \
--policy-id p-abc1234567 \
--target-id 111122223333
Account-level status after detachment:
{
"AccountVpcEncryptionControl": {
"State": "transitions-successful",
"Mode": "unmanaged",
"ManagedBy": "account"
}
}
ManagedBy has returned to account, and Mode has become unmanaged.
VPC-level Encryption Control required manual deletion.
aws ec2 delete-vpc-encryption-control \
--vpc-encryption-control-id vpcec-0bb7777777777777b
# → deleting
aws ec2 delete-vpc-encryption-control \
--vpc-encryption-control-id vpcec-0ee5555555555555e
# → deleting
Summary
We confirmed that AWS Organizations declarative policies enable centralized management of VPC Encryption Controls at the Organization/OU/account level. Although the policy specification is attempt_enforce, VPCs that meet the conditions transition to enforce state at the VPC level. Changes to Encryption Control by VPC owners were also blocked.
However, non-empty VPCs with Encryption Controls enabled incur charges per VPC. In the Tokyo region, this is $0.21/hour, approximately $151.20/VPC per month on a 30-day basis. Rather than a feature to be enabled as standard across all environments, it seems better to view this as a feature to consider adopting in environments with clear governance requirements.
When strict compliance requirements or internal guidelines necessitate enforcing VPC Encryption Controls at the organizational level rather than leaving it to individual accounts, this becomes a viable option. Since the number of target VPCs directly affects costs, we recommend clarifying the scope and requirements before use.
Reference Links
